TEMPEST.114

If you can't capture the radio tuning events then the mission can't know when they are listening - so that it can send an audio only once. I think what you're talking about is a looping message, like a beacon ident but only on a specific freq. Again, that's not useful. They need to be on the same freq as MOTHER or whatever ground / AWACS controller they're talking to, they just need to get specific messages related to their current activity and only that unit has the options to reply with a choice of replies. And when I say 'messages' I'm talking about through the mission editor or scripting to that specific unit - not audio or 'on-screen text'. You think I have an attitude but what I was facepalming was not what you replied about - I was facepalming the stupidity of not being able to detect cockpit switches or cockpit settings in MP, only in SP. That's a DCS oversight. Maybe you should stop being defensive for no reason.

Thanks for your input. I don't want the users (however many there are) to have to de-sanitise or do anything or install anything on their PC's for this to work. It all has to be done on the server. This needs to work SP and MP, no dedicated servers, the 'host' just needs to put my folder in the root of C, and then just add a single DO SCRIPT one liner in the mission.miz so that all the required mission scripts and stuff that are loaded on mission start and that's it. I then need to have the mission designer be able to create these interactions between a specific user and the 'mission engine' inside the DCS Mission Editor and never have to touch or know what's going on in the scripts - I have a mission designer API... the end result is that the mission designer can, at certain points in the mission, send 'comms messages' to a specific unit and specify the multiple choice answers to a question, or the unit's player can provide the closest answer to something they've had to play the mission to find out - and then the mission designer will take those 'replies' and will be able to branch their mission from there depending on what they answered or asked. I can't have the rest of the players in their group knowing what's going on. Yes, a hack is to make everyone their own group, but that stops being useful when it comes to things that need to be given to a group - then you have to have 'n' number of ways to counter that, when you don't know how many players are playing the mission. In the mission editor that means A HUGE amount of cloned statements going out to every possible unit combination in the event that some of those have spawned in MP. That's too much to put on a mission designer. Also pre-baked ED things, like reporting to the carrier for return get screwed up when everyone is their own group, or AWACS stuff etc. Some Mission Editor triggers are done at group level only, and some at unit level only so again, there's a cost/benefit to doing solo groups - it's not the best/right answer. I know already that there is nothing built in to DCS to do this and there won't be until (if ever) ED decide that it's worth their time to do it. I only hope against hope that whomever is the lead on the new comms system has looked at my requests and thought about how to implement these kinds of things - otherwise I'll be dead before the next time it's looked at and it will all have been for nought. I was kind of hoping for something cunning using some cool scripting tricks or something that would allow this. Or even some kind of way to manipulate the restrictive ED framework to make a viable workaround with no compromises (except complexity in my job for having to code it up). The comms menu system is already broken and can't handle what I'm trying to do with it, because for some dumb reason the pointers to the individual menu commands get switched/lost when ED refreshes things in the backend. Two years ago I had come up with a way to do this but keeping track of all the units in the group and updating only specific units comms menus when the mission storyline dictated - the only caveat was that everyone in the group had the same 'base' menu - F10 - OTHER - THEIR UNIT NAME - CUSTOM MENU, so as long as they never chose some other unit's name, then they had their own stuff... but it was also a hell of a lot of menu diving to issue a command or send a reply to the mission; but it kept getting out of sync and I couldn't figure why - the code was correct. Eventually I talked with Grimes about it and he confirmed the pointer switching going on - the backend was never designed to think that menus would need to be persistent over time and that pointers to specific submenus would need to never change... so that broke about four months of R&D. I'm guessing that there isn't a way to do this. Especially not something that can be bound to button / hat switches so pilots can choose their reply or message via the HOTAS... damn this is so frustrating... I'm just trying to elevate the immersion and experience and every time I'm crippled by decades old design choices or things that were never considered. NOT IN MP YOU CAN'T... it's yet another restriction. Can't capture radio tuning events or cockpit switch events in MP. /facepalm.

How does the specific unit reply with multiple choice of options without everyone in their group getting them in their menus?! They can’t. That’s the problem.

Let's say you have a two ship of F14's, they are sent to intercept an unknown contact. The lead pulls along side and see's something that they have to report to Mother - the wing, which isn't in position to see what the lead sees, doesn't have the option to communicate to Mother. Also, the human RIO should be doing this whilst the human pilot does the close formation. Mother then asks a question - this question and the possible replies that the crew and reply with should ONLY go to the lead aircraft team, and not to anyone else in the group. Whilst this is going on, Mother talks to the Wing and get's them to go do something else, which they then have a unique 2 way interactive conversation with MOTHER about. Finally, after resolving both issues, the lead aircraft forms back with the wing and they go off to the tanker as a pair and return to patrol.

Yes, I know groups of one is a workaround, but that doesn't help when you have to have a group with multiple aircraft for MP missions. I can give plenty of examples of one specific unit needing it's own menu commands rather than the group, it's not hard to consider. Workarounds and fudges aren't the answer - the answer is just to give us per unit comms options - AND to allow some button bindings to YES/NO type questions being posed by the mission. You know, player interaction that can have a branching effect on mission goals etc. It's getting very old just making missions to go drop bombs on a target and get home etc... something more dynamic and immersive is required.

Well I'm testing on my own PC, not on a DCS Server. Only change from a single player mission is changing player level from 'Player' to 'Client'. Still nothing changes the waypoints after pushing/setting new task.

Doesn't make any difference.

As title says. If a moving object (aircraft, carrier/ship, vehicle) has a set of waypoints for it's route, and you select that unit on the F10 map you are able to see them in yellow dashed lines connected by the waypoints, represented by circles with the waypoint number to the right of them. If you have previously selected the object and seen those waypoints, when those waypoints change (via a scripting or mission editor event 'setTask') the new waypoints are NOT DISPLAYED and the old, now irrelevant waypoints remain. This happens even if you resetTask() or popTask() and the either pushTask(newTask) or setTask(newTask). The F10 map never changes the waypoints visible for the object/unit from those very first ones.

If you try and save it won't save it under it's original name that you loaded. E.G. Create a mission, save it with a name eg. MyMission.miz Fly that mission from the Mission Editor screen. Be in that mission for a minute or two, then hit ESC and then select QUIT. On the after mission screen click MISSION EDITOR. When back in the mission editor notice that the name of the mission has been changed by the sim to 'tempMission.miz' This is a bug.

What does that mean? The link clearly shows the limitations of the missionCommands functions. Are you implying I've missed something?

Brilliant help! Thank you so very, very much!

If you find it, would you post which one here?

Any chance of being more explicit on those two lines please?

so i have to manually add 200+ triggers to a 'template mission', and do that for EACH MAP... That's the only solution?!

It's just that I need to add about 200 files to EVERY mission I make (mostly audio but some other files). Doing it manually in the mission editor would kill me. You can't even copy/paste triggers between mission files so that would be horrific to manually do each time. What would you suggest? What are these 3rd party tools?

I'm using W11 and NanaZip. If I look at a brand new mission file in NanaZip then I see that the method of compression is 'Deflate:Maximum' there are no 'Characteristics' and the Host OS is 'FAT'. When I add in my sound and image files, the method is changed on those new files to just 'Deflate' and the 'Characteristics' is NTFS. When I try and access them from the mission editor when running the mission, it can't see or find them, so I'm guessing it's these differences that are causing the problem. However I downloaded the free trial of WinRar and the same thing happened. It wouldn't play the audio or show the picture. BUT... If I add them in via the mission editor using a 'Show' or 'Play' to NEUTRALS when the mission starts, and then call them from my scripts as normal, they work fine. When I look at the .miz file in NanaZip then the Method is 'Deflate:Maximum' and there are no Characteristics. Is there a way to add all my files in Explorer somehow rather than doing events inside the mission editor at mission start?

This would repeat the last message that was sent to that player/group/coalition etc. This is handy with 9-lines, or missed bra calls or whatever when you're talking to other players and miss a critical call.

I'm using the following in my ATIS script local weather = env.mission.weather local cloudCover = api.TUC.GetCloudCoverAsString(false) local cloudBase = api.TUC.MetresToFeet(weather.clouds.base) local thickness = api.TUC.MetresToFeet(weather.clouds.thickness) local visibility = weather.visibility.distance local fogThickness = api.TUC.MetresToFeet(weather.fog.thickness) local fogVisibility = weather.fog.visibility local dustDensity = api.TUC.MetresToFeet(weather.dust_density) Everything looks okay except that the THICKNESS which I'm led to believe from the documentation on hoggitworld is for the lowest cloudbase, ALWAYS reports the same amount of 656ft, regardless of the weather preset used and how thick the cloudbase is to fly through. Am I using this correctly or is this a bug? Cross posted in the Weather System bug list just in case it's not a scripting error.

I'm using the following in my ATIS script local weather = env.mission.weather local cloudCover = api.TUC.GetCloudCoverAsString(false) local cloudBase = api.TUC.MetresToFeet(weather.clouds.base) local thickness = api.TUC.MetresToFeet(weather.clouds.thickness) local visibility = weather.visibility.distance local fogThickness = api.TUC.MetresToFeet(weather.fog.thickness) local fogVisibility = weather.fog.visibility local dustDensity = api.TUC.MetresToFeet(weather.dust_density) Everything looks okay except that the THICKNESS which I'm led to believe from the documentation on hoggitworld is for the lowest cloudbase, ALWAYS reports the same amount of 656ft, regardless of the weather preset used and how thick the cloudbase is to fly through. Am I using this correctly or is this a bug?

You can't make mission commands go to a specific unit. That's the problem! https://wiki.hoggitworld.com/view/DCS_singleton_missionCommands If you try using scripting, the back end will switch that around on you. I had a long chat about this with Grimes about 18 months ago. And as for typing - that's ludicrous when you're flying.

A) that doesn't work for MP missions B) what chat commands or mission commands are you referring to that can do this? Because AFAIK none of the ED ones allow it. FOR MP missions/dedicated servers - no SP.

Each unit has it's own uniqueness. I've been able to write a script that can address an individual unit within a group. It runs afoul of the artifical limitations from ED on how and when the menus are redrawn as it can change references in the background due to the update. It's really not a hard fix - much like the broken winds - it's just no one ever gets round to it in favour of other things - things that aren't always as big a win as fixing the wind for example.

Hear, hear.

Thanks but I know all this. There is still a critical need to be able to send / receive messages to/from a UNIT i.e. player in MP and in SP. And it needs to be native not via a 3rd party library. It's impossible to drive a narrative or issue specific instructions to an individual unit until ED add this feature. There is no reason for it not to exist. It's just a forced limitation, much like the inability to have more than 4 ships in a group or have mixed units in a group. No reason except artificial limitations.

https://www.scmagazine.com/brief/github-battles-massive-attack-of-malware-repos