[crossfire] Key repeat and keybindings

[Arvid Brodin]

On 2013-10-26 08:21, Mark Wedel wrote:
> On 10/25/13 04:59 PM, Arvid Brodin wrote:
>> On 2013-10-24 07:19, Mark Wedel wrote:
>>> On 10/23/13 06:53 PM, David Hurst wrote:
>>>> Hi Arvid,
>>
>> Hi!
>>
[]
>> For auto-repeating keys though, there are no release events between the key
>> press events:
>>
>> key pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key
>> pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key released: KP_2
>>
>> So keeping state for each button would be easy. It's also easy to see if a
>> key is actually pressed several times vs being held down. (Maybe focus in/out
>> can make things a bit more difficult, but not a lot, I guess.)
>>
> 
>  Interesting.  So I'm guessing that gtk must capture some of the events.  If I
> run xev, I do see key press/key release events for the keys.
> 
>  But even in the above example, it potentially means a more complicated setup,
> in that the client (or something) has to keep track if the release events has occurred.

Well, we already have a struct in which we keep info for each interesting key, with
quick, hashed access, so storing the state would be as easy as three lines of code.


>> It could be as simple as adding a few new start/stop type commands to the
>> server - walk (without attacking), search, and disarm, to begin with? - and
>> updating the client to use them. Assuming the client key handling is in
>> place, of course.
> 
>  I'd really prefer this not be in the server, and instead be in the client. the fire_on and run_on are really pretty terrible hacks as is, and I'd rather not add more of them.

I haven't looked at the server code, but the client hack is a bit terrible, yes. :)

 
>  The protocol has improved since those were put in.  The client should be able to better watch the number of acknowledge commands and send or not send commands as appropriate.  Note per my previous mail, the next enhancement that would be nice would be for the server to look at all commands, and in addition to having priority, there could be something like 'cancel are north commands', such that when the key is released, that is sent to the server and the server does just that.  That said, even this gets tricky - you don't want to cancel the a single command that was sent, which might mean the client has to know if multiple commands have been sent, and which ones.

If the client waits for the acknowledgements before sending the repeat, isn't there a risk that we handicap players with a high network latency? If the acks are sent from the server immediately upon reception of the command, perhaps this wouldn't be so bad in most cases. If the ack is sent after the command has been executed, it would be a big problem.

 
>  This reduces the server having to remember more state.
> 
>  In terms of what commands should repeat and what should not, this could probably be an option in the keybind menu, eg, 'repeat?' which notes if the command should be repeated or not.  Probably also allow it in the keybindings itself, because for some commands, there may be desire to repeat them in certain circumstances and not other (apply immediately comes to mind in certain cases, like eating a lot of low value food, but not in others, like using exits)

This is a great idea! It would also solve the problem with deciding whether to cancel a queue of commands or not - only on releasing the key of a repeating command should a "reset queue" command be sent to the server.


>>
>>
>> ----
>>
>> I've done some coding on the other, related issue of key
>> combinations/modifiers and key bindings.
>>
>> Today the client is extremely flexible: you can actually re-bind the run,
>> fire, alt and meta modifier keys! Is this a popular feature?
> 
>  Not sure, although I could imagine depending on keyboard layout, etc, there may be desire to do so.
> 
>>
>> Also, it is unclear how combinations of modifiers work: if you check both Run
>> and Fire in the Keybindings dialog, does the key work only when they are both
>> depressed, or with any of them? If you select no modifiers, does the key then
>> work regardless of modifier keys or only when no modifier keys are held?
>>
>> The code is a bit ambivalent on this, it seems (maybe this works
>> systematically by chance, but I found at least one obvious mistake in the
>> code, as well as code comments leading me to this conclusion).
>>
>>
>> I reworked the code a bit and added an "Any" checkbox in the Keybindings
>> dialog. This way you can choose whether the key should ignore modifiers, or
>> set the same key to different commands depending on the combination of
>> modifier keys held.
> 
>  Yes, that seems like a good fix.
> 
>>
>> At the same time I removed the code that treats default key bindings
>> specially, so now you can easily unbind/change them in the dialog box or
>> using the unbind command. (You could do this via the "unbind -g" command
>> before, but how would you know without looking at the code?)
>>
>> I also removed the possibility to re-bind the Ctrl, Shift, Alt and Meta keys
>> since that just seems overly complex.
>>
>> I can post the patch if anyone is interested. It also contains quite a few
>> style fixes though (mostly remove space before function '(', space after
>> comma, space around '='/'==' etc). I tried to use the most prevalent style
>> already in use in the file, but I should probably have done it in a separate
>> patch...
> 
>  I'd certainly say it is worth it to post it or upload it to sourceforge on the tracker.

Which is the preferred method? I'm used to sending patches inline in emails; the
sourceforge tracker is new to me.


-- 
Arvid