Re: Crossfire client (and Re: Patches, ftp, new releases. )

[Mark Wedel <master@rahul.net>]

 IT seems to me that there are really two types of animations that grouped
into one cluster.

 One type of animation is repetive (grass blowing in wind, waves going
up and down, and similar ones where the object just cycles through
a series of pixmaps, and provided the object does nto change, this cycle
always remains the same.)

 The other type is things like gates going up ball, fireballs expanding,
with the flame burning down, etc.  These are ones were they occur for
a short amount of time, and then become static (or disappear).

 The first can easily be handled in the client (easily and safely.)

 The second are a little more difficult, because you need to make sure
that the server and client are synchronized in what they think should
be displayed.  If the client is a few ticks ahead of what the server
think is displayed, or a few ticks behind, this could cause trouble for
players (and example might be a player sittign at the edge of a fire ball
and moving in as it burns down, so that he is always at the edge.  IF the
client is ahead in the animations, the server will think this character
is actually in the fireball.)

 I think the ideal client would handle as much of the routine stuff
as possible, without letting the client gain super powers (if someone
wants to right a robot to play for them, I think this is acceptable.)

 A big client may mean that a lot of common stuff is stored on both the
server and client (an example may be inventory.  The client could then
send messages to the server of the type 'drop shortsword (id#)', or
'use wand of small fireballs (dir E)'.

 If the server can not find such an item on the player, it sends some
sort of error code.

   Mark Wedel
master@rahul.net