Key is down says whether a key is held. To act once on a press, a
graph had only the events On key down and On key up. A behavior
that is called by another one and reads its input as data had to
keep the state of the last frame in a variable of its own.
- Key was pressed is true for the one frame in which the key goes
down, the frame On key down fires in. Key was released is the
same for the frame the key comes up.
- Both sit next to Key is down in the palette and have the key as
their only setting.
- NodeContext gains wasKeyPressed and wasKeyReleased. The behavior
context answers them from justPressed and justReleased of the
input, through keyName, so a key saved as "A" meets the key "a".
- No repeat. On key down may fire again while a key stays held, a
held key is pressed once here.
- When the window loses the keyboard, every held key counts as
released in that frame, as On key up has it.
- The engine prompt of the benchmark names the two nodes.
Tests:
- Gate on melektaus-atx right before this commit: 213 files, 3278
tests (3264 + 14), exit 0.
- e2e 18,20,43 on melektaus-atx: 57 checks, all pass.
- Ten unit tests in key-edges.test.ts on a real world, four cases
in the node catalog.
- Eight counter-probes all fail their tests. One did not at first
(the case of the key saved on the node), a test was added.
- No e2e check of its own, the sum stays 1676. The nodes were not
looked at in the browser, neither in the palette nor with a real
keyboard.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
