This component defines nodes to interact with a keyboard.
KeySensor processes simple key presses / releases.
StringSensor provides a simple way for user to type and edit
See also X3D specification of the Key device sensor component.
This components allows to read and process keys using X3D nodes.
Note: If you write a game using Castle Game Engine,
These nodes are not the most comfortable way to process keyboard. Do not use them.
TCastleView.Press method to listen to keys
(see any "New Project" template created by the editor for an example).
You can also react to
TCastleControl.OnPress or override
See the manual describing handling events.
If you definitely want to use these nodes with CGE, remember to set
For demos and tests of these nodes,
sensors_key subdirectory inside our VRML/X3D demo models.
Listen to key press and release.
Input and edit a string using keyboard.
actionKeyPress events follow
the "key repeat" feature of your operating system/window manager.
This means that when the user holds down a key, we generate many key press events.
Sometimes it's useful (for simulating normal text input, for example).
Report if you would like to make this feature optional (and maybe
off by default?), a field like
KeySensor.repeatKey may be added.
isActive := TRUE is also generated at each key press,
isActive := FALSE at each key release. So they do not match in pairs.
And it's not that simple, even if we would turn off the "key repeat" feature
mentioned above: imagine that you press one key, then you press a 2nd key,
and release the 1st key. Turns out that we have to track all the keys pressed,
and deactivate only when all are released, right? Things get more hairy
when you consider the first key to be the letter "a", and the 2nd key to be "Shift".
Conceptually, "a" is pressed, then "A" is pressed, then "A" is released...
but when was lower-case "a" released?
Actually, we do have a smart code inside an engine to track it correctly,
but it's not passed to the
StringSensor) may be active at given time. The specification
doesn't precisely say what should happen, with wording suggesting
that making a sensor enabled makes it also active (which contradicts the
spec), and without saying which sensor is chosen if many are present (the first?
the last in the graph?).
Copyright Michalis Kamburelis and Castle Game Engine Contributors.
This webpage is also open-source and we welcome pull requests to improve it.