Options for single use player slots in MP missions?

[esb77]

I think it can be done, probably in multiple ways, but I don't know enough to tell the difference between good ways and bad ways.

Desired behavior in a MP mission:  On no-fly-zone violation (any of coalitionA in zone), for each violation v1, v2, . . . ,vn, spawn one Coalition B fighter client slot, parking hot, with a specific payload.  If one of these client fighters dies or lands, it should not be able to respawn/rearm.  Basically I want a single-use player controlled aircraft slot to spawn based on a trigger, and become unavailable again once the player is done with it.   I'm considering 3 different approaches to solving this, and if anyone has good advice on one of them being obviously better than the others, or all being terrible compared to option 4 that I've never heard of, I'd appreciate any guidance.   I'm only about 10 days into the script/LUA rabbit hole, an I'm still not sure I've found a complete set of documentation yet (have Grimes's wiki and learned about script/Hooks docs in DCS install from looking at Ciribob's SSB mod).  Oh, and of course the LUA project wiki.

Approach 1    Base all the desired units at one airfield and increment warehouse weapon amounts on each violation.   This just controls missile numbers, doesn't worry about number of planes or whether they can respawn, but unarmed sorties aren't that effective so it should have the same effect more or less.  Haven't yet found any DCSscripts that look like they can be easily combined into a LUA script to increment/set the number of available rounds of a specific weapon as a trigger action.  Possible workaround, spawn AI units on short final and hope they despawn correctly after landing so that DCS increments their payload into the warehouse.  Sources have mixed reports on if this works, I haven't tested yet.

Approach 2    Activate - deactivate groups. 

CoalitionA unit entering zone sets flag v_i,  i=1,2,3,... 

Switched condition  Flag v_i activates delayed activation group g_i with single unit with desired payload.

Switched conditon Flag g_i monitors, death, crash, or landing and deactivates group g_i if Flag g_i = true.  

Activation works for me, deactivation is very inconsistent, not sure why, though single player, fly option from Mission Editor, and MP server all seem to behave differently maybe?   Need to test more, but I have problems where I'm able to spawn back into a group that should be deactivated.  Also having a player in the plane seems to prevent deactivation.  Sure, explode unit can solve that, but it's not an elegant solution in terms of wreckage on taxiways/runways.

Approach 3       Steal from the last few lines of Ciribob's- Simple Slot Blocking, ie. use the net.force_player_slot(playerID, sideID, slotID) -> boolean to  force kick to spectator in MP, to just boot players out of the slot with a message explaining it's unavailable if flags monitoring whether or not the aircraft has been used are true and the death/landing/despawn flag(s) are also true.  

 

Using the kick function from 3 also seems like it might be an option for making 2 work more consistently.

 

Any thoughts?

 

[Elphaba]

I agree, Approach 3 seems like the most reasonable and easiest to apply. 

 

[Dangerzone]

Approach 3 - however keep in mind SP and MP are two very different beasts and can behave differently. IIRC Simple Slot Block will only work on servers - and needs to be added to the servers hooks. (ie - can't be loaded and implemented into the .miz file or at a clients end). So stealing the code may not necessarily give you what you want - if you're planning on running it from a client's perspective.

Approach 3 will also give you more options down the track too - a lot more versatile. 

[cfrag]

I also think that Approach 3 is the way to go. SSB cleanly separates the server functions (slot availability) from the mission, can be nicely abstracted, and is well-tested. As @Dangerzone already pointed out, this requires SBB be installed on the hosting server, and the mission be run as MP. 

[esb77]

Hm, well I'm not sure if the server in question will have SSB or not, so I was thinking of primarily solutions that could be implemented in the .miz.  

I didn't know that the hook scripts were a separate category that needed to be implemented in .lua files in a particular spot in the server's install directory in order to be loaded and used.   Thank you very, very much for pointing that out Dangerzone and cfrag, it's a huge minefield that would have had me very frustrated at, "why is all this cool stuff not working for me." 

In checking out hooks and a brief overview of how they work, I stumbled across documentation for the DCS Singleton net.   Which has the force slot script.  Apparently added in 2.7.6, so pretty new.   So option 3, or a 2 & 3 hybrid look doable even stand-alone.   Just need to make sure I follow the Singleton documentation, and not the Hook documentation, though I'm not sure if there's actually any difference.

I'm sure SSB is the quickest, easiest and most reliable approach, and that'll be my backup plan,  but I think I'll have a go at seeing if I can get the behavior I want from inside .miz file.   At this point, even when I try things that fail, I'm learning so much from each failure that it's sort of worth it, and I fail enough that an extra failure or two doesn't really slow me down much because I'm already so slow.  I'll try to remember to post an update here once I've got results of some sort.

Thanks for taking a look, and for the advice.