sunski34

c'est fait, je t'ai envoyé un MP.

Ok... Je ne suis pas sur que celà change grand chose, mais bon. Peut etre si tu respawn.

Il doit y avoir un soucis collatéral je pense.... Mais je ne pense pas que celà vienne du getCount()

RAS avec mon petit test, deux stacks, copie comme toi en variable locale, et une qui s'incrémente avec des strings. Exemple joint (je viens de remettre la 147 à l'intérieur car c'était une version 148WIP) dans l'exemple antérieur ATME_Stack.lua ATME_Stack.miz

Non... Le constructeur retourne le stack et une variable interne locale nbItems est initialisée à 0 dans ce constructeur. Essaie dejà d'afficher à l'écran le getCount.... pour voir... Par acquis de conscience je vais créer une mini mission pour voir mais là je ne vois pas ce qui pourrait poser pb.

Le code de la classe C_Stack est simple et classique. Je l'ai testé avec un interpréteur lua indépendant avec pas mal de cas. Si tu récupères le getCount et que tu l'affiches par un thisModule:output, tu auras la valeur affichée. Je ne vois pas ce qui pourrait engendrer un soucis là. Mais bon...

tu es sur que le seadStack (ou le blueSEADStack) est initialisé correctement dans le cas SEAD ? Tu peux verifier le contenu en log avec thisModule:outputVar

envoie moi le code

Je viens de vérifier le code, getCount retourne 0 quand le stack est vide. Le nombre d'items est initialisé à 0 lors de la création. Je l'utilise beaucoup en interne ATME sans soucis.

Problème corrigé dans la V1.47 publiée ce jour. Attention à la fonction setAutoRespawn qui prend maintenant 2 paramètres, rules devenant obligatoire. Le deuxième paramètre est optionnel. Il correspond à la définition d'une callback qui sera appelée lors du respawn après la création du groupe par onGroupCreateHandler. Son usage est le même que pour la callback de spawn utilisée dans la classe ATME.C_CloningContext. Dans le cas d'un autorespawn, il n'y a pas d'instance de ATME_CloningContext, aussi, le premier paramètre de cette callback sera nil dans ce cas. Je te joins un exemple. ATME_direct_menu_spawn_destroy.lua ATME direct menu spawn and destroy.miz

Bonjour à tous, ce jour la version ATME 1.47 corrigeant le problème remonté par CougarFFW04 lors de multiples respawn d'aéronefs au même moment. De plus, la fonction setAutoRespawn de la classe ATME.C_Group a été modifiée pour permettre l'ajout d'une callback lors du respawn. On se reportera à la documentation mise à jour également pour plus de précisions. Le lien pour téléchargement : https://forums.eagle.ru/showpost.php?p=3001633&postcount=1 A+ Sunski

Ok, je reproduis le problème avec deux groupes d'hélico. Le problème n'existe pas pour les véhicules au sol. il ne concerne que les aéronefs. Tests faits sur la 1.45 Je livrerai un correctif dès que je pourrai sur ce point. Merci à toi A+ Sun

Je vais approndir ca ce we si je peux. Merci à toi. Comme le dis snow, on a fait des tests mais bien sur pas pour tous les cas possibles, ce serait un travail de fou. Je sais aussi qu'il y a de l'optimisation de code à faire au regard des contraintes DCS en terme de traitements. Il faut que ce reste fluides jusqu'à des limites acceptables. A+

Oui exact, réponse trop rapide de ma part...

Oui c'est possible... Je vais approfondir ca ce WE, ca doit etre une betise .... dans le code du Core J'ai pourtant tester avec plusieurs groupes mais pas simultanément. Bon si c'est isolé, pour l'instant contourne le bug en évitant les actions simultanées. Je te tiendrai au courant de la correction.

C'est ca. Si c'est une destruction dans DCS suite à une attaque ou une explosion -> true Sinon c'est effectivement disable ou déactivé, disparition sans explosion -> false Mais c'est sur onDeleteGroupHandler pas onCreateGroupHandler.

Elle est liée à l'unité donc bouge avec. Mais il y a des restrictions voir la doc pour ca.

Salut, Si le nom du groupe que tu mettais dans le nom de l'alarme est bon ta solution doit fonctionner, l'utilisation des privates datas est "plus joli" car c'est justement fait pour ca. Mais effectivement, aucune raison que celà résolve le soucis selon ce que je pense deviner pour l'instant. Mon idée sur le "bug" : J'ai vu que tu respawnais 2 groupes après destruction. Essaie ma mission qui doit fonctionner et après supprime un des deux groupes de la tienne... Et essaie. Je pense qu'il y a un soucis là. Si c'est confirmé, je regarderai ce WE avec des tests plus approfondis. sur ce sujet précis. On se tient au courant.

Salut, c'est get... pas set, tu l'as dans l'exemple. Les privates datas c'est un pointeur sur une table liée au module. Donc avec le getUserPrivateDatas tu obtiens l'entrée de la table pour un module donné. Et de là tu l'utilises comme tu veux. C'est une table vide au début. Et oui tu peux y mettre une table, ou des variables simples ce que tu veux

Dans ce cas, il n'y a aucune raison... Je vais approfondir quelques tests sur le sujet dès que je pourrai, mais avec la 1.46 et la mission que j'ai envoyée. Tu fais le respawn 2 groupes au même moment ? Si, oui essaie avec un .... et si ca marche il y a un soucis effectivement.

Dans ton log, je vois que ta mission a deux modules. Pour commencer, supprime le module qui ne gère pas le respawn pour voir si le bug existe toujours. Si oui, il faut déjà passer en 1.46 et refaire les tests. Penser à mettre le onSpawnGroupHandler à nil (ou à le supprimer) et mettre en commentaire la fonction associée car sinon problème. Tiens moi au courant. As tu lu tes messages privés?

Non car ATME ne lit pas tout le contenu de la mission pour suivre les taches en cours.

Une mission exemple Voici une mission exemple et son fichier lua. Se mettre hors de l'avions par F2, puis F10 F1 Pour le groupe au sol pas d'alarme avec autorespawn entre 1 et 4 sec F2 Pour les deux helico avec alarme de 10s et autorespawn à 5 sec En version 1.45, Oui il y a toujours un create après un respawn ou un spawn. Si une partie du traitement se fait après la première initialisation, utiliser le onStartHandler avec un test du paramètre paramètre à true et récuperer le groupe pour faire le traitement. En 1.46 il n'y a plus d'appel a une callback de spawn si c'est un autorespawn car ATME considère que c'est le même groupe. ATME direct menu spawn and destroy.miz ATME_direct_menu_spawn_destroy.lua

Es tu sur que _Group est bien non nil ? en d'autres termes que groupName est juste ? Le plus simple est de lié le groupe à l'alarme comme l'a dit snowsniper avec un getUserPrivateDatas qui te retourne une entrée sur une table à laquelle tu peut y définir ton groupe.

Oui c'est la solution, passer par la callback. Tu peux aussi par le onTimer mais en utilisant la boucle sur les événements à traiter.... suivi d'un gros if... elseif... end exemple : local function onTimer(events) for _id, _ in events:pairs() do if events:isCoreEvent(_id) == true then -- Si c'est un core event if events:getCoreEventType(_id) == "SIGNAL_UNIT_IN_ZONE" then local datas = events:getCoreEventDatas(_id) datas.unit:display("You enter zone", 5) elseif events:getCoreEventType(_id) == "SIGNAL_UNIT_OUT_OF_ZONE" then local datas = events:getCoreEventDatas(_id) datas.unit:display("You leave the zone", 5) end elseif events:isAlarm(_id) then --- Traitement d'alarme, _id vaudra l'une de tes alarmes TOTO TITI ou TATA end end end Mais la ca devient compliqué, mieux est donc effectivement la callback qui simplifie le code, le onTimerHandler devant être réservé à de petits scripts rapides. Pour info il existe aussi des callback pour les core events.