snowsniper

push task et non set task. tu as un parametre de position d'attaque qui peut être dynamique

oui voir la doc et les super schémas très clairs de la doc page 14 sur cet item. usage: ATME.coordLocalToDCS({x=(-150);y=0;z=12},origin_point,heading) la première partie est la distance en mètres dans le repère local orienté sur heading ( x sur heading, z à 90droite du heading, y on s'en fout c'est l'altitude ) origin point est l'origin du repère local en {x y z} repère DCS les donnée de sortie sont des coordonnées point x z y dans le repère DCS apliqué à ton cas "Pa exemple je veux mettre en groupe en escorte d'un autre, disons 5 miles en arrière, exactement dans l'axe et 3000ft au dessus" heading est le cap de ton groupe son repère local x orienté sur le heading z 90° droite en vue en plan. y l'altitude local pointEscort = ATME.coordLocalToDCS({x=ATME.convertNMtoM(-5);y=ATME.convertFtstoM(3000);z=0},group1:getPosition(),group1:getAzimuth()) après tu le spawn sur pointEscort avec le heading du group 1 et voili voilou. et si tu veux que ça continue dans le temps faut lui affecter la tache escort c'est mieux

je pense que si tu lui inject un settask attack 'sur une randomized target'. ou qu'il soit sur sa route il fera le detour si c'est à proximité.( par exemple settask associé à une détection de zone de proximité et tu n'as pas besoin de réinjecter un WP supplémentaire. non ?

je te rejoins sur le fait que le lua predicate est très interressant d'un point de vue alternative conceptuelle de fonctionnement, mais peu ou difficilement exploitable ou fiable à l'époque, ou on réflechissait à une logique cohérente ATME (...). DCS evolue. ... je pense effectivement qu'il faudra explorer cet aspect un jour plus en profondeur. la force d'ATME est la gestion Multiplayer des conditions et actions liées sans avoir a dupliquer les conditions pour chaque appareil de joueur. si le lua predicate nous permet un jour de gérer une ligne du mission editor standard pour l'appliquer à tous les joeurs en mission, on pourrait de fait proposer une alternative simple pour débutant qui permettrait dans une ligne de Mission editor standard de gérer un groupe de joueur complet. Je pense notamment à une unité Joeur virtuelle qui représenterait tous les joueurs en mission et qui serait reconnu et traité par le mission editor comme un joueur normal. mais ce n'est pas l'objet du thread. (et ce concept deviendrait de fait un "mod" interfacé avec le fonctionnement du mission editor, et c'est là que les choses se compliquent vraiment en terme de type de variables communes entre les 2 parties ) ...

hum hum interressant à priori des valeurs " string" detype Time, Flag ou waypoint reste à voir la forme adequate d'usage. pour time je pense que c'est une logique similaire aux alarmes de ce que je décrypte dans le core. avec des token relativ ou pas des valeur mini et max en cas de random etc .. etc.. pas trouvé d'indice pour pour flag et waypoint mais le flag true false devrait répondre à ton besoin je pense si il est armé par une fonction updatée régulièrement affaire à suivre ;-)

"Dommage qu' on ne puisse pas spécifier un point 2D avec un azimut absolu" ben suffit que tu récupères l'azimut de l'unité de référence avec unit:getAzimuth() après tu convertis le repère et tu auras un azimuth absolu Usage : ATME.coordLocalToDCS(point, center, azimuth) "Description : Cette fonction transforme un point donné dans le référentiel local défini par son centre et son azimuth en un point 3D dans le référentiel de DCS (x,y,z)."

local point1 = ATME.coordLocalToDCS({x=(213);y=0;z=0},origin_point,correct360(heading-9)) local point2 = ATME.coordLocalToDCS({x=(213);y=0;z=18.25},origin_point,correct360(heading-9)) thisModule:createNamedMultiSegment2D("waveoff",{point1,point2}) z longueur l parametrable c point parametrable = origin_point azimuth AZ parametrable voir la function ci dessu ATME.coordLocalToDCS et le dernier parametre heading.

la table indexée reste idéale pour du référencement identique et fiable d'objet, référencement utilisé ensuite dans plusieurs tables classiques ou pas; à toi de voir mais rien de très compliqué une fois qu'on a compris

bonsoir. si ta liste est une liste classique lua, ton script fonctionnera. si ta table est une liste indexée définie comme telle malist = ATME.C_IndexList() il faut faire autrement. elle vient de où cette table " blueTargetsListe" générée par une fonction ATME ? il est probable voir certain, que les tables générées en sortie par des fonctions ATME ayant cette sortie soient indexées. c'est à dire et c'est tout le principe de la table indexée: avec des index fixes même si la valeur a changé ou est nil extrait du manuel " Cette classe permet de créer une liste indexée pouvant contenir des valeurs nil. L’index sera forcément numérique et débutera à 1. ATME.C_IndexList permet une gestion optimisée de ces listes. Contrairement table.removequi engendre une modification des index suivant l’élément supprimé, ATME.C_IndexList met simplement à nil l’élément supprimé. Cette entrée devient alors valable pour la prochaine insertion. De plus, ceci évite de perdre un éventuel référencement au travers de l’index." --> l'interet est que ci l'on stocke à un index donné un objet ATME-DCS même si il devient nil l'index existe toujours sans décaler les autres . on peut donc tester si le group est détruit ou pas par exemple. usage de cette forme pour trier le meilleur moyen est de créer une nouvelle liste indexée selon des critères de tri. --première boucle for i,value in (matableindexée):pairs do -- deuxieme boucle for a,value2 in (matableindexée):pairs do if value2<value then ... -- critère de tri un exemple récent de ma part un peu complexe et obscur ( lourd et non optimisé mais qui fonctionne nickel ) dans mon module de monitoring des ground target, peut être ça aidera a comprendre comment on peut jouer avec les listes indexées souvent je crée une nouvelle table indexée de correspondance selon un tri donné, par exemple sur cette nouvelle table de correspondance , à l'index 1 de cette nouvelle liste j'ai stocké la valeur index 16 qui correspond ici à l'index des data avec la plus petite valeur de distance par rapport au joueur dans les datas stockée,( je les associe à une liste data standard lua non indexée lorsque j'ai trop de datas, ...et par facilité d'accès.)

m pour les hauteurs et distances m/s pour les vitesses. semble la par defaut pour le set Task orbit je suspecte par cohérence que ce soit aussi des m/s donc facteur x3600 limité par DCS au max à 600 knt mach 1,2 soit le max lol. pour les conversions faciles et rapides utiliser les fonctions dédiées ATME global fonction ATME.convert voir doc 1m/s ~= 2,23 miles / hours = 2,23 knots

un exemple ATME de cet usage mais en v145, je crois que ça a un peu évoluer le traitement des zones en 146, faut que je relise la doc aussi lol; notamment je crois que les sous zones ( ring circle ou autre) qu'on inclu a une area general ne sont plus nommées désormais car cela s'avère inutile, donc un parametre de moins dans la definition de ces sous zones. mis à part ça ... la logique d'usage reste vrai le link de l'area ici avec le player est la fonction thisModule:createNamedArea(areain,nplayer) -- creation d'une zone Aerea attachée au joueur / Create zone aerea linked to player / circle 40 Nm après on défini les sous zones qui composent cette area. Pour ce que tu veux faire ci dessus , tu peux regarder la tache escort, et aussi patrol

tout le travail, c'est sun. (pas moi.) moi j'utilise avec grand plaisir il est vrai, et promote le travail quand je peux, et je lance des nouveaux défis challenges idées, dans le meilleur des cas.( mais je me freine, parce que ... sun part au quart de tour sur les nouvelles idées, et dès que j'aboutie sur un turnaround sur un concept à moi après moult difficultés et débuggage et 2 semaine de cassage de tête ,si concept non implémenté en base , pas le temps de faire ouf qu'il y a déjà une nouvelle fonction qui règle en 2 ligne de code, un proto de 400 lignes bancal, et une nouvelle version ATME du core béta. ahah. et dans le pire des cas je détourne l'idée de base ou le concept de sun, dans une programmation à l'arrache et sans trop de rigueur... en faisant fi (enfin presque) des consignes et règles . mais ou je m'amuse beaucoup ça c'est sur.;-) ravi que ça te plaise.en tout cas.

Avec des scripts de bourrin comme ca on va pouvoir debugger atme dans ses limites c est cool lol . Ca va changer de mes scripts de noob hello world. Lol Vas y envois du lourd ;-)

J ai un module wip traffic ai et un module case3 avec cette fonction arra linked to unit ca marche nickel pour detecter ce qui est dans un volume autour d une unite mouvante

désolé, mais "certain" ne connaissent pas le bébé pour dire ça... les systemes sont assez ( voir très ) poussés, et surtout dans une logique DASSAULT, donc très interressants historiquement et d'un point de vue français. de plus l'ergonomie des systêmes si on affecte les touches et tous les boutons du joystick comme le vrai , est super bien pensé et mieux à l'usage que les avions US notamment le PA, etc le seul élément "poussé" qu'on peut regretter absent sur cette version du 2000 c'est un pod laser. une fois maîtrisé c'est un très bon chasseur, mais aussi un bon bombardier en bombes freinées raz du sol. le manuel fait 295 pages passionnantes. et en plus il a été traduit intégralement en français par l'équipe de trad. mais bon il y a plein d'autres modules passionnants c'est sur, ou "plus poussés" mais je ne sais pas sur quel critères a part les pods du AV8 non terminé ou le A10C et encore. par contre pour un français c'est une perle. ce niveau de modélisation est inégalé en terme de profondeur de systêmes, et même si on peut trouver des defauts franchement tu te fera moins chier qu'en mig 15 lol.( mais ceci n'est que mon avis ) si trop cher attend les prochaines soldes, il est régulièrement soldé. @+

la V146 a été publiée ici https://forums.eagle.ru/showpost.php?p=3001633&postcount=1

pour plus de précisions sur la creation de l'alarme : local datas = _Alarm:getUserPrivateDatas(thisModule) datas.objectgroup = _Group -- store in private datas, object sur la callback : local datas = _Alarm:getUserPrivateDatas(thisModule) _Group = datas.objectgroup

dans " autres exemples" ATME_M2000_VS_SU27_training.lua tu verras qu'on peut spawner a partir d'une definition type dcs (table comme tu evoques) et non d'un modèle du Mission editor. par contre aller chercher par ATME avec des fonctions les valeurs dans mission.lua dans le .miz. je pense pas que ce soit possible. mais Sun te confirmera ce point lorsque je veux récuperer ces tables comme modèles. je créé une mission génénique avec l'objet dans le mission editor et je recupere la table générée dans le miz file pour ensuite l'inclure dans mon script. ce qui permet de générer des spawn sans modèles. j'ai fait ça de manière très basique pour la venue d'un camion pompier sur la piste dès que l'intégrité de l'appareil est atteinte à l'atterrissage lol.

edit: moi j'utiliserais plutot " _Alarm:getUserPrivateDatas(thisModule)" de la classe alarm pour faire transiter l'objet group et non son nom a récupérer plutot que les tags .. mais ce n'est que mon avis. au feeling groupname doit être nil ou ne correspondant pas à un objet existant ( a tester avec une trace ), ce qui ne bloque pas le script si tu commente les 2 lignes que tu dis. mais dès que tu y fait appel. bing sun aura un avis plus rapide et plus éclairé, mais il ne sera dispo qu'à 16h30 sans certitude. J'ai l'impression que l'index 2 de la table des tags extraits ne te retourne pas toujour le groupname de l'objet spawné. il faut tester la sortie avec une trace. pour rappel un objet spawné , son nom de groupe est indexé, model #001 ce qui veut dire que son nom complet correspond à 2 tags et non 1 seul.

"D'ailleurs concernant tout cela je constate qu'un respawn déclencle a la fois un - onSpawnGroupHandler (a priori normal) mais aussi - onCreateGroupHandler (c'est peut-etre normal mais c'est ce que voulais éviter pour un respawn)" ça c'est parce que tu utilises la V145. sur la V146 il n'ya plus de onSpawnGroupHandler mais une callback spécifique.

tu as quoi dans le dcs.log ? tu peux pas le mettre en PJ svp. PM même si la fenêtre d'alerte renvoi a une ligne du core ATME, les bugs dans le core engine ATME deviennent extremement rares plus probable à 99% erreur de typo d'usage ou de definition de variable / objet il faut trouver le sous processus cause au plus prêt du script en cours, et de la ligne concernée. essayes qd même de mettre local devant les ligne 11 et 13. ça mange pas de pain comme dirait l'autre.

euh juste à tester, j'ai un petit doute : peut être essayes ceci : _Group:setAutoRespawn("5") au lieu de _Group:setAutoRespawn(5) tiens moi informé

après un bug, ATME ne tourne plus, donc cela ne reprend pas normalement. lorsque j'ai ce genre de soucis, la bonne méthode est de circonscrire pour trouver là ou est l'erreur ou la variable nil qui fait bugger. pour ce faire on peut utiliser des traces visibles dans le log dcs : sur chaque ligne de log on trouve le script en cours [ script ] blablabla les traces ( sous reserve que "ATME.setDebugLevel(0)" ou ATME.setDebugLevel(1) soit bien lancé dans le Mission editor sont de cette forme : thisModule:outputVar("text what to test ",variabletotestanddisplayinlog,niveaudevisibilité(1)) ou if vartotest == nil then thisModule:output("ci ceci s'affiche alors la variable est nil à ce niveau" ,1) end une fois le probleme circonscrit on peu retirer ou commenter les traces après là tout de suite je ne sais pas trouver l'erreur sans le code complet. sur quel ligne du script dans le log, cela crash t'il car dans la fenêtre là c'est une référence du Core, donc peut probable il doit y avoir une ligne qui crash avant dans le script en cours. à priori la ligne 13 ou 11 ? cela correspond à quelle ligne concretement ?

:P tellement vrai lol. voler entre gentlemen, ne pas se prendre trop au sérieux, et surtout prendre du plaisir, et y mettre un peu de rigueur quand même pour le réalisme, trouves toi des gens dans le même état d'esprit, ça existe. mais pour moi les "squadrons" ne sont pas la bonne porte, sauf exception ... Bon courage dans ta recherche. et à l'occasion, et sans obligations, on fait des missions sympa dans cet esprit à 2 3 tous les samedi AM et parfois le Dimanche AM ..;-)

"Par contre je ne trouve pas de fonction respawn dans la doc ATME" context:spawn(route) page 119 est ce que tu cherches. context étant l'objet de classe de cloning définie préalablement, la methode souhaitée et la nouvelle route ) ça c'est le spawn simple, sinon il ya l'autorespawn comme expliqué ci dessus par Sun, qui semble mieux correspondre à ce que tu voulais faire si c'est toujours le même trajet 2) objetdeclassegroup:disable() et objetdeclasseAIunit:disable() fonctionnent même si l'objet est en vie.