Page 1 of 1

Real persistent room variables for game rooms.

Posted: 25 Jul 2008, 01:54
by delany
... i.e. don't vanish when a user disconnects.

Not sure why this doesn't already exist.

Posted: 25 Jul 2008, 02:41
by BigFIsh
This has been widely discussed among this forum. However there is a solution to this in the meanwhile, is to have server owned variables. If you are using an extension for your zone, then have it to listen for room creation (newRoom) and get the server to set the variables from the parameters passed from the client upon creation of game room.


Client set variables for game room and send request to server - server catch this variable by using:

var newRoom = evt["room"]
var var1 = newRoom.getVariable("B").value;


vars.push({name:"B",val:var1, priv:false, persistent:true}); //doesn't matter if presistent is set to true or false, it's always "true" anyway..


_server.setRoomVariables(newRoom, null, vars, true, false); //true since server is setting ownership of the variables.

Posted: 25 Jul 2008, 02:55
by delany
Yes - the answer to many of the room variable shortcomings is extensions. However, I really think that basic functionality like this should be part of the built in API.

Smart Fox Server is flexible but has many oversights when trying to produce fairly basic game functionality. Nowhere more so than in the implementation of room variables (see also the much discussed ability to see - even static - ones from outside a room).

Having use SFS for a while now, I could not recommend it to someone looking for a product that provides a good suite of ready to go game functionality on which to build. For me this is a big part of the reason I buy a product like SFS - I don't want to have to reprogram basic functionality or work around the API structure to get it. There's too much missing from SFS's basic structures that requires working around using extensions.

Posted: 25 Jul 2008, 03:32
by Menser

Delany, the only shortcoming you are having with smart fox is because of the version you bought.... How is this a fault of the products?

If you read the docs, and the forums which are all freely available before purchasing, you would have a clear understanding of which of the three server packages you would of needed. I fail to understand where smartfox server is to blame..... Or you could of downloaded an eval version, tried to write your game, and found the issues that way as well... i just dont follow.

SFS is by far (IMHO) the best product of its type that i have tried and tested. Im also lead to think that it has to be the best you have come across as well, or why would you be using it?

So, in conclusion, dont go bashing SFS for your own shortcomings, its not nice, its not professional, and its not cool.


Posted: 25 Jul 2008, 03:43
by delany
Hey -

Menser -

Not sure how involved with SFS you are but I was not 'unprofessionally' bashing SFS.

I think it is, as I said, a very flexible product for advanced projects. However, as it stands, I would and do not recommend it for more basic ones relative to the competition. I work on both advanced and less advanced projects and use it accordingly. I was offering my thoughts on improvements - which is what this forum is intended for.

I have no problem with which version to buy - and I'm not in any way upset with what I got for what I paid. In fact I have projects on both advanced and basic versions. However, the functionality I want is not available - in the default structures - in any version.

Having once again been attacked and/or condescended due to a misreading of my post on these forums I would add a further suggestion that the SFS community needs to chill! (and be a little more receptive).

Posted: 25 Jul 2008, 05:15
by Menser

Sorry if my post comes off as a tad condescending.

Perhaps i am not understanding your problem or your post correctly then, it just came off as though you were just complaining for the most part.


Posted: 26 Jul 2008, 04:50
by Lapo
It's not clear what the true problem is ...
You said:
... i.e. don't vanish when a user disconnects.

Not sure why this doesn't already exist.

They "vanish" when the ownership property is set to an existing user
In this case they last as long as the user session lasts.
The reason goes back to the origins of this features. It has been discussed and requested this way by many customers. We evaluated all the possibilities and found that this was the best way to achieve flexibility.

> If you set a variable in the config.xml it will belong to the server, and will never disappear.

> If you set a variable from client side, it will belong to the requester user and it will disappear when the user is disconnected.
This is a very important mechanism as it allows to clean up values that describe user-specific informations. Without this mechanism it would be alot more complicated to handle proper room-values cleaning.

> Finally if you set variables from the server side you have all the options, as you can set the ownership of the variables to any user and the server itself.

With these 3 options you have complete flexibility, imo.
Anyways I'd like to hear any comment on how the competition provides better systems. There's always something new to learn :)

Thank you

p.s. = one final thing...
I definitely second Mesner comments, even if he doesn't get paid by us :)

The product can be evaluated in all its features with a free 20-users license with no time limitation.
You can build your entire project without spending a single penny, you get free help in this support board even without being a paying customer, you get the over 50 examples with source code and the full docs... what else would you expect? ;)

Posted: 29 Jul 2008, 13:15
by delany
Firstly - is this the requested features section or not?! Yes - it is. I am requesting a feature, not attacking your product, so chillax.

Secondly - I never said at any point that I was unsatisfied with what I bought. Again - calm down. I'm completely aware of the differences between the versions and have bought the ones I need for the projects I work on. As I said.

Finally - and this seems to be a point that is confused with complaining about versions time and time again on these forums: having a feature available by creating an extension is not the same thing as having it built in.

I use SFS to save time, because I don't want the hassle and time of programming my own socket server. So I want simple things like this to be simple - I want real persistent variables to be created the same way as non-persistent variables - not via a different extension mechanism.

And the reason I put this as a request, as Menser points out, is that, looking at these forums, I am clearly not the only one who sees this as a simple feature that should be built into the normal structure. Also, this is something that is simple to do with competing products.

And just to make it very clear: I'm not talking about Basic vs. Advanced - I don't care what version you put it in - I just want real persistent variables that can be created dynamically by a user (so not via config.xml) and I don't want to have to add an extension to do it.

Posted: 31 Jul 2008, 19:47
by flarb
I just encountered this issue myself. I think a good compromise would make it so that the variables you specify at the creation of a dynamic room are (or can be specified as) persistent. What I did was just looped through all the room vars in the constructor of the extension class and marked them all as persistent. But room creation is pretty much the only time I want to make persistent variables.

Posted: 13 Aug 2008, 13:47
by delany
Flarb and Lapo,

There are a number of pretty simple situations in which you would want real persistent room variables outside of room creation.


A game where a user can leave the game but other people can continue to play. At the moment all that player's moves would be removed. Bridge would be a very simple example where the dummy bids and then may leave.

More generally, even in the simplest of games, spectators want to see what happened in a game after one of the players has left but the others are still there.

A very common situation is created because of the Explorer bug that doesn't disconnect users until you quit. Rooms may persist for a long time as Explorer users get stuck there. Then spectators may enter the room but will only find the variables of the Explorer user - the game looks all wrong.

Also, logically, it makes very little sense that a room variable would be tied to a user with no built in way of attaching them entirely to a room.

Please, please seriously consider this functionality - looking round these forums I can see that it is something that many others see as basic need.


Posted: 14 Aug 2008, 08:22
by Lapo
Please, please seriously consider this functionality - looking round these forums I can see that it is something that many others see as basic need.

Yes, we'll do

Thank you

Posted: 20 Dec 2008, 15:24
by x.Mara.x
Yes Lapo, please i thnk that SFS is really cool it is the best server ever, adn even though i cant get the ilimited user license its worth it.. but ive been having serious problems with the room thingy.. i think that Menser already did a code to solve the problem it would be really cool if you could put antother type of Dynamic Room: Persistant that remains there "forever" until the owner decides to erase it.. it would solve many many problems and attract even MORE people to the SFS.. because many people give up when they reach this point.. i was about to.. but i found Menser post and i still have issues but i hope that someday they will answer me :)