Reprise du message précédent :
Moi je trouve ce projet très interressant et te souhaite que de la réussite !

Et comment tu fais sans prendre les unités une par une ? Tu vérifies toutes les cases qui sont suceptibles d'être la position d'une unité ennemie pouvant attaquer le roi ? ...........C'est pas con ça, c'est beaucoup plus rapide pour l'ordi. Mouais je vais faire ça.

Bah tu vois quand tu veux    

Merci. Pour l'instant j'arrive très bien les trucs que je pensais dûr à faire, et je galère pour les trucs qui paraissent tout con

Bon, j'avoue, t'es pas si bête si bête que ça.

Un proverbe chinois dit : "donnez une rose à une vache elle vous produira une bouse"

LOL. Mortel. Bon revenons à nos moutons. J'ai encore un problème à la con. Avec ce déclo :

Quand je donne un ordre à une unité, il est exécuté deux fois au lieu d'une. Comprends po.

Oups dsl.

Ah ben j'ai trouvé. Je galérais hier soir avec ça et en deux min je trouve today. Qqun peut-il m'expliquer pourquoi l'action pause unit déclenche sur putin de trigger des mes @#-/*$^ ????????????????

Pause unit interrompt l'ordre mais quand tu unpause l'unité si l'ordre n'est pas fini elle le reprend.
Donc tu doit ordonner à l'unité se stopper avant de la mettre en pause

Ouais ya la commande issue order unit to Stop ou qqch comme ça...

lol bin c'est celle la :  call IssueImmediateOrder( piece, "stop" ) (l.55)
 
Je suis kan meme obligé de mettre l'unité en pause

Un autre problème s'était posé (j'ai trouvé la solution mais je pense que ça pourrait vous intéresser). Comment faire pour qu'un joueur déplace un pion, une fois que celui-ci a fini son déplacement (d'une durée très variable), on passe à la suite. (changement de l'orientation de l'unité et permettre à l'autre joueur de jouer)
Solution : une région qui bouge.

Bon, on a vu que vérifier s'il le roi était en échec ou non, était assez facile à faire en fin de compte... maintenant, comment faire pour voir s'il y a échec et mat ou pat ?  
 
mat : un joueur gagne
pat : un joueur ne peut effectuer de déplacement sans mettre en échec le roi, alors que celui-ci n'est pas en échec --> pareil que pour mat sauf que le roi n'est pas en échec
 
Pour l'instant, la seule solution que je vois, est de tester toutes les combinaisons de déplacement possibles, jusqu'à ce que l'on trouve un déplacement possible, ou aucun. Ca ne me paraît pas insurmontable à faire, mais j'ai peur que ça fasse beaucoup souffrir le processeur. J'ai donc deux questions : est-ce qu'à votre avis ça fera effectivement souffrir le processeur ? Est-ce que vous voyez une meilleure solution ?
 
 
Pour éclaircir tout le monde :
 
A chaque tentative de déplacement on regarde :
1) s'il le déplacement est théoriquement possible. Si non on l'annule.
2) si cela met en échec le roi. Si oui on annule le déplacement.
 
A chaque fin de déplacement, on regarde si le roi ennemi est alors en échec. Qu'il le soit où non, on regarde si le joueur ennemi peut faire un déplacement sans mettre en échec le roi. Si c'est le cas, la partie continue, sinon : si le roi est en échec, échec et mat, sinon pat.
 
Le problème se situe là : "on regarde si le joueur ennemi peut faire un déplacement sans mettre en échec le roi".

L'action pause unit donne un ordre avec le centre de la map pour cible. Plutôt casse-couille comme bug.

et l'unité avait quel ordre avant d'être mise en pause ?
 

Pourquoi ?
L'ordre stop n'est pas plutôt un ordre sans cible ?!

stop est bien un ordre sans cible
Pause unit provoque un ordre avec le centre de la map pour cible.
Essai avec ce trigger :

Si je dois mettre l'unité en pause, c'est que l'ordre stop ne fonctionne pas s'il y a pas de temps d'attente entre le moment où l'unité reçoit l'ordre de bouger.

Ben l'ordre qui exécute le trigger.

Voici ma dernière version du trigger le plus chiant que j'ai jamais eu à réaliser :

    Pour cette fonction, je n'ai pas utilisé la fonction ForGroup (cad le pick every unit) car cela impliquait d'utiliser une variable entière globale. Or, étant donné que quand plusieurs unités sélectionnées reçoivent un ordre en même temps, la valeur de cet entier prend des valeurs inatendues. Ceci du au fait que la fonction est appelée plusieurs fois en un très court laps de temps.
(si je vous ai dit que c'était le trigger le plus chiant que j'ai jamais eu à réaliser, c'est pas pour rien lol)
 
 
    Je suis obligé d'attendre 0,01 seconde avant de désactiver le déclo parce que sinon, quand plusieurs unités sont sélectionnées, et qu'on donne l'ordre au groupe de se déplacer, plusieurs unités ne vont pas exécuter le déclo, et bouger normalement. Le problème est qu'il faut mettre l'unité en pause avant l'attente, sinon elle bouge. Et le problème c'est que du coup, l'action PauseUnit réexécute le déclo.

Bon, le problème du PauseUnit est résolu grâce à un rustinage (je ne sais pas comment faire autrement).  

Un problème persiste : lorsque l'on donne une l'ordre à une pièce de bouger dans une case où elle a le droit, elle reçoit deux fois l'ordre de se déplacer dans cette même case, donc elle ne bouge pas. Or je ne comprends absolument pas pourquoi, puisque l'action "call IssuePointOrderLoc( piece, "move", udg_caseCenter[ind] )" ne provoque pas de réexécution du déclo.
 
Afin de tests, j'ai ajouté la ligne suivante à la fonction IndClickedCase : call DisplayTextToForce( GetPlayersAll(), "orderedPoint = ( " + R2S(X) + " , " + R2S(Y) + " )" ).
 
Voici ce qui s'affiche quand on donne un ordre correct à une pièce :

Si on enlève la ligne "call IssuePointOrderLoc( piece, "move", udg_caseCenter[ind] )", voici ce qui s'affiche :

Je ne comprends vraiment pas pourquoi le trigger se réexécute.  
 
edit : Est-ce que par hasard, après qu'une unité soit enlevée de sa pause, elle ne recevrait pas à nouveau l'ordre de se déplacer ?

   Bon, c'était bien ça le problème. J'ai ajouté un wait après le unpause. Quant à l'histoire du 'movingUnit' (si l'unité reçoit un ordre pendant son déplacement, il doit être annulé, soit redonner à l'unité l'ordre de se déplacer dans la case), ça ne marchait pas, mais j'ai réussi à le résoudre rapidement. Voici donc le trigger final, qui marche bien (enfin ) :

J'ai également du modifier cet autre trigger :

Je ne crois pas que warcraft III ait été prévu à la base pour empêcher les unités de bouger selon les ordres du joueur ^^.

Des fois j'ai l'impression de parler dans le vent avec toi Maximaxou, lis les post précédents et tu verras que j'ai dit que lorsque tu unpause une unité elle reprend l'ordre exécuté.

sinon ca me semblait bizzare ton histoire de centre de la map et il semblerait que lorsque tu fais :
local location Point=GetOrderPointLoc(), ca se passe par référence, ca ne créé pas de point et donc que tu unpause l'unité ton point ne fait plus référence à rien, il a pour coordonnées X/Y (0,0)

Pour créer un point il faut utiliser la fonction Location :

Projet interessant j'espere que tu vas t'en sortir ^^ car sa n'a vraiment pas l'air evident ! Quand ton projet aboutira je testerai.

Non c'est faux puisque j'ai trouvé en relisant les posts précédents, et donc justement le tien. Je l'avais écrit d'ailleurs mais le site a pa voulu ke je post, parce que ça oré été mon 4ieme post en moins de 10 min. Et puis g eu la flemme.
 
Sinon je vois pas l'intérêt d'utiliser la fonction location alors que l'on a le point directement.
 
Et pour pause, jte di de faire ce trigger pour tester :

bah elle se téleporte à l'endroit de l'ordre.
 
Et si il faut utiliser Location, car lorsque tu pause une unité GetOrderPointLoc() ne correspond plus à aucun point

oui et quand tu pause l'unité, elle se télporte au centre de la map...........

Mais lol je te dis que GetOrderPointLoc() ne fait plus référence à aucun point lorsque tu pause une unité, d'où l'utilité de créer un point avec

comme je l'ai expliqué plus haut

Mais ça n'empêchera pas le trigger de s'exécuter... ?