Hardcard

After a quick test, at least I can confirm that the script runs from start to end (no apparent errors). Are you sure about the type, system and frequency values? There's a chance the enumerators from the Hoggit wiki are outdated. This is the SystemName enumerator table according to the current BeaconSites.lua file (located in Gamedir\Scripts\World\Radio). As you can see, these system enumerators don't match the Hoggit Wiki's: For the beacon types, I've found the following enumerator table in BeaconTypes.lua (also located in Gamedir\Scripts\World\Radio) Btw, I've seen this mod, perhaps you'll find it useful.

Yes, I noticed the submenu message problem as well. I think it was caused by the scheduler calling RadioMenu() again (thus creating a new menu structure), while the client was still using the previous menu structure (which no longer existed). With a sufficient scheduler delay (30 seconds or so), I was able to access all menus and get all the correct messages, since it was all done before RadioMenu() could be called again by the scheduler. As for removeItemForGroup(), I can confirm that it worked for me. When I commented the line out, radio menus started stacking every time RadioMenu() was called. So definitely keep it on, don't comment it out.

Tbh, I've never used such an iterator (the for loop). Have you verified that _id.groupID actually returns a valid group ID? If you add the following line at the very start of RadioMenu() function, do you get the client name and the group ID? trigger.action.outText(_id.name.." group ID = ".._id.groupID,10) If you don't, then there's your problem, I guess. If you do get them, then try commenting out the removeItemForGroup() line, see if the menus appear then: missionCommands.removeItemForGroup(_id.groupID, nil) EDIT: I've tested the script in a single player environment (switching between 2 clients) and I can confirm that both clients get the menus consistently. _id.name and _id.groupID seem to return the correct values. It's a matter of giving the clients the unit names MERLIN1 and MERLIN2 respectively... at least in a single player environment. This is the script version that I tested (I run it using a MISSION START trigger): Perhaps things get trickier in multiplayer environments, which might explain why your clients don't get the menus. Btw, I've noticed another mistake in the following line: function sub11(IDval) trigger.action.outTextForGroup(IDval.groupID, " You have entered submenu 11", 10 , false) missionCommands.removeItemForGroup([color="red"][i]val[/i][/color].groupID,{"SubMenu 1.1.","MainMenu 1"}) [color="Blue"]-- I guess it should be [i][b]IDval[/b][/i] instead of [i][b]val[/b][/i][/color] end In case you want to make the menus client-specific, I guess you could use groupID checks (you'll need to know the group ID of each client beforehand) :

And what's the problem exactly? Are the clients getting both nested menus instead of just the one? If it's not running, could the problem be related to the following bit?:

If you have trouble getting the Immortal command in ME to work, the following script will do the trick (required field marked in red):

When you say "SAM" what do you mean, exactly? Is it a single AA unit or a SAM group (radars + comms + launchers)?

@Colmillo And I thank you back for your kind words (I also thank Chile for Arturo Vidal :D)

@Colmillo I guess you're asking for something like this (it's standard DCS code, don't need MOOSE or MIST):

I mean...

@BoneDust I'd try it without route randomization (in case it's messing with ME wp tasks, somehow). If it still doesn't work, I guess you could script the tanker enroute task instead. I'd use :OnSpawnGroup() combined with :EnRouteTaskTanker(), with some sort of logic to decide when to push the task.

@BoneDust What about EWR_Red ? As I understand it, the error you're getting says that your A2ADispatcher global variable is invalid (so it can't be indexed): A2ADispatcher = AI_A2A_DISPATCHER:New( EWR_Red ) Are you sure that EWR_Red is a valid detection object? Are you sure it exists while the script is running?

I'll try to explain as best as I can. Afaik, the following code only defines ActivateBeacon task (or command, in this case). It doesn't do anything else: ActivateBeacon = { id = 'ActivateBeacon', params = { type = 16408, system = 7, name = 'Beacon', callsign = 'AA', frequency = 123000.0, } } The beacon needs to be assigned to a group/unit, so you need to specify that group/unit in the script, otherwise it won't do anything. Always keep in mind that scripts are "blind and dumb", meaning that they won't see/know/do anything that isn't specifically defined. In this case, you need to tell the script how to find the group (or unit) in your mission, and then instruct it to run the task/command that you've defined.

Could you share it?

Post your script here, there might be problems with it. I think the task needs to be pushed, like this: My_Group = Group.getByName("group name in ME") ActivateBeacon = { id = 'ActivateBeacon', params = { type = type_enumerator, system = system_enumerator, name = string, callsign = string, frequency = number, } } [color="Red"][i]My_Group:getController():pushTask(ActivateBeacon)[/i][/color]

@HawkHunter You could've just uploaded the lua script file instead :cry: I didn't have group tasking in mind when I created the original script, it needs to be added (either via ME tasks, like Habu_69 has suggested, or via scripted tasks).

I guess you could create a zone around the building (MOOSE allows you to set inner and outer zone radius for several methods) and get a random coordinate from it, which you could use to spawn the unit/group. Here's a MOOSE script example: If you want to do this for hundreds of buildings, though, I don't think this is a realistic solution :D

According to mist_4_3_74.lua, this is what happens when respawnGroup() is called: Anyway, I've no idea of what the problem might be, see if you can reach Grimes, he'll be able to help.

I don't know how MIST handles spawns, but if it works like MOOSE, you might have a problem with the group name. In MOOSE, every time you spawn a late activated group you're actually creating a copy of it (the original ME group is never spawned, it only acts as template). As you know, when you make copies of units/groups in ME, a #number is added to the unit/group name. In your case, perhaps this is what's going on: [color="Blue"]-- 'M29C' group is spawned as 'M29C#001' the first time around[/color] if Group.getByName('M29C') then [color="blue"]-- Group can't be found [/color] trigger.action.deactivateGroup(Group.getByName('M29C')) [color="blue"]-- Group can't be found[/color] end Run this script right after M29C group spawns for the first time to see whether it spawns as a copy or not:

I think he meant unit names. I seem to recall that the given ME unit names aren't kept when spawning units with MOOSE, only group names are (+ suffix, ofc). In any case, I'd ask this sort of question in the MOOSE Discord channel.

@Mano Sorry, I focused so much on the Position3 table explanation that I forgot to mention what Wingthor pointed out at the beginning. :GetHeading() is a MOOSE method, only compatible with certain MOOSE classes (in this case, UNIT class), whereas Unit.getByName() is a DCS class + method which returns an incompatible DCS object. Always pay attention to the kind of classes and methods you're using. DCS classes require DCS methods (and vice versa), MOOSE classes require MOOSE methods (and vice versa): You can still mix standard DCS code with MOOSE code, of course, but only if you observe class-method compatibility. Here's a quick way of getting the DCS unit from a MOOSE unit (it also works for GROUP class): UNIT:FindByName("name in ME"):GetDCSObject() The opposite operation isn't even worth trying, since it's quicker and simpler to get the MOOSE object directly: [color="Blue"]-- Instead of this:[/color] DCS_Unit = Unit.getByName("name in ME") MOOSE_Unit = UNIT:FindByName( DCS_Unit:getName() ) [color="blue"]-- Simply do this:[/color] MOOSE_Unit = UNIT:FindByName("name in ME") [color="Blue"]-- And once you have the MOOSE object, you can do this:[/color] Heading = MOOSE_Unit:GetHeading() Now, by BRC I'm guessing that you're referring to the Base Recovery Course of the carrier, right? In that case, I believe that the carrier's heading is all you need: carrier = UNIT:FindByName("carrier's unit name in ME") BRC = carrier:GetHeading() As for the "client-specific" F10 commands, I think I'll be able to help with that (like Wingthor said, it's a matter of passing the group object as argument when you call the function) Finally, as Wingthor mentioned, you should join the MOOSE Discord channel, it's a great place to get all sorts of help.

@Mano At first glance, there's a clear problem in the following part: carrierPos = carrier:getPosition() posMessage = MESSAGE:New([color="Red"]carrierPos[/color],25,nil,true):ToAll() MESSAGE:New() requires a string as first parameter, but you're giving it :getPosition() instead. :getPosition() doesn't return a string, it returns a table which contains a position + orientation tables: Position3 = { p = {x = number, y = number, z = number}, [color="blue"]-- Position subtable[/color] x = {x = number, y = number, z = number}, [color="blue"]-- X axis orientation subtable[/color] y = {x = number, y = number, z = number}, [color="blue"]-- Y axis orientation subtable[/color] z = {x = number, y = number, z = number} [color="Blue"]-- Z axis orientation subtable[/color] } Now, if you want to get the x y z coordinates of your unit relative to the map's origin, then you'll need to access the x y z values within the p subtable, like this: If you want to get the carrier's orientation instead, you'll need to access the x y z subtable values by navigating through the indices using single dots, as shown in the spoiler code (Ignore the double dots .. , those are used for concatenation of strings and variables within the body of the message) Regarding the message recipient, DCS doesn't allow for messages to be sent to individual units/clients. The best you can do is send the message to the client's group (I think there are ways of making it work even in multiplayer). As for getting the heading of the carrier, you can use :GetHeading(), no need to mess with the position + orientation tables (they won't tell you the carrier's heading anyway).

You'll need to use sets and iterators then. Depending on what you're trying to achieve with those flags, it could be done without them, which would make the script shorter and simpler. Now, if you really need all those flags, then you could do something like this (MOOSE script example, required fields marked in red): As I said, this would be much less of a hassle without all those specific flags. Depending on what you want to achieve, they might not be needed. What do you mean exactly? Are you referring to syntax? Here's an example:

@Sierra99 Nice :thumbup:

@Cyclonictank Aside from what EntropySG said, I don't recommend writing your scripts directly in ME. Use either Notepad++ or LDT to write your scripts for DCS (I recommend LDT because it has intellisense). explaining how to set yourself up. As for the script itself, you could do this for each group you want to respawn in your mission (these groups must be set to late activation in ME. Modify coloured fields according to your mission needs): The script will spawn the units in the group (up to the specified maximum number and provided they aren't already present on the map) every time the spawn scheduler runs. If the maximum amount of units in that group is already present on the map, none will spawn. When all units in that group are destroyed, new ones will spawn the next time the spawn scheduler runs (this will go on as many times as you specify)

@Cyclonictank Make sure that you're using the include version of Moose.lua in your mission. Also, it would be better for you to post both the script and mission here.