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

Re: CF: New client/server & command buffering.



On Feb 3,  4:49pm, Kjetil Torgrim Homme wrote:
> Subject: Re: CF: New client/server & command buffering.
> A different idea: If the client sends the server a message, and the
> player is out of time, tell the client how long it will take before
> the _next_ command will be processed. Note, _not_ how long it will
> take before _that_ message will be processed, since that requires
> quite a bit of processing on the server.

 The problem is that the definition of 'time' is pretty inexact.

 If someone is running a server with MAX_TIME (ie ticks) of 200 ms, and another
at 100 ms, and both say it will be 5 ticks, the client then needs to have some
idea of how long a tick is on the server.

 Although I suppose the server could tell the client is absolute terms (ie,
1000 ms).  Might be a little inexact do to lag (if a 100 ms connection lag.)

 But actually, that might not be a bad method - keeps the client pretty easy,
and keeps the server pretty easy.  However, not sure what happens in cases
where the player is paralyzed or something.

On Feb 3,  1:25pm, Kristofer Bosland wrote:
> Subject: 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
>

 We don't send keypress events to the server - that would be pretty pointless.
 Instead, we only send command directives, so to rephrase what you say,
everything we be 'start command' and 'stop command' type of things.

 Note by not sending keypresses, it means the client does local key binding,
which makes a lot of sense (and also allows keybindings to be used acrossed
save characters.)


On Feb 3,  3:13pm, Kristofer Bosland wrote:
> Subject: Re: CF: New client/server & command buffering.
>
> 	How does this degrade performance?  If you are talking about
> key-repeat, it seems like it could be configurable.  If your link is so
> slow, how do you react at all in the game?

 It creates more problems in that for any command (key), at mininum 2 commands
must be sent to the server (command start, command end).

 I am not sure how it necessarily decreases performance more - the
client->server link is generally not used used.  However, as said, we certainly
won't send the keypresses, but the actual commands that the client determines
the key is determined from.



-- 

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


Follow-Ups: References: