Werewolf Development

Well, I haven't posted here for awhile so I thought I'd get some info out there. I worked with the NeL community to recently get NeL 0.7.0 released and we should hopefully be seeing this in Debian and Ubuntu real soon now. It sounds like they've also packaged Snowballs and the NeLNS Qt Launcher so I had better get cracking on getting that demo shard running soon! Which leads me to the other thing: we were forced to move servers due to stability issues and general old-age of our former Debian VM. We're now running upgraded JIRA, Confluece and FishEye on a new Karmic VM at the same host. So far this seems to be faster and definitely more stable.

As for Werewolf I've only had meager moments of time to work on it. I've worked on the CEGUI/AngelScript module as well as beginning to bind NeL and Werewolf code in our WWSCRIPT module. There are two script demos in the source code repository: one demos the script engine's various features such as auto-binding using property maps and recompiling individual scripts from disk-source, the second is more of a play-ground to develop and demonstrate the AngelScriptModule I'm building for Werewolf's GUI. The ultimate goal here to to be able to siginificantly limit the scenarios where we need to recompile the source code to alter or add GUI elements.

In other news I moved on to renovating the chat system. This was unfortunately a heck of a lot more work than I had expected. One of the first problems I ran into was the inconsistency of players to users - every connection generated a user but not necessarily a user. That lead to a disconnect in users which are often the key for looking up characters and (in this case) the EMD or EMT used. Ultimately I eliminated all of the CPlayer usage in the frontend service (although I'm afraid there is still some vestigial code in there that we will need to clean up.) This forced me to expand the users table (not to be confused with the LS's user table) and the CUser object. I also added a ton of database persistence and "caching" logic to CUserManager.

After getting to a point where users are consistent with the user information being forwarded to the frontend server I needed to make sure that the client-server world was clean. This, unfortunately, is still a work in progress and I'm afraid may require me to do some large changes to ISimulationObj. I have some planning to do here. What I have done is updated the GUI to have a "Create Character" screen which is extremely rudimentary (it gives you a free text box and a drop down with available EMDs) which will transmit a CH_CR message (CHaracter_CReate) to the server to allow players to create characters. This required some updates to both the callbacks as well as to the CCharacterManager class. Related to the necessary changes to CUser and CUserManager the CCharacterManager needed to be able to pull up a CUser object to determine what the maximum number of characters a player could create was. When the FS receives the CH_CR it asks the character manager to create the character and then sends back a CH_CR_ACK (CHaracter_CReate_ACKnowledgement) message. If there was a problem with creating the character the first element of this message is a "reason" string. If it is not empty the client did not succeed in creating the character and is left at the character creation screen. We still have to create a dialog box to handle those non-empty reason scenarios which really just means I need to implement a framework to do modals in CEGUI.

Now we (theoretically) have the ability to log in, create characters, connect as a character and walk around. The next bit was to implement the simulation event chat system. As it stood before I embarked on this effort the chat system was basically this: the client grabbed a chat line from a dialog box, created a CHAT message containing nothing but the chat string. The FS then received that and forwarded it out to all clients. It was pretty crude, didn't take any proximity information into account, wasn't exactly something that could be scripted (e.g. AI listening) and contained no player/object information.

What I ended up doing was ditching the CHAT message entirely. I had to do some work on the GUI since a lot of the layouts are distorted still but the chat box now appears cleaned up. Next I created two sets of events: CGameChatEvent and CSobChatEvent. This can easily be looked at as a request/result pattern with the request (CGameChatEvent) being a player sending the chat and the result (CSobChatEvent) being the activity actually occurring. There was a necessity to process these on both sides.

First I needed to create ways to process the request on the FS. When the FS receives the CGameChatEvent object the CGameEventManager receives and processes it using its chat method which simply does some error checking (make sure I don't attempt to send a chat as someone else's character, for example) and then translated the CGameChatEvent into a CSobChatEvent and posts it on the server's event queue. Next I made two modifications to the server object view (SOV.) First I needed to make sure that it started listening to events targeted at Sob ID 0 (global, root sob.) The other modification was to ensure that I filter out any CGameChatEvents. Since the default behavior on events in the client is to attempt to repost them using an EVT to the FS I wanted to make double sure that the client didn't receive its own chat request and cascade chat events to the FS. The SOV now takes care of forwarding CSobChatEvent objects targeted at it's owner-performer and at the root sob to the client.

Next we needed to receive this event at the server. Initially this isn't a problem. The client infrastructure automatically posts new server-sent events to the event queue. I just needed a way to process and display this event. To accomplish this I created a new view called CPerformerChatView and made it a listener. I know this slightly "breaks" the policy of views being driven strictly by Sob data but I had one problem - I needed to know about chat events I originated as well as those targeted at me and a Handler will only receive those targeted to me. This view is pretty simple right now, it just takes the chat message and posts it to the GUI.

What is next on the agenda is to start to define our simulation object property dictionary. This is important because it is becoming increasingly difficult to find where data is hidden in the Sob hierarchy which includes character information. If I can simplify Sob properties to something similar to a dictionary it will also make scripting handlers easier (like owner->getProperty("name") for example) and just generally makes the code less complicated.