sunski34

you've right Just a precision ... The target was already on VTB and out of scope, and when moving TDC I can lock it immediatly. So it's not a bad VTB display but a real target already scanned, that what I want to say.... I think that a target out of scope cannot be displayed on VTB and when changing azimuth by moving TDC, it will take time to have a VTB displayed target. Hope my explanation more clear ;) I adjusted my first remark.

+1 ... If nothing is done to save this module (no update since end of 2016), that will be the first bad experience with DCS modules. I said the first because I think other modules like Mig21b seems to be stopped too for a few weeks !!!! May we still buy beta version modules in the future ? Can ED accept that situation for a long time ? Bad time for simers if my bad feeling become true.... Hope ED and 3rd parties will take the good decisions about that risk !!!

Hi, yesterday I tried several tests on Nevada with radar horizontal scanning scope set to +/- 15° and 30°. Altitude more than 15k feet. I noticed those strange things: A target (already displayed on VTB with large +/-60° scope) stays on VTB when switching to smaller scope and moving TDC to put it out of scope. Target isn't locked of course (No PIC or PID, just scanning). I didn't test if a target appears when out of scope and never scanned before. When a target is out of scope and displayed on VTB you can lock it immediatly (target already scanned by the radar even if out of scope) At long range (up to 40 Nm), there's no real time difference to scan and display a target (hot, 0°, same altitude). I didn't test with smaller range. May I have explanations about that? Thanks

Is that ok now? Hi, I didn't see anything in last updates... Is that correct now ? Thanks Sunski

Thank you Grimes... It is not a request just a question.... Of course, I think that having those functions on Unit level class and not Group class will be better even if it is not enough for multicrew aircrafts... If it isn't possible having a Seat equivalent class under Unit, we just have to code the good controls on F10 menus and have the ability to be sure that menu events (call of the callback ;) ) will arrive in the good order regarding their time creation. In that case, it is possible to avoid inconsistencies.

Nouvelle version V1.2.0 à venir Bonjour à tous, celà fait plusieurs semaines que je n'ai pas donné de news dans le forum sur ATME. La nouvelle version d'ATME est sur le point d'être publiée et a demandé pas mal de tests ainsi qu'une mise à jour sérieuse des deux documentations anglaise et française. Cette version sera accompagnée d'une reprise des exemples donnés dans les versions antérieures. Certaines classes/fonctions antérieures ont été remplacées et/ou améliorées. Elle va par ailleurs apporter son lot d'évolutions et surtout d'optimisations : Franchissement de frontière ou plus généralement de lignes définies Gestion améliorée des aires y compris des polygones Ajout de fonction comme les patrouilles, le démarrage d'aéronef initialement non contrôlés Ajout de fonctions pour gérer les options de groupe Ajout de la capacité JTAC utilisant la radio du groupe et l'activation de laser/IR sur cibles fixes ou mouvante. Parfait pour les GBU donc et étendre le JTAC de base DCS. Ajout de la dernière fonction permettant de connaitre la température et la pression en fonction de l'altitude (utile pour un QFE). Une gestion des alarmes (anciennement Trigger user) plus approfondie et cohérente Une capacité à ajouter ses propres données aux instances de certaines classes ATME avec une gestion assurant la cohérence complète du code (exemple : enregistrement d'une unité annexe à un instant t, cette valeur passera à nil si l'unité est détruite ensuite ; ceci évite un codage compliqué au niveau du module lua que vous développerez pour éviter les fuites mémoire). Parmi les améliorations aussi, la gestion des erreurs a été revue et permettra encore plus aisément de connaitre le module lua et le numéro de ligne où l'erreur s'est produite, y compris dans certains cas où normalement rien ne s'affiche en standard dans lua. Nous avons poussé les tests mais bien sur il s'agira toujours d'une version beta. Elle sera bien sur compatible avec la 2.1. J'espère publier maintenant rapidement cette version qui restera en l'état jusqu'à ce qu'elle soit parfaitement fiabilisée (sortie de version beta) D'autres évolutions viendront ultérieurement. A bientot Sunski

Hi, My final tests on next version of ATME highlight a problem with modules which accept two players like L39, gazelle or the future F14. Actually, Scripting Engine needs groupId to send message (text or sound) or to add menus/items in the F10 menu of a player. We all know there's a bug with Group:getID function and we need to read the mission datas to get the good groupId. Actually, if two players are in the same group, they all see the text message and ear the sounds using appropriate scripting engine function. Same for F10 menu, but in that case, that may be a problem : The two players in the same group share the same F10 menu so conflict may appear if the two players use for example opposite F10 menu item ! In that case, inconsistencies may appear. At this time, it's not a big limitation to limit the number of players in a group (1 player max). But in the future, neither groupId nor unitId wil be enough. I can't imagine having two players in a F14 (one pilot and one navigator) with same displays, same sound and mainly same F10 menus. I want to know how those scripting engine group functions will change in the future with the new F14 module. Sunski.

it's a bug :( Same problem on one of my missiosn when AI ground units cross a bridge ... one of them hit it !!! I thnik it's link to 2.x version not only Normandy (I saw the same problems on Nevada a few month ago).

CptSmiley wrote : Thank you for those informations.... :thumbup::thumbup::thumbup:

Thank's a lot ;)

I do the same but thoses events have to work like for players when landing. It's a bug I think

Inexploitable ! Absolument pas d'accord Il y a des trucs qui dysfonctionnent comme le mouvement des véhicules terrestres (ils s'emmêlent les pinceaux quand ils suivent une route dans une ville) comme dans Nevada d'ailleurs. Il faut revoir les réglages graphiques et c'est certainement un peu plus gourmand mais une 970GTX semble se tirer par mal du problème avec la bonne config. Peut être des soucis sur les textures ci et là et des problèmes à régler suite à la mise à jour (affichages lents au démarrage...etc).. On a vu cela. Mais une fois résolu, :thumbup::thumbup::thumbup: ca marche plutôt bien et même bien mieux qu'à la sortie de Nevada ! Et ca reste une alpha bien sur

So the only workaround is to test if units of the group are in air or not. I will do more tests ASAP. Seems to be ok for player's helicopters

Hi, AI helicopter's group defined with DCS Mission Editor starts from an airbase and land finally (last WP) on an airbase (same or not). when setting a task "Landing" on a WP of that group still with DCS Mission Editor, S_EVENT_LAND is never fired (single or Multi player mode). S_EVENT_TAKEOFF is fired once for the first concerned WP (if several WP of the route have that Landing task set) but no event fired for the other landing task of the route. Of course, first takeoff from airbase and last Landing on airbase are ok : events are fired. Sunski

What I understand (this is a personal vision) is that player is reserved for aircrafts players ! CA seems to have a specific approach, so the best way is perhaps having specific events for CA and players using CA without flying ! But this is another question

Surely.. Just a precision for my last post : S_EVENT_ENGINE_STARTUP that is the event not fired for remote clients. Events are very important to have a good working script, so they have be fired as needed. And setting task too, like modify a route for a group of aircrafts. :cry:

yes, of course... Like I did with enter unit event. There's another problem with remote clients starting engine event (with 1.5, didn't test with 2.x) : not fired

No unfortunately that doesn't work I tried : -> Waiting for all units of the group being in air and set the new route -> bug -> Set the land waypoint only when in air -> bug -> Delete the last waypoint of the initial route in the DCS ME and set a new one by script -> bug -> Set no landing WP to let it find the nearest airfield -> bug The only way I found is to delete and respawn the group when starting mission but in that case, parking number is bad (even if units have their "parking" and "parking_id" attributes set) So I must wait for a patch.

Exactly... That's the problem or if you want to track waypoints with a wrapped task included as I do... I lost time with that problem because I was sure there was a problem in ATME. Sunski

Hi, I had to do several tests using group's controller and task id = "Mission" because of a problem I have on my script. I thought I have an issue on my script, but all is good. So, you can find here a very basic script and a mission (see image below). The red dashed line is the route after using task mission and as you can see if you run joined mission, that's working. The problem is when a group of aircrafts starts on earth (not in air), when that group arrives in its destination, it will go back to its starting airfield. I tried to change this mission task after takeoff or just before and after the last WP, no change, it will still go back to its starting airfield -> there's a bug You can change WP 0 to start in air (Turning point), then no problem. Landing airfield is good. If you destroy and respawn the same group with that new mission task (with specific script), even if it is on earth, it's ok too (except that parking is bad, different from the original one). Is there a workaround ? I hope that can be fixed soon ;) same problem in V1.5.6 and V2.1 (and previous versions) Sunski setMissionBasicTest2.lua test std Mission Normandy.miz

S_EVENT_ENGINE_STARTUP is never fired for remote clients Same problem for S_EVENT_ENGINE_STARTUP is never fired for remote clients in multiplayer. Not fixed yet in DCS 1.5.6.5199 Sunski

I didn't test that with CA. So actually, I never know if a player took the control of a AI unit. But of course, S_EVENT_BIRTH is not good in that case. Did S_EVENT_PLAYER_ENTER_UNIT work in that case in the past, before DCS 1.5.4 or that event was already limited to aircrafts ?

you're welcome

Just use coalition.getPlayers(...) to have all players in a mission when needed. After, a basic logic has to be written to manage that combined with S_EVEN_BIRTH That's working. As you can see, I reported such a same problem in Sept 2016 so ... wait and see

A good workaround is to use getPlayers scripting function combined with S_EVENT_BIRTH and a players adjust function when a player leaves a mission