From Columdrum:

Seems that lately there is a lot of people working on persistence scripts, and this event its especially useful to save player data, server status, correctly handle player trying to exploit reconnect... So any improvement on this command could be really usefull. Here a list of changes that can improve it and make it really useful and reliable.

1- Make stackable, refs above all commented there so no need to add anything

2- Return the player object itself as param:
As already stated main use of this command right now its save player data, so most times you want to search for the player object, so that would make that easier and should be that hard to implement.

3- Some way to assure the eventhandler its executed before the unit its deleted:
With the current implementation of this event, to get the player data you should first search for the player object( by name or by UID), get all the data(position,weapons,...), and under heavy load (low server fps) that can cause that the object of the disconnecting player is deleted before getting all this needed data, and therefore its lost forever. Posible solutions to this would be:

-Only really delete the player object after all the onplayerdisconnected events are executed or any of them have returned a value( something similar to the keyeventhanderls where you can return true or false to indicate if the event have handled it completely or not). Main problem of this implementation is that if the script creator makes a mistake that generates an infinite loop inside the event could leave ghost players, could be avoided by introduce a adjustable constant (via config, description.ext, scripting command....) that indicates a timeout to handle this event.

• The player object that its returned by the event its a exact copy of the real player object, but its not the real one, so the real one can be deleted on all the clients or even the server, but you can still access all the data of the player object just like it was before disconnecting. This way you wont have posible ghost players problems, but may be really a mess to implement

I totally agree( btw thats a copy paste from my A2 ticket? https://dev-heaven.net/issues/39421 XD) .

Also there are other non stackable commands, most of them starting by "onXXX" that would be really useful, like onEachFrame, onMapSingleClick, onTeamSwitch , ...

The implementation of this would greatly improve addon and script compatibility, since right now you can't use any of those commands if you want to asure that your script would be compatible with others.

This needs to go to the top immediately unlike half the BS issues that are posted here this one is extremely important

Oh yes, don't want to make ARMA non persistent, very important!

I agree with DevilDogGamer

worthy

There are 3 key things here.

1. Make OPC and OPD stackable and also if possible the other OnXXX commands (such as OnSingleMapClick)

2. Fix the race condition that occurs on OPD where player unit can sometimes get deleted before the event handler starts/finishes

3. Return a "copy" of the player object on OPD to allow easier access to player data on disconnect.

Thanks!

This function might just make onPlayerConnected obsolete.
http://community.bistudio.com/wiki/BIS_fnc_MP

"2- Return the player object itself as param:"

I don't know if OP realises that this is server only command while the player object creation is client process. Unless client is fully loaded and player is created there is no way of referencing player object.

There are other special scripts that execute both client and server upon player joining.