Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol

[Tero Haatanen <>]

From: Kjetil Torgrim Homme <>

> Phew, this will probably be long.

If my previous mail wouldn't be delayed because of local network
problems, we probably haven't repeat the same things :). I must
say that I agree with most things. The major thing I disagree is that
client should get only images, not object data. (exclude object names 
below player). How random objects are implemented (rune is invisible
half of time). And most this information is mostly useless, names of
all no_pick items including monsters, walls and so on. And examining
squares not below player is not very frequently used action. And 
making diffence between background and objects creates and old problem
that eartwall is object but wall isn't. Back to .oo and .om files :(
Objects data of items in players inventory is totally different
story, this client of course knows.

The protocol main purpose is to get servers world to players, not making 
it easy to build robots. I don't want to start discussion if admins should 
allow robots or not (go rec.games.mud.admin if you want opinions on that ;)

> [Animation synchronization]

Let client do dump animation and leave smart ones to server and
send only images [see my last mail].
 
> All in all, I think a client can keep all its state for a map in 
> under a megabyte.

Hmm, DOS programmers loves allocating big memory arrays :)

> Let's say the client keeps all map info,

For one map or ALL maps? Players change maps quite active, keep that
in mind.

> The server
> keeps a bit in every object for each client saying whether it's
> up-to-date. If the object moves or its name changes, the flag word(s)
> are set to 0. When the object comes into view for a client, the flag
> is consulted, and if it not set, an ITEM message is sent.

This is the first solution what I see this problem, but it really consumes
servers memory and CPU time. The each object has to be flag for each
player and these must be dynamically allocated and updated everytime 
that someone moves. Probably this overhead is not a problem.

How about if client remembers it's current view and server remembers
last view it send to server. It would make much easier to implement
server side (save CPU time) and wouldn't require client to keep
big arrays. After view changes server check how many squares are
changed (after LOS calculation). If there is no changes even player
moves (walks in jungle and see only 9 jungle square and everything
else in black) nothing is send. Also walking in the long corridor 
wouldn't need any updates. This adds little more traffic if player
moves in same map, but saves traffic in battles (much updates in
objects).

> Like Carl said, a larger viewport is possible, but only the closest
> 11x11 (or whatever the default viewport size is - I vote we go for
> 13x13) will get updated.

Agreed here, but maybe client could select one of 11x11, 13x13 or 15x15?
15x15 could be nice if server implements moving light sources. And this
is one point more point to do LOS calculation in server side (some servers
might use it while others not). Fixed size might still better when thinking
xrays and other map features.

 -Tero