forums.smartfoxserver.com

Lapo,

My SmartFox game community has been experiencing problems when multiple users try to join a game room at the same time. I have investigated the problem and determined it to be a possible bug with the Smart Fox Server.

The issue:
Multiple users get assigned the same game room player id OR a user gets assigned a player id of -1 when they should be receiving a valid player index.

How to Recreate the issue:
1) Setup two testing machines. Login into the game client on one machine and create a game room.
2) Open two additional instances of the game client (one on each machine).
3) Have both users join the game room at the same time (several attempts may be needed to get the effect).
4) Trace statements will indicate a player id of -1 assigned to one of the users and/or both players will get tracked as having the same player id.

As a result of this bug, one or more of the following problems can happen in my game lobby:
1) Two users might get assigned to the same player slot (only one will actually get stored in the room variable, but on the other player's screen, it will appear that they are in that slot)
2) A user may simply fail to get assigned a player slot (since there player id was set to -1). This will cause an internal bug with my client, requiring the user to leave the room and rejoin to be assigned a valid player id.

This bug is becoming a particularly problematic issue since I released 8-player game support. After finishing a game, players will frequently start a new game and then all pile into the room at the same time. I would expect the server to delay sending a user join response until it can properly assign each user a valid player id.

I appreciate your support in advance, and, as always, I am happy to provide further information and support in whatever way I can to expedite a fix.

Hey Ross,

You could prevent this issue by applying this workaround:

1. Have the players send a XT message to the server requesting to join a room (or intercept the join room internal event)

2. Have the server determine which player ids are available (i.e. keep an array), and then manually assign a player id to that player and then join him/her to the requested room.

Enjoying your game

BigFish- good point- if need be we can probably resolve this issue by adding code to the server side extension.

Still, I'd ideally prefer a fix with the SFS itself, since it's already using resources for internally keeping track of player ids. If it's necessary to rewrite the player id assignment code in a custom extension, then having it as a feature of the included API seems irrelevant.

I should also add that there is also a bug with the Admin Tool regarding player ids. They always show up as "0".

Any thoughts on this issue, Lapo?

It's been over two weeks since and still no acknowledgement on this issue from Smart Fox Server team. I know there's a lot going on with 2.x development, but I would greatly appreciate a response.

Fixed in the upcoming update.

Original Issue Resolved
I have confirmed that patch 1.6.9 fixes the issue of simultaneous users being incorrectly assigned a player index of -1. This will correct the simultaneous room join bug for any users that follow the tutorials on this site whereby players are tracked in room variables based on the server assigned player index.

Closed Player Slots/Reserving Player Slots for Computer Opponents
In my newer game code, however, I had to change the way my client was internally storing the playerIndex in order to support the ability to add computer players and close player slots after a game had been created. Since the server only assigns player indices based on actual human players (or artificial sockets) that have connected to the game, I had to abandon the server-side assigned playerIndex and instead assign players positions based on what slots were available according to the room variables.

When the game host decides to close a player slot or add a computer, it creates a room variable for that player position (just as in SFS tutorial). Then, when a new player joins the game room, instead of setting their player variable based on the server-side assigned playerIndex (as done in SFS tutorial) I scan the room variables already set, give the player the first available position, and then tell them to set a new player room variable based on that index. The problem, of course, is that if two users join simultaneously, they both look at that room variable list and see that same position as available. As a result, they both assign the same player room variable and whichever one happened to fire last overrides the variable for the other player - so the last player to override the room variable gets their name added to the player slot and the other player essentially becomes a bugged spectator.

The solution to this problem: As BigFish suggested, I moved the player room variable assignment that was being done on the client side over to the server side. Since the server has direct access to the variables, it is able to set them immediately upon the user join without the delay.

Related Issues:
In order to finalize the server-side assignment of the player slot, I will also need to have the playerSwitched/spectatorSwitched functions call the assignPlayerSlot function on server side. However, these functions currently do not have a way to access the room object where the switch occurred.
See forum entry: http://forums.smartfoxserver.com/viewto ... 3132#33132

I’m now storing my playerIndex in the user variable so that the server side code has a way to set the resolved value (accounting for closed/computer reserved slots). However, I noticed that there isn’t an easy way for the client side to access the active user’s variables.
See forum entry: http://forums.smartfoxserver.com/viewtopic.php?t=8224

Enhancements to SFS Moving Forward:
I would consider the ability to close or reserve player slots for computers/friends to be a valuable functionality to many developers. As such, it might be worth it to consider a means to accomplish this without having to use server side code.

For example, you could allow the client to assign/reserve server-side assigned player indices. This way, when a new player joins, it skips over any player reserved player indices. This could also be useful keeping track of how many actual player slots are still open. Like room variables, once the creator of the reserved slots leaves the room, those reserved slots would become open once more.