Regarding dirtsand

[phoenix]

The driving reason behind the question is to understand the rubber banding and lag issue a bit better. If the positional tracking is in memory rather than on hardrive, it may solve the rubber banding and lag even more because of fast read/write speeds by using memory. Then the increments in the vector prediction algorythym might become a lot shorter giving a finer "grain" on the positional updates of the avatars and may result in much reduced or obliterated lag. (obliterated lag may be the ideal, and is a hefty set of goal posts for any mmorpg)

I gotto say that as a story teller, 'continuity' is really REALLY key to the illusion working (in an mmorpg age context). Imagine listening to a story teller who had a bad stutter... you would sit and bear it, but you would not enjoy it. Same goes for MOUL. We might yet get to the day when an age can support 100, 200 or 300 avatars at once without numerous instances of the age running concurrently.

How does MOUL/dirtsand track the positions of avatars considering that it is sending updated coords to each client, while the client is trying to predict where the next avatar position will be for those late positional packets coming from the server? And is the algorythm on the server harddrive centric or memory centric?

May the source be with you...

Phoenix

[diafero]

So Dirtsand writes the kickable SDL to the DB each time it changes? Or only on game server shutdown?

[phoenix]

From what I understand (corrections welcome) sdl states are persistent so get stored in the database, whether or not you shut down. Such as triggers, states, visibles, etc. But how the avatar positions are handled is another story altogether. If postgres does handle positioning, my argument would be why use such a slow access method for something so dynamic. Persistency is not an issue with avatar positioning, because if your computer crashed or you had a power out, you would not start from where you left off, your avatar would re-start from Relto.

The realtime positioning method relating to the avatars movements on the server is what I would like a bit of expounding on.

[Zrax]

If you noticed, I mentioned before that avatar position never gets saved to postgres... What I don't remember off the top of my head is whether those are stored in memory, or just broadcast to other players and then discarded... Either way, what I can tell you for certain is that the DirtSand code as it exists today was mostly written with the intention of "first get something that works and can be expanded upon fairly easily", meaning there's still a lot of room for features to be completed/added, bugs to be fixed, optimizations to be made, etc.

[phoenix]

I can understand your method, it makes sense to get a foothold before you can climb a mountain. It is a pity that Cyan did not choose to release the source for their server... but even as it is, what you guys have done is quite a feat.

In terms of methodology, I prefer both options you mentioned...

Zrax: whether those are stored in memory, or just broadcast to other players and then discarded

The reasoning is sound enough from an adminstrator point of view for a number of reasons;

* Using server-side memory for position tracking smooths out delays between reads and writes enormously compared to send/return requests between clients using server as the "via" point.
* Server would only have to store a minimalist number of variables to dictate the position and orientation of the avatar. (The client would interpret the position sent by server and the client would add the animations and fancy effects)
* The amount of memory on server would be really small compared to what the client would need, since server is only concerned with storing positions, directions (vectors), Ki handles, and a few other small variables.
* Also for the admin user running his or her own shard imagine a little grid map in plan view that the ubuntu admin user can launch to monitor what is happening in an age.

The entire aspect of server-side position tracking in memory has all sorts of untapped uses that can be added later, also will help admin deal with players issues with the level, track usage of certain areas of an age, highlight realtime problems in an age, etc.

Now I know the current version of CWE may not be ready for this now, but maybe some time in the future.

Take what you like and throw the rest away...

Enjoy

Phoenix

Here is an idea of how the gui might look one day.

[Lontahv]

I really like the idea of having a single regularly sent message from the server that contains avatar state info for all the avatars in the age (or at least avatar state updates). This would fix the problem of constantly and randomly getting gazillions of avatar messages that have been forwarded by the server from each avatar.

[phoenix]

You gotto be joking!

Lontahv: constantly and randomly getting gazillions of avatar messages that have been forwarded by the server from each avatar

If it is like this in the engine at the moment, I am very surprized at the methodology Cyan chose for this. For clients to randomly send avatar states whenever they wish is not really efficient in my mind, simply because the server/client architecture has to deal with a network pipe of differing capabilities on a global scale (as in planet earth!!), different client specifications, etc. The method you refer to makes for a coding nightmare similar to dynamic interrupt handling, which although needed in some cases is a complicated way to deal with requests. Now imagine duplicating the Admins Age Assister (at least in memory and without the gui) on every client. The "AAA" would only hold critical info for server/client data, and avoid handling anything that the client can interpret for itself. Now when server and client "talk" to each other about positions and such, they are talking directly from "memory to memory" (M2M). If M2M was also optimised to have a proper schedule of say 10 to 15 ticks a second (loose example), you wouldnt have read/write lags due to the client reading scene-data off harddisk trying to build the scene and trying to handle avatar positions, vectors and states.

The client would read position, vector and state info from the AAA in its memory which would be a clone of the server-side AAA. The only data sent from the client-side AAA to the server would be avatar position, vector and states, as a result the bandwidth would be extremely small, giving more room for KI, voice and other data.

[Lontahv]

Cyan uses the same setup for transmitting nearly all game states: unconditional client message forwarding. This is why any client is able to tell any other client exactly what to do. While this free-for-all setup (kind of) works for transmitting changing game states like levers and buttons, it is very bad at transmitting massive numbers of updates because the client has to open and process a message for every single update. This setup almost seems better suited for a peer-to-peer layout than one that runs data though a single server. Anyone feel like rewriting the network code?

[phoenix]

Wow! Thats a nightmare! I can understand the method in their madness if they had coded an engine for non time-critical algorythms like data downloading, email, etc, but real-time 3D, with realtime sound, and realtime chat...?

It makes sense that certain things do get sent to each client without the server getting too heavily involved, like chat for instance, because it is an on-demand service, but when you look at how Cyans current MOUL server runs, I dont get one (not one) smooth session even on uncapped ADSL. Music stutters, screen freezes, KI delays, heavy rubber banding, heavy lag, etc. (Sometimes even when my avatar is alone in an age...!!!)

Give credit where credit is due... Rands artistic vision was utterly impecable, but it seems that the methodology of the engine was not completely thought through by his Dev Team. I wonder if this was the reason Rand made it open source?

[Chacal]

In addition to making more sense, world updates pushed from the server make it easier to do sanity checking. This is why it is used in games like Battlefield 1942: to prevent some forms of cheating by players.
In Uru it could prevent the havoc caused by players using flymode on shards.