CougarFFW04

:thumbup:

Hello ATME Gurrus, C'est un peu brouillon dans mon code pour l'instant donc je ne suis pas sur 100% mais j'ai l'impression qu'il y a un bug dans le tracking sur une zone mobile attachée a une unité. Je précise que ca n'a rien a voir avec les dernière évolutions mais bien en ATME1.47 Soit une zone mobile ZONE attachée à un VOL - Au moment de sa création le VOL et sa ZONE sont en position A (ZONEA) - Plus tard le vol s'est déplacé en B avec sa zone (ZONE en position ZONEB) et aucune intersection avec ZONEA à cet instant. Au moment ou on déclenche un tracking d'un groupe dans ZONE, si à cet instant le groupe en question est dans les limites de ZONEA il déclenche bien un événement "dans la zone" alors qu'il est largement hors de la ZONEB à cette instant. Je ne sais pas si ce bug a lieu seulement si le tracking est déclenché à l'instant précis ou le groupe est dans les limite de ZONEA ou si c'est aussi chaque fois que le groupe repasse dans les limites de ZONEA Je ne sais pas si je suis très clair... :joystick:

Hello, Vu. Je test dés que possible et je te réponds. ++

Possible je n'ai pas testé mais dans ce que je fais les cibles sont potentiellement loin du waypoint Push. Et puis surtout ce n'est pas ce que je veux faire. Les cibles sont affectées en fonction de certains critères et c'est donc bien sur un cible donnée, sélectionnée en temps réel que je veux envoyer le vol. D'ou la raison de ma demande. ++

Stop condition testée sur heure relative : OK. @Snowsniper : pour l'instant je ne me suis pas vraiment encore intéréssé a ce que peut faire ATME concernant le joueur. Pour l'instant je me suis plutot concentré sur la gestion des vols IA. mais ca va venir un jour ou l'autre et si donc c'est ta tasse de thé alors probablement j'aurais besoin de conseils :thumbup: Petite question en passant concernant les Vector_3D (c'est pas hors sujet puisque ca entre dans les paramètres de certaines taches) : je pourrais expérimenter bien sur mais je me demande comment sont orienté les axes x,y,z en particulier quand c'est en référence par rapport a autre chose. 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. Quels sont les valeurs respectives de x, y et z dans ce cas ? Thanks :smilewink:

Hi SnowSniper, Effectivement ca pourrait etre une bonne solution pour une alternative :thumbup: Pour en revenir au coeur du problème, ca serait vraiment un gros travail de développement d'avoir une fonction qui pourrait insérer insérer un Waypoint entre deux waypoints d'un plan de vol existant ? A nouveau j'explique pourquoi cette doléance: imaginons un plan de vol basique constitué d'un WPT0 (décollage), WPT1 (Push), WPT2 (atterrissage). Quand le vol arrive au Push on lui injecte un WPT (Target) associé a un objectif aléatoire du scénario (ou choisi selon des règles plus élaborées peu importe) et la tache qui va bien... :pilotfly: Et BOUMMM Lorsque le vol rentre il est remis en place : nouvelle cible... :pilotfly: Et BOUMM :pilotfly: BOUMMM :pilotfly: BOUMMM Facile à coder avec cette hypothétique nouvelle fonctionnalité ATME, hyper efficace et à ressource constante.

:beer::rotflmao::yay::clap:

Hello, Cool merci. Je vois sans étonnement que tes formats possibles correspondent aux 3 conditions d’arrêts classique qu'on trouve dans l'éditeur de mission :thumbup: Mais Quid de la condition (Lua Predicate) ? C'est a celle-ci que je faisais référence quand dans mon message initial je parlais d'une fonction qui retourne true ou false. Y a t il une raison particulière pour laquelle tu ne la proposes pas ? Je pose la question car avec la fonction que tu es en train de mettre en place (pour trouver un groupe dans une sphère) ça ferait un duo de choc pour la gestion des packadges... Je m'explique (et oui ça parait peut-être pas comme ça mais il y a une petite logique derrière mais x questions et ma lise de doléances :music_whistling::D) : Un groupe est en attente sur un Waypoint jusqu’à : - une durée d'attente de x minutes max (donc ca OK avec ta chaine spécial) ou - jusqu’à ce que le groupe d'escorte arrive a proximité. Et c'est la que le Lua predicate serait hyper puissant car associé à une fonction basée sur la détection dans une sphère autour du groupe qui retournerait nil si le groupe n'est pas détecté ça ferait le taf a merveille sans se prendre le choux. J'ai testé directement dans l'éditeur de mission et c'est hyper efficace. Thanks

:thumbup::thumbup::thumbup::thumbup::thumbup::thumbup::thumbup: :pilotfly::pilotfly::pilotfly: MERCI

Ok. Cette petite chaîne va sûrement m éviter bien des tracas. J ai hâte de faire sa connaissance. Merci

Bon alors j ai un peu regarde différentes pistes mais il y a toujours un petit truc qui coince. A priori pas possible d intérêt sur la position des wpt d une route existante. Je me suis alors mis en tête de créer le plan de vol de toute pièce en me disant que addUnitRelativePolarwaypoint serait parfait mais c est dans un repère lié à l orientation de l unité et donc il faudrait que je créer une unité bidon. Faisable mais pas optimale. Dommage qu' on ne puisse pas spécifier un point 2D avec un azimut absolu. Bref pas concluait pour l instant mais je continue mes investigations.

OK. Merci pour la réponse, Je vais regarder ca d'un peu plus prés et voir comment je peux faire en attendant cette "hypothétique" fonction pour plus tard. Je vois a peu près comment je pourrais faire... l'idée serait : - je récupère le plan de vol existant, - j'en cré un nouveau en recopiant un par un les WPT et en insérant le moment voulu celui qui m’intéresse, - j'affecte ce nouveau plan de vol, Dans le principe ca demande juste une itération sur les WPT... Il y a juste ta remarque sur le dernier WPT qui me met qq doutes... Mais bon je testerais et on verra. ++

OK. Je comprends bien le mécanisme et c'est bien ce que j'avais capté. Mais donc si je comprends bien il n'y a pas moyen pour l'instant dans ATME a partir d'un plan de vol déjà existant, de simplement rajouter un WPT entre deux WPT choisis ? Pourtant tout existe déjà pour le faire. Une autre chose qui pourrait être extrêmement pratique. Et donc je me demandais :smartass: si c'est le genre de possibilité que tu pourrais mettre en place dans version a venir d'ATME :music_whistling::music_whistling: :D:D Et je crois que c'est bien dans la philosophie ATME de proposer des choses clef en main pour alléger et simplifier les codes Lua de tout un chacun. Et si tu as besoin d'un testeur pour ca, il est tout trouvé :thumbup: Merci pour tout.

Hello, Et bien voila c'est la question du jour... Et ca concerne les waypoints... A priori ce que je cherche se trouve dans "Route". Comme c'est un peu touffu cette partie et qu'il y a une fonction que je n'ai pas trouvé alors je pose directement la question. Le probléme est le suivant: J'ai un vol IA qui décolle depuis une base (WPT0) puis part sur un WPT1 avant de revenir attérir (WPT2) sur la même base (mais peu importe). - Comment faire avec ATME pour simplement insérer un nouveau WPT par exemple à la suite de WPT1 ? - Les index des WPT suivants sont-ils simplement décallés ? - Je ne trouve pas de fonction équivalante a la fonction DCS switchWaypoint (ou un truc comme ca, j'ai pas mon ancien code sous les yeux). Puis-je continuer a utiliser cette fonction DCS ou elle existe bien avec ATME mais je l'ai zappée ? Merci d'avance

You ROCK :thumbup:

Oui parfaitement clair. Bon je pourrais faire un truc comme ca et mettre la fonction updatePos dans le onTimer : function detectUnit(_foundItem, _val) local unit = Object.Category.UNIT local pilot = foundItem:getName() local groupName = _foundItem:getGroup():getName() trigger.action.outText(groupName .. "\t" .. pilot .. " IN " .. val .. " ZONE", 1) end function updatePos(_flight) local volS = { id = world.VolumeType.SPHERE, params = { point = mist.getLeadPos(_flight), -- sphere.point, radius = 1500 -- sphere.radius } } local posit = mist.getLeadPos(_flight) world.searchObjects(Object.Category.UNIT, volS, detctUnit, _flight) end Ca marche mais c'est pas très pratique et en plus de mixer les fonctions DCS, Mist ca ne sera pas aussi bien optimisé que ATME :music_whistling::music_whistling: Oui je flatte, je flatte :D C'est pour mettre en condition pour ce qui est dessous :megalol: Du coup je me demandais si il serait possible dans une version 1.47+ d'implémenter la détection dans une sphère avec des événements core associés aux entrées/sorties dans une telle zone :smartass: Ca pourrait etre pratique pour plein de choses :music_whistling: Qui ne demande rien n'a rien :D:D

Hello ATME Gurrus, Une petite idée de d'ajout pour ATME: Ce serait cool d'avoir une petite fonction dans la classe ATME.C_LINE2D (ou CLASSE ATME.C_VECTOR3D) qui pourrait créer un segment - de longueur L paramétrable - centré sur un point C paramétrable - orienté selon un azimuth Az paramétrable. Ca pourrait etre sympa pour mettre en place facilement des patrol en récupérant les point A et B via les fonctions "get" existantes. Il ne me semble pas que ca existe pas tel (même s'il est bien sur possible de le construire avec les fonctions ATME existantes). Au cas ou.. :thumbup:

Hello, Je fais une zone mobile de 10nm de rayon centrée et attaché sur un vol Donc pour la zone mobile je fais ca : -- Create an area linked to Lead Flight local areaNane = "areaArround_"..groupName local area = thisModule:createNamedArea(areaNane,ATME.C_AIUnit.getByName(groupName)) local circle = ATME.C_Circle(_Group:getPosition(), ATME.convertNMtoM(10)) area:add(circle) Mais est-ce que une aire de type Circle est une sphére ? Sinon comment créer une aire de détection qui serait une sphère (de même rayon que la zone cercle) ? Ou alors il faut faire une Box s'appuyant sur le cercle ? Pour ensuite dans une étape ultérieure détecter si un autre vol est dans cette zone en utilisant: Object:setGroupTracking(group) Au final ceci servirait entre autre de condition d’arrêt pour une tache par exemple avec un fonction qui retournerait "false" (=> arret de la tache) si un groupe ami est détecté dans la zone... Mais la je suis coincé par ca : https://forums.eagle.ru/showthread.php?t=231001

Hello, C'est encore moi... Et c'est pas fini :D Je voudrais établir une condition pour l'arret de l'execution d'une tache (ORBIT en l'occurence). A priori j'ai bien trouvé la fonction ATME qui ferait ca : A moins que je ne sois passé a coté, aucune trace de la fameuse chaine formattée...:helpsmilie: En fait ce qui serait cool ca serait que la condition d'arret puisse simplement etre un "true" ou "false" retournée par un fonction... A voir donc si c'est possible quand j'en saurais plus sur cette fameuse chaine... J'en profite pour signaler une erreur dans la doc suite a un probable cc entre le add et le stop... Thanks

Hello, Oui j'ai réglé ca en trois lignes de code for _i, _item in blueTargetsListe:pairs() do table.insert(temptab,_item) end sortnested(temptab, "incr", 3) :pilotfly:

Salut snowsniper, ha oui j'avais pas capté ca.... donc normal que ca ne trie pas... Ca va me compliquer pas mal la vie cette affaire... Je vais peut-etre repasser a une table Lua classique dans ce cas la. Merci quand même pour les conseils :thumbup:

Bon ben j'ai quand même une question... La fonction sortnested suivant permet d'ordonner une table par ordre croissant (ou décroissant) sur un l'index choisi. function sortnested(tabtab, order, indtosort) table.sort(tabtab, function (left, right) if order == "incr" then return left[indtosort] < right[indtosort] else return left[indtosort] > right[indtosort] end end) endTesté sur une table a la con et ca marche nickel. Par contre si je test sur une liste ATME, sauf erreur de ma part, ca n'a pas l'air de fonctionner... Sur ma table je fais un sort sur index 3 et ensuite j'affiche le premier de la liste mais apparement ca reste dans le même ordre... sortnested(blueTargetsListe, "incr", 3) ATME.displayForAll("SORTED "..blueTargetsListe:get(1)[3],3) Il y a une raison particulière ou simplement il est beaucoup trop tard pour que je puisse encore refléchir corrctement pour aujourd'hui :joystick:

Doublons... Voir dessous

Hello, Je voudrais savoir s'il est possible d'appliquer un table.sort sur une liste ATME ? ++ Edit : Bon j'aurais du tester avant de demander... Bref réponse : OUI

Hello, Donc c'était bien un problème a la $^% Je peux donc continuer... Désolé pour le dérangement... Mais partez pas je vais surement avoir d'autres problèmes :) Edit : et ben voila c'est débogué :) La dynaMo est repartie pour la suite des fonctionnalités :pilotfly: