chat filters

[chengen]

Currently, after login the client will join the world room (server created) and it's own kingdom room. When receiving leaveRoomEvent client will send request to join his kingdom room again. So this RoomTrackingEventHandler must close the kingdom room created by client without filter and create a new room with the exact same name and put clients back in. But if that is possible, then it needs to be done only once until server restart because this room will always be there even though everyone leaves, correct?

[tcarr]

If the room it creates is persistent, then it will remain on the server until the server is restarted, yes. Unless your clients are specifying persistent in the CreateRoomRequest, the room will be destroyed when all users leave it, then created again when somebody wants to join it. Making all rooms persistent will cause a memory leak if you want to keep your ES5 running for months at a time; if you are going to restart it daily then it's not a problem unless your game becomes VERY popular.

I think you can probably do this in userDidLogin in your login event handler. I suggest that you test it using the older client (but pointing at your test ES5) and see what happens.

Outline of steps for userDidLogin:
1. getApi().getUserJoinedRooms
2. Iterate through the Collection<RoomValue> looking for the room name for his kingdom room. If found, use getApi().getRoomVariable or similar method to check whether this room is one created by the server or not. If not created by the server, use getApi().destroyRoom, then create a new room with the RoomConfiguration that you need, including the filters and after creating the room, use getApi().createRoomVariable to set a room variable so that we can tell this room has the right filters.
3. If the user isn't already in his kingdom room, just create one and put him in it, as in step 2 above.

If the kingdom room IS persistent, then in the executeLogin method of your login event handler, you can create the room if it's not already created but not add the user to the room, or you could use the above userDidLogin process.

[chengen]

Teresa,
We want to avoid server reboot as much as possible. The only reason we should be rebooting the server is we make changes to our plugin (improvements, bug fixes). So I guess we will stick with non-persistent rooms.
I think currently we will just add the filter on client crr request. Hopefully the older version of the app will disappear soon then the problem is gone. We will revisit the options in this thread if we must override the remaining older versions.
Thank you for all your help on this topic.

[tcarr]

Sounds good. You want to add that ignoreUnknownMessages to the client pretty soon anyway, right?

[chengen]

Yes, that is added already.
The problem with iOS app is, it will take a while to get into distribution.

[chengen]

Hi, Teresa,
I just want to follow up and point out, the ES5 Admin console can't seems to modify the filter settings. Whatever I do, after I click save it revert back to default. Is that a known bug or something wrong with our installation only? I am using the AIR admin client.

[tcarr]

That was fixed with ES 5.3.3. For versions earlier than that, you have to use DbUtility to make a restore.xml file, edit it, then run DbUtility again. I explained how to do this to somebody recently; if it wasn't you let me know and I'll give you more details.

[chengen]

Sorry you explained to me actually. I was overwhelmed by the possible need to use DbUtility and didn't fully understand the bug is with ES admin console.
So in order to use admin console from 5.3.3 we must upgrade server also to 5.3.3 correct?

[tcarr]

Jason is the one who fixed that bug. My understanding was that it required both ES Admin and ES5 core server changes.

If you stop your server (for whatever reason) and then simply run DbUtility from the command line, then email me the XML that DbUtility generates, I'd be able to create a restore file for you to make the changes you need. Then you just put the restore.xml file in the same server/db/backups directory, and run DbUtility another time before restarting ES5. Simple. If you already did that, odds are you aren't seeing the right values in ES Admin because of the bug - that screen somehow just never got wired up and we hadn't noticed it.