ATME : Tracking Waypoint

[CougarFFW04]

Bonjour à tous,

 

Ce message fait suite à celui-ci :

https://forums.eagle.ru/showthread.php?t=229071

Mais je préfère écrire ici ce sera plus simple.

 

ATME semble être vraiment l'outil que je cherchais pour certaines fonctionnalités du code que je suis en train d'écrire sans avoir à réinventer la roue... Donc un grand MERCI d'avance.

 

Comme je disais je ne suis pas très familier avec les handler et bien que l'exemple qui m'ai été fournit me semble clair j'ai un peu de mal à l'adapter à ce que je veux faire et j'ai des erreurs...

 

 

D'un autre coté j'ai aussi une erreur quand je fais tourner la mission de démo au moment ou le F18 atteint son premier waypoint (cf dessous)... Le code rapporte quand même le passage du F18 au niveau du WPT1 mais après plus rien...

 

 

Concernant ATME j'ai crée un répertoire ATMEScript dans mon répertoire utilisateur DCS ou j'ai mis ATME_CoreV145.lua J'ai évidement modifié la mission pour pointer vers le bon dossier pour ATME_Core mais aussi pour le code lua de démo fourni.

 

 

 

 

 

En gros pour résumer, le code démarre un certains nombre de vols qui sont déjà en place en début de mission mais inactif et ceci a certains temps calculés peu importe comment. Pour certains ce ces vols, je souhaite faire un monitoring des waypoints pour déclencher certaines actions automatiquement au waypoint voulu via script. Supposons que j'ai écrit une fonction faitca() si je l'active directement dans l'éditeur au waypoint donné tout fonctionne a merveille. Le pb c'est que quand j'essaye de le faire tout en automatique j'ai des erreurs que je ne comprends pas...

 

En gros ca se présente comme ca et voila ce que j'ai fait pour essayer de metttre en oeuvre le tracking des waypoint de facon automatique :

 

-- On est d'accord ici c'est pas du vrai code de A a Z mais un cheminement des idées
-- Bref ca commence normalement comme tout script lua...

-- je définis un certain nombre de varaibles
TOTO = "pouet"
TITI = nil

-- et un certain nombre de fonction 

local function f1()
  whatever...
end

-- y compris ma function
local function pushWpt(events)

   -- retrieve data relative to this event
   local flightData = events:getDatas()
   if events:getType () == "TRACKING_WAYPOINT" then
       whatever    
   elseif events:getType () == "TRACKING_LAST_WAYPOINT" then 
       whatever
   end 
end

-- puis vient une antre fonction qui est checké chaque seconde par un trigger dans l'éditeur de mission
function activateFlights()

   -- peu importe ce que fait cette fonction mais a un moment, si une 
   -- condition est vraie un vol est activé. Et c'est a ce moment la que je veux
   -- activer le suivi de waypoint pour ce vol en question:
  if true then
               startFlight(leadGroup, leadName)
               -- et je démarre le monitoring pour ce groupe
               leadGroup:setWaypointsTracking (true)
               thisModule:addCoreEventCallback (leadGroup,pushWpt)
  end
end

-- Ensuite arrive la fin du code et une function qui est lancé dans l'éditeur 
-- via un trigger "début de mission"
checkIniFlights()
   -- Cette fonction fait pas mal de chose et en particulier c'est la que j'ai mis :
 
    thisModule = ATME.C_Module("peu importe", {activateFlights}, true)]]

   -- et le code se termine la
end
 

Et le problème c'est que ca plante avec ca comme indication :

 

 

 

La ligne de code 337 coorespond a l'instruction : thisModule = ATME.C_Module(....) du code ci dessus.

Je précise que le probléme ne vient pas d'une erreur de syntaxe lié a des instructions AUTRES que celles liées a ATME... puisque sans la partie ATME que j'ai rajouté, tout fonctionne comme prévu.

 

 

Mon problème c'est que je ne maitrise pas trop ces handler et donc j'avance un peu dans le floue et du coup je ne suis pas trop sur que l’adaptions de l'exemple donné est correct... Et à l'évidence non puisque sans la partie ATME ca marche nickel mais dés que j'introduis les ligne de code afférent à ATME ca plante...

Et surtout je ne vois pas trop le rapport avec ce mis....0782.lua J'ai aucune idée d'ou sort ce truc...

 

 

 

En particulier puisque le handler fait référence a activateFlights j'immagine que je n'ai plus besoin de mettre cette fonction dans un trigger évalué chaque seconde dans l'éditeur de mission puisque le handler est "lancé par CheckIniFlight une fois pour toute en début de mission..

 

 

Bref comme vous voyez ces handler ce n'est pas trés clair dans ma tete...

ceux par défaut de DCS ca va je m'en sort assez bien mais le custom handler de ATME j'ai plus de mal..

 

Si quelqu'un pouvait me dire ou est l'erreur ce serait cool...

 

Merci d'avance

Edited January 13, 2019 by CougarFFW04

[CougarFFW04]

Hello,

 

 

Bon ben après une journée entière a essayer d'identifier le problème je tire ma révérence en attendant le retour des codeurs/testeurs/spécialiste ATME.

 

 

Le simple fait de rajouter :

 

 

local moduleName = " module_Randomize_Mission "
local thisModule



-- TRACKING WAYPOINT
local function pushWpt(events)

   -- retrieve data relative to this event
   local flightData = events:getDatas()
   if events:getType () == "TRACKING_WAYPOINT" then
       -- display data retrieved
       ATME.displayForAll((flightData.group:getName()),5)
       ATME.displayForAll( "passing Waypoint :"..(flightData.idWaypoint),5)
   
   elseif events:getType () == "TRACKING_LAST_WAYPOINT" then 
       ATME.displayForAll((flightData.group:getName()).." end of track : last Waypoint " ,5)
   end 
end



local function onSpawnGroup(leadGroup)
   -- start monitoring waypoint for this group
   leadGroup:setWaypointsTracking(true)
   thisModule:addCoreEventCallback(leadGroup,pushWpt)
end

do 
   newHandlers = {
       onSpawnGroupHandler = onSpawnGroup
   }

   thisModule = ATME.C_Module(moduleName, newHandlers, true)
end

 

 

induit les problème mentionnés alors que sans ces lignes de code, tout fonctionne au poil...

 

 

A bientot donc,

 

 

++

[snowsniper]

Bonjour je ne vois tes messages que ce lundi matin.

Donc je pourrais regarder attentivement tes experimentations

Que ce soir apres le boulot.

 

 

J ai l impressiion que ton interpretation de la logique

Des handlers est pour le moins... Innatendu

Et je vais avoir besoin de comprendre ce que tu veux faire.de maniere precise.

 

Le script exemple waypoint est parfaitement fonctionnel et teste tel que mis a dispo. Le atme core puisqu il n est pas destine a etre modifie laisses le dans la mission.

[snowsniper]

Bon dans l'ordre de ce que je peux regarder à ma pause du midi.

 

 

tout d'abord je pense que tu confonds Handler et callback.

 

 

la callback est une fonction créée spécifiquement qui traite les events relatif dans l'exemple à tout objet s'appellant "F18test". si tu veux etendre à d'autre objet cette même callback tu peux mettre sur le Handler "oncreateGroup" un filtre avec Coalition / en vol / etc ... à définir selon tes besoin. Mais pas besoin de tracker tous les objets de la mission à priori.

 

 

 

 

Le Handler check et alerte sur un evenement spécique propre au joeur, aux objets DCS group ou AiUnit, ou StaticUnit. les handlers par défauts utilisables dans ATME sont listés en fin de script.

 

 

le On spawn Handler a été supprimé de la V146 core. tout objet spawné en cours de mission sera traité par le Handler OncreateGroup désormais.

 

 

un objet inclus dans la mission, mais a activation retardé sera traité dès le début de la mission. ce qui n'est pas du tout dérangeant pour un lui affecter un Settracking par exemple.

 

 

enfin le fait de déporter le script de la mission avec un dofile, est un routtage utile pour gagner du temps en débuggage, mais uniquement sur le module courant en cours de dévelloppement. le faire sur le core qui n'est pas destiné à être modifié, ne sert à rien. le laisser dans le do script file de la mission.

 

 

enfin

thisModule = ATME.C_Module("peu importe", {activateFlights}, true)]]

 

 

le peu importe, importe désolé, il faut absolument en tête de module

thisModule = ATME.C_Module(moduleName, newHandlers, true) comme tu as fait dans le script juste au dessus et définir un moduleName en tête de script.local moduleName = " module_Randomize_Mission " -- > OK

 

 

Donc si je prends ton dernier script :

local moduleName = " module_Randomize_Mission " -- OK

local thisModule -- OK

 

 

 

-- TRACKING WAYPOINT

local function pushWpt(events)

 

-- retrieve data relative to this event

local flightData = events:getDatas()

if events:getType () == "TRACKING_WAYPOINT" then

-- display data retrieved

ATME.displayForAll((flightData.group:getName()),5)

ATME.displayForAll( "passing Waypoint :"..(flightData.idWaypoint),5)

 

elseif events:getType () == "TRACKING_LAST_WAYPOINT" then

ATME.displayForAll((flightData.group:getName()).." end of track : last Waypoint " ,5)

end

end

 

 

 

local function onSpawnGroup(leadGroup) -- mettre le Handler onCreateGroup(leadGroup ) ( modification de la V145 à la V146, manuel en cours d'update )

-- start monitoring waypoint for this group

leadGroup:setWaypointsTracking(true)

thisModule:addCoreEventCallback(leadGroup,pushWpt)

end

 

do

newHandlers = {

onSpawnGroupHandler = onSpawnGroup -- dito on CreateGroup SVP

}

 

thisModule = ATME.C_Module(moduleName, newHandlers, true)

end

 

 

au delà de ça ce script devrait marcher, pour ton premier post en haut, il faut qu'on echange un peu plus en détail sur ce que tu veux faire précisément. mais je suis sur qu'il y a une solution simple ATME à ton projet ;-)

 

 

Pour ma mission exemple qui planterait après le premier Waypoint, je verrais ce soir car il me faut mon DCS, et je l'ai pas au boulot lol.

[snowsniper]

garde aussi en bas de page toutes les définitions de handlers de base, si non utilisé tu mets nil. assures toi aussi qu'il y a bien un objet client ou player dans la mission, sinon ATME ne tournera pas car il est destiné aux missions avec un joueur au moins.

 

 

tu peux m'envoyer aussi ton miz file si tu veux, je t'envois mon mail perso en message privé.

[CougarFFW04]

Hello,

 

Bon alors :

 

- j'ai rééssayé la mission démo sans rien toucher et effectivement ca marche. Je n'avais pas compris que la 1.46 était inclus directement dans la mission et du coup j'avais édité pour pointer sur le 1.45lua installé.

 

- j'ai aussi réussi a faire mon petit exemple perso (principalement la dernière version du code au dessus) et ca marche.

 

PAR CONTRE :

 

il me semblait qu'il n'y avait pas de différence en soit si on utilise :

- exécuter fichier script (et on pointe vers le fichier en question)

ou

- exécuter script (et on entre le chemin explicite pour le fichier)

 

D'autre part comme j'ai un bug connu de l'éditeur (a savoir que parfois quand on modifie un script ce n'est pas répercuté dans la mission) on m'a conseillé d'utiliser cette méthode le temps du développement : on met simplement ceci dans la condition éxécuter script :

dofile([[C:\Users\CougarFFW04\Saved Games\DCS\MyLuaScript\Test_ATME.lua]])

Avec évidement le nom du bon fichier lua (ici Test_ATME.lua).

 

 

J'utilise toujours cette méthode car je suis sujet a ce bug (non résolu par ED) et ca marche très bien sauf si j'utilise ATME. En effet, pour un même script Lua :

- si j'utilise le éxecuter fichier script ca marche

- si j'utilise la méthode précédente j'ai tout les messages chelous tel que présenté au dessus...

Et je ne comprend pas pourquoi...

Pourtant je dois utiliser cette méthode au moins le temps du développement a cause du bug...

 

Donc dans un premier temps si tu pouvais essayer de voir (simplement sur ta mission en exemple avec le chemin vers ta 1.45 qui est la seule dispo ) pourquoi la méthode expliqué (en gras) pose problème ca serait déjà un grand pas pour moi.

 

Merci d'avance

[snowsniper]

https://forums.eagle.ru/showthread.php?p=3736043#post3736043

 

 

 

Tu peux meme en mettre plusieurs

Mais gardes dans le mission editor

Le core lua.

 

En faisant comme ca tu peux lancer la mission

Modifier ton module en cours de dev et tester la modif

En relancant la mission sans avoir a reloader un nouveau script par le mission editor

 

Par contre quand le script est fini il faut le mettre en entier dans le me. Pour envoyer le.miz a des potes !

Edited January 14, 2019 by snowsniper
Update

[CougarFFW04]

Cool ca marche :D

 

 

Merci :thumbup:

[snowsniper]

de rien.

mais je t'invite à jeter un coup d'oeil à la doc (et surtout aux exemples de base.dans le premier post du thread principal ATME )

 

pour ce qui t'interresse

surtout :P211 description des handlers de base

surtout : P125 description des coreevents et des datas qu'on peut traiter et récuperer

 

après pour les fonctions de class ( objets de class group / Aiunit / player / static ) on retrouve a peu près les mêmes fonctions pour toutes les classes. pour faire du tri ou récuperer des informations d'etat. tu as des liens hypertextes dans le pdf pour naviguer plus vite une fois que tu sais ce que tu cherches.

 

en PJ la doc v146 fr ()

pour le core V146 tu peux le récuperer dans l'exemple Miz file avec winrar ou unzip ;-)

mais Sun est pas décidé encore à la publier. (version non officielle avec quelques erreurs de typo ou autre hehe mais vaut mieux partir sur une version proche de la version finale, à mon avis )

ManueldeReference - ATME V146.pdf