On 10/23/13 06:53 PM, David Hurst wrote:
Hi Arvid,
I have discussed these issues in some detail in the IRC channel. I believe I can
answer your questions and propose solutions, sadly I lack the talent to make any
changes.
There are a few things that we are both annoyed with though. One is the key
press handling. If I "walk" by holding a direction key, it seems key repeats are
queued so that the PC continues to walk long after the button is released.
Usually into a trapped door...
>
Similarly with search: hold down the search key to make a thorough search of
the immediate area (say, 4 x 5 searches), and after the key is released, and
additional 2 x 5 searches or so are made before the PC can do anything else. The
delay is a couple of seconds and makes the client feel really sluggish. This
usually happen when something horrible shows up, like a "sweet little girl".
(She killed me. Oh, the shame!)
This is client side effect. The client will store up to 10 commands before
'overflowing' and ignoring further commands. For very slow actions this is very
noticeable. When a player starts running the client will continue to send
running events (i think this is actualy server side, sorry beyond my knowledge)
until an interrupt is sent to stop. The solution I have discussed was that the
client should queue commands as long as they are the same action as per the
current system, however, if an alternate action is pressed it should interrupt
the queue and immediately do this action instead. I believe it was added to
someones to do list right down the bottom but I agree that this seems to be a
really powerful aspect of crossfire which adds a laggy or delayed feel to an
otherwise rapid paced game. I suggested this might be a client setting that
users can set a preference for.
A lot of this has to down how keys are handled, at least on x-windows.
If you could down the control, shift, or other modifier keys, a single event
is generated - that the key has been pressed, and another event is generated
when the key is released. This is all done in the x-server - at a level beyond
the client.
For other keys, autorepeat kicks in. So if you hold an arrow key, the
x-server is generating numerous key press/key release events, which the client
then sees and takes as different key presses. Best I know, there isn't an easy
way to know if multiple key presses are a result of autorepeat or if the player
is actually pressing and releasing the key (as a side note, for myself, for
things like search, I would just hit the s key 5 times to know how much I'm
searching)
Given this background, run and fire are handled differently, since these are
modifiers - when the client gets that the key is pressed, it just sends the
appropriate fire_on or run_on to the server, and when key is release, send
fire_off/run_off.
As you can imagine, for other keys, it can't use this same approach - the
arrow key will generate constant press/release events - while the client can
ignore them, that probably isn't desirable either.
You can actually change the amount of commands the server/client buffer - this
is in the config window - if you are playing on a lan, dropping it down to 1 or
2 is probably fine. The reason that might not be good on WANS is that if the
server is far away, the character may end up not doing anything as it hasn't
receive commands for it because of the time it takes for the data to go back and
forth.
Another complication in all this is that how many actions the character gets
isn't constant - it may move slower if it has a lot of equipment on, could move
faster with different spells, etc, so it is a little harder to keep it all in sync.
Basically, yes I agree with your concerns and questions that this aspect of
crossfire could be improved and I believe the current bottleneck is simply time.
The age old #crossfire response: "sure, code it".
Yep - and given this isn't just a simple fix, such code is more difficult.
The proposal to fix it would be for the server to inspect all commands from
the client as it gets them. Right now it is a FIFO - if the server inspects
them, certain commands (drink healing potion) could have higher priority than
other commands. This also allows something like 'ignore all commands up to this
command' to basically flush the queue - in that way, one could interrupt things.
However, when to interrupt and when not still isn't an easy problem. It may
simple enough - if I'm holding the north key down, then when I press the east
key, have it drop any queued up north commands and just start moving east. But
suppose I'm on a map (saw a town) and know I want to go 5 north and 3 east, and
press those keys individually - as noted above, there is no easy way for the
client to know that is the case vs keys being held down.
In the short term I found it very valuable to understand how the client works, I
have changed the way I make key pressed to minimize such "sweet little girl"
scenarios as you have described :).
Yes - exactly how it all works likely will help determine the sweet spot.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
