sunski34
-
Posts
753 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by sunski34
-
-
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.
-
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
-
Juste un petit message pour dire que j'ai refait plusieurs tests et je n'ai plu de plantage donc a priori c'est bien lié a des respawn quasi simultanés.
Bon courage et merci :smilewink:
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
-
Oui deux modules suite a mon pb et vos conseils.
cf https://forums.eagle.ru/showthread.php?t=229653
Dans le premier module tout les handlers sont a nil et il n'y a rien d'autre
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.
-
local function reSpawnAlarm(_alarm) local alarmName = _alarm:getName() if ATME.getTags(alarmName) ~= nil then groupName = ATME.getTags(alarmName)[2] _Group = ATME.C_Group.getByName(groupName) _Group:setAutoRespawn(5) _Group:disable() ATME.displayForAll(groupName.." will be respawned in 5 sec",3) end endEs 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 endMais 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.
-
repawn
Bonjour,
il n'y a pas de fonction respawn à proprement parler. Pour faire un respawn automatique, il faut utiliser la fonction setAutoRespawn de la classe ATME.C_Group. Cette fonction permet de respawner un groupe détruit avec un délai donné.
Pour détruire un groupe, deux possibilités :
- dans la réalisation de la mission, à la réception des events DCS ad'hoc
- par ton script en utilisant la fonction disable de la classe ATME.C_Group, c'est ce que veut dire snowsniper
Voici un exemple simple qui fixe l'autorespawn entre 1 et 4 seconde puis si le groupe existe le détruit... Donc il sera recréé ensuite dans le délai indiqué. Il existe un exemple en 1.45 dans "Other examples.zip" dont est tiré l'extrait ci dessous (ATME_direct_menu_spawn_destroy) :
local group = ATME.C_Group.getByName("copy0") if group ~= nil then -- If exists, disable group ... thisModule:output("Avant auto...",1) group:setAutoRespawn("RANDOM 1 00:00:04") thisModule:output("Après auto...",1) group:disable() endMais en faisant celà, le groupe va toujours refaire la même chose.
Maintenant, si tu veux qu'un groupe reparte de l'endroit ou il est, il faut toujours faire un disable puis faire un spawn à partir du cloningcontext créé comme je t'ai montré mais cette fois avec une route inverse. Il faut la faire waypoint par waypoint pour l'instant car les copies de route ne se font pas en sens inverse (c'est une idée que je retiens).
Je précise que dans les dernières version de DCS, pour les avions, il existe un nouveau cas "atterrir et repartir", je dois voir celà car pour l'instant non implémenté dans ATME.
- dans la réalisation de la mission, à la réception des events DCS ad'hoc
-
Bonjour à tous,
ce matin la version 1.4.6 a été publiée avec sa documentation à jour et le fichier basique pour créer un module.
On notera cependant que les exemples restent actuellement dans les anciennes versions. Les mise à jour sont en cours et seront publiées dès que possible (en fonction de ma charge de travail professionnelle).
Je reste disponible pour toute question ou remarque.
Le travail sur les optimisations se poursuit afin de rendre ATME encore plus performant.
Merci à tous pour vos encouragements ;)
Le lien pour le téléchargement :https://forums.eagle.ru/showpost.php?p=3001633&postcount=1
A+
Sunski
-
J'oubliai :
tu peux aussi créer plusieurs groupes identiques avec un délai entre chaque et une quantité définie. C'est la fonction setAutoRepeatSpawn(qté, période) dans la classe C_CloningContext.
La période peut etre fixe ou aléatoire avec un min/max en secondes, voir la doc.
-
en complément, dans l'exemple, le nouveau groupe est spawnné dans une zone DCS nommée "spawnZone". Le positionnement dans cette zone est aléatoire. Après, à partir du waypoint 1, c'est la route du groupe "source" qui sera donc suivie elle aussi à partir du waypoint 1.
-
Cloning
Il est tout à fait possible de cloner un groupe en multiple version, il faut utiliser la classe C_CloningContext.
Deux possibilités, le faire avec des données directement dans le lua c'est plus compliqué car ce sont les tables DCS.
Ou plus simple cloner un groupe existant, dans le cas ci dessous son nom est "source" et le groupe cloné s'appelle "dest". Si tu spawn plusieurs fois tu auras "dest #001" "dest #002" etc....
Dans l'exemple je mets une route spécifique. Pour avoir le même route que le groupe initial, il suffit de ne pas mettre de paramètre à la fonction spawn. Tu peux aussi créer des routes diverses donc avec cette classe C_Route.
local cloningContext = ATME.C_CloningContext("source", "dest") if cloningContext ~= nil then local route = ATME.C_Route("GROUND") route:addAbsoluteWaypoint("spawnZone", 0) route:addInitialWaypointsFrom("source", 1) cloningContext:spawn(route) endATTENTION : A partir de la V1.46 à venir, le onSpawnGroupHandler n'existera plus mais tu pourras ajouter une callback qui sera executée lors du spawn après le onCreateGroupHandler s'il existe :
local cloningContext = ATME.C_CloningContext("source", "dest") if cloningContext ~= nil then local route = ATME.C_Route("GROUND") route:addAbsoluteWaypoint("spawnZone", 0) route:addInitialWaypointsFrom("source", 1) cloningContext:addSpawnCallback(mySpawnCallback) cloningContext:spawn(route) endet la fonction callback est de type :
local function mySpawnCallback(context, group) -- Callback de spawn pour mon contexte cloningContext que l'on récupère dans context -- Le groupe spawné est récupéré dans group. ATME.displayForAll("New group " .. group:getName() .. " is spawned from intitial group : " .. context:getGroupName(), 5) end
ATME (1.46) : Stack getCount()
in Français
Posted
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...