Hardcard

Guys, I've been working on this script for the last couple of days, try it out! https://forums.eagle.ru/showpost.php?p=3979600&postcount=23 It works like a charm in SP It basically handles static aircraft spawn/removal depending on which clients are active. It's pretty neat :thumbup:

Well, I've managed to improve the script quite a lot, now you only need to fill up the reference table and specify the common client prefix/suffix, the script should take care of the rest :thumbup: I've tested it many times, I get no error messages or crashes, I can also respawn clients using the key command as well. The script keeps working when clients die and respawn as well. Btw, I've discovered that the template statics don't need to be alive after spawning for the first time, you can set them to DEAD in ME, the script will still work! IMPORTANT NOTES: Here's the improved script (all the required values are marked in red, don't remove any commas or quotation marks): Demo mission + script file attached Client Static Replacement (improved).miz Client Replacement with Statics (improved).lua

@Rudel_chw Hey, thanks for testing! Was the TF-51 static being removed properly when you spawned the client? As it's written, the static will be removed after the client spawns, so there's a chance it won't be removed in time and cause damage (due to delays in the execution of the script) As for the crash when the client gets killed, I'll need to run tests, might be due to several reasons. Yesterday I managed to make substantial improvements to the script design, I'll probably post an improved version today...

@hancerPL https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Core.Menu.html https://forums.eagle.ru/showpost.php?p=3969423&postcount=20

@Knock-Knock Nope, no dice. Looks like statics can't be spawned on carriers using this method... I can make them spawn on the correct coordinates, but they're placed at the bottom of the sea instead of on the deck... :cry:

@Knock-Knock If the carrier is moving and turning (which I'm assuming will be the case) the script needs to be modified, but yes, it should be possible. Luckily, funkyfranky created a new MOOSE method at my request, which will come in handy here, this is the perfect opportunity to test it ;) Here's what I'll do: - First set of statics will appear when clients are on deck - When no clients are on deck, the static set will be swapped The inbound trigger that you mentioned would require custom F10 menus for carrier based groups and extra logic... I don't want to go there just yet, let's keep it simple.

Hi there guys Glad you got it working with additional clients :thumbup: @Rudel: Please, if you get a chance, test this in MP I foresee problems with the script when clients or replacement statics are killed (not 100% sure, though). I'm also afraid that the clientSET won't update properly in MP (I really hope it works, fingers crossed). Also, I don't like the way the script handles country and coalition settings for the replacement statics... Perhaps the script could use another layer of "automation", so less input from the user is required. I might improve this script in the future. Now I'll try to answer some questions: As Rudel pointed out, it can be either a prefix or suffix. Syntax-wise, I normally use prefix_, although this time I went for _suffix You can use any letter you want, stuff like * - also works. I'd say most symbols should work, however, I wouldn't use any of the following: . , : ; () {} [] / \ I mean, as long as they're between quotes (string format) they should work fine... it's just that I don't trust DCS to always tell them apart from regular LUA operators :D That file is outdated, I'm afraid: MOOSE GITHUB Commit Hash ID: [color="Red"][b]2018-04-07[/b][/color] Sure, it's a lighter file partly because it doesn't include comments... and partly because it's missing several new classes and methods that have been added over the last year. At the very least, you should be using the latest release ( November 2018 ) However, new classes and methods have been added since last november as well, and several bugs have been fixed. I'm using the Moose.lua develop version that I linked in my previous post, which I know to work. The script might still work with older MOOSE versions...but it might also crash (the moment the old Moose.lua stumbles upon a new class / method).

Unfortunately, this apparently simple mechanic requires a rather elaborate script (since this stuff isn't actually implemented in the game). I've simplified it as much as I've been able to, but it'll probably freak you out anyway :cry: IMPROVED VERSION OF THE SCRIPT HERE FURTHER IMPROVED VERSION HERE ULTIMATE VERSION HERE (Highly recommended)

@Grimes Thanks for the answer. Yes, I used the getFuel() check that you mentioned when I wrote my air refueling script. It works as intended, but I was hoping for a better way of doing it. Isn't there a way of detecting the presence of external fuel tanks more directly?

I'm afraid you'll need to use a script for this. If you're cool with it, I can show you how I do it.

Does Unit.getAmmo() detect external fuel tanks as well?

@Mojeaux Make backup copies of all your custom key mappings, missions, tracks, templates, etc. located in C:\Users\YourUserName\Saved Games\DCS (or DCS.openbeta, in case you're using the beta) Then delete that DCS (or DCS.openbeta ) folder and start the game. You'll get a new one (generated automatically), that might solve your problem. As for the cause of the problem, perhaps you tried to load an incompatible sound file a year ago, which caused ME to freak out and lock itself. Can you post the problematic sound files here, so we can take a look at them?

:clap_2:

@Delta99 Sorry, I couldn't remember the name of the video, otherwise I would've linked it too :doh:

@A101Wayz At first glance, you don't have any checks in the OnEvent functions, so every time a Shot or Dead event happens, everything is triggered. You don't need to use separate handlers for each SET, btw. Common event handlers can be used instead: This is too simple, though, in order for the scoring to work properly, additional checks are needed.

I think you can kind of do it with MOOSE https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Warehouse.html

@hancerPL :InitKeepUnitNames(true) must be included in the SPAWN declaration as well, right after :New() (also, remember that :SpawnScheduled() must be placed at the end of the declaration) I've attached a test mission + script file Immortal Su25T client available at Batumi (ramp), a late-activated armored vehicle will be periodically spawned and blown up in front of it. All blue coalition clients will get both the spawn and destruction messages (including the unit name of the armored vehicle) Here's the raw script: Spawn IniUnit Test.miz Spawn IniUnitName test (SET version).lua

:OnSpawnGroup() won't do anything in the script you provided (since you didn't embed any function in it). If you aren't going to use it, remove it from the declaration. EventData.IniUnitName will return the unit name of the initiator unit (the one that just died)... I'm not sure I follow. I'm definitely not following :huh:

Bandar_e_Jask_airfield is included in the current MOOSE develop version. Join the MOOSE Discord channel and check the #configuration section, you'll find LDT setup help there. This link will take you there (hopefully): https://discordapp.com/channels/378590350614462464/413691502729101312

Several things: 1- Please, use a CODE / SPOILER wrap when including code in your posts (far less messy, easier to discern) 2- SPAWN:New() will look for the specified late-activated group in ME and use it as template only. When you do :Spawn() , :SpawnScheduled(), etc., you're actually spawning copies of that template (which have different group and unit names), not the late-activated group itself. Therefore, :FindByName() will never find anything if you give it the name of the original template group as parameter. Solutions: - Meet your new friend, :OnSpawnGroup - Meet your other new friend, SET_GROUP 3- Method order is important when dealing with SPAWN class. Spawn methods like :Spawn() , :SpawnScheduled(), etc., should be placed at the very end of the SPAWN object declaration

I think this is what you're looking for: https://wiki.hoggitworld.com/view/DCS_func_removeItem Also, take a look at this: https://forums.eagle.ru/showpost.php?p=2954080&postcount=4 From what I understood, you need to include the commands in a table (assigning them custom indices), then reference these custom indices when you want to remove the commands they are associated with. Here, I've modified your snippet, this should do it:

@JFO82 The thing is that you'll need to test the mission as you go, otherwise there's a pretty good chance it won't work as expected when you get back home. I guess that a low end laptop would be enough to create and test simple missions (without massive unit concentrations)... but 1k units, that might be too much to ask from a low end laptop.

DCS performance is severely affected by the number of AI units. That's probably because DCS processes were paused.

@Harker That post was written a year ago

@Habu I was deliberately avoiding MOOSE ;) @L39Tom :GetHeight( true ) (MOOSE function) will basically run the standard DCS code I provided, requiring a considerably shorter script, as Habu has shown (you'll need to load Moose.lua at mission start for it to work, though).