Fix boss jitter; add a settings screen for controls and volume
ci / verify (push) Successful in 48s

The jitter had two causes, and the larger one is embarrassing: boss_state()
handed back the newest snapshot raw while players and enemies both went
through the interpolator. The boss therefore stepped at the 20Hz snapshot rate
instead of the frame rate. Invisible for as long as every boss stood still,
and the first one that moved looked broken. It is interpolated now -- but not
across an instance change, where the previous snapshot describes a different
fight in a different room and lerping to it would fling the new boss across
the map for a frame.

The smaller cause was server-side: a CHASE boss corrects by the SIGN of its
distance error, so at the standoff the sign flipped every tick and the boss
vibrated a couple of pixels at 60Hz. It has a dead band now.

The settings screen covers rebindable controls and volume, reachable from both
the main menu and the in-game menu. Bindings are stored as physical keycodes
-- following key position, the choice setup_input_map.gd already made -- and
labelled back through the active layout so an AZERTY player reads the letter on
the key their fingers are on. A rebind replaces every event on the action
rather than the first, because an action that kept its alternates would still
answer to the key you just moved away from. A key already in use is refused and
the clash is named. Reset restores what the PROJECT shipped, captured once
before anything overrides it -- captured later it would restore the last
session's choice, which is the thing being undone.

Effects play on an SFX bus created at runtime, so both sliders are real mixer
settings rather than a number multiplied into every play() call.

Worth recording: the test suite AND the smoke test both passed while a client
logged twelve engine errors on every startup. ConfigFile.get_value(s, k, null)
does not mean "no default" -- it means the key is absent and no default was
given, and the engine logs an error per action. Nothing caught it because the
smoke refutations matched SCRIPT ERROR and friends, and a plain ERROR: is none
of those. It surfaced from running the client and reading the output. smoke.sh
now asserts no plain engine errors either, excluding by name the one line Godot
prints on every clean exit, and reintroducing the bug makes it fail.

One mutation caught nothing and should not have: the early return in
linear_to_db_clamped was dead code, since the clamp beneath it already prevents
negative infinity. Removed rather than left looking tested.

check.sh clean, 439 tests, SMOKE PASS (23 assertions), all four diagnostics
green, and a real client boots with zero engine errors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-07 10:56:44 +02:00
parent 4a98cf4b0e
commit 872922e9e2
22 changed files with 943 additions and 7 deletions
+23
View File
@@ -97,6 +97,27 @@ check() { # check <label> <file> <pattern>
fails=$((fails + 1))
fi
}
# Plain engine errors, which the pattern below deliberately does not catch:
# "SCRIPT ERROR" and friends are GDScript problems, and a great many engine
# complaints are neither. A settings file missing a key logged one ERROR line
# per action at startup and this suite reported a clean pass, which is what
# motivated this check.
#
# One line is excluded by name rather than by pattern: Godot reports a resource
# still in use at exit on every run, and naming it means anything else that
# turns up is a real finding.
no_engine_errors() { # no_engine_errors <label> <file>
local hits
hits=$(grep -E "^ERROR:" "$2" | grep -vF "resources still in use at exit" | wc -l)
if [[ "$hits" == "0" ]]; then
echo " ok $1"
else
echo " FAIL $1 ($hits engine error line(s) in $(basename "$2"))"
grep -E "^ERROR:" "$2" | grep -vF "resources still in use at exit" | head -5 | sed 's/^/ /'
fails=$((fails + 1))
fi
}
refute() { # refute <label> <file> <pattern>
local hits
hits=$(grep -cE "$3" "$2" || true)
@@ -147,6 +168,8 @@ check "a polite disconnect is also channelled" \
# and tools/diag_upgrades.tscn covers the loop itself.
refute "no server script errors" "$OUT/server.log" "SCRIPT ERROR|Parse Error|USER ERROR"
refute "no client script errors" "$OUT/bot1.log" "SCRIPT ERROR|Parse Error|USER ERROR"
no_engine_errors "no engine errors on the server" "$OUT/server.log"
no_engine_errors "no engine errors on a client" "$OUT/bot1.log"
echo
if [[ $fails -eq 0 ]]; then