SWAPR - SWeet Automatic Player Replacement script

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...

A beautiful solution to an age old problem in DCS. I would like to suggest that when you are building the reference table and you need to change all the clients to AI, that you could save those changes to another mission name. This will leave your original mission set with clients, saving you that step of changing the AI back to clients, you only need to add the trigger to load SWAPR.lua (after inserting the reference table and other changes) in the original mission and should be good to go.

I would like to suggest that when you are building the reference table and you need to change all the clients to AI, that you could save those changes to another mission name. This will leave your original mission set with clients, saving you that step of changing the AI back to clients

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:

Thanks a lot for developing this Scripts @Hardcard :) your post is very thorough, but I would like to provide a bit of context to help highlight the significance of your development:

Up to now, when I'm the first person to arrive into a Multiplayer server, I'm greeted by an empty tarmac where my aircraft stands alone until other human players begin to login and pick up their slots .. but even then a lot of the ramp places remain empty as rarely enough players gather together to man every aircraft and helo.

For a long time I longed to have the option of having playable aircraft parked empty with no pilot on the ramp until a human player select that aircraft in the multiplayer lobby and jumps into it.

I wanted to have visible and parked over the designated parking slots all "playable" aircraft and before a pilot can jump on it in multiplyer.

This feature even presents the interesting situation to allow that client aircraft to be destroyed by the enemy on the ground when the fight moves over an airfield, even if there is no human pilot for it.

As an example, this is "The Enemy Within 3.0 MP" mission that Baltic Dragon shared on this Forum a short while ago .. I'm the first pilot to connect to the Server:

I'm the only aircraft on the ramp .. the Mission designer has placed a few ground units there in an attempt to avoid having a bare airfield, so it looks pretty nice.

However, when using @hardcard's script, the Mission now looks like this:

much better, isnt it? :) ... I love the fact that the "empty" aircrafts are shown by DCS with no pilot and their canopies closed, while my aircraft has a pilot and the canopy open ... it looks really good and makes the extra mission editing effort really worthwhile.

Best wishes,

Eduardo

This looks very cool. I’m going to try it!

Does it work in all DCS maps?

Yes, it should

 

So far, I had tested it on Caucasus and Nevada, but today I tried it out on the Persian Gulf and it works perfectly :)

Here is a shot with the un-moded Mission (this is the excellent "Crack the Channel", by Apache600 https://www.digitalcombatsimulator.com/en/files/3305550/) .. I feel so lonely:

Here is the same, but with @Hardcard's Script providing static replacement for those Clients not yet connected:

And here, its the same, but also with one of my Airfield Templates (https://forums.eagle.ru/showpost.php?p=3679000&postcount=36):

Love the added scenery, it makes the airbases come alive.

Cheers!

Eduardo

.

Attempting to build the table on a Normandy WWII mission with over 200 client aircraft. I have my prefix set and and for the first 80 some aircraft, the table data looks fine. After that, the tables are truncated.

My Prefix code I am using is "%(".

Good data:

 local Reference_Table = { -- ===================== TABLE STARTS HERE!!!

  ["(B) Chevy 28-1"] = { -- Start of (B) Chevy 28-1 subtable
    ["Heading"] = 4.5890454471979 ,
    ["Country"] = 66 ,
    ["Coalition"] = 1 ,
    ["x"] = -21711.705078125 ,
    ["Livery"] = "FW-190D9_JG54" ,
    ["y"] = -8164.1577148438 ,
    ["StaticName"] = "(B) Chevy 28-1_Replacement_Static" ,
    ["ClientName"] = "(B) Chevy 28-1" ,
    ["TypeName"] = "FW-190D9" ,
    ["CategoryName"] = "Airplane" ,
  }, -- End of (B) Chevy 28-1 subtable

Truncated data(somewhere after 80 aircraft, prior entries were complete):

   ["(B) Uzi 23-1"] = { -- Start of (B) Uzi 23-1 subtable
    ["Heading"] = 2.4245519116035 ,
    ["Country"] = 2 ,
    ["Coalition"] = 2 ,
    ["x"] = -9336.021484375 ,
    ["Livery"] = "USAF 364th FS, HURRY HOME HONEY" ,
    ["y"] = -72570.4375 ,
    ["Coalition"] = 2 ,
    ["y"] = -25101.83203125 ,
    ["ClientName"] = "(F) Uzi 4-1" ,
    ["CategoryName"] = "Airplane" ,

  ["(F) Colt 4-1"] = { -- Start of (F) Colt 4-1 subtable
    ["Country"] = 2 ,
    ["Coalition"] = 2 ,
    ["Livery"] = "USAF 485th FS" ,
    ["y"] = -25116.49609375 ,
    ["TypeName"] = "P-51D-30-NA" ,

  ["(B) Chevy 26-1"] = { -- Start of (B) Chevy 26-1 subtable
    ["Country"] = 66 ,
    ["x"] = -21674.8984375 ,
    ["Livery"] = "FW-190A8_2.JG 54" ,
    ["ClientName"] = "(B) Chevy 26-1" ,
    ["CategoryName"] = "Airplane" ,

  ["(C) Dodge 13-1"] = { -- Start of (C) Dodge 13-1 subtable
    ["Country"] = 66 ,
    ["x"] = -34071.203125 ,
    ["y"] = -10075.522460938 ,
    ["StaticName"] = "(C) Dodge 13-1_Replacement_Static" ,
    ["CategoryName"] = "Airplane" ,

Is there some limit to the number of aircraft the script can handle? I realise this is probably on the high side and could/should be trimmed down.

My largest mission had 90 clients .. you really have a large one :) .. I hope @hardcard can shed some light into this.

That’s a strange prefix, but I dont believe it is related to this problem .. on my missions I used the "_Client" suffix, as it is easily seen on the unit list and prevents confusing Client with AI aircrafts.

Yeah, It was a unique character already set in the mission for clients, and with that many client aircraft, thought I would give it a try.

To explain further, the client aircraft all have an Airfield code at the start, identified with the 1st character of the name of the field surrounded by parenthesis for sorting.

Since the parenthesis is a special character in Lua, have to use the escape character % prior to it so it will actually look for (.

@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! ;)

I have done a couple of those things like removing all other triggers and leaving only Moose and the table building script. 200 plus aircraft is a lot to go through and compare, but feel that each one is setup uniquely and the mission has no mods. The mission has been running great for the past couple months on the Warbirds of Prey server. I will look into reducing the number of client aircraft and see how that works out, but will probably take me a while to wittle things down.

Again, thank you for a great script!

@Rudel_chw

Thanks for showcasing SWAPR in your posts, cool stuff! ;)

You are most welcome :)

.. I do have a suggestion tough: I understand the need for a small offset on aircrafts spawn on FARPs, but in the case of the Harrier can the Script be modified such that the Harrier doesnt get offset when placed on a normal parking position?

For example, on the above screencaps you can see that my Harrier is offest relative to the remaining three unocuppied clients .. I'd like to have the Harrier with no offset on this type of parking.

Thanks a lot,

Eduardo

in the case of the Harrier can the Script be modified such that the Harrier doesnt get offset when placed on a normal parking position?

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:

I ended up trimming down the table build mission to 56 aircraft. This was probably more than required to get it to work, but for the mission, made a logical sense for the aircraft placement and population there of. I kept the same number of clients in the original mission and things seem to be working properly.

@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 also ran into the issue where not all aicraft gets enumerated. In our mission I've never been able to get more than 76 slots to get enumerated by the script and the wanted total is about 115. There seem to be a set of aircraft that it can't enumerate even if I remove others so I'm currently messing around to see what the blockage is.

I'm only using parking spots on Senaki-Kolhi and Sochi, no FARPs or freely non-parking spot placed aircraft.

Total unit count ~300.

Latest version of the reference builder mentioned above I get an error on line 56:

2019-08-04 19:37:25.074 ERROR DCS: Mission script error: : [string "<edited path to reference lua>"]:56: attempt to index local 'ClosestFARP' (a nil value)

stack traceback:

[C]: ?

[string "<edited path to reference lua>"]:56: in main chunk

[string "assert(loadfile("<edited path to reference lua>"))()"]:1: in main chunk

Cool, thanks, Yeah, the large number of client aircraft is mostly to give them preset options. I am sure that modern day missions might have even more given the fact that there are even more different aircraft to choose from.

And learning from this, and I am sure you knew already, but for others looking into this script, you do not HAVE to build a table entry for EVERY client aircraft if you have a large selection. You can tailor the list to have just enough to make it look populated, but not bloated full of targets.

Yes, doing this, there will be some aircraft that pop into existence, but its another trade off from showing a 100% full airfield because you want to give your clients options. That in itself may be an unrealistic situation.

For many years, this has been asked for and always the answer was that it could not be done. YOU have made it work. Not only that, but in a way that can be integrated into older missions. Yes, there IS a certain amount of work involved to do it, but for most that have put in that much work into a mission, this would be miniscule amount in comparison. Well worth the effort and can only see it being improved from here! Well done!

Latest version of the reference builder mentioned above I get an error on line 56:

2019-08-04 19:37:25.074 ERROR DCS: Mission script error: : [string "<edited path to reference lua>"]:56: attempt to index local 'ClosestFARP' (a nil value)

stack traceback:

[C]: ?

[string "<edited path to reference lua>"]:56: in main chunk

[string "assert(loadfile("<edited path to reference lua>"))()"]:1: in main chunk

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:

Brilliant idea, mate! This also has some nice implications for PvP scenarios. For example, one could disable client slots if the other coalition manages to destroy some static aircraft. Just thinking out loud here :)

You may want to consider making this an open source project and see how it naturally grows, perhaps put it on github or something similar. People can make changes and then submit them for incorporating into the master file (which you can still review and approve and maintain control over the master file). Development of new features and bug fixes can have a shorter turn around time. Not all scripts are right for this approach, but I feel like this one would be an ideal candidate for open source. It is a great idea :)

@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

You are one certified beast!

I'd like to chime in to the other praise too, you are currently doing one cool as hell implementation to solve a age-old "issue". I really do appreciate what you are doing!

New version of Reference builder works much better (I get all client aircraft enumerated in the counter now, but still "only" get 39 in the log to copy&paste)

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

Correct, mission is Caucasus based.

I'll PM you the mission in a couple of hours, don't have access to it atm due to me being at work :)

@HARDCARD

Awesome script! Thanks so much for doing this.

Is there a way to use multiple prefix/sufix like it suggests (:FilterPrefixes)

My missions are already using a very specific naming convention so I can't get capture all the client slots with just one prefix.