dwpenney

It's a way around the multiplayer issue of creating a menu for a client that has not logged in (ie: nobody is occupying the slot). If no one is occupying the slot, you can not (I think) set the menu for that particular client. You can use the global menu (ie: game, or coalition) no problem. That means if someone was to join that slot with the mission already in progress their comms menu would not be complete. A hack around this is to rebuild the menu every little while. I am thinking that there may be a way to set the menu once at the mission start and then detect players joining with the ON_BIRTH event to set the menu at that point - to get around both issues but I have not had time to try this in/with MOOSE.

DCS 1.5.6; I am running into a weird issue with regard to MENU_CLIENT_COMMAND. I realize that the client code is only partially working until the final few related DCS bugs are addressed but I was using the example code in MOOSE as a baseline. So, here is what I was doing. I was creating a training mission with 4 client player aircraft and I was choosing one of those (by name) as the training master. I wanted this client to have access to menu commands to spawn adversary aircraft on command while the other 3 client player positions were for the trainees. I used the same method in the MOOSE test missions: create a scheduled function call to generate the menu items every 30 seconds. The function would create/re-create the top level Flight Lead Commands menu item with a Spawn Active and Spawn Passive menu under that. In each of the Spawn Active and Spawn Passive menu options would be the actual spawn commands. In this case there were 8 of those. Going through the menu would be like this: F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F1. Spawn Su-17 Defensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F2. Spawn Su-17 Offensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F3. Spawn F-5E-3 Defensive; F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F4. Spawn F-5E-3 Offensive; etc The menu items were created correctly with the correct names. The problem was that, randomly, the list would be reversed but not reversed in the F10 menu. Normally, following this chain would spawn the first item (F10 -> F1 -> F1 -> F1) and this would spawn the last item (F10 -> F1 -> F1 -> F8) but every now and then the items were switched even though the menu text was not switched. Meaning that the following sequence (F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F1. Spawn Su-17) would actually execute the expected result from this sequence (F10 -> F1. Flight Lead Commands -> F1. Spawn Active -> F8. Spawn Mig 29); This is weird and I could not figure out if it was a MOOSE issue or if it was related to DCS. As I understand it, the pattern portrayed in the MOOSE Test code creates a scheduled task to create the menu hierarchy and this hierarchy is recreated each time that the scheduled function is called. Sometimes it seemed that although it was creating the list in the correct manor, DCS was interpreting the underlying calls to be in the reverse order. DCS would display the menu in the correct sequence but when the sequence was called it would be, in effect, reversed. I was wondering if that seemed plausible from the MOOSE framework point of view. I was thinking that maybe I was hitting a spot where I was accessing the menu items at the same time that it was being re-written so I extended the time between the scheduled function calls and could reliably get the right spawns about 70% of the time. Weird? In the end I removed the scheduled function calls to create the MENU_CLIENT_COMMAND and replaced it with a static global set of MENU_MISSION_COMMAND calls. I will attach my code but I would guess a mission would be better? The commented code at the bottom replaces the code just above it. I do not think it is the MOOSE calls as I am using them sequentially and unless MOOSE is caching them (?). Instead I think that it may be related to the nature of having a scheduled function replace the menu structure every 20 seconds or so - ie: replacing the menu structure repeatedly is causing DCS, from time to time, to get confused. Side note: I was considering using the scheduled task once to establish the menu structure and then relying on events (ON_BIRTH, ON_DEATH) to detect the client 'logging on/off to the server since this is targeted at a multiplayer environment. For the mission I have 2 sets of route groups/units (ie: groups with the name Passive Route #001 and the unit name of the single unit in the group set to the same name (note the comments below where I need to change this!)) and a second set of template groups named as Passive_TargetRoute. PS: My earlier problem with DCS World 2.0 with 'late activation' units moving before they are activated is back again :-) do -- TargetRoutes are single unit groups with the group name matching the unit (pilot) name. THIS NEEDS TO CHANGE! Passive_TargetRoutes = { "Passive Route #001", "Passive Route #002", "Passive Route #003", "Passive Route #004" } -- Unit/Group names Passive_TargetGroups = { { spawn = SPAWN:New("P-Su-17M4 01" ):Limit( 10, 10 ), txt = "Su-17M4 Single" }, { spawn = SPAWN:New("P-Su-17M4 02" ):Limit( 10, 10 ), txt = "Su-17M4 Pair" }, { spawn = SPAWN:New("P-Su-17M4 01A"):Limit( 10, 10 ), txt = "Su-17M4 Single AA" }, { spawn = SPAWN:New("P-Su-17M4 02A"):Limit( 10, 10 ), txt = "Su-17M4 Pair AA" }, { spawn = SPAWN:New("P-F-5E-3 01" ):Limit( 10, 10 ), txt = "F-5E-3 Single" }, { spawn = SPAWN:New("P-F-5E-3 02" ):Limit( 10, 10 ), txt = "F-5E-3 Pair" }, { spawn = SPAWN:New("P-F-5E-3 01A" ):Limit( 10, 10 ), txt = "F-5E-3 Single AA" }, { spawn = SPAWN:New("P-F-5E-3 02A" ):Limit( 10, 10 ), txt = "F-5E-3 Pair AA" }, } Active_TargetRoutes = { "Active Route #001", "Active Route #002", "Active Route #003", "Active Route #004" } -- Unit/Group names Active_TargetGroups = { { spawn = SPAWN:New("A-Su-17M4 01" ):Limit( 10, 10 ), txt = "Su-17M4 Single" }, { spawn = SPAWN:New("A-Su-17M4 02" ):Limit( 10, 10 ), txt = "Su-17M4 Pair" }, { spawn = SPAWN:New("A-Su-17M4 01A"):Limit( 10, 10 ), txt = "Su-17M4 Single AA" }, { spawn = SPAWN:New("A-Su-17M4 02A"):Limit( 10, 10 ), txt = "Su-17M4 Pair AA" }, { spawn = SPAWN:New("A-F-5E-3 01" ):Limit( 10, 10 ), txt = "F-5E-3 Single" }, { spawn = SPAWN:New("A-F-5E-3 02" ):Limit( 10, 10 ), txt = "F-5E-3 Pair" }, { spawn = SPAWN:New("A-F-5E-3 01A" ):Limit( 10, 10 ), txt = "F-5E-3 Single AA" }, { spawn = SPAWN:New("A-F-5E-3 02A" ):Limit( 10, 10 ), txt = "F-5E-3 Pair AA" }, } local function SpawnControl_spawn ( _data ) -- Expects : _data._client = _data._client or nil -- Reference to the client, if it exists. Will be nil if it call is from 'global' message command pool _data._spawnobj = _data._spawnobj or nil -- Reference to the MOOSE SPAWN pool object _data._routelist = _data._routelist or nil -- Reference to the list of routes (list of unit names that map to groups) _data._txt = _data._txt or nil -- Basically the Menu Command text _data._grp = _data._grp or nil -- Basically the index of the menu parent entry _data._idx = _data._idx or nil -- Basically the index of the menu entry if _data ~= nil then -- Get the Route Unit (unit whose route we will clone) -- TargetRoutes are single unit groups with the group name matching the unit (pilot) name. THIS NEEDS TO CHANGE! local idx = math.random( #_data._routelist ) -- OLD local UnitName = _data._routelist[ idx ] local RouteUnit = UNIT:FindByName( UnitName ) local RouteGroup = GROUP:FindByName( UnitName ) -- NEW -- RouteGroup = Get Group by Name from Route List (So Route List is a Group List) -- RouteUnit = Get First Unit in Group as the spawn unit (position where the cloned group will spawn) -- Check to see if we have a _client client_txt = "<MISSION cmd>" if _data._client ~= nil then client_txt = "" .. _data._client:GetName() end env.info( "SpawnControl_spawn: Call from client " .. client_txt .. " requesting spawn of " .. _data._txt .. "[" .. _data._grp .. ":" .. _data._idx .. "]" .. " to route unit " .. UnitName .. "[" .. idx .."]" .. " - spawn obj ref: " .. _data._spawnobj.SpawnTemplatePrefix) if RouteUnit ~= nil and RouteGroup ~= nil then local RouteRef = RouteGroup:GetTaskRoute() if RouteRef ~= nil then if _data._spawnobj ~= nil then -- Spawn From Unit (clone from unit ref) and assign the route from the Group that contains the Route Unit local spawn_ref = _data._spawnobj:SpawnFromUnit( RouteUnit ):Route( RouteRef ) if spawn_ref ~= nil then env.info( "SpawnControl_spawn: Call completed with no errors." ) if _data._client ~= nil then -- If there is a client, send a client message _data._client:Message( "Group Spawned via call from: " .. client_txt .. " - Spawned Group " .. _data._txt .. " (" .. _data._spawnobj.SpawnTemplatePrefix .. ")" .. " to route " .. _data._routelist[idx], 15 ) else -- Else send a general message MESSAGE:New( "Group Spawned via call from: " .. client_txt .. " - Spawned Group " .. _data._txt .. " (" .. _data._spawnobj.SpawnTemplatePrefix .. ")" .. " to route " .. _data._routelist[idx], 15 ):ToAll() end else MESSAGE:New( "Failed to Spawn Group; spawn_ref empty after spawn req. Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to Spawn Group; spawn_ref empty after spawn req. Request from: " .. client_txt ) end else MESSAGE:New( "Failed to access spawn obj (from menu call data). Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to access spawn obj (from menu call data). Request from: " .. client_txt ) end else MESSAGE:New( "Failed to get ref to route: " .. RouteUnit .. ". Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to get ref to route: " .. RouteUnit .. ". Request from: " .. client_txt ) end else MESSAGE:New( "Failed to get ref to route unit or route group: " .. _data._routelist[ idx ] .. ". Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to get ref to route unit or route group: " .. _data._routelist[ idx ] .. ". Request from: " .. client_txt ) end else MESSAGE:New( "Failed to Spawn Group; no _data from menu call. Request from: " .. client_txt, 15 ):ToAll() env.warning( "Failed to Spawn Group; no _data from menu call. Request from: " .. client_txt ) end end local function SpawnControl_check () local msg = "Active Spawns:\n" for idx,val in pairs (Passive_TargetGroups) do local GroupPlane, Index = val.spawn:GetFirstAliveGroup() while GroupPlane ~= nil do msg = msg .. "P:" .. idx .. ":" .. Index .. "-" .. GroupPlane.GroupName .. "\n" GroupPlane, Index = val.spawn:GetNextAliveGroup( Index ) end end for idx,val in pairs (Active_TargetGroups) do local GroupPlane, Index = val.spawn:GetFirstAliveGroup() while GroupPlane ~= nil do msg = msg .. "A:" .. idx .. ":" .. Index .. "-" .. GroupPlane.GroupName .. "\n" GroupPlane, Index = val.spawn:GetNextAliveGroup( Index ) end end MESSAGE:New( msg, 15 ):ToAll() end --[[ --]] local grp = "B1" env.info( "SpawnControl: Adding MENU_MISSION commands" ) local MenuBSpawn = MENU_MISSION:New( "Flight Lead Commands" ) local MenuBSpawnPassive = MENU_MISSION:New( "Spawn Passive Group", MenuBSpawn) local MenuBSpawnActive = MENU_MISSION:New( "Spawn Active Group", MenuBSpawn) local MenuBSpawnPositions = MENU_MISSION_COMMAND:New( "Debug: dump route unit positions", MenuBSpawn, SpawnControl_GetRoutePos, nil ) local MenuBSpawnPositions = MENU_MISSION_COMMAND:New( "Debug: dump spawned list", MenuBSpawn, SpawnControl_check, nil ) if MenuBSpawnPassive then for idx,val in pairs (Passive_TargetGroups) do MENU_MISSION_COMMAND:New( idx .. ": " .. val.txt, MenuBSpawnPassive, SpawnControl_spawn, { _client = nil, _spawnobj = val.spawn, _routelist = Passive_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end end grp ="B2" if MenuBSpawnActive then for idx,val in pairs (Active_TargetGroups) do MENU_MISSION_COMMAND:New( idx .. ": " .. val.txt, MenuBSpawnActive, SpawnControl_spawn, { _client = nil, _spawnobj = val.spawn, _routelist = Active_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end end --[[ --]] --[[ SCHEDULER:New( nil, function() local PlaneClient = CLIENT:FindByName( "Trainer #001" ) local grp = "C1" env.info( "SpawnControl: Refreshing Comms Menu for " .. tostring(PlaneClient:GetName())) if PlaneClient and PlaneClient:IsAlive() then local MenuCSpawn = MENU_CLIENT:New( PlaneClient, "Flight Lead Commands" ) local MenuCSpawnPassive = MENU_CLIENT:New( PlaneClient, "Spawn Passive Group", MenuCSpawn) local MenuCSpawnActive = MENU_CLIENT:New( PlaneClient, "Spawn Active Group", MenuCSpawn) local MenuCSpawnPositions = MENU_CLIENT_COMMAND:New( PlaneClient, "Debug: dump route unit positions", MenuCSpawn, SpawnControl_GetRoutePos, nil ) local MenuCSpawnPositions = MENU_CLIENT_COMMAND:New( PlaneClient, "Debug: dump spawned list", MenuCSpawn, SpawnControl_check, nil ) if MenuCSpawnPassive then for idx,val in pairs (Passive_TargetGroups) do MENU_CLIENT_COMMAND:New( PlaneClient, idx .. ": " .. val.txt, MenuCSpawnPassive, SpawnControl_spawn, { _client = PlaneClient, _spawnobj = val.spawn, _routelist = Passive_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end else PlaneClient:Message( "Unable to add Passive Comms Menu for Client: " .. tostring(PlaneClient:GetName()), 15 ) end grp ="C2" if MenuCSpawnActive then for idx,val in pairs (Active_TargetGroups) do MENU_CLIENT_COMMAND:New( PlaneClient, idx .. ": " .. val.txt, MenuCSpawnActive, SpawnControl_spawn, { _client = PlaneClient, _spawnobj = val.spawn, _routelist = Active_TargetRoutes, _txt = idx .. ": " .. val.txt, _grp = grp, _idx = idx } ) end else PlaneClient:Message( "Unable to add Active Comms Menu for Client: " .. tostring(PlaneClient:GetName()), 15 ) end end end, {}, 10, 20 ) --]] end

I did not think that it was possible to access the resources of the airbases from within Lua. Is that a thing now?

Thanks for the hard work and dedication FlightControl! It is appreciated!

Forum moderation is a thankless job. Really. And I think that the moderators here have a very fine line that they are trying to follow. I do not envy them their task. They are never going to be seen as right when they have to intervene and us simmers can be a passionate, passionate group. They need to protect the brand and the atmosphere while striving to find a way where critical feedback (beneficial criticism) can occur without getting out of hand. And that ain't easy. Hey! We love our hobby! We want to see more! We want to see better! I would love to see forum software that could detect tone and institute a cool down period before some people could throw up a post. Then, if you still want to do it, well that is up to you. The largest problem we fall into as a group is being so passionate about what we want and often, instead of admitting that we might have been aggressive or personal with post we get defensive and double down on the rhetoric. That and we fail to manage our own expectations. I am thankful for the moderators here. I might not agree everything that happens but I would rather this than having a steaming pile of aggressive negativity permeating the group. I just wish that people would be less polarizing in expressing their opinions and that they stay away from trying to be the loudest voice in the room - that is not how you get results.

Thanks FlightControl! I am looking forward to digging into the new release in the new year!

The DCS Witchcraft utility does work and provides a Lua interface that can be used to query the game live. That lives here: https://jboecker.github.io/dcs-witchcraft/ I have that working but each patch/update means I have to reconnect it. :-) That an there is a utility called snake-tail which will follow log files as they are generated (like the tail utility for unix)

Thanks FlightControl! I have been using MOOSE in my missions a fair bit. I have a semi-dynamic helicopter mission based on nodes I scatter around the map - meaning ground forces attack and defend the nodes. I am hoping to make some use of the Mission Orchestration and Cargo Handling features of MOOSE .. when I get back into that mission. If I can, anything I come up with I am going to try and contribute to the code base but that is a looong way off at the moment! Thanks for doing this work! It has made my mission building life so much easier.

Looks good. Order placed :-) And I have mentioned this on the Mudspike forums too. More exposure never hurts :-) https://forums.mudspike.com/t/the-contollr/2990/54?u=fridge

That is true and a cool idea. I was thinking more of the panel that sits in front of the throttle (with the knobs on it). I think it slopes up a little more than the throttle. But either way, options are good. I wouldn't stress or delay anything because of this :-)

I think that is probably ok. I thought at first that everything on the side panels (left and right sides of the cockpit) were all flat. I see that the panel that goes in front of the throttle slopes down to the throttle a little, which is what I was looking for. Plus, if you design/make the CUBs able to connect like that, it doesn't take too much to adapt to that design and help them tilt a little more if you need it. It is really hard to find a good profile picture of the side panels (or at least my google skills are not up to the challenge) :-)

This would be quite useful! If I could have the panel sit in front of my Warthog throttle and slope up it would fit my setup perfectly! Looking forward to this addition, the DYI set and the next box! :-)

I should have clarified that earlier. I match group and unit names for these. Since the groups that I use for paths are single unit groups, I match the group name and unit name to make it clear (to me) which group I am referencing without having to worry about it having a different unit name. That is possibly not the clearest thing I could have done but it seems to work :-) So in this case, I am re-using UnitName as both the Unit to spawn in as and the GROUP Name to get the path for. I did post an edited version of this question (my earlier post) to the DCS World OpenAlpha forums and Grimes did a quick test and did find that the late activation units are moving. His code for spawning the unit, however, did reset the path. I take this to mean that the Late Activation unit is moving (and it shouldn't) but when he assigns the position and path to the cloned unit it seems to reset to the path start. I am waiting for a follow up on that post to to see if there is a difference in how MOOSE handles the clone and path/route assignment and how his code handled it. I could be that the way MOOSE clones and assigns the route was sensitive to the position of the Late Activation unit in a way that his code is not (a choice of how to assume where the 'start' position is). I will let you know what comes of it. Here is the brief thread: https://forums.eagle.ru/showthread.php?t=177975

I have a really stupid question. Should 'Late Activation' units be moving? I have a situation where I am trying to spawn in some 'target' units via radio calls. So here is the expected MOOSE pseudo-code 1. Put a pair of 'spawnable' units in the ME. One is a single element group (1 ship) of target aircraft and the other is a pair element (2-ship) of target aircraft; 2. Put in a set of paths that these spawnables get assigned to randomly; 3. Set all of these groups/units to 'Late Activation' so that they, I think, do not spawn it. 4. Set up a radio menu to allow the pilot/client to request a spawn; 5. Set up a spawn function to spawn one of the spawnables (point 1 above), get a random path (point 2 above) and spawn the spawnable in on that unit (SpawnFromUnit) and assign that route (Route( GROUP:FindByName( UnitName ):GetTaskRoute() ); The issue is that at mission start, if I call the radio commands then the appropriate actions happen (the requested group spawns in on the randomly assigned unit/route). That is all fine. The problem is that if I wait, take off and fly to the target area and then request the spawn, the unit/route position is a hundred miles off to the west?? So, to try and figure out what might be happening I added a debug menu command to send a message to everyone with the North and East positions of all of the paths (point 2 above). And, before spawning anything, I call that menu command twice to view the output. I expect that the positions of the 'Late Activation' units would be 'static' until they are activated via the above SpawnFromUnit and Route calls BUT I am seeing changes in the position! That tells me that the 'Late Activation' units are actually activating but are hidden? Am I crazy? I want to ask here before to make sure my MOOSE calls are correct. I want to avoid the obvious first response :-) So here are the spawnables: SpawnSingle_Template = SPAWN:New("RED Target 01"):Limit( 10, 10 ) SpawnPair_Template = SPAWN:New("RED Target 02"):Limit( 10, 10 ) and here is the array of unit/route/path units: RedRoutes = { "RED Target Route #001", "RED Target Route #002", "RED Target Route #003" } and here is how they would be spawned: local idx = math.random( #RedRoutes ) local UnitName = RedRoutes[ idx ] local SpawnUnit = UNIT:FindByName( UnitName ) SpawnSingle_Template:SpawnFromUnit( SpawnUnit ):Route( GROUP:FindByName( UnitName ):GetTaskRoute() ) and here is what I am doing to get and report on the positions of the 'Late Activation' units: for unit_idx,unit_val in pairs (RedRoutes) do local tmpunit = UNIT:FindByName( _unitname ) local tmppos = tmpunit:GetVec2() <cut putting that into a message for all> end Everything from the MOOSE code should be fine but it seems that my assumptions about 'Late Activation' has changed with a recent patch ... oh ... DCS World 2.0.4

Question: If I despawn a group with the DCS destroy() command, the count of those units get removed from the Spawn object? Example: I have a supply group that I create a SPAWN object for. That group and set it to Limit (10 Units and 2 groups). When they are spawned with Spawn from unit, they are assigned a Route with the proper call and they head out. If they reach the destination (something I am polling for), they are destroyed by getting the DCS group and calling destroy. I can do this one more time before I run out of units from the SPAWN object instance. Is there a way that I can 'return them to the pool' of spawnable units? EDIT: Switched to the MOOSE GROUP:Destroy() call and I can see the SPAWN:SpawnCount stays the same but the SPAWN:AliveUnits goes down. It seems that the SpawnCount (counting groups) does not (and maybe is not intended to) be lowered when a group is destroyed?

That is the way I always feel in Lua :-) And don't worry about rushing a new release. All of that documentation, testing, demoing and training takes a lot of time. I will share what I am working on when it gets a little clearer. Right now I have the framework for something that may provide something for helicopter pilots to fly against :-)

Yes. I thought they might maintain their order once they were placed with something like SpawnFromVec2. I see the difference now :-) BTW: Much respect for hat you have done here. The code, documentation and test missions are very well done! I can see the obvious work that you put into them!

I think I understand. The Array () function is intended to have the Spawn object visible and ordered ... which means that the template is visible. When I call SpawnFromVec2 I am creating a clone of that template at the vector but it does not conform to the ordered positions of the template. IE: the template placement on the map (positions of each unit in the group) does not get copied to the cloned instance. TLDR: I am misinterpreting the function.

Ok here it is. I think I have stripped out most of the useless bits. In the DG_Ops_tmp-01.lua script, lines 91,92. I think that each of the depot groups should be spawning in formation but I may have something wrong. Depots-tmp-01.miz

Thanks for the reply. I will try to get that done either tonight or tomorrow night.

I have a question. Maybe I am just misunderstanding the behaviour but is it possible to spawn a group as an array at a particular Vec2? This works to spawn my group in the intended zone Depot_Spawned = SPAWN:New ( Depot_Template_Name ):Limit (5,1) Depot_Spawned:SpawnFromVec2 (Zone_Vec2, 50, 5) Which works .. in that the units I intended get spawned within 50m of the zone Vec2 position. When I add the array call in, like this: Depot_Spawned = SPAWN:New ( Depot_Template_Name ):Limit (5,1):Array (45,10,30,30) Depot_Spawned:SpawnFromVec2 (Zone_Vec2, 50, 5) which I think means to spawn them facing 45 degrees, 10 wide, 30 m, delta 30x, and delta 30y), I get a nice line of units from the right group but (there had to be a but :-) ) they are located at the position of the template group and not at or near the Vec2. I assume I am doing something wrong. Lua is not mu first language :-)

That. Is. Cool. If that worked in Multiplayer it would be awesome! Wonder if that is something on ED's radar? To fix that for Multiplayer?

I had not thought of that. Thanks. Ahh, what? This sounds interesting but I am not sure I understand. Do you set the audio transmission up as a Task Action and then use AI PUSH to trigger it? Interesting.

So adding a Stop Radio Transmission call immediately after the Radio Transmission call terminates the transmission before it really starts (I am assuming nanoseconds of processor time). The only way I could think of to get around this, and still have the transmissions occur on a particular radio frequency, was to add a Flag On call after the Radio Transmission and then another Continuous event to capture the Flag is True AND Time Since Flag conditions ... allowing me to way a few seconds before terminating the transmission. This seems really odd. The only way around this (if it is indeed implemented as intended) is to just use Sound To Coalition/Group instead. But that means people can not 'tune out' of those calls if they are doing something else (ie: they can not tune to a different frequency). I am a little worried that having n Continuous Event checks in the mission editor gets worse when you have m additional Continuous Events to clear the radio comms. Maybe I am not using these functions as intended in the Mission Editor?

Ahh. Ok. I was wondering if Stop Radio Transmission was required or not. Do you know if it is called immediately after Send Radio Transmission, does it cut off the initial transmission? I can test this later today after work.