Jump to content

snowsniper

Members
  • Posts

    730
  • Joined

  • Last visited

Everything posted by snowsniper

  1. 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
  2. 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
  3. 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.
  4. 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 ;-)
  5. 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
  6. 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é. @+
  7. la V146 a été publiée ici https://forums.eagle.ru/showpost.php?p=3001633&postcount=1
  8. 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
  9. 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.
  10. 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.
  11. "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.
  12. 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.
  13. euh juste à tester, j'ai un petit doute : peut être essayes ceci : _Group:setAutoRespawn("5") au lieu de _Group:setAutoRespawn(5) tiens moi informé
  14. 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 ?
  15. :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 ..;-)
  16. "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.
  17. le plus simple dans le Mission Editor tu fais un TOTO Group que tu met en"activate later." il sera non visible dans la mission et va te servir de modele tu cree ton cloning_context avec comme modele de group TOTO, tu fais pour que le clone réutilise exactement la même route que le modèle et le même point de départ ( ou tu en redefinies un autre ) tu spawn le clone que l'on nomerra TITI, et qui aura exactement les même caractéritiques et emports. une fois TITI atterit, sur l'evenement handler onStopEngineAIUnitHandler ( au parking il eteint ses moteurs normalement ) tu fais un TITI:disable() et tu respawn TITIN°2 etc etc tu peux le faire avec l'autorespawn. et si tu veux pouvoir lui faire faire des choses particulière quelque soit le nombre / nom de l'avion spawné ( parce que le nom est indexé à chaque spawn) , le plus simple est de stocker dans une variable tampon propre au module, l'objet Aiunit ou Group que tu viens de spawner ATME.module[modulename].avionencours = Aiunit ou Cgroup à chaque nouveau spawn. comme ca tu peux lui faire faire une fonction facilement sur un appel F10radio ou d'autres conditions . en utilisant la variable ATME.module[modulename].avionencours
  18. pour un objet de classe Group ou AiUnit :disable() fonctionne pour désactiver faire disparaitre de DCS ton avion. " je veux simplement le re-spawner à l'identique" --> au point de départ du plan de vol ou il repart de là où il vient d'atterir ? si il repart du point de départ c'est mieux de faire un respawn ( duplication d'un modèle que tu peux mettre en invisible ) et detruire disable celui qui vient d'atterir. je pense que c'est ce que fait mist aussi a priori. ce n'est pas le même avion qui se téléporte lol. si tu veux que ce soit celui qui vient d'atterir qui repart en vol alors il faut lui affecter une nouvelle route, et des nouvelles taches : dans ce cas il faut que tu explore les set task pour de nouvelles actions et surtout set route pour refaire un nouveau plan de vol une fois atterit, ce qui permettra de réaffecter des chose à faire au meme objet group bonne découverte ;-) ...et bonne recherche je regarde de mon coté et je te mets les bonnes page de la doc en edit de ce post. : essenciellement : documentes toi dans la doc V146fr sur classe ATME.C_Task et tu fais une recherche sur "task" pour voir toutes les possibilités dans ton pdf reader ( il y a des liens clickables pour en haut de chaque page pour retourner rapidement au sommaire général ou au sommaire de la class en cours ) et surtout tu lis la page dans la classe ATME.C_Group : Object:setRoute / Object:setTask il y a aussi des exemples exploitable pour le setRoute, dans les missions exemples "autres exemples"
  19. 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
  20. 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 !
  21. 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é.
  22. 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.
×
×
  • Create New...