Yup. The advantages of having keyboard input conditions would be threefold:

1) Actions, such as toggling an setting on and off, no longer need two keypresses to accomplish. The game could register a single key being pressed, transmit that to the server, and the action would persist until the server receives the signal that the key has been released. For example, this would be a very intuitive way for characters to run in a game -- holding down a specific key (like Ctrl) to run faster.

2) Serious reduction in single-player client lag; currently, the client has no polling of the input routines, and instead directly receives input from the Windows keyboard buffer via MFC. Over the internet, Dream Seeker only transmits a limited number of commands. However, in single player, the keyboard repeat rate, when set to fast, can flood the buffer and cause incredible slowness*. In the simplest terms, pressing and holding a direction key would no longer require multiple commands to be transmitted to the server, but rather require only a loop to move the player while the key is pressed.

3) More complex support for keyboard input in games is always a plus. The macro system in BYOND, though it works, definitely seems to be an afterthought (and rightly so -- it was added because most of us whined about a lack of extensive keyboard support! ;-)).


Here are my thoughts on the implementation that I would find most intuitive:

client/proc/KeyDown(key)
Whenever the client presses a key on the keyboard, a unique string belonging to that key is passed into the KeyDown() proc as the key. Pressing the Shift+A key combination, for example, would transmit an ASCII code internally, but this procedure would receive the string "A". Pressing the A key would again internally send the appropriate ASCII code, while the procedure would receive the string "a".
The names belonging to each key are indentical to the names given in the Macro keywords list.
Unless, of course, other people would prefer to receive the raw ASCII code...

If client.KeyDown() is not defined, key presses are not sent to the server directly. Otherwise, all key strokes and key releases that are done when the client is receiving "macro input" are sent to the server.


client/proc/HasKeyPressed(key)
This returns 1 if the server believes that the client currently has the named key (string) pressed, 0 otherwise.
This does *not* poll the client. However, if the HasKeyPressed() proc is called in the code, then all key strokes and key releases must be sent to the server. In simple terms, if HasKeyPressed() is used, then it is precisely similar to if KeyUp() and KeyDown() were defined.


client/proc/KeyPressed(key)
This is a shortcut routine that only receives a single press. If KeyUp()/KeyDown() are not defined, then this will only send the keydown condition to the server -- ignoring the keyup condition -- registering only a single button press (the client must release the key and then hit the key again to send another signal).
The key argument is given the key string as in KeyDown().


client/proc/KeyUp(key)
Like KeyDown(), but when a key is released.


These procs could eventually be expanded to trap meta keys. They would be done in the same format as KeyUp/KeyDown, but would not be given key arguments: exempli gratis ShiftUp(), ShiftDown(), HasShiftPressed(), and ShiftPressed().


* This is confirmed, I might add -- I tested it yesterday: with a full keyboard repeat rate, holding down a movement key causes Dream Seeker to respond at first, but then become incredibly laggy as the client command queue is flooded; with a slow keyboard repeat rate, the queue has no opportunity to become flooded, and the game proceeds at a regular pace.