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

[Kjetil Torgrim Homme <kjetilho>]

Next time, Carl, please READ my posts before replying.

First - BITMAPS won't be rotated for the player, so the roof of the
shop would appear beneath the door.

+---
| But even a client which keeps old mapping information is allowed to
| throw it away if there is a real memory crunch.

The point was that the client could tell the server that it wouldn't
do that in order to save bandwidth.

+---
| Here I disagree.  What you are proposing is just a variation of the  
| client-side LOS scheme with all (or at least most) the attendant  
| problems.

WHAT? My scheme is a superset of yours. Only objects in the viewpoint
are updated, and only if they have changed since they last were in the
clients viewport.

This can be done very efficiently in the server. No need to add flags
dynamically to objects, just reserve a long word as a bitmask (max. 32
clients). Object size is currently ~250 bytes, so this doesn't make
much of a difference RAM-wise or CPU-wise, but it has a tremendous
effect bandwidth-wise.

+---
| No side _ever_ sends binary data without the other side requesting it  
| first.  And the REQUEST command contains a TYPE field which allows the  
| client to specify what kind of data it wants.

That was exactly my point. When the client requests an image, the
server can respond with an image type unknown to the client, and the
client can do _nothing_ about it.

+---
| However the client can REQUEST not just PIX and SND types, but can
| request the types BW1, BW2, BW3, ..  BW8 to receive black and white
| XPMs of one to eight bit planes and CO1 to CO8 to receive color XPMs
| of one to eight bit planes per color.

Why restrict yourself to 8 bit planes? The full set of XPM's in
Crossfire could use 16,777,216 colours. An individual bitmap can only
use 256 of them, though. More seriously - this isn't something we need
to decide now, if you just allow some sort of negotiation.

And Carl, have a look at the crossfire.pix file to see that XPM is a
different beast altogether from just an 8 bit colour image. (search
for booze, for example)

One more thing I forgot last post: You misread the meaning of my MAP
extension - it should list multiple pixmaps on that coordinate!

I must say I agree with Tero, though - we really don't want to go back
to .om.  I revise my standpoint, and suggest

MAP <x> <y> <lightness>

currently, <lightness> will only have two meanings, 0 (corresponds to
UNMAP) and 9. When we get light sources later, we can send other
numbers. Many clients could map all values > 0 to 9, ie. no shading.

Okay, with all that said, perhaps a little on where I agree with you?
:) ITEM commands are a nice, general approach to it, especially after
you said that animation sequences is just another sort of image.

BTW, I think there should be a protocol response for damage. 
DAM <object damaged> <object doing damage> <number>

That way a client can present it graphically, not just spew out a
stream of text. Since the client knows the names, it can make up the
text itself if it wishes to.


Kjetil T.