Notes on the work in progress

Today we will get into some more detail as to what the WIP list means and check what comes next:

Work in progress (WIP) of the To-Do List:

* Create an action plug in template [easy / pending]
Currently a user logs on and a socket + chat client process are created, what is needed now is another process that will sort out what to do with the messages, what this means is that the socket is the non-transient part of the user, if he disconnects this process gets killed immediately, but the CC client stays there for "x" time, so a user cannot just logout when in danger and no harm will happen to him, this CC socket guarantees, that he cannot cheat by quickly logging out. The plugin is required to process his requests and whatever comes to him, this includes for example:

>> Action dictionary: what actions the user may execute, like chatting, moving, joining other channels, changing clothes and other stuff, so with that you could simply delete chat from his action list and mute the user, remove his movement ability and have him stand still or disallow a certain spell for a while.

>> Swap the action plugin: under certain circumstances you may want to put the user under script control, like for cut scenes or "mind control" a user by another user, so being able to switch the action plugin is helpful.

>> Put in the ability to have several plugins, this way we could f.e. log all chat activity, maybe this is not required.

* Internal user registration (to avoid same user on several nodes) [easy / partially done]
This is done for the CC processes, but needs to be done as well for socket processes, this shouldn't be too hard.

* Cluster behavior [medium / pending]
Here we might predefine what server does what task and what to do when that server is unavailable. This way we don't have to configure our cluster each time we start it up.

* Zone Simulation Manager [medium / WIP]
This part will include a chat manager for a certain zone and to extract from the database all the objects that are contained within it, like fixed objects and moving objects.

* TPC/IP server with authentication [medium / WIP] + protocol converter [medium / WIP]
This is basically done, what's missing is the above mentioned database registration for logged on users. The server has already functionality in place to block certain IPs and to avoid flooding by disallowing the port for 100ms, hence only 10 actions per second are possible.

* TCP/IP test client [medium / WIP]
First client is done, which is a simple text client that displays all messages and crashes *sigh* after minutes or hours because it can't handle all the display stuff, next a graphical client is needed, this will be done in Apocalyx.

* Apocalyx integration [medium / pending]
The first client in Apocalyx is right ahead, this is the next step that we need to create, hopefully not too much of a mess to do.

* Master node [hard / WIP]
The ultimate goal of this is to run a process on the master node that "thinks" for the rest of the infrastructure, like how many processes are running on each node, how many SOX users, CC users, Sims and so on and rebalance the equation, this will require a lot of work and will be most likely the last thing to do.

* NPC scripts [hard / pending]
This will represent a mayor effort to finish, given that this will have to handle scripted quest givers, movement from one place to the other and simulate AI to give the NPCs a certain life and methods of learning, exciting but difficult, given the overall broad approach.

* Subscription Server [hard / partially done]
The first part is already implemented, each user has a validity period after which he cannot log on anymore, you can already, per shell, increase the period, but we cannot handle prolonged subscriptions as of yet nor do we have like a web-based secure server in place for this.

* Interrealm connector [hard / pending]
In a word: Think BIG !! Each realm might be a separate instance of the same Simulation/Game or it might be a completely different game, so user data needs to be copied over, and obviously a domain/realm browser needs to be created. Sounds like fun.

* Physique server implementation [medium / pending]
This can be done the easy or the very hard way by duplicating all the Apocalyx logic into Erlang (sounds like disgusting) or to use Apocalyx itself. If we use Apocalyx, then we have to have a client (probably for each zone) that runs it and every user will send their requests like this:

game client --> SOX --> CC --> action plugin (sorting out movements) --> physique server (sort out the ACTUAL possible moves) --> action plugin --> CC --> SOX --> game client.

In order to make this work, the Physique server needs to do a simple rendering, that does not use any textures or coplex figures, so we might represent of all items only the bounding boxes for collisions and represent users as boxes, this should make this process painless and fast and if a collision is detected then only the real movement gets reported back.


So the next steps are the SOX database registration to avoid double logins and to create a simple Apocalyx client. After that the zoning and char room part with authorizations is due.

Warm regads,

Sunweaver