Joe DiPrimaandClaude Opus 5
6a96fb6420
A replicant could not start walking between gait-change records. The port's
body case 4 (the task-#64 lockstep twin) is an INSERTION sitting between case 0
and the advance group; in the binary case 4 is a MEMBER of that group
(FUN_004a5678 @004a5678: case 2,3,4,5,8,... -- no turn block, no speed exit),
so case 0's fallthrough is meant to land on Advance(). The insertion caught it.
On a replicant that is not a race but an identity: case 0 arms walk iff
standSpeed < bodyTargetSpeed, and the inserted block resets iff standSpeed <
bspd -- where bspd IS bodyTargetSpeed for a replicant. Same expression, so arm
and reset fire on the same frame, forever, and a peer parked at Standing with a
live replicated demand never cycles. bodyCycleSpeed stays 0 while position
advances from dead reckoning: the skate.
This is the sequel to e91d447 (#82). Before it the replicant branch read the
dead local mapper cell (0 forever), the exit never fired, and the fallthrough
worked BY ACCIDENT. Fixing the dead cell closed the escape hatch.
Fix: case 0 -> goto advance_body_normally, the leg twin's own idiom, restoring
the binary's structure without touching the #64/#82 turn logic.
BT_NO_BODY_FALLTHRU=1 reverts.
Measured (2-node, scratchpad/night13/skatelock.sh):
legacy 336 consecutive locked seconds, bspd=39.2324 bts=39.2324 every line
fixed 0 locks, every pass
master body-Standing samples 52 -> 21 (it locked too, invisibly at mj=0)
turn-in-place intact: pivoter body state 4 x9 / leg state 4 x8, in lockstep
Diagnostics (both keepers): [skate] now carries bstate= -- the field lines
proved "both channels idle" but never named the state, which was the whole
answer; [bodySM]/[peergait] under BT_BODY_SM_LOG instrument the arm->reset pair
and a moving replicant's body channel.
NOT claimed: that this accounts for the night-13 field episodes. That link is
inference -- locked + translating IS the skate signature by construction, but no
bench caught the two together. bstate= settles it next playtest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCJQkvq6G2JNrpVbA75tVZ
67 lines
4.3 KiB
Python
67 lines
4.3 KiB
Python
"""Night 13 housekeeping, part 2: comments + state changes on existing issues."""
|
|
import sys
|
|
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
|
|
import gitea
|
|
|
|
N13 = "Playtest night 13 (2026-08-06, build **4.11.817 (6fcff95+)**). "
|
|
|
|
# ---- #89 SPLASH: verified working, close -----------------------------------
|
|
gitea.close(89,
|
|
N13 + "**VERIFIED WORKING -- closing.**\n\n"
|
|
"SAURON: \"Splash damage looked good to me, **splash worked on mechs that died close**\". "
|
|
"epilectrik: \"splash damage seems ok?\" -- no dissent from any tester.\n\n"
|
|
"Oracle (original-pod player) also gave the era calibration that explains why splash reads as "
|
|
"inconsistent rather than absent, and says our current behaviour matches it: \"sometimes you "
|
|
"really catch it and sometimes not. It jogged my memory and I vividly recall that **being at "
|
|
"different elevations on a hillside sometimes made a real hash of it** -- the effect could be much "
|
|
"stronger or weaker\" ... \"it was **not** the mechwarrior 3/4 splash model\". SAURON: \"that seems "
|
|
"correct to me\". So an unpredictable, elevation-sensitive splash is AUTHENTIC and should not be "
|
|
"'fixed' into a clean radius falloff.\n\n"
|
|
"One sub-case survives and is filed separately as **#144**: no splash on a panic/eject/suicide "
|
|
"death (authenticity not yet established).")
|
|
|
|
# ---- #108 GHOST MECH: recurred ---------------------------------------------
|
|
gitea.comment(108,
|
|
N13 + "**Still present, and it was the headline problem of the night.** epilectrik: \"**ghost mech "
|
|
"biggest surprise**\" when reviewing regressions.\n\n"
|
|
"No new detail beyond the existing repro in this issue -- recording the recurrence on 817 so the "
|
|
"issue is not read as stale. Field logs for all four players (3 desktop + the pod cart) are staged "
|
|
"in `scratchpad/night13/`, including the pod's matchlogs, which is the first time this issue has "
|
|
"log coverage from a hardware seat as well. Analysis: `docs/GHOST_MECH_ANALYSIS.md`.")
|
|
|
|
# ---- #76 layout restore: superseded by #140 --------------------------------
|
|
gitea.comment(76,
|
|
N13 + "**Overtaken by #140.** As of 817 the problem is no longer 'two windows fail to restore' -- "
|
|
"`BT_GLASS_LAYOUT=save` now writes a `glass_layout.cfg` with the MFD and Secondary lines missing "
|
|
"entirely (Plasma survives), so nothing restores at all. See #140 for the reports and the suspect "
|
|
"commits.\n\n"
|
|
"Fix #140 first; this issue may turn out to be a subset of it. Re-verify the two windows named "
|
|
"here only once saving writes a complete file again.")
|
|
|
|
# ---- #123 searchlight / night visibility: era testimony --------------------
|
|
gitea.comment(123,
|
|
N13 + "**Primary-source testimony on night visibility** from Oracle, who played the original pods "
|
|
"at Lazer Park. This is directly about the deferred half of this issue (the fog swap), and it "
|
|
"raises the priority of the fog over the beam:\n\n"
|
|
"- \"some maps were not very dark, some were very dark\"\n"
|
|
"- \"**the FOG was what really killed visibility**\"\n"
|
|
"- \"I do recall basically stumbling into each other point blank at times and **having to use "
|
|
"radar to navigate**\"\n"
|
|
"- \"it could be very difficult to make a shot in those conditions\"\n"
|
|
"- \"it was 90's tech there\"\n\n"
|
|
"Takeaway for the implementation: the authentic night experience is driven by FOG DENSITY, not by "
|
|
"ambient darkness, and it was severe enough that radar navigation was the norm. The "
|
|
"`searchlightfog=` / `nosearchlightfog=` environment swap described above is therefore the "
|
|
"high-value half of this work, not the projected beam.\n\n"
|
|
"Operator note the same night: general night-visibility tuning is **deferred** until the correct "
|
|
"behaviour is known -- epilectrik: \"the night time visibility I might defer for now since we "
|
|
"don't really know the correct behavior ... I'll try to retrieve it from the binary again but "
|
|
"might be a hardware side thing\". This comment is that missing calibration.")
|
|
|
|
# ---- #61 ThermalSight: point at the new visible-half issue -----------------
|
|
gitea.comment(61,
|
|
N13 + "Cross-ref: the **visible** half of ThermalSight now has its own issue, **#145**, with "
|
|
"primary-source description of what the IR mode actually looked like (a palette shift, explicitly "
|
|
"NOT a heat image -- possibly a hardware test mode rather than a designed effect). Worth reading "
|
|
"before anyone implements a presentation off the toggle this issue restored.")
|