fix(keybinds): the dropdown is 121,112, and 121,108 is what hides it

sickday commented

2026-08-19 01:37:21 +00:00

Owner

A row button hands script 982 four components -- 121,109, 121,108,
121,112 and 121,113 -- and the previous fix took 121,108 off that list by
eye. It is the wrong one. 982 does CC_DELETEALL and CC_CREATE on its own
parameter slot 2, the third of the four, so the entries are children of
121,112; 121,108 is the outer container and the only thing that ever
happens to it is that 983 hides it when a choice is picked.

So if_setevents granted op 1 on a component with no children, and the
handler keyed on the same wrong number, and it shipped green: the world
test drove the click at Keybinds.dropdown(), the module's own constant, so
both halves of the mistake agreed perfectly.

The symptom is the part worth keeping. It was not "nothing happens" -- the
dropdown still closed, because hiding it is 983's client-side work and
onOp runs before the mask is consulted. A row that shuts and then does not
change reads exactly like a server that received the click and refused it,
when in fact nothing had been sent.

keybinds_test resolves the component through the call now: it reads 982's
opening ILOAD n; CC_DELETEALL, checks the same slot is what CC_CREATE
writes into, and maps that parameter position back through 985's argument
list. The number cannot drift again, and restating it in a test is what
let it drift the first time.

Reported from a live client, where Restore Defaults and both 'Attack'
options pickers were already confirmed working.

A row button hands script 982 four components -- 121,109, 121,108, 121,112 and 121,113 -- and the previous fix took 121,108 off that list by eye. It is the wrong one. 982 does CC_DELETEALL and CC_CREATE on its own parameter slot 2, the third of the four, so the entries are children of 121,112; 121,108 is the outer container and the only thing that ever happens to it is that 983 hides it when a choice is picked. So if_setevents granted op 1 on a component with no children, and the handler keyed on the same wrong number, and it shipped green: the world test drove the click at Keybinds.dropdown(), the module's own constant, so both halves of the mistake agreed perfectly. The symptom is the part worth keeping. It was not "nothing happens" -- the dropdown still closed, because hiding it is 983's client-side work and onOp runs before the mask is consulted. A row that shuts and then does not change reads exactly like a server that received the click and refused it, when in fact nothing had been sent. keybinds_test resolves the component through the call now: it reads 982's opening ILOAD n; CC_DELETEALL, checks the same slot is what CC_CREATE writes into, and maps that parameter position back through 985's argument list. The number cannot drift again, and restating it in a test is what let it drift the first time. Reported from a live client, where Restore Defaults and both 'Attack' options pickers were already confirmed working.

sickday added 1 commit

2026-08-19 01:37:21 +00:00

fix(keybinds): the dropdown is 121,112, and 121,108 is what hides it

ci / gates (pull_request) Successful in 3m21s

Details

build / image (push) Successful in 37s

Details

ci / gates (push) Successful in 3m54s

Details

b14b64d262

A row button hands script 982 four components -- 121,109, 121,108,
121,112 and 121,113 -- and the previous fix took 121,108 off that list by
eye. It is the wrong one. 982 does CC_DELETEALL and CC_CREATE on its own
parameter slot 2, the third of the four, so the entries are children of
121,112; 121,108 is the outer container and the only thing that ever
happens to it is that 983 hides it when a choice is picked.

So if_setevents granted op 1 on a component with no children, and the
handler keyed on the same wrong number, and it shipped green: the world
test drove the click at Keybinds.dropdown(), the module's own constant, so
both halves of the mistake agreed perfectly.

The symptom is the part worth keeping. It was not "nothing happens" -- the
dropdown still closed, because hiding it is 983's client-side work and
onOp runs before the mask is consulted. A row that shuts and then does not
change reads exactly like a server that received the click and refused it,
when in fact nothing had been sent.

keybinds_test resolves the component through the call now: it reads 982's
opening ILOAD n; CC_DELETEALL, checks the same slot is what CC_CREATE
writes into, and maps that parameter position back through 985's argument
list. The number cannot drift again, and restating it in a test is what
let it drift the first time.

Reported from a live client, where Restore Defaults and both 'Attack'
options pickers were already confirmed working.

sickday merged commit b14b64d262 into main

2026-08-19 01:40:55 +00:00

Rows
Columns

fix(keybinds): the dropdown is 121,112, and 121,108 is what hides it #240