Hardcard

@hancerPL Ok, I've put this together, it should meet your requirements (haven't tested it, though, modifications might be required) You need to create a late-activated strike group in ME and give it a bombing task there. The number of units in that strike group must be specified in the script Btw, the script can be modified to work with several randomly selected strike groups, but I decided to keep things simple. As it's written, it will only work with a single late-activated strike group (it has 100 spawns available, so the whole thing can be repeated). Also, I assumed that the F/A-18C, F-14 and M-2000C clients would be in the Blue coalition, so the script will only work with Blue. If those clients are included in the Red coalition, you'll need to change all instances of coalition.side.BLUE to coalition.side.RED Clients will have 5 minutes to accept the bomber interception, if they don't , their menu will be removed. The bomber interception task will be made available to the clients periodically... I've randomized the scheduler repeat time (any number of seconds between 1800 and 14400, ie between 30 and 240 minutes) You only need to introduce the group name of the late-activated strike group in ME and the number of units it contains (the required fields are marked in red, coalition enumerators marked in magenta): Interception = "Clear" local Bomber_Spawn = SPAWN:New("[color="red"]Name of the late-activated strike group in ME[/color]") :InitLimit([color="Red"]number of units[/color] ,100) :OnSpawnGroup( function(BomberGroup) BomberGroup:HandleEvent(EVENTS.Dead) function BomberGroup:OnEventDead(EventData) if BomberGroup:IsAlive() == nil then local ClientSET_Ded = SET_CLIENT:New():FilterActive(Active):FilterOnce() for i , Client in pairs( ClientSET_Ded:GetSetObjects() ) do local TypeName_Ded = Client:GetTypeName() local Coalition_Ded = Client:GetCoalition() local Group_Ded = Client:GetGroup() if TypeName_Ded == "F-14B" or TypeName_Ded == "FA-18C_hornet" or TypeName_Ded == "M-2000C" then if Coalition_Ded == [color="Magenta"]coalition.side.BLUE[/color] then MESSAGE:New("Bombers have been destroyed, stand down",10):ToGroup(Group_Ded) Interception = "Clear" end end end end end BomberGroup:HandleEvent(EVENTS.EngineShutdown) function BomberGroup:OnEventEngineShutdown(EventData) local InitiatorUnit = EventData.IniUnit local InitiatorGroup = EventData.IniGroup local InitiatorVelocity = InitiatorUnit:GetVelocityKMH() if InitiatorGroup == BomberGroup and InitiatorVelocity == 0 then InitiatorUnit:Destroy(true) end end end ) local function InterceptionStart(Group) Interception = "Accepted" Bomber_Spawn:Spawn() BomberStrike_Root:Remove() MESSAGE:New(Group:GetName().." is intercepting the bombers!",10):ToCoalition([color="Magenta"]coalition.side.BLUE[/color]) end local function BomberStrikeRemove() if Interception ~= "Accepted" then BomberStrike_Root:Remove() end end SCHEDULER:New( nil, function() local ClientSET = SET_CLIENT:New():FilterActive(Active):FilterOnce() for i , Client in pairs( ClientSET:GetSetObjects() ) do local TypeName = Client:GetTypeName() local Altitude = Client:GetAltitude() local Coalition = Client:GetCoalition() local Group = Client:GetGroup() if TypeName == "F-14B" or TypeName == "FA-18C_hornet" or TypeName == "M-2000C" then if Altitude > 1500 and Coalition == [color="magenta"]coalition.side.BLUE[/color] and Interception == "Clear" then MESSAGE:New("WARNING !!!\nHostile bombers flying towards our airport\n\n***Bomber Interception menu created***",10):ToGroup(Group) BomberStrike_Root = MENU_GROUP:New( Group, "Bomber Interception" ) BomberStrike_Accept = MENU_GROUP_COMMAND:New( Group, "Confirm!", BomberStrike_Root, InterceptionStart, Group) timer.scheduleFunction(BomberStrikeRemove, nil , timer.getTime() + 300) end end end end, {}, 1, math.random(1800, 14400) ) Let me know how it goes :thumbup:

Guys...you're making me :blush: @TheBamse Your mission is based on Caucasus, right? Please, post it here or send it to me via PM, so I can have a look

The DCS scripting engine doesn't handle fuel quantity in the way you're probably assuming. Fuel quantity is expressed as a decimal value (I think it's the percentage of the internal tank capacity divided by 100): What are you trying to achieve, exactly?

@Everyone Uploaded yet another new version of SWAPR (Reference_Table builder).lua, considerably simplified (sometimes my brain stops working and I end up needlessly complicating stuff :doh: ) @TheBamse Sorry for the multiple uploads, try the new file! @GTFreeFlyer Thanks for the suggestion, I had already considered it, we'll see. Never managed any project using Git, still need to learn the ropes :book: @funkyfranky That sounds like a great idea, tbh. I have no clue of how client slots can be blocked, I know there's a script out there that does this, but I haven't checked it out yet

Yes, I was just reviewing the new version again and thought to myself "wait... if they have no FARPS in the mission, this is likely to generate a nil error, I need to fix it before anyone notices!" :doh: :lol: I'll fix this in a moment, sorry about that ;) EDIT: I've uploaded a corrected version of SWAPR (Reference_Table builder).lua , the issue should be solved, give it a go and let me know if it works. :thumbup:

@Everyone I've improved SWAPR (Reference_Table builder).lua and reuploaded it, check the changelog ;) @Shahdoh Thanks a lot for the info! :thumbup: So it seems that there is indeed a limit of clients that can be targeted in a single run... I'll need to look into this issue, chances are other people will experience it too... I'll probably modify SWAPR (Reference_Table builder).lua again, see if I can make it reference clients by groups of 50 or so. ;)

I guess I could create specific checks for harriers and helicopters, so that they only get offset when placed on FARPs... I'll look into it and perform tests, see if it's feasible. In the meantime, you're free to remove the y offset applied to helicopters and harriers, simply subtract 5 from their y values in Reference_Table. For instance:

@Shahdoh That's an interesting issue, could you share the full dump from dcs.log and the reference table builder script that you're using? Btw, when you get the AI_SET count, does it match the number of clients that you've selected in the mission? Do you get errors in dcs.log? Also (you've probably thought of this already), for now, I'd do what you suggested yesterday. Make a copy of the mission and give it a different name, so you can make wild modifications to it, then try the following stuff: Target only the clients whose tables came out truncated, see if the problem persists. If it does, the source of the issue is likely there, we'll need to look into those clients to see what's different about them... Are those clients very close to other clients? Like less than 10m/~30ft apart?. Are those clients based on an airbase (with their own parking spot)? (screenshots might help make things clearer) If it doesn't persist, then proceed to the step(s) below Remove all the unrelated triggers, leave only the Moose.lua and the Reference_Table builder triggers...and the clients, ofc. Run the mission again, see if the dumped table is still truncated... if it comes out fine, then I guess you have a trigger conflict / overload problem in your mission. If it still comes out truncated, then get rid of / exclude half of the clients in the mission and run the test again. If it works, proceed to do the same for the other half of the clients, see if it also works. If it also works, then it's pretty clear that there's a limit to the number of clients that can be targeted in each run. If none of the above works, then reduce the client selection to a third/quarter instead of a half and repeat the test, see what happens. If the issue persists, get rid of the "%(" prefix, don't use any lua magic characters in any of the client PILOT names. Also, you could try changing the parking spots of problematic clients. Also, if you're using mods, disable them, see what happens. Please, keep us informed, I'll probably need to modify some stuff depending on your results. :thumbup: @Rudel_chw Thanks for showcasing SWAPR in your posts, cool stuff! ;)

Listen to the man, people! ;) I didn't want to complicate the process even move, but sure, having a client version and an AI version of the same mission (only for reference table generation) is a neat trick :thumbup:

The time has come! SWAPR script has been finally released! https://forums.eagle.ru/showthread.php?t=246709

@Anyone interested The day has finally arrived, SWAPR script has been officially released! https://forums.eagle.ru/showthread.php?t=246709

If you're tired of... having aircraft popping in and out of existence as players join/leave having empty airbases and FARPs being forced to add replacement units by hand getting high fps in airbases and FARPs I present to you the brand new... Setup video: Slot Block demo video: What does SWAPR do? SWAPR handles the swapping of clients and their automatically generated replacement units It will dynamically generate and spawn replacements for any chosen number of clients It will also remove those replacements dynamically, as players join client slots SWAPR also includes an optional slot block feature for MP, which will block client slots if their respective replacements are destroyed Does it work with all airframes, coalitions and countries? Yes, it should (ship-based clients are no longer supported) Does it work in all DCS maps? SWAPR has been successfully tested in Caucasus, Nevada and Persian Gulf maps. (It should work in any map that uses the same airbase and coordinate structure, but I can't test it in any other maps, since I don't own them) Does it work in MP? Yes, SWAPR has been successfully tested in MP (dedicated server) Can I integrate SWAPR in my ridiculously complex missions? Yes, SWAPR has been successfully integrated in several complex missions during its testing phase Are there any special requirements? SWAPR is partially powered by MOOSE. You'll need to load Moose.lua using a MISSION START trigger first, then load SWAPR using a ONCE trigger after it. Use the Moose_INCLUDE lua file from the latest MOOSE release, which can be downloaded HERE DO NOT USE OLDER VERSIONS OF MOOSE! Where can I get SWAPR? SWAPR v1.4 (New & Recommended!) Where do I report issues? Issues can be reported directly in this thread (you can also send me a PM). Please, always include your mission file, dcs.log and server hook (if MP) in your reports IMPORTANT NOTES (extended): Known Issues: Changelog: Big thanks to...

No need to apologize, Polish and English are very different languages. As for the rest: Sure, feel free to send me the mission file and any scripts that you're using, see if I can make sense of it :thumbup:

Nah, it's not hard, just takes a bit of work and planning. Just to make sure we're on the same page here:

@Rudel_chw Great news! Thanks for all the tests! :thumbup: Looks like I'll be releasing the new version pretty soon!

@Stonehouse Thanks for the info! The script has evolved quite a lot since I wrote that, though, it no longer requires any template statics to be present on the map. All the required information is included in an automatically generated reference table, it's pretty neat. :thumbup: It's almost ready for release, we're still ironing out some minor problems with certain airframes from certain "factions" (USAF Aggressors... pita). I hope I'll be releasing it in the following days, along with the tutorial (fingers crossed) ;)

By "radio units" you mean late activated AI units? What's "Alert 5"? Also, when you say "the group", is it supposed to be Player_1 group? Sorry, what? :huh: Again, sorry, what? :huh: Can you write the post in Polish and add the text in a spoiler or something? I think I'll be able to understand you better that way. :thumbup:

1. Moving or not, the mere presence of units (even statics) on the map will be the main performance hitter (according to my tests). 2. Sure, EWRs might impact performance more than regular units, but I'd need to run further stress tests in order to confirm it. Contrary to what I thought, enabling AI for AA vehicles (radars included) has a pretty negligible impact on performance (at least that was the case in the stress test mission I created). 3. Depends on the triggers and timers. Continuous or switched condition triggers in ME are as "bad" as continuous schedulers (timers) in scripts. I'd recommend setting up your triggers / scripted schedulers so that they only run when needed. Also, as feefifofum mentioned, be careful with "heavy checks", they might clog the game if you abuse them. But, anyway, in my experience, the number of units / statics on the map will impact performance much more drastically than inefficient combinations of triggers and schedulers. 4. Event handlers are super useful, so, yup, take advantage of them. 5. Generally, yes. However, keep in mind that plenty of users out there aren't computer savvy, they might blame their performance issues on your server when, in reality, the problem is on their end. ;)

If server performance gets "infected", try using an antivirus :D Now seriously, the number of units / missiles on the map is the main factor to consider.

@Those interested Rudel and I have been testing the latest versions of the script in different MP missions for the last few days. It looks like this last version is almost ready for prime time now...still need to solve a minor issue with static/client name checking, though. When I'm done, I'll be posting the new files and the tutorial I mentioned (I'll probably start a new thread dedicated to it ;))

My answer is still the same as before, then: MenuTop_2:Remove() BUT, you need to create a logic structure that will "detect" the presence of submenus and decide whether to remove MenuTop_2 or create it again, depending on the situation. Something like this (check that the two extra JTAC menu functions have the correct autolase parameters. Use "Enable JTAC Menus" F10 menu to generate the JTAC menus):

You asked how to remove the main menu, specifically, "MenuTop_2" AFTER removing all submenus... and I told you how to do it. ;) You didn't mention anything about keeping the submenus, quite the opposite. Also, I warned you: Formulate your questions properly, please...otherwise we'll enter a "vicious circle" :) So you want a main menu with 4 submenus in it, right? Menu_Top_2 JTAC_1 JTAC_2 JTAC_3 JTAC_4 Is this meant for SP or MP missions? When do you want each of the submenus to be removed? Directly after execution? If you delete them directly after execution, other clients won't have access to them until the whole nested menu structure is created again. In that case, you might want to use group menus instead of coalition menus. Describe what you want to do, EXACTLY, otherwise you won't get the answers to the specific problems you're having.

Looks great! :thumbup: If you experience any issues, let me know!

Place this in a function when you're done with JTAC: MenuTop_2:Remove() However, keep in mind that you'll need to create the nested menu structure again from scratch, if you plan on using it later

Glad you got it working! I'll post the new scripts + tutorial video (in English) here as well, for other users that might be interested. Today I'm going to be quite busy with other stuff, though, so I'll do it when I have time :thumbup: