[1.31] Key_released and Key_pressed events

These events would be especially useful when mapping key combinations (e.g. Ctrl+arrow keys) for use in program. Right now there's no way to distinguish a key combination from two keys pressed one after the other. What do you think?

We've discussed this and to implement it would mean for every char typed you would have to send more data through the server. CC already sends alot of data through packets and keeping it to a minimal is the key.

But can you at least make 'key' event return a table with every key that is pressed ATM?

That would require sending a packet every x period of time for as long as a key is held.

You can do "workarounds" with timers for key combinations, but finding out if a key is held-down or not will prolly require a peripheral since Dan doesn't want to add all kinds of extra data to packets :mellow:/>/>

How about pressing two in quick succession? Like 1 sec between the two?

Liraal, on 11 March 2012 - 01:03 PM said:

How about pressing two in quick succession? Like 1 sec between the two?

I just tried somethin like that, i.e. a two key combo with a timer-interval that clears any key presses so that only quick presses in succession will be successful.
But if you make the interval longer than 0.2 seconds, then you can just press one key and then the other, like typing (instead of a real combo).
Even if the interval is tweaked to a good value it's still error prone.
You can't, for example, hold one button and then take your time pressing the second one, because of the problem you already mentioned: Only pressing is an event, not holding or keyDown or keyUp.
Therefore, even though you're still holding the key, the interval-timer will still fire and nil your pressed key variables.
Not much one can do about it for now. At least as far as I know. :mellow:/>/>

I think best compromise is shiftstate sended with each key pressed. Only state of each shift, ctrl, alt keys. May be meta/win too, but I doubt it. So two keys each will be additional byte in packet. This make possible all shift- alt- .. combination without much efforts and problems.

I don't see why Dan can't add at least key_up event. Single event per key release won't increase server load too much. It's als a good idea to remove key_repeat event and leave only first key_down (and maybe emulate key_repeat on server side in fixed time intervals until key_up, but only as optional feature, not really useful)
P.S. Why not simply send raw keyboard scan-codes? One byte for each key press/release isn't very much. (at least if you don't send each in a separate packet)

Except they do all have to be sent in a separate packet.

As far as I can see the main problem is that each key has to be sent in a separate packet (their size now is miserably small so doesn't need care)
If so, why not group these events into single packet? I mean most keys are released in less than half a second after they were pressed, so waiting for a second after keypress before sending will result in about 6 events in one packet (3x press/release). I think increasing size of packet won't result on performance, but decreasing their amount will. If I'am not right, please correct me.
However, it may be difficult to implement and will not be implemented soon (if will be ever)

The problem with that idea is that, in order to discover the second keypress, you have to delay the first one a bit. If the delay is really short, it won’t make any difference (because the packet will be sent before a second key event occurs); if the delay is a bit longer, it can actually be rather disconcerting and take some time to get used to a keyboard that delays keypresses even for a fairly short period of time, so that may not be desirable.

Yeah, keypresses in SMP are already semi-laggy, we definitly don't wanna lag them more :mellow:/>/>

IMHO no mater why keypress callbacks are delayed - because of internet connection or because of specially used delay. I think most users will not notice half-second delay between keypress and response (You don't hold keys for half-second, do you?) and in my case it will result in (average) 2 or 3 keys per packet (4 events)

Remember that when we say "packet", we're talking about Minecraft packets, not network packets. Multiple Minecraft packets are aggregated into a single TCP segment anyway. Honestly, it's not clear to me why doubling the number of keypress packets would have any measurable impact on the bandwidth usage of a server, considering the frequency with which people type keys and the fact that dozens upon dozens of packets per second are sent in both directions in vanilla Minecraft anyway.

… and most people not type to console constantly.

but why would they be needed always/when the computer is open?

Wouldn't be easier to send key up/down events only while holding a specific item like a remote controller (then you code the computer to do whatever you want with it: remote controlled turtles, secret doors, domotics, etc)
If you want to use hotkeys to swap interfaces in the computer I think it'd be easier to intercept keypresses to some subset of keys WHILE you have the PC open, for example the F-keys since you wouldn't use them to type anyway.

This is a very old thread, but sooner bump this than rewrite the suggestion.

Much as initially stated, better key events or direct access to the state of each users keyboard would greatly benefit input and UI design.

As noted, additional package information is a serious downside to this idea, and finding a easy way to compress all keyboard information and send it regularly is a daunting task, but the result would certainly be worth the effort.

I don't feel this is one of the more pressing issues with CC at the moment, but it's worth bringing back to light in some official sense for later consideration.