Hi,
I think I discovered some incoherent/misleading/incomplete documentation as to the client-side (JavaScript) access of user objects.
I got the impression that client-side access to user objects of other users is unwanted. There might be good reasons for that design, but I would have appreciated having found some words about this philosophy in the documentation. Similar situation as to the visibility of room variables: I had posed questions about this topic in a forum thread (viewtopic.php?f=33&t=32697&p=107226#p107194), and my questions had been fully answered (thanks again), but I think, it would have been even better having found such details more clearly documented in the first place.
In detail, as to the accessibility of user objects: From my experience about the limited visibility of room variables (they are only visible to everybody who can see the room if the "global" flag is set, room variables without that flag are only visible to users who are already in this room), I supposed that this might be similar for user objects of other users. To my surprise, I found that these SFSUser objects of other users are not even accessible from users within the same room (or I have some bug in my code). There is, e.g., the client-side (JS-)method "getUserById", both for instances of SFSRoom and for the SFSUserManager (by the way: when to use which, what is their intended purpose?). However, they both return "undefined" for other users' IDs, even within the same room. The API documentation for these methods say "Returns SFSUser An object representing the user, or undefined if no user with the passed id exists in this Room" for the SFSRoom method and "Returns SFSUser The SFSUser object representing the user, or undefined if no user with the passed id exists in the local users list" for the SFSUserManager method. The respective SFSRoom documentation is plainly wrong (given that I don't have a bug in my own code) and incomprehensible in the SFSUserManager case: What excactly is the local users list? What exactly is meant by "local" if it is not the current room?
Anyway: If the client-side access to foreign user objects is unwanted/prohibited, why does the method "getUserById" exist at all in the client-side API?
In case you asking why I tried to use the getUserById method in the first place, I describe my use case. You can judge yourself how exotic it is: It is the match making phase of a multiplayer, turn-based board game. I have read your documentation about your Game API, but I don't feel that your suggested invitation logic is the most appropriate design for my game: Rather than the creator of a game invites other players according to some matching criteria, in my case it should be the potential co-player's choice which game to join. Therefore, the creator of the game announces its game at some kind of blackboard, together with its specific initial board configuration, the number of intended players and the number of AIs among them. A potential co-player then scans the blackboard according to his/her preferences. Once the specified number of human players have joined a game, each one gets the name and whether it is a human or an AI from each co-player (AIs are joined server-side from the room extension on room creation automatically). This is the point where I wanted to get the co-players' user objects to access their respective user variables. Possibly, I can access the name property of another user without need to get access to the full user object (I have not tried this), but I definitely need to store the information whether the user is a human or an NPC (Non-Player Character) in a user variable since - a SmartFox design decision - a user's property of whether to be a normal user or an NPC can be accessed server-side only. So, once I need to encode this in a user variable anyway (as I thought), I can do the same with a user name since, once again, it was not clear from the documentation whether a user name needs to be unique or what exactly happens if another user with the same user name is already logged in and since I cannot guarantee a unique user name as the user can a) freely choose it and b) there is no way before login to see all already existing user names, but the user name has to be given together with the login request.
All these complications are manageable: I have created a room variable of type SFSArray that records the names and their human/AI-property of all players. However, I wished I had already read about your access philosophy of user and room data in the documentation. Moreover, I expected my match-making scenario to be very ordinary and therefore was really surprised to need to make-up these rather cumbersome workarounds just to get data about co-players (and room data for not-yet-joined users, as they still want to decide whether to join or not). If you share my suspicion that the match making scenario I have described here is not really uncommon, I suggest to rework the access-related aspects of your documentation. The exact circumstances under which the getUserByID methods return undefined should be clarified in any case, I think.
Nevertheless, thank you for your product and I hope that my feedback helps to improve it.
Misleading and/or incomplete API documentation: user object access, room variables visibility
Re: Misleading and/or incomplete API documentation: user object access, room variables visibility
Hi,
I will just address this problem first:
No this is not the default behavior and you can verify it in our example applications that are freely available here: https://www.smartfoxserver.com/download/#p=examples
When you join Room X the server will send the complete list of Users in that Room and populate the local user list, which can be accessed from the Room object, for example with the getUserById() or getUserByName() functions.
Depends ont the context. Typically it is the Room object since most apps and games work by organizing players in Rooms. There are however scenarios where you may not use a Room or support multi-Room join (e.g. players being joined in X Rooms at the same time). In such case you can use the global UserManager object.
The point is, it is not prohibited
Please check the tutorials to see this in action and maybe compare it with your current code.
Cheers
I will just address this problem first:
I found that these SFSUser objects of other users are not even accessible from users within the same room (or I have some bug in my code).
No this is not the default behavior and you can verify it in our example applications that are freely available here: https://www.smartfoxserver.com/download/#p=examples
There is, e.g., the client-side (JS-)method "getUserById", both for instances of SFSRoom and for the SFSUserManager
When you join Room X the server will send the complete list of Users in that Room and populate the local user list, which can be accessed from the Room object, for example with the getUserById() or getUserByName() functions.
(by the way: when to use which, what is their intended purpose?)
Depends ont the context. Typically it is the Room object since most apps and games work by organizing players in Rooms. There are however scenarios where you may not use a Room or support multi-Room join (e.g. players being joined in X Rooms at the same time). In such case you can use the global UserManager object.
If the client-side access to foreign user objects is unwanted/prohibited, why does the method "getUserById" exist at all in the client-side API?
The point is, it is not prohibited
Please check the tutorials to see this in action and maybe compare it with your current code.
Cheers
Re: Misleading and/or incomplete API documentation: user object access, room variables visibility
When you join Room X the server will send the complete list of Users in that Room and populate the local user list, which can be accessed from the Room object, for example with the getUserById() or getUserByName() functions.
Could it be that updates to the local user list are not synchronized if users join or leave? My scenario is the following: After users had joined a room but according to the specified number of players there were still players missing, users can join and leave (if they think they are waiting too long for a game to become complete they can leave and join another game). So, after the initial join of a room the user list changes in general. If and when the last missing user joins, then I tried to get the user objects at that time by getUserById() (I did bookkeeping of the IDs of joined users in a global room variable that is managed by the room extension) and it returned undefined, except for the own ID and except for NPCs.
An example: I had 3 browser clients open for, say, users with IDs A, B and C, who had joined a room when the specified number of players were reached. User A got (his own) user object by getUserById(A) and undefined for getUserById(B) and getUserById(C), respectively. User B got (his own) user object by getUserById(B) and undefined for getUserById(A) and getUserById(C), respectively. Similar for user C (OK, to be fair: from my memory, I cannot guarantee that for all other users undefined was returned, but at least for some).
Is this a bug in SmartFox or in my code, or is this the intended behavior?
Re: Misleading and/or incomplete API documentation: user object access, room variables visibility
Could it be that updates to the local user list are not synchronized if users join or leave?
If you join a Room you will always be synchronized with the Room changes (room variables, user list etc...). As soon as you leave you will stop receiving updates for that Room and all clients joined in it.
Is this a bug in SmartFox or in my code, or is this the intended behavior?
If you think you have found a bug send us all the details. See here for the list of info we need: viewtopic.php?f=18&t=16497
Thanks