Page 1 of 1
calling createRoom crashes smartfox
Posted: 03 Jul 2008, 11:19
by burritos
Hi.
I am trying to dynamically create rooms with a client but once I call the SmartFoxClient.createRoom-method, it causes the client to crash.
The reason for the crash is a null-reference somewhere inside smartfox syshandler, I'll copy and paste the code here:
Code: Select all
// Successfull room Join
public function handleJoinOk(o:Object):void
{
var roomId:int = int(o.body.@r)
var roomVarsXml:XMLList = o.body
var userListXml:XMLList = o.body.uLs.u
var playerId:int = int(o.body.pid.@id)
// Set current active room
sfs.activeRoomId = roomId
// get current Room and populates usrList
var currRoom:Room = sfs.getRoom(roomId)
// Clear the old data, we need to start from a clean list
currRoom.clearUserList() /// <---- HERE currRoom is null
// Set the player ID
// -1 = no game room
sfs.playerId = playerId
...
It seems that the room creation itself was succesful as I get the following info to the server console:
[ INFO ] > Room [ The Hall ] created!
Any ideas?
Posted: 03 Jul 2008, 11:33
by burritos
Now that I change 'isGame'-variable to false, Smartfox doesn't crash but it does not dispatch an event telling whether or not the creation
was successful. What am I missing here?
Posted: 03 Jul 2008, 13:17
by Lapo
It's indispensable that you receive the current list of rooms from the server before you create new ones.
If you use a default login the getRoomList() method is called for you behind the scenes. If you use a custom login procedure simply make sure to call that method after a successful login
Posted: 03 Jul 2008, 13:23
by burritos
I am using the default login procedure.
I also tried to make a workaround and send custom message to server extension which would create the room instead. However, even the room is successfully created by the extension, clients in the same zone get no notification about that.
I am confused.
Posted: 03 Jul 2008, 13:41
by burritos
This is what happens:
1. my superserver-client logs in to the system
[Sending]: <msg t='sys'><body action='login' r='0'><login z='mygame'><nick><![CDATA[superserver]]></nick><pword><![CDATA[superserver]]></pword></login></body></msg>
[ RECEIVED ]: <msg t='sys'><body action='logOK' r='0'><login n='superserver' id='0' mod='0'/></body></msg>, (len: 92)
2. my superserver handshakes with the extension
[Sending]: <msg t='xt'><body action='xtReq' r='0'><![CDATA[<dataObj><var n='cmd' t='s'><message>
<type>PerformHandShakeMessage</type>
<id>3</id>
<username>superserver</username>
</message></var><obj t='o' o='param'></obj><var n='name' t='s'>game_extension</var></dataObj>]]></body></msg>
[Sending]: <msg t='sys'><body action='getRmList' r='-1'></body></msg>
[ RECEIVED ]: <msg t='sys'><body action='rmList' r='0'><rmList><rm id='1' priv='0' temp='0' game='0' ucnt='0' maxu='40' maxs='0'><n><![CDATA[Lobby]]></n></rm></rmList></body></msg>, (len: 166)
[ RECEIVED ]: %xt%<?xml version="1.0" encoding="UTF-8" standalone="no"?><message><type>HandShakeOKResponse</type><username>superserver</username><userID>0</userID></message>%-1%, (len: 165)
3. Trying to create a gameroom
[Sending]: <msg t='sys'><body action='createRoom' r='-1'><room tmp='1' gam='1' spec='0' exit='1'><name><![CDATA[The Hall]]></name><pwd><![CDATA[]]></pwd><max>15</max><vars></vars></room></body></msg>
TypeError: Error #1009: Cannot access a property or method of a null object reference.[ RECEIVED ]: <msg t='sys'><body action='joinOK' r='2'><pid id='1'/><vars /><uLs r='2'><u i='0' m='0' s='0' p='1'><n><![CDATA[superserver]]></n><vars></vars></u></uLs></body></msg>, (len: 166)
at it.gotoandplay.smartfoxserver.handlers::SysHandler/handleJoinOk()
Posted: 03 Jul 2008, 13:51
by Lapo
Ok, the reason is that you are not yet in a room.
For security reasons you are very limited before you have at least joined one room.
You should create a container room, maybe hidden if you prefer (use a Limbo type room), where to autojoin the user and from there perform any other actions.
Posted: 03 Jul 2008, 14:04
by burritos
Ok thanks. I'll try that out.
How about if you add a single comment to the sources related to this issue? I just lost 4 hours trying to investigate this issue. A single comment would have been a lot help!
Cheers!
Posted: 03 Jul 2008, 14:18
by burritos
Hmm.
It seems that the automated roomlistupdate is performed AFTER the event regarding to successful login has been dispatched. This is a bit irritating because now I cannot perform the autoJoin-in the login handler but I must create a timer that triggers the autoJoin sometime later? Am I correct?
Posted: 03 Jul 2008, 14:20
by burritos
... Because if I perform the autoJoin in the login handler, the system will crash in similar way because room list hasn't been received yet.
Posted: 07 Jul 2008, 12:17
by Lapo
How about if you add a single comment to the sources related to this issue? I just lost 4 hours trying to investigate this issue. A single comment would have been a lot help!
You mean a comment about the fact that you should be joined? It's all over the place in the docs...
The first examples, the code templates, the forums.
... Because if I perform the autoJoin in the login handler, the system will crash in similar way because room list hasn't been received yet.
You can follow these steps:
1- handle the login
2- send the room list
3- perform the autojoin
Posted: 08 Jul 2008, 20:51
by burritos
I think the basic problem is that the system crashes if used incorrectly.
If you ship a product, you should never assume that users use it correctly. If customer uses your product, I think it is reasonable to assume that it does not crash but gives an error in case user did something wrong. Most of the time, like in this case it is an user error but the simplest thing you could do to help us developers would be to add those error codes, and pass them as events if required.
Current scenario:
1. make a mistake
2. crawl web, documents, forums about the issue
3. possibly post a message, wait for an answer
4. fix the problem
Better scenario:
1. make a mistake
2. get an error such as ROOM_LIST_NOT_UPDATED from the api function you used or as a separate event
3. fix the problem
In which scenario you think the developer might be most satisfied?