No Subject

>     The client/server protocol does not have "rounds".
> 

> Yes it does. See below

Forgive, me but I wrote this protocol.  If you want to argue that it  
has to have, do so.  But please don't tell me what I meant to say.

>     Yes, the server has   to keep LOS maps, both for computational
>     efficiency and for the sake of   the protocol.  Whenever an item
>     moves or changes, the server goes   through the list of the LOS
>     maps for all players and immediately sends   ITEM commands to all
>     the players for whom the item is in the LOS.
> 

> Absolutely positively not.

Absolutely positively yes. 


> The protocol itself does not have an explicit notion of rounds, but
> that's because it's underlying purpose is to best handle rounds. The
> whole model for crossfire REQUIRES syncroynous rounds, across
> player/monster movement.

Synchronicity is a pain not a boon.  It is much easier to construct a  
logically consistent and CPU efficient simulation in which all events  
are serialized.

> At each round, the server goes through each player's 11x11 map, and
> sends everything relevant. A player move takes (usually) one or more
> number of rounds. But so does standing still for some amount of time.

So the you require the server to go through the entire map for every  
client many times while nothing at all is happening.  Personally, I do  
not consider thumb twiddling and wheel churning to be high virtues.

> The only reason the protocol has support for partial uploading of a
> 11x11 map to a client, is simply because it's more efficient that
> way, not because we want asynchronous updates.

Why don't we want asynchroneous updates ?  Because we like wasting  
processor cycles and network bandwidth ?  Or because we can't admit  
that we could possibly be mistaken about something ?

	Carl Edman