Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CF: New client/server & command buffering.


 I've done quite a bit of work on the server and the C client from the
last release (I will even go so far as to say it is pretty much complete).
However, there is one problem which I don't have an ideal answer for.

 As background:  Under the current X11 client, the server will execute
a command when only when the character has time.  If a player is holding
down a key, the server only checks and applies that action if the player
has time.

 In the new client/server method (hereafter referred to as newcs), the
client has no method of determining if the character has time to execute
a command.  If you press 's' 10 times, it will search 10 times as expected.
However, if you hold the 's' key down, the client sends a bunch of
search commands to the server, based on how fast the client is running.
This tends to result in many more commands of some type than the player
wants to execute (in some cases, the player might get bogged down searching,
or move too many spaces.)

 There are at least a few solutions to this problem, each with its
pros and cons:

1) have a server send a message to the client when the player has
free time.  Client then only sends a repeat command when it gets such
a message.  Main disadvantage is the lag involved.  Crossfire operates
on 120 ms ticks.  If the lag is also 120 ms, it takes 1 tick for the
message to reach the client, and another tick for the command from
the client to reach the server.  This is effectively a lag of 2 or 3 ticks,
which could drastically reduce the occurence of some commands (supposing
a speed of 1, it means that you are now only searching 1/2 or 1/3'rd of
the time you should be)

2) Implement a look ahead on the server, and discard client commands if the
player is out of time.  Main disadvantage is this is a bit of work (need
to add buffer structures and so on), and some commands probably can not
be discarded (ie, too important.)  Also, this method probably won't work
if the player hits a key 10 times expect the command to happen 10 times -
server will probably execute 1 or 2, run out of time, and discard the
rest.

3) Add a 'repeat command' to the Protocol.  Server keeps doing that
action until it another command or a repeat stop command (the run
and fire commands more or less already do this.)  This is a little more
complicated on the client side (need to check all xevents (or at least
until the next key event)) to determine if the command should be sent
as a repeat or not.  Also, a lot of commands might get sent as repeats
just because the player doesn't release the key fast enough.


 Right now, I would probably lean towards #3 - keeps the server simpler,
and the cons probably have the least affect of playing than the other
methods.

 Any other thoughs/input?




-- 

-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: