Re: Client/server part x

[Mark Wedel <>]

<This is a long response to Tero's message>

Global coordinate system:  YEah - I suppose that is a problem in changing
maps - all previous coordinates would be wasted.  Using relative coordinates
might be a good idea then, just a little harder to debug.


MAP & ITEM:  MAP is just a fast way to send data.  In theory, everything
could be sent as ITEM commands - the client will work the same, server
probably won't care.  IT just takes up some more bandwidth.  Secret
doors would not become visible - these are no different than a wall, except
that people can walk through them.

There should be same basis of what is used in a MAP command versus
item.  My basis would be a MAP is used for something that meets the
following criteria:  The object has not speed, no cycling animations (meaning,
it cycles through images when nothing is happening, versus gates which
only change animations when activated.)

This should probably be expanded.  But the above two checks are
quite easy to make.  And note things like secret doors and weak walls
would fall into that category.  Fireball walls would not, but they are
pretty obvious from the start.

Since the MAP command uses image names, as long as the weak wall or
earthwall uses the same image name (when at full strength), the client
knows nothing.  Note that some weak walls (Even at full strength) do
have different images.  This should either be changed, or recognize the
fact that people will come up with clients that have images for these weak
walls that are greatly different.  No change in the protocol will solve
the problem of weak walls with different starting images.

Floors could use the MAP command.  On the client, do you care that
this is a woodfloor versus a cobblestone?  There are some cases where
the floor name is different than standard.  Perhaps in that case you
do use the item command (check ob->name != ob->arch->clone->name or whatever
is also pretty easy to do.)

Using numeric image ID's instead of actual names:  Can be done, but I see
no reason to do so, at least in the first version.  Makes debugging harder
(it sent a MAP 45 126 247 14 12  So now what are those actual images?)

 Optimizing the MAP command so it just streams the image names with
no coordinates does improve network efficiency.  But as you said, this is
only of relevance when you change maps, which doesn't happen all that often
(and in many cases, the full 11x11 map may not be in view.  Maybe only
half or less.).  If we use relative coordinates, at worst, that is 9
bytes per space.  Most image names are about that same length.  So if we
have less than half a map, your method really doesn't gain anything - 
especially if some of the map is the same.

ITEM command:  Yes - face is missing, but if you read the protocol, face
can be sent instead of arch name.  If an object is using a replacement
face, it can not be animated.

Optionally, expanding the ITEM command to also allow the face could be done,
but I don't see much point.

However, I strongly disagree that a local archetype file is not needed.
Having this gives the local client a lot more power.  A player could
tailor this archetype file, even altering things like the type of an
item, so that better sorting happens locally.  Or alter the local value,
or other changes, so that client can use this information to perform
certain actions on certain items.

While objects are used in maps, they are very infrequently changed, and
even those changes are such that the player would not know about them.
So figuring out the archetype from the objects loaded in a map are
quite easy to do.

ITEM command should be used for all interesting items on the map.  In
this way, a smart client can be used to go and do stuff with those items.
Maybe someone writes a client with a smart pickup mode.  This then goes
through the map (when activated), and picks up the interesting items.
IF the only thing that is known about object non on the square but its
image, this is more difficult.  And if you go to numeric image ids,
this becomes impossible.

nrof could be added.  Simpler would be to always use numeric number
ids in the item (so instead of fifteen arrows +1, it is 15 arrows +1).
This make parsing easier on the client side, and wants to keep track
of the number, it can.  In any case, this is only a minor convenience.
If the client says to the server to drop 15 arrows, the server still checks
to make sure the client has 15 arrows to drop.  The only thing the client
can do is check the validity of the number specified, and this is going
to be a small gain in any case.

 I would keep ITEM as I specified it:
ITEM <length_flags> <tag> <locx> <locy> <arch_name> <flags> <weight>
        <name>

 The main gain from the length is that in many cases you may want to omit
the name & weight (by and far, that will probably equal the same number of
bytes as all the other values.)  If an item is across the room, you don't
need weight and name - at least not right now.   What should probably
be added is something like:

C->S: REQUEST_ITEM_INFO <tag> <flags>

This requests additional information.  So when the player moves onto
an item that it doesn't have the weight and name for, the client requests
this information.

MOVE: I agree that a nrof is needed in that command.

A GO <obj> <dir> command is probably a good idea.  I see no need for
a run command.  IF you just want to move 1 space, send a MOVE command
instead.  GO would represent that you want to keep moving that direction
indefinately.

FIRE: The advantage of using a range identifier on the client is that
you don't have disagreements.  Change FIRE to FIRE <flags> <tag>
Where flags in direction and perhaps other specifiers, and tag is the
item tag, works just fine.  You just might then get cases where
tag isn't something that can be fired.  But actually, I like this
idea - if throw is ever added, then <tag> could be anything, and
it would then be thrown.  <tag> should perhaps be a string or
negative number to represent a spell being cast.

 The basic problem with your simplified client/server (cache only image
names) is that for one, you are assuming you are only have 1 relevant
image/square.  With XPM, this is hardly true.  Right now, the present
system has up to 3 displayable object per square.  If you have a fast
connection & fast server, you may want to do 10 per square.  Your 
message really doesn't address that area. (and note, that for many 
areas, you do have 2 objects in 1 space that should be sent with a
MAP command (wall on top of floor.)

The way I envision the code is this:

In each player structure (on server), you keep an 11x11 array that
has linked objects on it.  Then, you check to see what has changed,
and send various commands to the client to that.  To keep things
more efficient, you store a value that represents the center of the
array - 5,5 is not where the player will always be.  He may start
at 5,5, but when he moves north, now 5,4 (in that array) is now where
the player is.  In this way, not much info needs to be copied.

As for ITEMS:  My idea is to send only basic information at first,
and let the client request more as needed.  This keeps bandwidth low,
and means that the server doesn't have to remember what was sent.

 --Mark