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

CF: newcs buffering


 There was actually a mini discussion on this a couple months back, but 
'armed' with new information, it is worthy to be brought up again.

 Basic problem is this:  If using the new client and you hold down
a key, it sends a bunch of the appropriate commands to the server - more
than you want.  A simple example might be holding the the 's' key to search -
even after you release the key, you will continue to search for a little while
as the client has sent a bunch of search commands to the server.

 What I have learned since that discussion is that the client (or any X11
program) does not see a held down key as just one keypress, but rather the
auto repeat stuff kicks and, and a bunch of key press and key release
events are generated.  This make things more difficult to determine if the
player is holding down a key, or is pressing a key numerous times.

 A few of the more popular/reasonable options were:
1) Some option in which the client can tell the server to disregard all
previously sent commands.
Pro: easy to implement on the client
Cons: Not clear if this is a user interaction or automatic (if the
former, less useful, if the later, harder to determine when to send it.)
All commands on the server will also be discarded, which may not be desirable.
Also, this makes the server more complicated, as a look ahead buffering
method needs to be added.

2) Add a repeat command to the protocol, and server keeps doing that until
it gets a repeat stop or just another command.
Pro: Fairly easy to do on the server, in theory works well (maximizes
player time, minimum amount of lag when user stops)
Con: Hard to implement on the client, as it is hard for it to determine
if the key is being held down continously, or is being pressed reasonably
quickly to do some action a specific amount of time.  Client detection of
when to stop sending not particularly easy.
This was actually my preferred method, until I found out that pressed down
keys just generate numerous events - if we just got one key press and
one key released for held down keys, it would be pretty easy.

3) Server sends how much time the current command will take, and the client
throttles back as necessary.  Example, player is doing a repeat search,
server sends that the command will take 200 ms.  Client makes sure it doesn't
send too many to server.
Pro: Client determines buffer characteristic, so player can customize it.
Minimal amount of lag between when player stops the action and the server
stops doing it
Con: Determining time on server is inexact (players time can change, thus
the amount of time it will take changes).  Also, some base commands (ie
apply) might take different amounts of time depending on what is being
done (putting on plate mail should take longer than equipping a dagger.)
Also, not quite the simplest to do on the client side, but not too hard.

Note: Having the client aware of the players time has pretty much the
same con as above.

4) Put some windowing method on the commands.  For each command the
client sends to the server, it precedes it with a number that it increments
by one each time it sends the command.  When the server processes a command,
it sends back the command number &completion to the client - command
number is that provided by the client.
Pros: Buffering handle by client.  Modification to server is trivial.
Client modifications not too great either (it basically does a compare
between its last received completion method and what it is about to send,
and determines what to do)
Con: Each command number is effectively a tick.  So a window of 4 commands
is still half a second with a player of speed one, and could be several
seconds before server stops those commands.

5) Partial combination between 3 & 4.  Still include command numbers
in C->S commands.  On the S->C return, include last executed command and
how often (in ms) the player currently moves.  Client can then potentially
adjust the number of outstanding commands based on players speed.
Pro: Server changes still pretty easy (going by player time instead of
command time is much easier).  Buffering still handled on client side
(can ignore command completions if it wants)
Con: Still some lag when command stops, although it should be less than
just #4 above.  Client implemenation a little more complicated than
either 4 & 5 to implement on the client.

 Any other thoughts/ideas?




-- 

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