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

[Kjetil Torgrim Homme <kjetilho>]

++--- Kjetil T. Homme:
|| Good! I'd like to add something like "whitespace is not ignored and
|| not allowed in arguments except where indicated.
+--- Carl Edman:
| Well, one could add that but it wouldn't gain much. [...]

I wasn't thinking of CPU.  I was thinking about flexibility in the
grammar, don't allow people to be too smart for the server's good and
so on.  Besides, it was needed for my extensions to MAP and QUERY :-)

++---
|| Control characters (0-31, 128-159) are only allowed in binary data."
+---
| Let's make it client dependent with clients encouraged to interpret
| characters with the high bit set as ISO Latin characters where that
| is easily done.

That's what I implied, really. The range mentioned is control codes in
all ISO character sets, the rest of it is OK to use.

+--- [ 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.

+---
| 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. 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! 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.

+---
| I'm prejudiced against SET commands in all kinds of protocols and
| languages.  In general they just add four characters which need to
| be sent with little gain.  If you really want an IMAGEFORMAT
| command, why not just call it IMAGEFORMAT ?  

Because unknown commands should be errors in general. Also, I said I
wanted two commands for each keyword, SET and SETF. (SETF may not be
the best way of doing it.)

+---
| 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.

+---
| 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).

+---
| 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... Also remember that you can currently click at an
arbitrary spot in the map view, and that I thought a (possibly)
stateless connection was a goal.

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.)

+---
| 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?  (currently, "magic mapping" reports monsters as well as
floors, btw).

+---
| 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. 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 :-)


Kjetil T.