View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009610||Multi Theft Auto : San Andreas||Synchronization||public||2017-04-29 21:41||2017-07-04 15:58|
|Target Version||1.5.5||Fixed in Version|
|Summary||0009610: Setting player name in an onPlayerConnect event handler results in desync|
When you change the name of a player attempting to join your server upon the "onPlayerConnect" event fires, the client gets desynchronized.
|Steps To Reproduce|
Execute the following example code:
|Tags||No tags attached.|
Servers cannot permanently change another players name. In your steps to reproduce you've got "Reconnect" so I'm pretty sure this is a false bug report as you're reporting an intentional feature as a bug.
Reconnect so you actually get a chance to trigger that event yourself without the need for any other players on the server.
When you call the (server-sided)
Only when setting the name inside a "onPlayerConnect" (server-side) event handler occurs the problem I described - values returned by
To better illustrate the issue, suppose this situation:
What happens after that:
Hope this helps.
Edit 2: This issue won't be fixed. The problem is getPlayerFromName, which returns a valid player element to a player, which didn't join the game yet and this particular client won't receive the update packets related to his player element, leading to desynchronization. Instead of synchronizing the server's player with the client's local player on successful join, the code will show a warning if any script tries to use player-modifying functions on the player element.
It would be nice if there was a way to assign new nicknames to players on join. Right now it is a bit problematic, because the default "joinquit" resource uses the "onClientPlayerConnect" event to display join messages.
I've been able to workaround this with a bit of hacks, mainly using the "onClientPlayerChangeNick" event instead of "onClientPlayerConnect" in the client-sided "joinquit" resource.
As for the actual desync issue, I think a warning is fine. It'll at least make the script authors aware of some otherwise hard-to-spot problems.