fix(settings): a runtime dropdown is labelled, not enabled #239
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/keybinds-and-attack-options"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Setting a keybind did nothing: the panel drew, every row offered every
function key, picking one left the row on None, and Restore Defaults was
inert. Both 'Attack' options pickers had the same fault with a worse
symptom.
The keybind implementation bound on opcode 184, the key-down batch, and
every step of the argument behind it is true -- nothing in the cache
writes the fourteen binding varbits, 184 is the only c2s message carrying
a key, and the client's remapped index makes F1-F12 into 1-12. The
conclusion is still wrong, because this cache's panel never asks for a
keystroke. Script 985 opens a dropdown, 982 creates one child per code
into layer 121,108 -- child 0 is None and 1..13 are the keys, so the child
index IS the code -- and 983, the entry's own handler, only hides the
list. The choice arrives as an ordinary component click.
121,108 scores zero in the cache because its children exist only on the
client, and CC_SETOP writes a label without touching a mask, so without
if_setevents no entry ever sent a packet. What binding on a keystroke did
instead was bind Escape to whichever row was open, Escape being how the
dropdown is dismissed. Dispatch drops :key_presses now.
The 'Attack' options pickers are the same construction one interface
along: 261,83 children 1..4 write varp 1107 and 261,84 write 1306, value
being the child index minus one, both stated by 1127's own comparisons.
There the local SET_VARP made it look like it worked -- the label changed,
the menus followed -- and it was gone at the next login. That varp is the
client's only input into where Attack sits: the demote byte is skipped for
that label and the NPC builder has no flag at all, so Left-click where
available was unreachable, which is most of what a PKer clicks.
Also fixed along the way:
1159/1160, and the gap is where the client puts the digit keys. They
store, draw as None and match nothing.
the same value.
states the pairing component by component, and the test regenerates
the whole table from the cache instead.
revision, so the table is sourced and mapped onto this cache's own
panel list; it is a bijection over the thirteen keys, and a test says
so, that being its only independent check.
Unlocks go out where the screens are bound: the controls dropdown as its
panel opens, after the bind, and both 'Attack' pickers once at seat.
Setting a keybind did nothing: the panel drew, every row offered every function key, picking one left the row on None, and Restore Defaults was inert. Both 'Attack' options pickers had the same fault with a worse symptom. The keybind implementation bound on opcode 184, the key-down batch, and every step of the argument behind it is true -- nothing in the cache writes the fourteen binding varbits, 184 is the only c2s message carrying a key, and the client's remapped index makes F1-F12 into 1-12. The conclusion is still wrong, because this cache's panel never asks for a keystroke. Script 985 opens a dropdown, 982 creates one child per code into layer 121,108 -- child 0 is None and 1..13 are the keys, so the child index IS the code -- and 983, the entry's own handler, only hides the list. The choice arrives as an ordinary component click. 121,108 scores zero in the cache because its children exist only on the client, and CC_SETOP writes a label without touching a mask, so without if_setevents no entry ever sent a packet. What binding on a keystroke did instead was bind Escape to whichever row was open, Escape being how the dropdown is dismissed. Dispatch drops :key_presses now. The 'Attack' options pickers are the same construction one interface along: 261,83 children 1..4 write varp 1107 and 261,84 write 1306, value being the child index minus one, both stated by 1127's own comparisons. There the local SET_VARP made it look like it worked -- the label changed, the menus followed -- and it was gone at the next login. That varp is the client's only input into where Attack sits: the demote byte is skipped for that label and the NPC builder has no flag at all, so Left-click where available was unreachable, which is most of what a PKer clicks. Also fixed along the way: * bindable? was bounded by the varbit's five bits rather than by enum 1159/1160, and the gap is where the client puts the digit keys. They store, draw as None and match nothing. * picking None swept every other row, because every unbound row holds the same value. * the slot table was documented as an unproven inference; script 984 states the pairing component by component, and the test regenerates the whole table from the cache instead. * Restore Defaults is implemented. No default scheme exists in this revision, so the table is sourced and mapped onto this cache's own panel list; it is a bijection over the thirteen keys, and a test says so, that being its only independent check. Unlocks go out where the screens are bound: the controls dropdown as its panel opens, after the bind, and both 'Attack' pickers once at seat.