TEMPEST.114

Without writing a server hook, this is all you can get from the Mission Scripting Environment: https://wiki.hoggitworld.com/view/DCS_singleton_net I'd suggest you write a server hook and put it on each server and then feed that information into your mission script via your own TCP link. https://wiki.hoggitworld.com/view/DCS_server_gameGUI

PS I think this is in the wrong channel; it's not a bug in the mission editor...

If you have discord and are willing to stream your mission editor I can help walk you through this. I do this all the time, so it is working, I think it's just a simple confusion on the triggers. DM me if you're interested. Alternatively, take a look an example I just made: Radio Set Task.miz

https://wiki.hoggitworld.com/view/DCS_option_alarmState https://wiki.hoggitworld.com/view/DCS_enum_AI https://wiki.hoggitworld.com/view/Category:Tasks https://wiki.hoggitworld.com/view/DCS_func_setOption https://wiki.hoggitworld.com/view/DCS_option_roe If you use the controller singleton you should be able to interrogate a group to iterate through it's current TASKS to find one with the option for ROE and compare it to the enums from the AI table. This is a snippet from the IADScript that creates an new task to change the groups task based on the ROE local task = iadGroup:getTask() if timer.getTime() > (task.count * (task.int * math.random(5))) + (task.startTime - math.random(10)) then -- if its time to blink task.count = task.count + 1 if task.type == 'engage' then -- alternates between fire and search if radar is on when blink order given if iadGroup.ROE == 'fireAtWill' then iadGroup:search() elseif iadGroup.ROE == 'search' then iadGroup:shoot() end else -- otherwise toggles on/off if iadGroup.ROE == 'dark' then iadGroup:search() elseif iadGroup.ROE == 'search' then iadGroup:goDark() end end end else -- setting the task local task = {} if iadGroup.ROE == 'fireAtWill' or iadGroup.ROE == 'search' then task.type = 'engage' task.radarAction = 'fireAtWill' else task.type = 'off' task.radarAction = 'search' end task.duration = length -- how long task is performed task.startTime = timer.getTime() task.action = 'blink' task.int = 5 task.count = 1 task.taskFor = length + timer.getTime() iadGroup:setTask(task) Hope that helps.

When did I ever say ED was good (or bad) at it? Just that it should be first party not third. If anything from the warnings I've had from Bignewy and Nineline, they'd say I was firmly in disagreement with your fallacious claim? But I see I've touched a nerve despite you not being the web dev in question.

As I've said many, many times, web apps are NEVER the solution to anything. I took a look at your 'co-dev's' site. It's broken - which is typical of web apps. The link to documentation opens a new tab of the same page and you don't get any documentation. Web dev is never the answer but especially when you need to hook into a game engine. This needs to be a proper programming language solution built by real software engineers, not self-taught bedroom 'web devs' and architected properly using good Software Engineering principles. Hence, only ED - or a team ED subs out to - can do it.

Depends how you got the sound playing. If it's from a beacon and on a loop, just stop it, or make it play a tiny 'silent' mp3 file. There's a reason I've written my own lua sound system - the DCS one is pretty awful.

AFAIK, that's pretty much all we have. As for 'polluting the debrief screen', have you tried it? If it happens before players have jumped in, does it show up? And if so, is that a problem? As for your solution, seems perfectly reasonable to me. Though from a mission creator's point of view, I'd think about making a public API function call from the Mission Editor on MISSION START that you can use with DO SCRIPT and pass in a table of object names or ids or whatever, and then let your script destroy them or randomly choose from the list and destroy them, that way you have unexpected stuff each playthrough and you only need to pass in a table from within the mission editor and it keeps it clean. Just my 2p.

I’m guessing but I’d think it’s like the DO SCRIPT FILE - everything in the mission table is a snapshot at that time, so you’d need to refresh everything to pick up the new changes, but like I said, that’s a guess.

You're welcome, but doesn't that mean you have to know the ID's before you can do the scripting? Like, they're hard coded? Is there a better way so it's more dynamic or does your solution do everything you need? I know I had to adjust my Superscript because I thought ID's were easier to pass around, but it turns out you can't 'get' an object from it's ID (I did raise a bug/wishlist about this a few days ago) but only from its name string. Seems like both should be available to me, but I guess that the devs thought the only person who'd know the ID's was the mission creator and thus they'd also know the names. However, if you scrape the mission file on mission start, you can find all the unitID's with their unit and group name strings and keep your own table of them (MIST/MOOSE do this but they call them a 'database', however really it's not a database at all, it's just another lua table). If you went that approach then you could dynamically search your own tables and match things up; however, you're also then required to keep them up to date with births/deaths etc. Hope that helps some.

Are you using a 3rd party library or native DCS Scripting Engine? Because everything in the engine is based of the name strings, not the id numbers.

Sad panda. Seemed like a way to unleash power and creativity for a “little” upfront work, but okay.

Yes, it seems EVERYTHING in ACTION related to flags does it but NOT the CONDITIONS, thankfully. Thanks @Flappie

It's not a .miz - it's a Mission Editor bug. 1. Create a trigger with an action of FLAG IS ON 2. Name the Flag. 3. Realise you didn't mean ON and wanted OFF instead. 4. Change the action FLAG IS OFF 5. Notice the M.E. obliterates the name of the flag and returns it to a name of '1'. 6. Give it the correct name again. 7. Realise you actually did want ON instead of OFF. 8. Change the action to FLAG IS ON. 9. Notice the M.E. Resets the name back to '1' again. NOW.... before the devs say this is 'correct'.... 10. Create a CONDITION - FLAG IS TRUE 11. Give it a name. 12. Realise you actually wanted FLAG IS FALSE 13. Change the CONDITION. 14. NOTICE HOW THE NAME PERSISTS!!! THIS IS CORRECT BEHAVIOUR. The wiping out of the name for the ACTIONS is a bug.

The downside is that you have to use MOOSE... shudder...

IRL if you're doing a proper pairs take off, the wing should keep their head in line with your nosewheel and stay there throughout the take off. Basically you need to use half the runway as your 'full width' runway. As for M.E. setup, the 2nd page of the forum provides this: Hope that helps.

Most 'coders' don't or won't think about anything other than getting the technical stuff done (the bit they're interested in) and the UI is just a frustration or annoyance. There's a reason why UI/UX programmers are rare but valued.

This has been mentioned many times. The whole UI/UX is very ‘anti-ux coder’ utilitarian themed and written by people who knew how everything works under the hood but think end users are mind readers - nothing has been designed with the end users in mind. Labels, units, descriptions and even utterly missing information (see my recent bug report on the helper gates for the manual/real life test vs what the devs were thinking but never conveyed). We need a ui/ux programmer/designer to overhaul the M.E. But that’s probably never going to happen. We all just learn by trial & error or asking the same questions over and over again ad infinitum. New creators just keep finding the same stuff we’ve been saying for a decade.

You can do it already with a flag, just toggle the flag off when 'Missile In Zone'. Therefore when flag is ON it's out of the zone. Or have two zones, an outer and in inner. Use those to set the flag.

And could give them a free reload. tut tut... lol

Not possible. You can't toggle the unlimited fuel/invulnerability cheat codes on/off during the mission. You have to have them set prior to mission running in the Mission Editor. Just do a training op to get your noobs up to scratch on tanking; it's not hard. Do close formation work first.

Have you solved this? Do you need more help?

You should read this:

Yet more people have told me they didn't know about this or that it was on their hard drive. Can we pin it?