Hardcard

@Z4ng3tsu Don't know about AI helicopter behaviour, but I believe you can make your code shorter.

In order to work with late activated groups in MOOSE, you can use either: 1- SET_GROUP:New() + a filter to target specific groups --> SET_GROUP:FilterPrefixes(Prefixes) & SET_GROUP:FilterStart() + some iterator like -->SET_GROUP:ForEachGroup(IteratorFunction, ...) Example: 2- SPAWN:OnSpawnGroup(SpawnCallBackFunction, SpawnFunctionArguments,...) Example: Hope this helps.

@Skippa I had a similar issue with LDT some months back. If I remember correctly, I solved it by doing this: -Uninstall Java using this tool -Remove all traces of any previous LDT installations from your system -Download/Install Java 8 from here -Use this LDT build -Then simply follow the rest of instructions from PS. I'm assuming you have a 64bit version of Windows, btw.

Glad you got it working! PS. The MOOSE discord channel always delivers (might take weeks / months sometimes, but it always does! You just need to be patient.) :thumbup:

AFAIK, infantry units don't actually "embark", they are simply removed from the map, giving the impression of embarking. When it's time to "disembark", what actually happens is that new units are spawned (which are copies of the previously removed units). Your problem might simply be that those infantry units don't exist anymore after "embarking" (aka being removed from the map), so DCS scripting engine can't find them (zone check can't be done), therefore, no messages are sent. If I were you, I'd create a tiny moving zone based on the helicopter and count the number of units within it during the "embarking" process. The moment that count returns 0, it must mean that all infantry units have "embarked". That way you won't be looking for units that no longer exist, so the messages should trigger correctly. Might need to use a script in order to do that. PS. I might be wrong about all this. :D

I'd go the SET_GROUP + iterator way too (combining it with checks and flags, in order to manage scheduler activation, specific number of units to spawn, and all that stuff). If you haven't already, join the MOOSE Discord channel. People over there will help you crack this, ask the MOOSE contributors over there (Pikes and funkyfranky should be able to help you with this)

That's what I thought when I read your post this morning, but I didn't comment on it because I assumed you already knew :doh: (I thought you were spawning it some other way I don't know about :D)

First you need to learn some Lua Also, check out the links from this post

Sure, flags, zone checks, mission specific functions, etc. should be used as well, in order to prevent undesired effects. I thought this was always implicit, my mistake :doh:

I'd subscribe the chopper to an engine shutdown event and then use it to trigger mission end messages / stuff. I've never tried that with a chopper, though. I'm not 100% sure it'll work, but I think it should.

@doodenkoff I think we have different interpretations of the OP's intentions here. To me, that means "I want to learn Lua / MOOSE scripting", rather than "I want to grab some random bits of MOOSE code and incorporate it in my missions... maybe I'll even learn something, eventually". Also, as Habu_69 noted, the ability to create your own scripts from start to end is what matters, if the OP doesn't know how Lua / MOOSE work, grabbing random bits of MOOSE code ain't gonna cut it (imho). So, based on all that and on my personal MOOSE learning experience, I recommend LDT over Notepad++ without a doubt, that's what I was trying to say. Now, I don't know about you, but I won't derail this thread by starting an argument over what MOOSE developers should or shouldn't have done. I don't think the OP cares about that, tbh. Also, if a halfwit like myself managed to learn MOOSE by following those terrible instructions, perhaps they weren't THAT bad after all. :D Cheers :thumbup:

@GunghoGW Don't worry about those build module errors, I get them too. As long as intellisense is working, you'll be fine. @doodenkoff I honestly don't know what it is that you find so complicated about LDT. All that it requires is source folder setup (which is no hurdle), other than that, you can simply think of it as an advanced text editor (like Notepad++, but better). LDT provides essential information about syntax, available class functionalities, function structure and hierarchy, etc. Notepad++ doesn't. Do you want to know which functionalities are available for, say, GROUP class? Notepad++: Sorry, check the MOOSE documentation if you want to know. LDT/Intellisense: Here you have them! Do you want to know whether your script is syntactically correct? Notepad++: Why do you ask me? Don't you know your Lua? LDT: You made a mistake there. / Everything is fine! Do you want to know whether that parameter / variable is being passed the way you want it? Notepad++: Why do you ask me again? You should know your Lua! LDT: This variable / parameter is being taken from there, see? and so on... In other words, LDT removes very real obstacles and challenges for newcomers (I'm a relative newcomer myself, that's how I know this), it speeds up the learning process and makes it far less painful. Recommending Notepad++ over LDT in this case doesn't make much sense, imho. But, hey, it's ok to disagree.

Use LDT rather than Notepad++, intellisense is something you want to have available.

So, using the script I provided before as a means to get your plane's descent rate, you could simply add a few extra lines inside that same scheduler (at the bottom, before the end) in order to receive those messages you mentioned when the client is within that zone. I think these extra lines should do the trick: Of course, in order for all this to work, the units and zone names in the script must match the ones you defined in ME.

I looked into it yesterday (after reading the other thread you wrote, which doesn't seem to exist anymore...for some reason :music_whistling:) and it seems like MOOSE doesn't "support" helicopter ground escort tasks per se (unless I'm missing something). If you somehow found a way to script ground escort tasks for helicopter groups, then I guess it would simply be a matter of using sets and iterators to find those dynamically spawned units/groups and push the escort task to the helicopter groups. Perhaps this could be achieved without scripting an escort task per se. Maybe you could just set up moving zones based on convoy units/groups and set the helicopters to engage enemies while inside that zone (and remain in it). I've never tried such a thing , though, just an idea.

Seems like we're in sync or something. I spent the whole day trying to create a MOOSE script that successfully returns unit climb/descent rate. It's still work in progress, but it seems to work decently (the returned values are quite close to indicator readings, which is a good sign). Here's the script: Now, this script will only give you the following values: - Unit's velocity (expressed in m/s and Mach number) - Unit's climb/descent angle (expressed in radians and degrees... if I'm not mistaken) - Unit's climb/descent rate (expressed in feet per minute and meters per second) It won't set up any checkers, flags or triggers (which you'll probably need in order to accomplish what you described). Lucky for you, that's the easy part :thumbup: PS. If anyone knows a better way of getting unit climb/descent rates, I'm all ears! EDIT: Found a better way!

Could you please upload your mission here? It would be much easier if I could just take a peek to see what's going on. As for getting the plane number (you mean the "tail#"?) instead of the callsign, I've found no way of doing this in MOOSE. You can get the name of the unit, its callsign, even the unit number within the group (ie. 1,2,3 or 4), but not the "tail#". NOTE: Keep in mind that the "Red coalition default" aircraft use numeric values for callsigns instead. Also, the DCS scripting engine doesn't offer "message to unit" functionality, you can only go as far as group level if you want to send messages. Now, if each client is placed in a separate group, that's fine, but if you have several clients in the same group, then all of them will receive the same message (since it'll be a group message), which is a problem. I think that your best bet is to put each client in its own separate group and work at group level, using those ME callsigns. :cry: (It's either that or playing around with unit names, but then you might have trouble working with sets, depending on what you want to accomplish).

I've attached a MOOSE demo mission and the script it runs on. It contains 4 client aircraft and 2 zones. If any of these clients is at <= 25% of their internal fuel capacity when inside any of the 2 zones, a text message will be sent to them once (which will include their individual callsign). I've added a couple of commented lines in the script, which are meant for sound messages (just introduce the name of your sound file in the bracket and uncomment the lines, it should work). As for plane flags, I haven't used any (not sure why you would need them). If you explained the purpose of those plane flags, though, we could find other ways of achieving the same goals (or not :D ) Although this is a MOOSE script, the concept can probably be implemented using DCS scripting engine functions instead. PS. Note that the DCS scripting engine doesn't return fuel quantities based on weight, but on percentage of total fuel capacity for each plane (expressed in decimal form). Since planes have different fuel capacities, the fuel percentage equivalence in weight will vary from plane to plane. For instance: F15C @25% internal fuel = 1526Kg (~3364Lbs) A10A @25% internal fuel = 1257Kg (~2771Lbs) Su25T @25% internal fuel = 948Kg (~2090Lbs) Su25 @25% internal fuel = 709Kg (~1563Lbs) Bottom line, working with fuel weight rather than percentage isn't ideal when scripting in DCS. Zone fuel check + message demo.miz Fuel Check in Zone demo.lua

What details would those be, exactly?

I've finished commenting, tweaking and testing my air refueling demo mission (a bare bones version of it, rather :D ), so, as promised, here you have it! Single F15C client available, with access to F10 menu commands (which are used to manage the air refueling task). A commented version of the mission script is also attached. Still, as I mentioned earlier, basic Lua / MOOSE knowledge is needed in order to understand what's going on :book: Hope you find it helpful! EDIT: Reuploaded the commented script yet again! Apparently, the whole script got shifted by 3 lines (which messed up line references in some comments :doh:). Also, I corrected a few other minor mistakes. It should all be ok now :thumbup: Air refueling mission demo.miz Air Refueling mission demo.lua

@Shadow.D. I'm working on a simplified version for PaxxPrime (with comments), which will only include air refuelling for a single F15C client. I'll post it here when I'm done. :thumbup:

That's the thing, though, you won't understand the scripts without basic Lua / MOOSE knowledge, so they'll be useless to you. I recommend that you start with this Lua tutorial site in order to get acquainted with Lua. Also, check out the links in this post to get started with the DCS scripting engine and MOOSE. It seems like a lot to process at the beginning, but scripting is actually kind of simple (once you understand the basic rules), just take it one little step at a time and you'll be writing your own scripts in a matter of days.

Yes, there are ways of doing this, but I'm afraid they involve Lua scripting. Afaik, ME doesn't offer the option to set up "fuel quantity" / "tanker contact" checks, which would be needed for such a mission to work. This can be easily achieved through scripting, though. PS. I have a MOOSE mission project which offers air refuelling tasks to clients, with voice/text messages and all (everything is handled via F10 menu). Trouble is that the scripts for this mission are rather long and require basic Lua / MOOSE knowledge. If you're interested, I could give you some pointers and share scripts.

Nice to see that you got it working! Btw, I've just tried the script with a train and it works too! You'll be able to map railway networks as well :thumbup:

Looks like those are raw coordinates which need to be converted to DDM or DMS format (don't take my word for it, though). Btw, I didn't mention this earlier, since I assumed you'd notice it while checking the demo mission triggers by yourself. The thing is that in order for dcs.log to actually log those coordinates (using the script I provided) you need to create an additional trigger in ME (either MISSION START or ONCE type). That trigger should perform a "DO SCRIPT" action and run the following script: This is one way of telling MOOSE to trace "BASE" class (ie. log it in dcs.log every time it's used), that's why I added the following bit at the end of the scheduler: Btw, you can simply delete the "DMS/DDM coordinates:.." part, since it's not needed. Those "RoadMapperLLDMS/LLDDM" variables will return strings which already specify the coordinate format. In fact, you could actually replace that by the name/identifier of your vehicle, so you'd know where those coordinates belong (in case you decided to use multiple vehicles to map several roads at once). Yes, the script can be modified to allow for multiple vehicles, but the "output method" (coordinate logging format in dcs.log) needs to be given some thought, otherwise you'll end up with a messy coordinate list :cry: I'm mentioning all this stuff just in case you decide to create your own missions in order to do this, only to discover that dcs.log isn't actually logging the coordinates :doh: