Inscrit le: 21 Fév 2010 Messages: 1785 Sujets: 22 Spécialité en worldedit: La modestie Médailles: 1 (En savoir plus...)
Posté le: 10/08/10 21:52 Sujet du message: Utiliser un filtre pour les actions de trigger
Salut, je viens de me poser la question si on pouvait pas utiliser un filtre à la place d'une action dans un trigger, de la même façon qu'on utilise déjà les conditions.
J'ai fait un test rapide et :
function Init takes nothing returns nothing
local trigger t=CreateTrigger()
call TriggerRegisterEnterRegion(t,REGION,Filter(function Filtre))
endfunction
Cela m'affiche le nom de l'unité quelque soit le résultat du filtre.
Donc, est-ce que quelqu'un a déjà fait ou vu les résultats de tests pour savoir si :
-on peut utiliser toutes les fonctions dans un filtre qu'on pourrait utiliser dans une condition (les 2 sont des boolexpr, à priori),
-le filtre est plus rapide que la condition ou pas?
Après, on ne peut pas utiliser de réponse évènement dans le filtre, mais ça pourrait déjà être pas mal, non? _________________
Inscrit le: 13 Oct 2007 Messages: 994 Sujets: 25 Spécialité en worldedit: Codeur
Posté le: 11/08/10 12:51 Sujet du message:
Beaucoup se sont déjà posés la question. Et oui c'est quelque chose de très utilisé.
Je te résumé en espérant que je ne dise pas de bourde :
- Les filtres sont plus rapide que les actions. Par contre ils ne sont pas lancés dans un autre thread ce qui aura des effets méchants si tu fais des calculs et/ou des actions lourdes dedans.
- Il est impossible d'utiliser Wait et PolledWait ainsi que toutes les actions qui demandent d'attendre (déplacement de caméra, tout ce qui est lié aux cinématiques en général).
- C'est n'est pas très proche de la sémantique d'un filtre de faire des actions dedans. Mais ça il faut voir avec ta conscience. _________________
- La théorie c'est quand rien ne fonctionne mais tout le monde sait pourquoi.
- La pratique c'est quand tout fonctionne mais personne ne sait pourquoi.
- Chez moi la théorie et la pratique sont réunies, rien ne fonctionne et personne ne sait pourquoi.
Inscrit le: 21 Fév 2010 Messages: 1785 Sujets: 22 Spécialité en worldedit: La modestie Médailles: 1 (En savoir plus...)
Posté le: 11/08/10 13:09 Sujet du message:
Okay, merci mais qu'est-ce que tu entends par "lancé dans un autre thread"?
Si je me souviens bien, ExecuteFunc est lancé dans un autre thread, ce qui lui permet d'exécuter des actions "en parallèle" avec la fonction qui l'utilise mais j'aurais besoin de plus d'explications (quels sont les 2 threads dont tu parles dans le cas des filtre, par exemple ^^).
Après, que ce soit plus rapide qu'une action, je m'en doutais un peu, mais si c'est utilisé, c'est que ça doit également être plus rapide qu'une condition ^^.
Pour la sémantique, ça me pose aucun problème, au contraire : la géométrie n'a pas évoluée plus que le jour où l'on a abandonné le sens millénaire qu'on attribuait à une droite. _________________
Inscrit le: 13 Oct 2007 Messages: 994 Sujets: 25 Spécialité en worldedit: Codeur
Posté le: 11/08/10 13:35 Sujet du message:
Oula ça fait longtemps que je n'ai plus touché au Jass ... je viens de dire une bêtise ><
J'ai confondu filtre et condition.
C'est les conditions qui sont plus rapides que les actions et qui sont beaucoup utilisés "comme des actions".
Mais c'est aussi valable pour les filtres. Les filtres et les conditions sont aussi rapide vu que c'est en fin de compte exactement la même chose.
Pour l'histoire du thread :
Pour résumer comment marche Warcraft 3.
Un événement est fait (n'importe lequel). Warcraft 3 regarde les déclencheurs qui répondent à cet événement et il va donc exécuter les conditions pour savoir si le déclencheur doit se lancer ou pas.
Si les conditions du déclencheur sont bonnes, Warcraft place le déclencheur dans une file d'attente. Et il recommencera exactement la même chose au prochain évènement.
En parallèle, il y a un processus qui vient périodiquement regarder cette liste d'attente. Il prend le premier déclencheur de la liste et il l'exécute.
En gros, tu peux voir que si tu mets des choses bien lourdes dans la condition, ça peut mettre un joli bordel dans l'exécution des conditions et les ralentissements se feront sentir "plus vite" que si tu le fais dans les actions.
Les filtres sont des conditions et ils fonctionnent pareil. Dans l'exemple que tu donnes, le filtre sera exécuté en même temps que la condition du déclencheur. C'est donc une condition.
Quand tu utilises un ForGroup par exemple, c'est pareil. Le filtre est exécuté sur toutes les unités du group et tout est mis dans une file d'attente qui sera exécuté en parallèle par un autre processus (c'est pour cette raison que mettre un Wait dans un ForGroup est inutile. Car les actions se font toutes en même temps en parallèle et pas à la suite). _________________
- La théorie c'est quand rien ne fonctionne mais tout le monde sait pourquoi.
- La pratique c'est quand tout fonctionne mais personne ne sait pourquoi.
- Chez moi la théorie et la pratique sont réunies, rien ne fonctionne et personne ne sait pourquoi.
Inscrit le: 21 Fév 2010 Messages: 1785 Sujets: 22 Spécialité en worldedit: La modestie Médailles: 1 (En savoir plus...)
Posté le: 13/08/10 11:06 Sujet du message:
J'ai oublié de te remercier, je comprends mieux comment ça marche maintenant (même si je ne pense pas qu'il soit nécessaire d'avoir tout le temps ça en tête).
Si les filtres sont aussi rapides que les conditions, c'est pas la peine de les utiliser plus que normalement alors ^^. _________________
Inscrit le: 23 Aoû 2007 Messages: 7143 Sujets: 147 Spécialité en worldedit: le troll, le flood, la vulgarité, mon coeur balance Médailles: 2 (En savoir plus...)
Posté le: 14/08/10 18:57 Sujet du message:
C'est du grand Mendes
Warcraft3 ne gère qu'un seul thread à la fois, la callback d'un ForGroup, ou le filtre d'un GroupEnum ne peut avoir qu'une seule instance de lancée à la fois.
On peut mettre un wait dans un ForGroup si je me rappelle bien, le seul "problème" c'est que GetEnumUnit renvoie null après un wait, mais on peut utiliser une local pour pallier à cela.
Par contre je ne sais plus trop si un nouveau thread est lancé ou non, au pire je peux le retester si ca vous intéresse vraiment.
A ce qui parait une condition de trigger est plus rapide qu'une action de trigger, à code équivalent bien sûr, mais j'ai jamais vu un seul benchmark validant ce pseudo fait et j'ai toujours eu la flemme de tester.
Je me permet quand même d'avoir un doute à ce sujet car il était admis qu'une condition de trigger ne lancait pas un nouveau thread, contrairement à une action.
Or je me suis aperçu que c'est totalement faux, il suffit de lancer des grosses loop dans plusieurs conditions de trigger qui cumulées devraient normalement faire atteindre le limit op, et on s'aperçoit qu'on ne l'atteint pas, en effet à chaque évaluation de condition un nouveau thread est lancé.
Non, l'intérêt réel d'une condition par rapport à une action, c'est qu'en cas de destruction de trigger on n'a pas à se soucier de remove les conditions, contrairement aux actions (TriggerClearActions désactive les actions sans les supprimer de la mémoire).
Une condition de trigger ne leak pas.
Attention toutefois à l'emploi des fonctions And() Or() (oui les fonctions, et non les opérateur logiques "and" "or"), car celles ci créent systématiquement un nouveau boolexpr.
Les filtres pour les TriggerRegister sont un cas à part, ils ne semblent pas avoir été achevés, seul GetFilterUnit fonctionne (tout le temps ?) et correspond à l'unité qui déclenche l'event.
De plus dans le cas de l'event "enter region" ce filtre est exécuté avant la création de l'unité, ou du moins juste avant toute autre action suivant un CreateUnit... (je ne m'en rappele plus).
Cette astuce est utilisée par les plus récents unit indexer.
Je recommande vivement de ne pas utiliser ces filtres, mais une condition plutôt.
(posez vous la question pourquoi Blizzard ne les utilise pas) _________________
Page 1 sur 1 La question posée dans ce topic a été résolue !
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum