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

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

[Mark Wedel]

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

I imagined using absolute time, say in ms (fits in a short), but it
really doesn't matter. The tick length could be part of the connect
packet. If responding with ticks make the server simpler/faster, go
for ticks.

BTW, I think the "busy" packet should include both how long the
current action will take in total, and how much more time it will
take.

 Player presses Shift-h.
 Client sends shoot left.
 Player keeps pressing Shift-h.
 Client sends shoot left.
 Server replies "busy for another 150 ms, current action takes 200ms".
 Client waits for 350 ms, then sends another shoot left.
 Client waits for 200 ms, then sends another shoot left.
 Random event: Server slows down a little due to loading a map, so
 Server replies "busy for another 50 ms, current action takes 200ms".
 Client waits for 250 ms, then sends another shoot left.
 Client waits for 200 ms, then sends another shoot left.
 etc.

The nice thing here is that when the player releases Shift-h, he will
stop firing immediately, without undue expense in the server or
client. (Just a little more state in the player struct.)

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

Perhaps it is worthwhile to time stamp every packet from the server?
Establish a zero point during connection to keep the data size down,
and handle wrap around properly.

Then the client can try to be intelligent when lag happens since it
can measure it all the time -- I don't think this should be a
priority, though.

[Scott Wedel]

|   A fundamental problem with sending KEY UP and KEY DOWN events over
|   distance is that the server can easily see a much different
|   keypress duration than what happened at the client. A quick key
|   press could easily turn into a short run and so on.

That's a very good point.

|   Seems to me that the best solution is to make the client smarter
|   and not send up commands faster than the player's movement. Which
|   means remove the whole concept of repeat between client and
|   server, but instead repeat is a client issue of when to send up
|   the next command. If server updated client with character's speed
|   then client could pace the sending of commands so that server
|   never has more than a couple commands buffered for the player.

Not all actions should take the same time, i.e. dealing a blow with
your sword and casting a spell. I think it should be up to the server
administrator to adjust these times, and it would be bad to have to
keep the client and server in sync. (Of course, the server could send
a reply stating how long that command will take, but the time is
always dependent on many variables so it makes little sense to do
caching.)


Kjetil T.
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: