185 lines
12 KiB
Python
185 lines
12 KiB
Python
# -*- coding: utf-8 -*-
|
|
"""Night 7 (2026-07-30) field-report housekeeping: closes + notes."""
|
|
import gitea
|
|
|
|
HDR = ("**Field report, playtest night 7 (2026-07-30, build 4.11.659 (e91d447))** -- "
|
|
"SAURON, RajelAran, Oracle (new tester, original-pod experience).\n\n")
|
|
|
|
# ---------------------------------------------------------------- CLOSE #81
|
|
gitea.close(81, HDR +
|
|
"**Closing: the respawn cycle was clean for the whole session on three machines.**\n\n"
|
|
"Asked directly and answered repeatedly during play:\n"
|
|
"- operator: \"how about death/respawn? clean so far?\" -- SAURON: \"yes clean so far\"\n"
|
|
"- Oracle: \"death repsawn OK so far\"\n"
|
|
"- No ghost/zombie respawn was reported by anyone across a ~2h session with many deaths "
|
|
"and respawns, against the ~1-in-3 rate that produced this report.\n\n"
|
|
"The fix that landed for this was the removal of the `deathPending` one-way latch and "
|
|
"the respawn-record path rework (shipped in 4.11.659; bench-verified beforehand at 4 "
|
|
"nodes / 56 overlapping death cycles with zero strands).\n\n"
|
|
"**One wreck sighting DID occur tonight, but it is not this bug:** SAURON's Hellbringer "
|
|
"rendered as wreckage on peers while alive and fighting, triggered by a mech-to-mech "
|
|
"**collision** -- no death, no respawn. Filed as **#94**. If that turns out to share a "
|
|
"root with this one, reopen.\n\n"
|
|
"Related: #45 (the K/D replication half of the same work), #94 (collision-triggered "
|
|
"wreck graphic).")
|
|
|
|
# ---------------------------------------------------------------- CLOSE #46
|
|
gitea.close(46, HDR +
|
|
"**Closing: an unpurged ammo bay fire is now lethal.** Oracle, mid-session:\n"
|
|
"> ammo bay fire and alarm seems OK\n"
|
|
"> and I go boom when I failed to eject\n\n"
|
|
"That is exactly the behaviour this issue said was missing -- Cyd and RajelAran each sat "
|
|
"through two bay fires without dying on 4.11.524. A fresh tester now gets killed by one "
|
|
"he failed to purge, and separately reports the bay-fire alarm firing.\n\n"
|
|
"**Still open in the neighbourhood:** #47 -- the JAM annunciator. Oracle observed an "
|
|
"ammo jam on the Avatar's AFC50 with no flashing red indicator (commented there). The "
|
|
"bay-fire alarm half of #47 now looks satisfied; the jam half does not.\n\n"
|
|
"Related: #28 (vital-subsystem-crit death path), #47 (jam annunciation).")
|
|
|
|
# ---------------------------------------------------------------- CLOSE #78
|
|
gitea.close(78,
|
|
"**ANSWERED: yes -- Tesla 4.10 has a limping ('gimp') mech mode, and it is reconstructed "
|
|
"and live as of build 4.11.659.**\n\n"
|
|
"Settled from the binary rather than from argument, as this issue asked. The 4.10 code "
|
|
"carries a complete gimp gait layer, not a hint of one:\n"
|
|
"- A dedicated body-animation driver for the damaged gait (`AdvanceBodyAnimationGimp`) "
|
|
"alongside the healthy one.\n"
|
|
"- Dedicated animation states: the `gg` and `gs` gimp cycles (24/25 and 26/27) plus "
|
|
"GimpToStand transitions (22/23) -- a whole state family that exists for nothing else.\n"
|
|
"- Its own leg driver path, distinct from the healthy leg channel.\n\n"
|
|
"**So both parties were partly right, along the lines this issue predicted.** A limp "
|
|
"mode is authentically in 4.10 (VGL Lynx's videos are 4.x behaviour, not Firestorm). "
|
|
"What SAURON is describing -- leg gone = mech gone -- is the destruction threshold, not "
|
|
"evidence against a damaged-leg limp.\n\n"
|
|
"**Field-confirmed 2026-07-30** on 4.11.659, from every viewpoint: Oracle -- \"gimp is "
|
|
"OK\"; operator saw the limp from every mech's POV in a 4-node arena test. Peer-side "
|
|
"correctness took two more fixes after the gait itself (#82).\n\n"
|
|
"Full write-up: `context/locomotion.md` (gimp gait + the peer body-channel trn-lock).\n\n"
|
|
"Related: #82 (peers saw the limper skating -- fixed), #75 (myomer damage -> speed, the "
|
|
"other consumer of the same mover feed, still blocked on the WAVE 6 cutover).")
|
|
|
|
# ---------------------------------------------------------------- NOTE #82
|
|
gitea.comment(82, HDR +
|
|
"**Field-confirmed fixed.** Oracle: \"gimp is OK\". The operator additionally confirmed "
|
|
"the limp reads correctly from every mech's POV in a 4-node arena test before the build "
|
|
"shipped.\n\n"
|
|
"Note for anyone reading this later: a mech was seen **skating** tonight, but with a "
|
|
"different trigger -- RajelAran's Sunder started skating immediately after being rammed "
|
|
"and recovered when it stopped. That is the older #52 ski (gait desync), not this limp "
|
|
"bug; commented there.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #52
|
|
gitea.comment(52, HDR +
|
|
"**Still live in 4.11.659 -- and tonight it came with a sharp, reproducible trigger: a "
|
|
"mech-to-mech COLLISION.**\n\n"
|
|
"Oracle's written notes (item 8):\n"
|
|
"> When the two mechs initially collided, Sunder started skating and resumed normal "
|
|
"animation after coming to a stop.\n\n"
|
|
"RajelAran, live, immediately after the same event: \"I started skating right after "
|
|
"that\".\n\n"
|
|
"That matches this issue's original signature exactly -- slides without walking, "
|
|
"self-heals when the subject stops and the gait state machine re-enters -- but the "
|
|
"earlier reports had no known trigger. A collision gives us one to drive on a bench.\n\n"
|
|
"**This is NOT #82.** #82 was the peer body-channel trn-lock (a limping mech shown "
|
|
"gliding with turn-steps); that is fixed and confirmed tonight. This is the older ski, "
|
|
"on an undamaged mech, caused by an impact.\n\n"
|
|
"**Repro lead:** two nodes, drive one into the other under `BT_AUTODRIVE`, observe from "
|
|
"the third. Build 659 changed collision handling (`9c83a46` self-damage / `14ff351` the "
|
|
"collision divert), so check whether the impact path now interrupts the gait feed -- and "
|
|
"whether the same impact is what put the OTHER mech into the wreck graphic (**#94**, "
|
|
"same collision, same second).\n\n"
|
|
"**RajelAran has video of this event** -- worth collecting before it ages out.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #47
|
|
gitea.comment(47, HDR +
|
|
"**Half of this looks satisfied, half does not -- narrowing it.**\n\n"
|
|
"**Bay-fire alarm: appears OK now.** Oracle: \"ammo bay fire and alarm seems OK / and I "
|
|
"go boom when I failed to eject\" (the lethality half closed #46).\n\n"
|
|
"**Jam annunciation: still missing.** Oracle's written notes, item 10:\n"
|
|
"> Possible, need to test further - Observed ammo jams on Avatar AFC50 but no flashing "
|
|
"red indicator, weapon resumed working after clearing jam.\n\n"
|
|
"So on a jam the ENG-page button still does not flash to draw the pilot's eye -- the "
|
|
"original complaint from Cyd and RajelAran, unchanged.\n\n"
|
|
"Two follow-ups for the next session:\n"
|
|
"1. Confirm whether the **bay-fire icon** beside the ammo counter now appears (Oracle "
|
|
"reported the alarm, not the icon).\n"
|
|
"2. \"weapon resumed working after clearing jam\" is worth a look against #30 -- a jam is "
|
|
"documented as mission-permanent per the binary (clears only on ResetToInitialState / "
|
|
"respawn). Either the Avatar's AFC50 hit a different state than a true jam, or the jam "
|
|
"clear is too lenient.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #19
|
|
gitea.comment(19, HDR +
|
|
"**Partial positive evidence -- seek select looks functional in 4.11.659, but not yet a "
|
|
"clean confirm.**\n\n"
|
|
"Oracle, describing the myomers: \"definitely not generating heat on myomers **I have "
|
|
"them at seek 4**\" -- i.e. he set and held a seek level. He also reported the engineering "
|
|
"side responding: \"loop prioritization is working too / I can see the response of the "
|
|
"loops and the sub-systems\".\n\n"
|
|
"**Not enough to close**, because this issue is specifically about **ADV control mode at "
|
|
"expert experience**, and we do not know Oracle's control mode / experience for that "
|
|
"round -- and #2 (the egg `experience` field is parsed but never applied, so everyone "
|
|
"runs VETERAN) may still be masking the expert gate either way.\n\n"
|
|
"**To close this:** one round at expert + ADV, step seek on BOTH myomers and a weapon "
|
|
"emitter, and confirm the lamp/step moves. Ask Oracle -- he reads the eng page closely.\n\n"
|
|
"Related: #85 (myomers produce no heat at seek 4 -- the seek setting is reaching the "
|
|
"display but may not be reaching the heat model), #2.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #30
|
|
gitea.comment(30, HDR +
|
|
"**The enforcement half of this is now its own issue: #86.**\n\n"
|
|
"All three testers confirmed that a **destroyed** weapon keeps firing and scoring -- limb "
|
|
"visibly gone, X drawn on the MFD, launcher still launching, and peers see the phantom "
|
|
"shots. Oracle: \"When limbs or weapons (missile launchers) are visibly destroyed the "
|
|
"weapons continue to function and score damage (score increases)\"; RajelAran: "
|
|
"\"destroyed weapons do seem to cycle still\".\n\n"
|
|
"So the split is:\n"
|
|
"- **this issue (#30)** -- the weaponAlarm level-5/7 *presentation* (a dead launcher "
|
|
"looks identical to a healthy idle one)\n"
|
|
"- **#86** -- the *enforcement* (level 7 / mount destroyed must veto fire, recharge and "
|
|
"ammo draw)\n\n"
|
|
"Worth fixing together: the level-7 state is evidently being reached (the X draws), so "
|
|
"both halves are consumers of the same state.\n\n"
|
|
"Also from tonight, relevant to the jam machinery here: an Avatar AFC50 jam **cleared "
|
|
"mid-round** without a respawn (Oracle, notes item 10), which contradicts the "
|
|
"mission-permanent jam documented above. See #47.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #45
|
|
gitea.comment(45, HDR +
|
|
"**Status check -- the fix shipped, but nobody explicitly re-verified tonight, so leaving "
|
|
"this open.**\n\n"
|
|
"The kill-attribution / death-tally replication work shipped in 4.11.659 alongside the "
|
|
"#81 respawn fix (bench-verified: 4 nodes, 56 overlapping death cycles, DEATHS tallies "
|
|
"matching across machines).\n\n"
|
|
"From tonight's three-player session: **no K/D complaint from anyone**, against an "
|
|
"original report where three players raised it independently within one night. The only "
|
|
"score-related remark was Oracle noting his score DID increase when firing his "
|
|
"(destroyed) weapons -- see #86.\n\n"
|
|
"Silence is weak evidence. **To close:** one round where two players cross-check the "
|
|
"KILLS/DEATHS rows against what actually happened, on both machines."
|
|
)
|
|
|
|
# ---------------------------------------------------------------- NOTE #80
|
|
gitea.comment(80, HDR +
|
|
"**Correction to a baseline assumption in this issue.**\n\n"
|
|
"The body states, as the known-good baseline: \"the paper doll (Damage view) shows "
|
|
"per-ZONE armor tint\", and builds the three-layer analysis on top of that being "
|
|
"already-working.\n\n"
|
|
"Three testers report otherwise tonight. SAURON: \"no damage displaying on enemy mech "
|
|
"panels that have been damaged / looks 100% fresh on all panels\". Oracle: \"I'm not "
|
|
"seeing darkening panels due to damage\" and \"also not seeing panels darken from damage "
|
|
"/ even when red/flashing red\".\n\n"
|
|
"Filed as **#87**. Verify which is true before relying on the armor-tint layer here -- if "
|
|
"the doll is NOT tinting, then \"doll shows damage, crit panel shows nothing\" is not the "
|
|
"expected state and part of this issue's framing needs rewriting.")
|
|
|
|
# ---------------------------------------------------------------- NOTE #75
|
|
gitea.comment(75, HDR +
|
|
"Adjacent report from a new tester: **the myomers also produce no HEAT** -- \"definitely "
|
|
"not generating heat on myomers I have them at seek 4 / they remain ice cold\" (Oracle, "
|
|
"confirmed against the engineering panel). Filed as **#85**.\n\n"
|
|
"Same class as this issue: the Myomers subsystem is wired to the display but not to the "
|
|
"systems that should consume it. This one is speed (blocked on the WAVE 6 mover "
|
|
"cutover); #85 is heat, which should NOT be blocked on WAVE 6 -- the heat generation term "
|
|
"feeds the heat family, not the mover roster, so it can likely be fixed independently.")
|