Hardcard

@Olddog Post the missions that are giving you trouble here. Also, if you provide the specific script requirements, it'll be easier for others to contribute with their own solutions. I might be able to write a "standard" DCS script for you (as soon as I beat this nasty flu :cold:)

@TonyG Here you'll find one of my "old" MOOSE test missions. Several things in the mission are handled via nested F10 menus (smoke units, open fire, hold fire, call in a helicopter/bomber/naval strike, etc.), all AI groups in the mission are late activated. The beauty of this demo mission is that you can switch between client groups as much as you like, you'll always get the nested F10 menus for each group (sometimes they'll take a few seconds to appear, though). Automatic menu removal is also implemented in the mission, iirc. The mission uses a couple of rather long scripts (two versions of the same script, one for each coalition), which I wrote several months ago (my scripting skills weren't great back then, so you might find silly stuff in there :D) You'll find the nested F10 group menus/commands towards the end of the scripts. Anyway, I think this demo mission is a decent example of how to orchestrate stuff using nested F10 menus for different clients. Now, in order to get everything started, you'll need to run "Zone Detection Test Menu" via F10 menu after entering any of the clients. Next, keep flying straight until you enter the mission zone, then you'll get all the juicy F10 menu structure (I recommend helicopter and naval strikes, they're fun ;) ).

@franx Delete both dcs.openbeta and dcs folders from there (remember to backup your custom control mappings, missions, etc. if you have any). Rerun DCS, see if the problem persists. If it persists, proceed to a full removal of DCS from your computer (dcs folders from c:\users\username\saved games included), then reinstall it (make sure that you have no antivirus crap running).

Ok , guys! After many hours of trial and error, I've had some minor success in getting a few values from those elusive objects! So far, I've been able to access their description tables in order to get displayName, typeName, category and life (initial life, that is). However, I can only work with these elusive DCS objects when their DEAD events happen :cry: Here's the script I've used (demo mission + script file attached): Any ideas on why the methods marked in red target the runway craters instead of the elusive objects? There's another interesting thing, you'll see the following errors in dcs.log when you run the mission: 2019-02-03 23:08:09.686 ERROR wInfo: can't open Objects[MI-8] table 2019-02-03 23:08:09.694 ERROR wInfo: can't open Objects[bARREL] table 2019-02-03 23:08:09.695 ERROR wInfo: can't open Objects[WOOD_BOX_01] table 2019-02-03 23:08:09.697 ERROR wInfo: can't open Objects[WOOD_BOX_02] table 2019-02-03 23:08:09.872 ERROR wInfo: can't open Objects[uRAL_ATZ_P1] table 2019-02-03 23:09:01.032 ERROR wInfo: can't open Objects[AN-2M] table Elusive Objects Test.miz Elusive objects.lua

According to the declaration, I think it returns a subtable called 'Scenery' (which is located inside the table 'ScanData') : return self.ScanData.Scenery Now, if I have to guess, 'Scenery' subtable might contain information about the SCENERY objects found in the zone radius. For instance, if you do :GetScannedSceneryType(), this seems to return the object type by reading from the 'Scenery' subtable. Here's the declaration of this method: ZONE_RADIUS:GetScannedSceneryType( SceneryType ) return self.ScanData.Scenery[sceneryType] end Anyway, it really bugs me that some static and scenery objects don't have a DCS category assigned. This makes Object.Category.x virtually useless :cry:

Nice, thanks! I'm assuming that this is the correct one, right?: As for the event handler idea, I think it will work. I made an AI Su-24 bomb those Mi-8s earlier this afternoon and the mission report did return their DEAD event initiator names (I believe they were using "monument" as name, isn't that weird?).

Hi Grimes, I was just thinking about you! :D I noticed something odd in the Hoggit documentation and some clarification would be appreciated. Is this table discrepancy accurate or is it some sort of typo? Shouldn't both Objects and StaticObjects use the same Category table? Hey, you might be onto something here! Last month I got the categories from those sea shelf objects by using an event handler for a DEAD event! I'll add an event handler to the script, see if I get lucky! Thanks!

I've been at it for several hours and I'm starting to think that those helicopter objects can't be targeted by scripts atm (they seem to be "out of reach", just like cockpit arguments). They don't seem to belong to any of the main DCS object categories (UNIT / WEAPON / STATIC / SCENERY / BASE / CARGO), so world.searchObjects() doesn't work on them (which means that I'm out of ideas :cry:). Oddly enough, static Sea Shelf Objects can't be targeted either, since they no longer seem to use category 0, like they did last month (perhaps EDevs changed this in a recent update). I've attached a modified version of Quadrafarian's demo mission (+script), which uses a standard DCS script to detect all objects within the zone (based on their DCS category). As I said, the Mi-8s aren't detected (the crates and barrels aren't detected either), but the AAV7 and the nearby airbase truck are detected... Here's the script I used: I've checked and tested several MOOSE classes and it does look like the standard world.searchObjects() DCS method is the best way to go. Zone Object Detection by Category.miz Object Detection in Zone Test.lua

@SUNTSAG @Quadrafarian Nice, I stand corrected then. Time to figure out what's going on "under the hood".

@jsr9597 AFAIK, only objects placed by the user can be removed via ME triggers. If you want to remove objects within an airbase template, that'll probably require messing around with DCS files (if it can be done at all).

@Rudel_chw @HiJack Thanks for the info!

Scroll up to post #11 The link I provided directs you to the download link of the latest Moose.lua (include version). However, if you want to know the location where MOOSE releases can be found, that would be the Github release branch

AFAIK, that only changes the country composition of each coalition. It should be working with customized coalitions too.

That's pretty interesting! Have you thought about creating a tutorial on how to do this? I think many people around here would appreciate it! :thumbup:

What about planes like the Su-25T? Are they considered FC airframes as well?

@BoneDust If you learn scripting, you'll have all methods available for any mission...forever Copy/paste this bit from here, copy/paste the other bit from there, done! :thumbup: The time and effort it takes to learn scripting is nothing compared to the time and effort you'll waste every time you need to create a complex mission from scratch using ME.

@ivo Set the group task to CAP/Nothing (or any other task "compatible" with the MiG29), set the country to Russia, Georgia, Ukraine, etc. (any country that has flyable MiG29s), flyable planes will appear in yellow on the dropdown list. Finally, you need to set the aircraft skill to either "player" or "client", so you can jump in when the mission runs.

@Fisherman82 Sorry, I don't know of any convenient way to target flags based on value change. It can be done, I guess, but I imagine it would be pretty inconvenient. I usually create flag status messages as I program each flag (this is a pretty straightforward process when scripting missions, but more of a hassle when using ME triggers). The thing is that you'll never get the status of 200 flags on display at the same time, so perhaps it would be a good idea to divide them in groups of 10-20 or something like that. Then you could create custom F10 menu commands, which would allow you to access each group of flags (something like "Show flags 1-10","Show flags 11-20", etc.) I've modified the demo mission + script to incorporate these changes. Now there's an F10 menu available for all Red coalition clients, which allows for flag status message management (it uses MOOSE, btw). Here's the new script: Now, there are a few things to consider: - In order for this script to work with your mission, you'll need to run Moose.lua with a MISSION START trigger - Flags 7-10 will be enabled when the Mirage reaches an altitude of 5000+ meters. Flags 11-20 will be enabled when the Mirage lands. - Since I didn't feel like setting up my HOTAS, I used a red igla manpad as "client" in the attached test mission (Combined Arms module is required for players to take control of this unit). This igla manpad "hermit" is located on top of Mount Elbrus, it'll allow you to access the custom F10 menu once you take control of it. If you don't own Combined Arms, simply add any flyable red aircraft that you want, that way you'll be able to access the custom F10 menu (I guess I should've done that, but I wanted a hermit flagmaster on Mount Elbrus :D). - In order to avoid this sort of problems/nuances, I recommend that you learn basic scripting. :book: EDIT: I noticed that the script was still using iterators from a previous test version, I've removed them since they aren't needed. I've uploaded the corrected test mission + script Flag status message test (F10 menu + MOOSE, no iterator).miz Flag checker loop (no pairs test).lua

https://forums.eagle.ru/showthread.php?t=215825

@maverickturner This is my first time using SCORING class, so I don't quite know what I'm doing :D Anyway, this seems to do the trick (Demo mission + script file attached): NOTE: I was too lazy to set up my HOTAS, so I used playable AA vehicles to destroy the choppers in the demo mission (Combined Arms module is required) UN Huey Scoring Test.miz UN Chopper Score Test.lua

@pimp That's an older MOOSE release @Teriander Modify Moose.lua at your own risk, I don't recommend it, but you are free to try, ofc. As for performance, Moose.lua by itself shouldn't affect it. Think of it as a "scripting dictionary/translator", it shouldn't do anything by itself. It'll simply "translate" your MOOSE scripts so the DCS scripting engine "understands" them. Anyway, you can always use DCS scripting methods instead, no Moose.lua required for those.

@Fisherman82 I created a demo mission + script which includes a real time flag monitoring routine. A Mirage2000C will climb up to 5000+ meters and then RTB. I've set up 6 flags in the mission, which will be enabled/disabled depending on the plane's altitude. You'll get a "permanent" text message, showing the state of all flags as the plane climbs/dives. When the plane lands, the routine will be automatically stopped. Here's the script: Now, you'll probably need to get rid of the "Mirage check" in order for this script to work in your mission. You can loop it indefinitely by doing something like this: Btw, in order to load the script in your mission, you can create a MISSION START trigger, with a DO SCRIPT FILE action Attached mission + script below Flag status message test.miz Flag checker loop.lua

Yes, it's in there. Open the mission file with winzip/winrar/7zip/etc. and navigate to Stennis static spawn_despawn.miz\l10n\DEFAULT , you'll find it there. Alternatively, you can download it here As you've probably deduced, the script won't work without Moose.lua being loaded first, since it's a MOOSE script. You need to create that "MOOSE load" trigger at mission start, with a "DO SCRIPT FILE" action that runs Moose.lua

FPS aren't a good indicator of DCS scripting engine performance / load. You can run DCS at 200 FPS and still get DCS scripting engine errors (or "trigger lag") due to high load. At any rate, replacing a few continuous triggers with a script won't make much difference. However, replacing hundreds of continuous and switched condition triggers with one script (or a few) can make a considerable difference (as long as the scripts are written with efficiency in mind). Let's agree to disagree :D Ok, just to make sure that we're on the same page... You know that all continuous (and switched condition) triggers in ME will keep running throughout the mission, right? For instance, in your case, when flag 97 is true you won't get the messages anymore, but those continuous triggers will keep checking for each condition every second, regardless. This is another perk of scripting, it gives you control over continuous functions/checks. For instance, in the script I posted, all checks stop running when the plane lands (the scheduled function that contains them won't be called anymore), which makes DCS scripting resources available for other stuff. :thumbup: As I said, if you only have a bunch of continuous / switched condition triggers in your mission, this doesn't matter... but if you have hundreds of them (which is the case in complex missions), it does matter.

Not at all! Your ME solution is quite inventive! :thumbup: Problem is that ME triggers are inherently restrictive, which forces people who don't script to create those trigger jungles :D If you apply your wit to scripting instead, the sky is the limit! :pilotfly: