{ Update } SmartFoxServer PRO 1.6.3 available

[Ganius]

A couple of quick questions regarding the forcelogin paramater on the loginUser function:

What does it check to see if the user is already in the zone? Username? IP address?

Also, does the forcelogin cause the old connection to become disconnected? If not, will this ever be an option?

I ask because we append a random number to the end of our guest connections and sometimes we have ghost connections remaining behind after they leave. We use forcelogin, but it seems that the ghost connection remains, so the user is logged into the zone twice...

Cheers,
K.

[Lapo]

What does it check to see if the user is already in the zone? Username? IP address?

It checks if an identical username exists in the specified Zone, if so it will first perform a disconnection of that user, then login the user again.

Also, does the forcelogin cause the old connection to become disconnected?

Yep!

[Lapo]

I ask because we append a random number to the end of our guest connections and sometimes we have ghost connections remaining behind after they leave.

But... if you don't use the same exact name as before the mechanism won't work

The only way we recognize the same user is from a username, provided that your login system verifies credentials.
In other words, if you use the default system with guest users it won't work.

[Ganius]

Thanks for the info Lapo.

What would be the likelihood that in a future release it checks the username, then if there is no match it checks the users IP address, then kicks the old user if there is a match...?



Cheers,
G.

[Lapo]

Unfortunately this is not an option, because more users could be behind the same IP address. So if we have 10 users coming from 30.31.32.33 we have no way to know which one among those should be disconnected.

[Ganius]

Fair enough - I figured as much. Worth asking though!

Unfortunately MaxIdleTime is not good for me, cos we need to allow a massive idle period. I'll have to work out another way to rid these connections...

Thanks,
G.

[Lapo]

Keep a short MaxIdleTime but make the client send custom keep-alives messages. (Empty calls to an extension)

This way you have control over which users are not active, they won't send the pings (according to your logic) and will be disconnected.

Additionally SFS 1.6.3 adds the MaxSocketIdleTime for pending socket connections (which have not performed a login)

[saxmaestro]

Hi Lapo--

To put a spin on the previous post related to sendXtMessage giving an error about needing the room list, we intentionally disabled the getRoomList item in DisabledSysActions in config.xml. Then after successfully moving a user into a room, we use sendXtMessage to send to that room.

Is there any way to suppress the error or fake the room list on the client side so that it will still send? When we enable the getRoomList item in config.xml it works again, but not whenever it is disabled. With the number of and nature of rooms we have, we would much rather not broadcast them at all. Is there a way to override the getRoomList function on server-side that I may have missed that could accomplish the same thing?

Your advice is much appreciated!

--Jonathan

[saxmaestro]

Lapo--

I realize that this workaround may not work in future versions so would appreciate a better alternative, but for anyone else facing this issue at the moment, I put this code into my login handler:

_root.smartfox.roomList = [new Room()];

where _root.smartfox is the SmartFox instance. This gets our app back to working order, but is obviously not ideal or version-safe. I'd still love an official workaround if you can offer one!

--Jonathan

[Lapo]

To put a spin on the previous post related to sendXtMessage giving an error about needing the room list, we intentionally disabled the getRoomList item in DisabledSysActions in config.xml.

Which post!?
It doesn't make sense posting here, it's completely unrelated

Please start a new thread, and I'll remove these posts from here

[saxmaestro]

Lapo--

Hah, sorry for the confusion. I am referring to BigFish's post on page 2 about the error "The client API cannot function properly until the room list is populated". While BigFish got the message because he had not moved the users into a room before trying to send a message, our app was working fine in version 1.6.2 but broke in 1.6.3 because we suppress the roomList message. I can start a new thread if you'd like, but I figured this was the right place because it directly relates to an upgrade from 1.6.2 to 1.6.3. Thanks!

--Jonathan

[Lapo]

our app was working fine in version 1.6.2 but broke in 1.6.3 because we suppress the roomList message

Suppressing the roomList message is not a good idea. You can send a different room list, maybe with a filtered version of the whole list instead.

In order to do so you will have to mimic the XML sent by a regular getRoomListUpdate

[BigFIsh]

Suppressing the roomList message is not a good idea

Not really, I have done this myself too. I managed to send the room list to each client that is about 2 times shorter than the original, although I had to add some code in the SmartFoxClient.as to get this working but it works as expected.

Jonathan, you can get around your problem by commenting out the new code at line 2771 in SmartFoxClient -> if (checkRoomList()) return; in the meanwhile.

We are following pixelGame's example - although that game doesn't work anymore with SFS1.6.3...

[Lapo]

We are following pixelGame's example - although that game doesn't work anymore with SFS1.6.3...

What is not working?
I am playing with that example right now, using 1.6.3 and without a single problem.

[BigFIsh]

I tested that game again, but the problem still persist. I'm using the new API i.e. /Actionscript_API/Flash-AS2/. The game works fine with the older version which is /Flash API/Actionscript 2.0/

I think the problem occurs at this particular code:

smartfox.sendXtMessage(xtName, "jme", [], "str", -1)

which gives this error:

****************************************************************
Internal error:
The room list is empty!
The client API cannot function properly until the room list is populated.
Please consult the documentation for more infos.
****************************************************************

or maybe I didn't RTFM