Hardcard

GROUP:GetHeight(FromGround) Returns the [u][b]average[/b][/u] group height in meters What some MOOSE users do (myself included) is create a separate group for each unit, that way we can use GROUP functionalities with individual UNITs (then use SETs to target all those single-unit groups at once). So, in this case, this would return the height of your L39 (since it's the only unit in the group, the average height of the group would be the actual height of that L39 unit), which should be good enough for what you wanted to accomplish. It's either that or finding workarounds, like you did. Anyway, you can always do what Grimes suggested, his scripting Wiki is quite useful, you can combine it with MOOSE without problems (as far as I know).

UNIT functionality in MOOSE is limited, you can do considerably more stuff at GROUP level. This is probably what you were looking for: GROUP:GetHeight(FromGround) Returns the average group height in meters. Parameter •#boolean FromGround : Measure from the ground or from sea level. Provide true for measuring from the ground. false or nil if you measure from sea level. Return values 1.DCS#Vec3: The height of the group. 2.#nil: The GROUP is not existing or alive. The solution you found seems nice enough, though. Maybe "GROUP:GetHeight(true)" uses a similar method to find the value.

@ Colmillo Parece que tienes los mensajes privados desactivados, puedes enviarlos, pero no recibirlos. Cambia la configuración de tu cuenta (customize profile > Edit Options > Activa "Enable Private Messaging" y desactiva "Receive Private Messages only from Contacts and Moderators")

Maybe take a look at MOOSE Tasking documentation. Never used any of that myself, but sounds like a "graceful" way of managing tasks and missions. In any case, you can always create the abort commands yourself, which would remove all the mission related stuff and reset everything (that's what I do).

@Colmillo I'm afraid this would require a full script in order to work as intended. I've written scripts that accomplish similar things, problem is that you'll need basic Lua knowledge to understand them. Using scripts, I was able to determine the amount of external fuel tanks on, say, an F15C (based on fuel quantity), then use fuel quantity checks while refuelling, in order to receive different kinds of messages (air refuelling "success" or "failure", basically), which took the number of external fuel tanks "detected" into account. Flags and/or scheduler stoppers can be used to prevent those messages from showing all the time, which is probably what you want. Spanish is one of my native languages, so, if you want to, I can show you the basics of Lua, that way you can create your own scripts and overcome the limitations of the Mission Editor. Mándame un privado y te comento.

Yes, that's one way of doing it. Did you manage to get it working?

Can't you load the main ATME script normally and then use Frag's trick to load the rest of scripts dynamically?

What do you want to achieve exactly? 3 missiles per "Fire at Point"? For this, you'll need to check "ROUNDS EXPEND" checkbox and then select 3. You can do this multiple times by simply cloning the task. Keep in mind, though, that the cruiser will perform just one task at a time, not all of them at once. Also, the missile rate of fire isn't that high, it takes time for the 3 missiles to be fired. Remember that you can also use an "Attack Group" task for this. If you do, the cruiser will keep attacking the target until it's destroyed.

I've achieved this using Ticonderoga-class cruisers ("CG-60 Normandy" ship in DCS). It fires tomahawks at ground targets. Using ME functionalities, you should be able to set up a "fireatpoint" task for the ships, then define the kind of weapon to be used and the amount of ammo (missiles) to spend. Alternatively, you could use an "attackgroup" task, I guess. I did it via MOOSE script myself, but in the end it's the same kind of thing.

Yes, that seems correct.

Mission Editor doesn't read the attached script and sound files dynamically. When you attach any file to a mission in ME and save the mission, you're actually creating COPIES of those attached files and saving them inside the .miz file for that mission (it's a one time thing). This process needs to be repeated every time you make changes to those files. I think there's a way to make ME read files dynamically, but you'll need to set up symlinks in Windows.

Hi there There's no way of targeting individual units directly in the current DCS scripting engine. Groups, however, can be targeted individually. So, what you need to do is create groups composed of a single unit, that way you'll be able to target them (ie. 2 groups, one boat in each of them). EDIT: As for getting group coordinates in MOOSE, you can use: GROUP:GetCoordinate() Check the MOOSE documentation for GROUP and CONTROLLABLE functionalities (both apply to groups). In order to get the distance between the coordinates, you can use: COORDINATE:Get2DDistance(TargetCoordinate) Check the MOOSE documentation for COORDINATE functionalities. As for the message trigger, I'd use a simple distance check within a scheduler (which could be programmed to stop once the distance check returns "true"). The thing that you need to decide is the message recipient(s), though. Will it be a message for all, for coalition or for a group(s)? Hope this helps PS: An alternative method would be to create a 200m trigger zone around either of the boats (the zone would move with the boat it's attached to), then use GROUP:IsCompletelyInZone(Zone) inside the same kind of scheduler, in order to check for the presence of the other boat. Check the MOOSE documentation for ZONE functionalities.

Yw, Delta! The credit goes to Mechanist, for the most part, since I took the concept from his tanker script, which he posted on the MOOSE Discord channel and was kind enough to explain. @rassy7 You bet it cuts out lines of code, my mission went from 5600 to 800 lines :D (not to mention the time savings) Now if you want to create customized group menus for different client groups, all you have to do is include those in a separate SET_GROUP (which would target them specifically, via prefix filters, for instance), then run the iterator for that SET_GROUP and pass on the client group value to the relevant functions. Easy peasy! PS: I'm worried about MP functionality, though, I have only tested this in SP. I'm guessing that several modifications will be required in order to use this kind of thing in MP missions.

Hi there again! I've got great news!!! Thanks to the nice people over the MOOSE Discord channel, I've finally learned one way of using SET_GROUP iterators to manage client group menus/menu commands! Remember that my test mission had 14 scripts (one for each client)? Well, NO MORE!!! I've managed to get the mission working properly with just 2 scripts (one per coalition)... actually, it might even work with just a single script, haven't tried merging the scripts yet, but it might work. The good news is that the method I used in the script will allow you to do precisely what you wanted: target individual client groups without the need to use checks for each of them (or separate scripts for each client group). I'm attaching the updated test mission and the 2 scripts that are used in it. Haven't had time to comment it yet, but it's basically the same kind of script, with a few minor modifications. NOTE: Now there's a permanent scheduler in place that refreshes/creates the basic loading menu for active clients every 5 seconds. If the F10 menu is missing after switching clients, simply wait for 5 seconds tops, it'll appear! :thumbup: Zone Client Detection with working SET_GROUPS for clients.miz Client Zone Detection Test MooseClient RED.lua Client Zone Detection Test MooseClient BLUE.lua

Hi again! After several hours I've managed to comment the whole script with a fair amount of detail. In the end I've decided that there's no need to comment the script for the BLUE coalition, since both scripts are very similar, there are no fundamental changes between the two. Also, this Su25T RED script can be used for the rest of RED clients in the test mission (as long as ALL instances of "Su25T" in the script are replaced AND the client group name in line 36 matches the client group name in ME). I hope you'll find this specially useful :book: :thumbup: Client Zone Detection Test Su25T RED (commented).lua

Thanks for that. That's probably why the blue coalition cruisers in my mission target the same enemy ship all the time... I deployed them on the map using the "copy/paste" method in ME. I'm truly hoping this is the cause of the issue.

Tomorrow I'll start working on a commented version of the "generic script" for this mission. I'll post it here once everything is checked and tested. In the meantime, the 14 relevant Lua scripts are located in "Zone Client Detection Demo v1.miz\l10n\DEFAULT" (Unpack them with WinZip/WinRAR/7Zip or whatever.) Keep in mind that all these are simply copies of 2 "generic scripts" (BLUE and RED), just take one of each and you'll have the full script structure, so to speak. I'm attaching the BLUE and RED "generic scripts", which, in this case, target the respective Su25T client groups in each coalition. It's 360 lines each, so take it easy :book: As I said, tomorrow I'll start preparing truly generic coalition scripts, with comments for each function/method. Much easier to understand what I did that way :thumbup: Client Zone Detection Test Su25T BLUE.lua Client Zone Detection Test Su25T RED.lua

Hi there! After a few days of expanding, testing and debugging the demo mission, I think it's finally ready for prime time! :thumbup: As I said earlier, I haven't been able to use SET_GROUP iterators to handle client group menus, I've had to use separate scripts for each client group instead (7 client aircraft for each coalition, 14 total). All client aircraft are basically from FC3 (Su27, Su33, MiG29S, J11A, Su25, Su25T, A10A, F15C), but I guess any flyable aircraft could be added, as long as it's fully functional within the DCS scripting engine. Adding new clients is actually not that much work once you nail down the "generic script" for each coalition. Just make a copy of that "generic script" for each new client in the coalition, then simply replace the client group name within the script as required, it'll work. (Can't be grateful enough to the person who created the "Replace All" functionality in text editors :smilewink:) Each active client group in zone should get its own group menu/menu commands, which enable several kinds of functionalities: Client zone menu: -Active client group identification -Smoke ground units -Ground units open fire -Ground units hold fire -Remove alive ground units -Call in helicopter strike -Call in bomber strike -Call in fleet Fleet menu: -Request naval support (fleet weapons free + attack enemy ground target area for 2 minutes RED and 1 minute BLUE. Fleet AI is switched off after that, to avoid unwanted engagements) -Switch fleet AI on (Added) -Switch fleet AI off (Added) -Remove alive vessels Everything runs on a client group zone "detector" scheduler, which needs to be activated manually. I've set it up like this because, otherwise, the scheduler would run all the time, consuming resources pointlessly. Once the scheduler detects the relevant active client in zone, it'll enable the client group menu tree and stop (all functionalities within the group menu will still work, don't worry). In order to get a "fresh" group menu tree, just rerun the scheduler (select "Load test!" menu command) and get back inside the zone (if you aren't in it already). I've done quite a lot of testing and everything seems to work pretty much as intended. Might've missed some stuff, though, if the mission gives you trouble, just let me know! I'd be specially interested in knowing if this actually runs on MP... I've put some spawn restrictions in place (to prevent undesirable "multispawning"), but I have no way of testing it in MP... it would be great if someone could test it for me. NOTE: I foresee menu inconsistencies in MP, after other players decide to spawn/remove AI units, due to the lack of permanent menu refresh schedulers in the script. For instance, if another client (aka player) decides to remove the allied fleet from the map after you've called it, you'll be left with a useless fleet menu... this could be avoided with permanent schedulers, but I'm not a fan of those. Hope you find it useful! PS: I guess I could also create a commented version of the "generic script" of each coalition, explaining exactly what every line/function/method does. Let me know if you're interested in such a thing. EDIT: I discovered a couple of problems in the script logic, so I had to fix them. Also added some additional functionality for fleet management. Attached test mission updated!!!! Zone Client Detection Demo v1.miz

For the last two days I've been "investigating" different ways of targeting individual client groups when in zone. First, I tried using a client SET_GROUP and iterators in order to handle group menus (it's definitely a nicer method), problem is that only the first client group detected in the zone would get the group menus... (I was probably missing something) Then I tried to mix coalition and group menus in the same script file, but DCS didn't seem to like it. Finally, I reverted back to the good old "one script file per client group" method, this finally worked as intended. I'll post a simple demo mission tomorrow (it was a lot of fun to create). It allows for specific client group detection when in zone and provides several functionalities via group menus/menu commands specific to each client group (combat group engage/disengage, smoke, remove combat groups from map, fleet bombardment, etc.). Truth is that once you get group menus/menu commands working for each client group reliably, you can pretty much do anything. While creating this demo mission I learned some handy new methods that I didn't know before, also, I've managed to get SET_GROUP iterators to handle some stuff successfully (SET_GROUP engage/disengage/remove from map). Next step is figuring out how to use those same iterators to handle group menus :thumbup:

:D The problem is that you want group menus/menu commands, this makes things tricky (based on what I've seen). Group menus are a pain in the butt, since they'll stop working as soon as you switch clients. Maybe it's just that I don't know how to set them up properly, but the thing is that I asked around the MOOSE Discord channel about this a few months back and, based on the replies I got, it seems like a genuinely tricky issue (a DCS Group bug seems to be involved). The only solution I've found so far is precisely what you mentioned: writing a separate script for each client group. Sure, it's not elegant, but gets the job done, which is what matters in the end (you can crash, respawn and switch clients as much as you want, the group menus always seem to work that way). Is your mission meant for SP or MP? I mean, if you are going to use it for SP only, why not simply use coalition menus/menu commands? No need to target individual groups then, which makes it all a whole lot easier.

Yup, that's kind of "buried" within the MOOSE documentation. It's actually explained (sort of) here ...in a pretty loose and indirect way :cry: SPAWN:New("WhateverMEGroupName") simply defines a late activated group in ME to be used as a TEMPLATE. SPAWN:Spawn() spawns a COPY of said template on the map (hence the "#001" after the ME group name). I agree that this should be clearly explained in the MOOSE documentation, since this is the sort of thing that can potentially drive people away from MOOSE. EDIT: Tbh, it's explained at the start of the page I linked above. Problem is that we lowly noobs have trouble connecting the dots sometimes... :doh: In any case, just remember that I'm using variations of the method I described above in the mission I'm working on, so I should be able to provide practical examples. Good luck!

Yep, that's the way I do it in MOOSE. Just create a separate group for each client and target it every time you want to send text and sound messages to that specific client. Btw, you can use scripts to subscribe groups to certain events in game (EngineStart events, for instance). Now, there are still ways of accomplishing the kind of stuff you described without having to put all clients in a single group. You can create sets of "single-client groups", which will allow you to target them all at once, so to speak. Alternatively, you can also set stuff at coalition level (as you already did).

Why do you need to use GROUP DEAD, exactly? Also, can't you achieve the same goal using MOOSE scripts only?

OnSpawnGroup comes in handy when you only need to handle one or two groups. Any more than that, I'd use SETs and iterators instead. (More on this below.) 1) & 2) I'd create a new SET_GROUP containing all the relevant clients in your mission. (Note that these must be groups composed of just a single client aircraft). Then I'd run ":AnyCompletelyInZone()" SET_GROUP iterator inside a scheduler, in order to regularly check for the presence of clients within the zone specified in ME (and then run the function(s) you're interested in for each of the groups in the SET_GROUP) With that, you can create the group menu commands responsible for spawning the AI bandits when your specified clients are in zone. 3) Not sure about the invisibility thing (since I've never used it like that), but those late activated enemy groups can be included in another SET_GROUP (which you can filter as you like), and spawned/handled according to your needs. Important note regarding late activated group names in MOOSE: If you're interested in script/mission examples of this, just let me know. I should be able to set up a demo mission for you (it would be good practice for me too :thumbup:)

@Delta99 Ok, thanks for the clarification :thumbup: