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
