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

["Carl Edman" <>]

From: Kjetil Torgrim Homme <>:
> >--- [ about the direction of the axes ]
> > In any case a client which got this convention wrong might appear
> > slightly confusing to the player who is used to see the map the
> > other way around but would be perfectly functional.
> 

> Nope. Imagine the big buildings and monsters.

I think I can, but I don't see how this changes anything.  A player  
with the coordinate system the other way around would see a mirror  
image of the world but everything would work just for him as well  
(until, that is he works with other players and they all agree to walk  
north now :-) ).

> > The way I see it every location has just one map type which
> > describes what kind of 'terrain' it is in.  _Everything_ else is
> > items.  How the client choses to represent items (only display the
> > top one, overlay them, whatever) is purely up to it and the server
> > doesn't care.
> 

> Fine, but this changes my view on your protocol entirely. It could
> (with minor modification) easily be supported by a stateless client,
> but still have reasonable performance on a clever client. Now you say
> that the client needs to remember where _every_ object in the map is.

No, only those objects which the user can see at the time.  


> Well, then it makes little sense to lump together the update commands
> for position, outlook and name. What's worse, if you have a stack
> with animated objects in it, they will send commands like
> 

> ITEM 323 2 2 diamond.111 nineteen diamonds ITEM 324 2 2 pearls.111
> five pearls ITEM 325 2 2 finesword.112 an Elven sword ITEM 323 2 2
> diamond.112 nineteen diamonds ITEM 324 2 2 pearls.112 five pearls
> ITEM 325 2 2 finesword.113 an Elven sword
> 

> etc. even if they are not strictly in view!

No, it won't.  You still think of the protocol as a series of commands  
to the client to draw this then and there.  It is not.  The protocol is  
a means by which the server describes the actual world to the client.   
The client adds that information to its own internal database of the  
world and then uses that entire database to draw the world -- or not.  


A perfectly fine client may not do any graphics at all.  One could  
easily conceive of a robot client which just reads and writes the  
protocol, running around picking up valueables and following the player  
around without ever creating a graphical representation.  Another  
client may be curses based and never use the pixmaps but instead a  
custom set (of its own chosing) of ASCII characters.  All of that is  
purely up to the client.  The server does not care.

To answer your specific question, animation information is part of the  
image information and is handled 100% on the client side.  The server  
nevers sends a command to animate something.  The ITEM information is  
about items, not pixmaps.  ITEM commands are only send when something  
actually physically happens in the world, such as when an item (not  
pixmap) is created, destroyed or moved from one location to another.   
(Only if it moves by itself -- items inside other items are moved along  
automatically without any further commands sent).

> Also, the client has no ordering information. The server should have
> some way of hinting to the client which objects are more prominent.
> 1. ITEM should be split into three commands. 2. The client should
> have a way of _hinting_ the server how many items it considers for
> each square.

It doesn't need to.  Every client needs to know all items in a square,  
if not for graphical display, then for the case when the user clicks on  
the square (in current crossfire terms).

> > Besides I think that image format is something which really should
> > be up to the client.  Or are you going to add more conversion code
> > to the server every single time a new client is created ?
> 

> No, don't be cheap.  I want it mainly for expansion, but it is needed
> to negotiate colours.

I don't think we should negotiate colors.  Colors are up to the client  
side.  Please try not to think purely in terms of current X hardware --  
there are machines with one million and one different kinds of color  
hardware.  And in every case the client knows far better how to make  
use of it than the server will.  The server gives the client full  
information and the client makes use of it as best it can without any  
server interference.

> > Probably the server should send the item command first and the view
> > command only after that.
> 

> VIEW with an unknown object as argument should present the player
> with a black screen (good for rolling characters).

That is probably a good idea.

> > Examining items or locations is something which is done 100% client
> > side without any server calls.  That is what all those ITEM calls
> > were good for.
> 

> Uhm, Carl, when did you last examine an object in Crossfire? Must be
> some time ago...

Well, there are different levels of information.  Everything that you  
would see e.g. in an inventory or when you click on a monster or a spot  
on the map is in the 'name' part of the ITEM command.  Admittedly for  
longer texts (like descriptions of weight, value, or special magical  
properties like e.g. the rings of Storm/Life/whatever) you probably  
need an 'EXAMINE <item tag>' command.  But the reponse to that is just  
a couple of TEXT descriptions.  There is no need for special client  
smarts here.

> Also remember that you can currently click at an
> arbitrary spot in the map view, and that 


Sure.  And if the client knows of some item there (i.e. when it has  
ever seen anything there), it will give a full list just like it does  
in crossfire today.  If it hasn't it wont.  Some client may even pop up  
a window when you click on a square or a character and allow you to  
move items around just dragging them from one window to another.  All  
that is up to the client.  All the server does is send ITEM commands  
when the items become visible and receive MOVE commands when the user  
wants to move one item somewhere else.  Everything in between is a user  
interface matter exclusively of concern to the client.

> I thought a (possibly) stateless connection was a goal.

No, that would be using the client just as a dumb terminal which would  
be a waste.  If you are going to write a custom client, make it a smart  
one.

> The EXAMINE command could also be used by the client to get updated
> information about a square if it for some reason had thrown that
> information had been thrown away. (Also nice for debugging, I
> imagine.)

The client is only _required_ to keep the information on the couple  
dozen squares which are in current view (though good clients will want  
to keep more around as a form of automatic map drawing).

> > As a matter of fact a 'magic mapping' spell would be implemented by
> > sending the client map commands for all squares in the map and then
> > unmaps at end of the spell.  

> 

> Cute, but how would the client know that it should zoom out or
> whatever?

That's a good question.  I was thinking of clients which don't zoom out  
at all, but instead keep the entire known map in some sort of scrolling  
view.  If players want to look elsewhere they just shift the scrollers  
around.  But that is just an idea for the particular client I intend to  
write, not a general requirement.  Other clients may want to use  
heuristics.  If that doesn't work we may have to add a bit of  
complication to the protocol and give the client a hint that we are  
seeing the entire world.

> (currently, "magic mapping" reports monsters as well as
> floors, btw).

No, not on my old B&W system it doesn't ! :-)  Seriously, that only  
means that magic mapping not only has to send MAP commands for the  
entire map, but also ITEM commands for all items.

> > BTW, i think pickup can be implemented purely on the client side.
> 

> Not with the new functionality Peter Mardahl (I think!) added - it
> considers value towards weight.

That is what I thought about which is why I said "I think". :-)   
Personally, I'd love to see as much as humanly feasible of these  
interface decisions to go into the client.  For example, a client may  
have several 'pickup' lists (some hardcoded, others added by the user)  
which cause it to e.g. automatically pick up (i.e. send MOVE commands  
for) anything called 'diamonds', 'rubies', 'pearls' and 'platinum  
coins'.  Whether that is an acceptable solution is debatable.

> However, the "search" function would be very appropriate to put into
> the client (good thing - "search" used to consume a fair bit of CPU
> in the server :-)

Absolutely.

	Carl Edman