[crossfire] Key repeat and keybindings

[Mark Wedel]

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.