forums.smartfoxserver.com

To start with, I am using the .dll Thomas sent me on 2/14 (which I know contained changes in this area), so I'm not sure this has much affect on the community at large and perhaps there has already been a fix. But since this is definitely a bug, I figured I had better report it.

Here's the step by step:
1. Client1 creates a game room.
2. Client1 sends a PlayerToSpectatorRequest, and is changed to a spectator (PlayerId = -1).
3. Client2 joins the room. According to his client, Client1 is a player with PlayerId 2. Client2 is assigned PlayerId 3 (both clients agree on this).
4. Client1 switches back to a player via a SpectatorToPlayerRequest. He is assigned PlayerId 4 (any changes made with both clients present are correctly updated on both clients).
5. Continuing to switch Client1 back and forth between spectator and player, his assigned PlayerId continues to count up (6 the next time he's a player, then 8, etc.) until the maximum number of players is reached, when he is finally assigned PlayerId 0.

I'm still using the default PlayerIdGenerator.

If I were to guess, I would suppose that when being switched to spectator, he's getting a new PlayerId assigned to him, and neither this one or his old one is being freed.

Whatever the case, it'd be great to see this resolved. Let me know if I can provide any more info.

For what it's worth, I wrote a simple PlayerIdGenerator and ran some tests.

Indeed, whenever a PlayerToSpectatorRequest or a SpectatorToPlayerRequest is received, getPlayerSlot is called. freePlayerSlot is not. Having no idea what the server code looks like, I think it would be fair to guess that the PlayerToSpectatorRequest handling is intended to be calling freePlayerSlot, but is calling getPlayerSlot instead (maybe a copy/paste error). This suggests the problem is with the server, and not the Unity client.

I will post on the server forum.

Super - will keep an eye on it

Fixed, a patch is coming soon. Stay tuned.