Re: CF: newcs buffering

[swedel@Tymnet.COM (Scott Wedel)]

I think #5 is the best choice.  Since number of outstanding commands
multiplied by player speed is how many ms player is ahead of response
then it allows client to have a "typeahead time_limit" parameter which
player can set to what works best for them.  Typeahead time_limit is
the problem that is being addressed (having commands being processed
long after player stopped typing).  This allows client enhancements
such as repeated keypress typeahead_limit (possibly a lower threshhold)
in addition to a general typeahead_limit.

Note that player speed need only be sent when it significantly changes
and only a byte is needed for window size (pretty unlikely a player
wants to be 256 moves ahead of server).

I don't think the Con of "Still some lag when command stops" is accurate.
If user holds down a key for a bit and then switches to another command
then I think it should without added a pause.  The client would quickly
reach typeahead limit and then ignore the repeated command.  When player
types new command then that should cause enough of a pause for the new
command to be recognized and so no pause.  Client can also take steps
to minimize likelihood of missing the command after a keypress repeat.
If client simply does a command read and tosses command if it cannot
immediately be forwarded then the new command can easily be tossed.
If client instead of simply tossing the command temporarily saved it
as "last command tossed" and then when receiving a response from server
then forwarded it (as window is now open) to server and cleared it (so
it only gets used once) then only if user also typed ahead on the new
command would the new command get lost.  But it should solve most cases
of moving and doing something without the first command after the repeated
keypress from being lost.

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

							sdw
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]

---

• Prev by Date: CF: This and that
• Next by Date: CF: newcs buffering
• Prev by thread: CF: newcs buffering
• Next by thread: CF: This and that
• Index(es):
  • Main
  • Thread