joinRoom always returns isSpectator=true
joinRoom always returns isSpectator=true
Server 1.4.5 beta AS3
joining a gameroom with server.joinRoom(roomId, pass, false) seems to correctly return a player number (1 or 2) and error out if a 3rd player attempts to join (maxUsers set to 2, maxSpectators set to 25)
however
user.isSpectator() returns false
user.getPlayerId() returns -1 (spectator)
when called in the onLogin event handler
Seems trivial but we may need to use these in our app and they don't seem to work properly.
Any ideas here - is this a bug?
joining a gameroom with server.joinRoom(roomId, pass, false) seems to correctly return a player number (1 or 2) and error out if a 3rd player attempts to join (maxUsers set to 2, maxSpectators set to 25)
however
user.isSpectator() returns false
user.getPlayerId() returns -1 (spectator)
when called in the onLogin event handler
Seems trivial but we may need to use these in our app and they don't seem to work properly.
Any ideas here - is this a bug?
Are you sure is the onLogin event handler? That's the event that is fired after you have successfully joined a Zone, but you are not logged in any room yet.however
user.isSpectator() returns false
user.getPlayerId() returns -1 (spectator)
when called in the onLogin event handler
Maybe you mean the onJoinRoom event?
Lapo wrote:Are you sure is the onLogin event handler? That's the event that is fired after you have successfully joined a Zone, but you are not logged in any room yet.however
user.isSpectator() returns false
user.getPlayerId() returns -1 (spectator)
when called in the onLogin event handler
Maybe you mean the onJoinRoom event?
Right.. my bad. I meant the onJoinRoom() event.
any ideas?
-
knegarpetter
- Posts: 13
- Joined: 11 Apr 2008, 10:25
it seems like this bug is still alive...
regards
Petterhttp://forums.smartfoxserver.com/viewto ... =spectator
regards
Petterhttp://forums.smartfoxserver.com/viewto ... =spectator
Was this ever fixed? We're having the same problem using java server extensions. We do all of our joining, leaving, and creating rooms server-side. When the user1 joins several rooms and is a non-spectator in one room, it works fine, he can recognize that he is a spectator or not correctly in all rooms.
Then user2 logs in, it shows user1 as a spectator in all rooms. There's nothing we can edit in your code because the message is coming back from the server incorrect and those files are already .jar.
Here's what I mean:
in the above example, I joined them to the same room both as non-spectators. In the admin tool, it shows 0 spectators in that room. What gives?
Yes they are game rooms, we verified that in the admin tool.
Yes we passed isSpectator in the joinRoom arguments
Yes we set the player index when the user joins and is not a spectator...
On a side note we noticed, the user doesn't "auto join" when he creates a game room serverside, we have to join the user to the room. The docs say otherwise somewhere. Not sure if it's supposed to work this way or not, maybe he only autojoins when we call createRoom on the client and we're doing everything server side. Regardless we're lost on the spectator thing and we considering everything that might be causing it no matter how remote the possibility.
Then user2 logs in, it shows user1 as a spectator in all rooms. There's nothing we can edit in your code because the message is coming back from the server incorrect and those files are already .jar.
Here's what I mean:
Code: Select all
...snip...
<u i='16' m='0' s='1' p='-1'>
...snip...
<u i='17' m='0' s='0' p='1'>
...snip...
Yes they are game rooms, we verified that in the admin tool.
Yes we passed isSpectator in the joinRoom arguments
Yes we set the player index when the user joins and is not a spectator...
On a side note we noticed, the user doesn't "auto join" when he creates a game room serverside, we have to join the user to the room. The docs say otherwise somewhere. Not sure if it's supposed to work this way or not, maybe he only autojoins when we call createRoom on the client and we're doing everything server side. Regardless we're lost on the spectator thing and we considering everything that might be causing it no matter how remote the possibility.
Hi ryratt,
the client API keep track of a few properties like isSpectator, playerId and activeRoom which can convenient when using a single-room approach.
For the multi-room approach you should handle these ids/flags manually with a little extra code that fits your custom needs.
Example: if you want to keep track of the isSpectator status you could simply store the playerId in an array on each onJoinRoom event where the key is the room (or room id).
In other words on each onJoinRoom you would probably have something like this:
In order to see if your client is spectator in a certain room you can use the same array and see if the playerId == -1, if so the player is a spectator.
Hope it helps
the client API keep track of a few properties like isSpectator, playerId and activeRoom which can convenient when using a single-room approach.
For the multi-room approach you should handle these ids/flags manually with a little extra code that fits your custom needs.
Example: if you want to keep track of the isSpectator status you could simply store the playerId in an array on each onJoinRoom event where the key is the room (or room id).
In other words on each onJoinRoom you would probably have something like this:
Code: Select all
playerIdByRoom[roomId]Â = sfs.playerIdHope it helps
No that won't do it. As I said in my post, the client can tell if itself is a spectator or not, but no matter if we set playerId before or after they join a room, it can't get the correct isSpectator or playerId of the other users in the room. It simply sets them all to spectators with a -1 playerId. Also, the admin tool shows everyone with a playerId of 0.Lapo wrote: In order to see if your client is spectator in a certain room you can use the same array and see if the playerId == -1, if so the player is a spectator.
Hope it helps
If you look at the xml message in my previous post, you'll see what I mean. That is the userlist in the joinOk Message for the room in which they are both non-spectators.