[Goober5000]

Cause

With mouse flight on ("Mouse: Joy-0"), a Joy-0 axis binding also reads the mouse. In scale_invert(), the mouse's per-frame delta was added to the absolute throttle's position and inverted with the absolute rule (F1_0 - val). So a still mouse contributed F1_0 * factor (~2×10⁸), which pinned the throttle at 0% at every lever position. Relative axes were unaffected, because inverting a zero delta is still zero. New pilots have mouse flight on by default.

More broadly, a mouse on an absolute axis action was an incomplete feature: the delta was read as a position instead of being accumulated into one. Absolute actions also summed all their inputs, which doesn't make sense for positions; two levers bound as first and second were already broken this way.

Fixes #7951.

Fix

• Inversion follows the input, not the action: joystick positions invert as F1_0 - v, and mouse deltas always invert by negating.
• New abs_axis_state for absolute actions: it keeps the action's current value. A joystick sets the value outright and the mouse nudges it, and whichever input moved last is in control.
  • A lever that has lost control must move more than 1.25% of its range to take it back, so an idle lever's jitter doesn't fight the other inputs. This matches the analog throttle's keyboard override (1.5 of its 120 throttle-percent range). The mouse has no threshold, since a still mouse reports no movement.
  • A lever's first reading only takes control if no other lever has reported or is in control.
  • A disconnected joystick reads as centered, so it is ignored rather than treated as a lever position.
• Rebinding or inverting mid-mission: when an absolute action's bindings change (controls screen, Lua, presets), its levers re-anchor without moving the throttle, and the lever in control keeps control and applies the new binding at once.
• Mouse scale: it matches the mouse's feel on the relative throttle, which is the existing factor without the /frame_time. Mouse Z does nothing, because Mouse_dz is never set.
• Only one caller updates the absolute axes: the axes can be read more than once per frame (free-look in view_modify(), and photo mode), so those callers pass update_abs_axes = false and only read_keyboard_controls() updates them.
• Reset at mission load: a lever sets the throttle on the first frame. The analog throttle's keyboard override (override_analog_throttle, analog_throttle_last) also resets each mission; before, a throttle key pressed in one mission made the next mission ignore the lever until it moved. A mouse-only absolute throttle starts at 50%, the same as the existing analog_value default.
• Relative actions are unchanged.

Testing

• Unit tests: new tests for abs_axis_state in test/src/controlconfig/test_abs_axis.cpp. The full unit suite passes.
• In-game: the absolute throttle works with mouse flight on, both normal and inverted.

🤖 Generated with Claude Code

[dustinspace217]

This also fixes #7951 (inverted absolute throttle stuck at zero with mouse flight on), so "Fixes #7951" in the description would close it. From reading the source and the new tests, three things:

1. The anchors only reset at mission load. If the throttle is rebound or inverted mid-mission (the controls screen, or Lua bind->invert), a new lever is ignored until it moves 1.5%, and an inversion toggle can let an idle second lever take over. Could the anchors and active be cleared when that action's binding or inversion changes, keeping value?
2. analog_throttle_last and override_analog_throttle (playercontrol.cpp:648-649) never reset. After a throttle key in one mission, the next mission's lever is ignored until it moves, which contradicts "a lever sets the throttle on the first frame". Reset them alongside control_reset_axes(), or reword that line?
3. The update_abs_axes flag already stops the free-look double read, since only one caller passes true. Could the serial go? That also drops the mouse.cpp/h changes.

Smaller: the keyboard gate is about 1.25% (819 fix units), not 1.5%. Was the mouse taking control with no threshold intended? The description could say mouse Z does nothing, since Mouse_dz is never set. A test through update_abs_axis would pin the wiring.

[Goober5000]

@dustinspace217 Ok, points addressed and PR updated

[dustinspace217]

This is a code-reading review of c3f26e6; nothing was built or run.

Thanks, all three earlier points are resolved:

1. Anchors now clear when an absolute action's bindings change (controlsconfig.cpp:3159). Keeping active instead of clearing it, as I had asked, is the better choice, since an idle lever only re-anchors and the lever in control applies its new reading at once.
2. analog_throttle_last and override_analog_throttle now reset in player_level_init(), which runs once per mission.
3. The mouse delta serial is gone, and mouse.cpp/h are out of the diff.

The smaller points are handled too: the threshold is now F1_0 / 80 (819 fix units), matching the keyboard gate, and the description now covers the mouse threshold and mouse Z.

One new issue in the rebind path. If the mouse moved last (active == -1) and the bindings then change, clear_anchors() leaves nothing anchored and nothing in control, so the lever's next reading takes control and the throttle jumps to the lever.

That contradicts "its levers re-anchor without moving the throttle". clear_anchors_keeps_value_from_delta stops right after clear_anchors(), and going by the source, adding state.update_position(0, 20000); ASSERT_EQ(25000, state.value); would fail on the current code.

One fix is a flag set by any reading, cleared by reset() and kept by clear_anchors(), so a first reading after a rebind only anchors. Narrowing that line of the description would also work.

Still open from last time: the tests only cover abs_axis_state, so the mouse invert type in update_abs_axis, the disconnected joystick guard and the rebind check can each be reverted with the suite staying green.

Smaller: no test moves a lever down to retake control or pins the 1.25% value, so dropping abs() or zeroing TAKEOVER_THRESHOLD would also pass.