Purely from the onBirth or onEnterUnit event data, how to tell if player is a RIO/WSO/Backseater?

[Elphaba]

Assuming that nothing in the Mission Editor has been setup i.e. naming the Pilot something with 'RIO' in their playerName etc.

Is it even possible from when they just into the back seat to know that they aren't the pilot from an onBirth or onEnterUnit event -  obviously this is in MP or even dedicated server environment.

 

Edited March 25 by Elphaba

[Elphaba]

So, the best way I've been able to come up with is to keep a table of all players, by unitID's. On the PLAYER_ENTER event, check if a unitID with a player already exists in that table, and if so, then you must be a RIO/WSO. However I haven't checked this; it might not work because hoggitworld says:

Occurs when any player assumes direct control of a unit. Initiator : The unit that is being taken control of.

And that would imply it only fires for the pilot, not the backseater. 

On top of that, there's no way to know which player (client) was the one who triggered this because it's not included in the event. So maybe I need to also keep track of births and cross-check?

Anothery source of failure I can see is for the Apache, where you can MP as a CPG and then have a human jump in as pilot.

So somewhere there is a way to know which slot you're filling, but I'm not sure it's exposed to the scripting side (sigh).

Unless someone can think of better? 

Edited March 25 by Elphaba

[Elphaba]

So because of the decade old bug of S_EVENT_PLAYER_ENTER_UNIT not firing in MP games, it's impossible to use that to know when a player enters a unit and then see if that unit already has a player and therefore you know it's a backseater. 

I have posted another request to fix it in the bug channel; please upvote if you care about MP games. 

 

 

Edited March 26 by Elphaba

[Grimes]

The server API has finer detail on it via the onPlayerChangeSlot callback. The net functions are accessible in the server API and mission scripting, which you can use net.get_player_list and net.get_slot to get the slot, and therefore seat the players are in. You'd have to constantly be calling it unfortunately to get up to date information. The slot id is the unit id for a given unit with a _x to define the seat a player is in. For example in a F-15E, F-14, and AH-64 it would be unitId_2 for the WSO/CPG. unitId_3 and unitId_4 would be left gunner and right gunner in the Huey. There is no information currently on who initiated a given action. For stats in slmod I attribute it to everyone in the aircraft. 

[cfrag]

On 3/26/2024 at 12:34 AM, Elphaba said:

So because of the decade old bug of S_EVENT_PLAYER_ENTER_UNIT not firing in MP games, it's impossible to use that to know when a player enters a unit and then see if that unit already has a player and therefore you know it's a backseater. 

Unfortunately, player_enter is borked in MP, which is truly unhelpful since that is when it is needed most. What you can do do (and what @Grimes kindly alluded to) is write a small server script that works similar to the way SSB communicates with client-side missions: whenever a player connects to a slot or leaves a slot, set a flag with the exact name of that player to a value: 0 = not connected, 1 = PIC, 2 = crew - and interpret that value during events. It's less than optimal (you'd need active polling), and I don't know how quickly the server synchs flags (I have a nagging suspicion that it can take up to a second for some clients). But it may be a start, and if you are writing missions specifically for crew, I think you'll have some kind of active monitoring in place for players anyway.

[Elphaba]

I'm waiting to test it but I might have a workaround, due to the architecture of my Superscript. Failing that, then polling the net stuff seems like the only thing left to do... I can't believe such an important thing for scripters has been logged for over 10 years and never been fixed.

[Elphaba]

On 3/27/2024 at 9:04 AM, Elphaba said:

I'm waiting to test it but I might have a workaround, due to the architecture of my Superscript. Failing that, then polling the net stuff seems like the only thing left to do... I can't believe such an important thing for scripters has been logged for over 10 years and never been fixed.

So, I have a workaround. I didn't have to rely on polling or the net singleton stuff... but my Superscript has a Player Manager script and through a little bit of cunning I was able to utilise that and the way that DCS works with / without events to make it work. 

I know it won't happen, but damn I wish MP had all the same events as SP...