Hi, in my application i am not interested in knowing when a particular user entered a room so i didn't hook USER_ENTER_EVENT to a room in admin panel at the other hand i need to know when user exists a room so i added the USER_EXIT_EVENT to that room, its a single event that i need there.
However i discovered that when i don't have USER_ENTER_EVENT i am not getting USER_EXIT_EVENTs fired for users leaving room unless they weren't in the room when i joined. Is there some dependency there? I can see that there may be at the other hand i don't see a reason for it.
If this is so i am stuck with using both events all times which means additional traffic or creating my own functionality for it.
Thanks.
USER_ENTER_EVENT/USER_EXIT_EVENT dependency?
USER_ENTER_EVENT/USER_EXIT_EVENT dependency?
Pushing the limits of flash platform at http://blog.flash-core.com
Yes, the two events are dependent.
If the client API never receive a USER_ENTER they will know nothing about Users in a certain Room besides those that are sent initially when you join it. Consequently when a USER_EXIT is sent to the client and no corresponding user is found no event can't be fired.
If the client API never receive a USER_ENTER they will know nothing about Users in a certain Room besides those that are sent initially when you join it. Consequently when a USER_EXIT is sent to the client and no corresponding user is found no event can't be fired.
Lapo thanks, i was worried its something like this. That means i need to do my own exit which sends only user name to identify him i don't need the whole user instance.
Pushing the limits of flash platform at http://blog.flash-core.com
No, I think you should not worry at all. We are talking about updates that are really small and efficient. I don't think it's necessary to get to this level of paranoia for negligible update such as this. I can assure you that this is really a super minor thing in the big picture of building any game or application.
Lapo again thanks, i will think about it. But i would think that user join events also carry the user variables information which may be not negligible in this scenario. This application is too specific and i need this exit event for back compatibility with a functionality that was implemented in previous version build on SFS1 where everyone needed to be in atleast 1 room. I will try to get rid of this in next versionsl.
Its a chat application where most users are not in any room at all. But this means that if 2 users chat and 1 disconnects the second one doesn't know about it. As i see it there are 3 solutions for this:
1st buddies, which means that all chatting users will be buddies for the length of their conversation, this however is not a viable option if there is also other buddy functionality. It can turn into chaos where no one knows who is a real buddy and who is just temporary. Also i think its an unnecessary overhead.
2nd big limbo room, this was the solution in SFS1 version. Its nice, clean and easy to monitor everything that happens. The problem is that user theoretically knows about users that he doesn't need to, also i would imagine that with thousands of users this will start to be a problem.
3rd conversation manager done on extension, so user chats through extension which checks if there is conversation going on between those 2 users and if not it will add it to the manager. This way everything is monitored as it should be just between users that actually chat. During any critical event LOGOUT/DISCONNECT etc. all linked users can be notified. This is how i did it now in SFS2 version.
The problem is that in the old version there was some specific functionality that can't be done the 3rd way so i will still use 2nd for back compatibility and slowly transform or get rid of those parts in next versions.
Its a chat application where most users are not in any room at all. But this means that if 2 users chat and 1 disconnects the second one doesn't know about it. As i see it there are 3 solutions for this:
1st buddies, which means that all chatting users will be buddies for the length of their conversation, this however is not a viable option if there is also other buddy functionality. It can turn into chaos where no one knows who is a real buddy and who is just temporary. Also i think its an unnecessary overhead.
2nd big limbo room, this was the solution in SFS1 version. Its nice, clean and easy to monitor everything that happens. The problem is that user theoretically knows about users that he doesn't need to, also i would imagine that with thousands of users this will start to be a problem.
3rd conversation manager done on extension, so user chats through extension which checks if there is conversation going on between those 2 users and if not it will add it to the manager. This way everything is monitored as it should be just between users that actually chat. During any critical event LOGOUT/DISCONNECT etc. all linked users can be notified. This is how i did it now in SFS2 version.
The problem is that in the old version there was some specific functionality that can't be done the 3rd way so i will still use 2nd for back compatibility and slowly transform or get rid of those parts in next versions.
Pushing the limits of flash platform at http://blog.flash-core.com
One thing is a user leaving the room (USER_EXIT) and another thing is a user who disconnects.Its a chat application where most users are not in any room at all. But this means that if 2 users chat and 1 disconnects the second one doesn't know about it. As i see it there are 3 solutions for this:
You can catch disconnections on the server side in your Extension and fire a custom event back to your clients where appropriate.
Lapo indeed thats the solution 3 i mentioned. That basically i need to know and manage which users started conversation between themselves. Whereas in the room scenario there was no such management needed since everyone knew about everyone 
Pushing the limits of flash platform at http://blog.flash-core.com