Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: New client/server & command buffering.
I vote for key-down and key-up events sent to the server. This
seems to preserve the best information.
-Kris
On Mon, 2 Feb 1998, Mark Wedel wrote:
>
> 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]
>
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups:
References: