Jump to content

ATME (1.47) : Task (Stop condition)


CougarFFW04
 Share

Recommended Posts

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 :

 

Usage : Object:addStopCondition(condition)

Description : Cette méthode ajoute une condition d’arrêt d’une tâche. Le paramètre condition est une chaine de caractères formattées dont le détail est donné ci-après.

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


Edited by CougarFFW04
Link to comment
Share on other sites

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 ;-)

[sIGPIC][/sIGPIC]

all my skins :

here

 

Core i7-4790 @ 3.6- 4GHz - 16GB

- nVidia RTX 2070 - 2xSSD -

GRANDIN TV screen 39" in 1920x1080 cockpit scale 1:1

- MS FFB2 Joystick

- DIY MIDI Throttle with 14 analogic sliders and knobs

- Saitek Pro Flight Rudder Pedals

 

Link to comment
Share on other sites

Je viens de regarder... mon code et la doc, mais attention, je n'ai pas fait beaucoup de tests. Je vais en refaire pour m'assurer du bon fonctionnement, notamment startCondition. Ce qui est sur c'est que la structure nécessaire à la gestion DCS de la tâche est bien renseignée.

 

Il existe deux cas startCondition et stopCondition mais seul stopCondition est défini dans la wiki. Des tests m'ont montré qu'il existait aussi startCondition. Pour les deux cas c'est une tâche spéciale nommée "ControlledTask" qui englobe donc une tache et les conditions start ou stop.

 

Les formats possible sont (un choix à faire parmi les 3) pour l'activation startCondition ou stopCondition :

 

  • Si on veut activation sur une heure : "TIME xxx" avec xxx une heure absolue ou relative
  • Si on veut activtion sur un flag : "FLAG flg" avec flg nom du flag qui doit être activé
  • Si on veut activation sur un waypoint : "WAYPOINT numWP"

 

Je mettrai la doc à jour après quelques vérifications à faire.

 

voici le lien Wiki DCS si intéressé : https://wiki.hoggitworld.com/view/DCS_Scripting_orig_Part_2, rechercher "ControlledTask"

 

A+


Edited by sunski34
Link to comment
Share on other sites

Attention cependant, concernant la gestion des tâches, DCS a évolué depuis le moment ou j'ai implémenté les fonctions....

 

La fonction setTask écrase toutes les tâches en cours y compris la mission donc les WP attribués.

Il faut donc utiliser pushTask pour ne pas écraser la mission en cours.

 

Ces deux fonctions sont dans la classe ATME.C_Task

Link to comment
Share on other sites

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 smartass.gif 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


Edited by CougarFFW04
Link to comment
Share on other sites

Pour l'instant je n'ai pas du tout regarder l'aspect prédicate qui doit effectivement être intéressant. Avant de me lancer, je dois finaliser les autres points en cours et analyser la cohérence avec l'éditeur de mission sur ce sujet. Ceci étant les fonctions find de C_Group sont globlaes, donc avec quelques tests bien mis, le prédicate devrait marcher. La ou je suis plus circonspect, c'est pour les instances d'objets.


Edited by sunski34
Link to comment
Share on other sites

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 )

...


Edited by snowsniper

[sIGPIC][/sIGPIC]

all my skins :

here

 

Core i7-4790 @ 3.6- 4GHz - 16GB

- nVidia RTX 2070 - 2xSSD -

GRANDIN TV screen 39" in 1920x1080 cockpit scale 1:1

- MS FFB2 Joystick

- DIY MIDI Throttle with 14 analogic sliders and knobs

- Saitek Pro Flight Rudder Pedals

 

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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


Edited by snowsniper
complement

[sIGPIC][/sIGPIC]

all my skins :

here

 

Core i7-4790 @ 3.6- 4GHz - 16GB

- nVidia RTX 2070 - 2xSSD -

GRANDIN TV screen 39" in 1920x1080 cockpit scale 1:1

- MS FFB2 Joystick

- DIY MIDI Throttle with 14 analogic sliders and knobs

- Saitek Pro Flight Rudder Pedals

 

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...