Page MenuHomeFeedback Tracker

Enable Persistent Missions: onPlayerConnected and onPlayerDisconnected scripting commands are not stackable
Reviewed, WishlistPublic

Description

Seems that lately there is a lot of people working on persistence scripts, and these events are especially useful to save player data, server status, correctly handle player trying to reconnect... So any improvement on these commands could be really useful.

At this time the onPlayerConnected and onPlayerDisconnected scripting commands are not stackable.

e.g:

onPlayerConnected "diag_log _this";
onPlayerConnected "diag_log 'test123'";

When a player connects, only diag_log 'test123' will be logged; the command overrides itself on consequent usage.

it would be great if we could get;
addOnPlayerConnectedHandler - perhaps returning an index, to be used with
removeOnPlayerConnectedHandler

(and the same for onPlayerDisconnected).

Details

Legacy ID
1114843433
Severity
None
Resolution
Open
Reproducibility
Always
Category
Scripting
Steps To Reproduce

onPlayerConnected "diag_log _this";
onPlayerConnected "diag_log 'test123'";

When a player connects, only diag_log 'test123' will be logged; the command overrides itself on consequent usage.

Event Timeline

Tupolov edited Steps To Reproduce. (Show Details)Jun 28 2013, 2:40 PM
Tupolov edited Additional Information. (Show Details)
Tupolov set Category to Scripting.
Tupolov set Reproducibility to Always.
Tupolov set Severity to None.
Tupolov set Resolution to Open.
Tupolov set Legacy ID to 1114843433.May 7 2016, 3:05 PM
Tupolov added a subscriber: Tupolov.May 7 2016, 3:05 PM

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

There are 3 key things here.

  1. Make OPC and OPD stackable and also if possible the other OnXXX commands (such as OnSingleMapClick)
  1. Fix the race condition that occurs on OPD where player unit can sometimes get deleted before the event handler starts/finishes
  1. Return a "copy" of the player object on OPD to allow easier access to player data on disconnect.

Thanks!

Ed added a subscriber: Ed.May 7 2016, 3:05 PM
Ed added a comment.Jun 30 2013, 5:58 PM

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.