Sweet =)
But yea the best solution to this issue is disable as many default server events as possible and use extension calls with the JSON protocol. Its by far the best feature SFS has =)

Humm really? I always leave it on. Any reason (performance wise) why we should turn AutoReloadExtensions off? Sometimes during production some players find bugs that are so rare they can only be found in very specific situations. I find this tag extremely useful for me to fix these things in run tim...

Humm sorry I have no idea why I didn't see "setCreator" in the docs lol. But yea, the use of internal variables seems more reliable. I made it so when the server fires userExist or userLost internal event from a room, the host propertie goes to the next one in the user list, and when the h...

Humm another find here: Turns out that getCreator() always retrieve the original creator of the room. It doesn't pass the host to the next player. At first it is useful, but since there is no setCreator, you can't rely on it to pass it over and over as people leave the room. example: - Player X is t...

Interesting in deed =) Thanks for that BigFIsh. Never knew anything about SocketChannel til now hehe. I actually decided to make a system here myself, but I think I'll get back to use the SocketChannel idea you gave. Here is what I did: if (evtName == "userExit" || evtName == "use...

Thanks for the quick reply and the suggestion BigFIsh. I didn't want to answer right away before I try everything myself =) Well turns out that getCreator() doesn't really return the creator of the room, but instead a SocketChannel (sorry, don't know what that is). I could probably just assign a pro...

hey there fellas I'll probably get to that by the end of this week, so I'm asking in advance just to make sure. I understand that room.getCreator() will get you the user that originally created that room. But what happens if that user leaves? Does the ownership of that room goes to the next user ins...

Cool thanks Big Fish =D Yes in fact there are room.getUserByName(uName) and zone.getUserByName(uName). I found them both on posts from Lapo in some old topics, but its not documented in the online docs (at least not in the AS extensions documentations) Is there a place where I can check for all the ...

Hi guys, Is there a way to retrieve the user class from a room instance in the server the same way we do client side? Client Side example: var user:User = sfs.getRoom(1).getUser(uName); In the Actionscript Server Side documentation (http://www.smartfoxserver.com/docs/docPages/serverS...

CPU overload resolved: - Turned out to be a sequence of events that would lead into an infinite function call loop. If one client would trigger that sequence, the server would then get stuck in a single loop that consumed the entire CPU in a matter of hours. But still, now just out of curiosity and ...

Hello there, We are on the final stages of our newest expansion and currently at the "stress test". Our CPU hits 100% every 10 to 16 hours forcing me to restart SFS. When I do, CPU gets back to normal and the process starts all over again. My first clue to what could be going wrong is our ...

I know this post is extremely old but for those who eventually have the same problem, here is the real reason for the error: - Rhino can't handle big chunks of code within one method alone. In my case I had a single function with over a thousand lines of code. Solution: Split your function into diff...

Thanks lapo thats what I needed to know

Let me refine my question: the create room method from the client API tells us that when a room is a game room (isGame = true) it automatically joins the creator of that room in. In order for that user not to leave the previous room, there is a tag called exitCurrentRoom where you set it to false du...

Lapo wrote:User data that needs to stay server side only goes into User.properties

Awesome! That is exactly what I need! Thanks a bunch