on computer changes a bit how control works

metaheavens commented

2026-09-12 12:25:36 +00:00

Owner

the different skills are hard to use in this game, instead of changing the currently selected weapons, each weapon will have a touch that directly triggers it. Q for bombs, E for lasers, space for dash

metaheavens referenced this issue from a commit

2026-09-16 05:42:26 +00:00

#231, #230: a key per ability, and an upkeep sheet that adds up

metaheavens commented

2026-09-16 05:43:17 +00:00

Author

Owner

Done in 34e2520.

"The currently selected weapons" names a real mechanism: MouseCombatController (#80) has number keys that select which weapon a click fires. That is two acts for one shot, and the selection is invisible unless you look at the buttons — which is what made the abilities hard to use.

Q, E and space now fire the gas bomb, the laser and the dash outright, wherever the mouse already points. It goes through fire_at(), the same public entry the click path uses, so every guard comes with it — no hull ready, cannot afford the shot, a panel over the button. The number keys stay: they are not what this ticket is about, and removing them would take the click path's abilities with them.

One thing the ticket did not mention and I had to decide. Q and E were already bound — they pivot the formation. The pivot pair moved to Z and C, one row under the movement keys and still left-hand. That is a change to a control you may use constantly, and the part to push back on if it is wrong.

test_keyboard_input spelled Q and E out and so reported a broken pivot when the pivot was fine. It reads KEY_PIVOT_CW/CCW off the controller now, and additionally asserts the pair is not bound to an ability key — the failure that would actually matter.

The new test initially passed while proving nothing: it called fire_at() directly rather than pushing key events. It now drives _unhandled_input with real InputEventKeys and has a negative case for an unbound key. Rebinding Q to J fails it.

Done in 34e2520. "The currently selected weapons" names a real mechanism: `MouseCombatController` (#80) has number keys that **select** which weapon a click fires. That is two acts for one shot, and the selection is invisible unless you look at the buttons — which is what made the abilities hard to use. **Q, E and space** now fire the gas bomb, the laser and the dash outright, wherever the mouse already points. It goes through `fire_at()`, the same public entry the click path uses, so every guard comes with it — no hull ready, cannot afford the shot, a panel over the button. The number keys stay: they are not what this ticket is about, and removing them would take the click path's abilities with them. **One thing the ticket did not mention and I had to decide.** Q and E were already bound — they pivot the formation. The pivot pair moved to **Z and C**, one row under the movement keys and still left-hand. That is a change to a control you may use constantly, and the part to push back on if it is wrong. `test_keyboard_input` spelled Q and E out and so reported a broken pivot when the pivot was fine. It reads `KEY_PIVOT_CW`/`CCW` off the controller now, and additionally asserts the pair is not bound to an ability key — the failure that would actually matter. The new test initially passed while proving nothing: it called `fire_at()` directly rather than pushing key events. It now drives `_unhandled_input` with real `InputEventKey`s and has a negative case for an unbound key. Rebinding Q to J fails it.

metaheavens closed this issue

2026-09-16 05:43:18 +00:00

Rows
Columns

on computer changes a bit how control works #231