diff --git a/scratchpad/night14/housekeep14.py b/scratchpad/night14/housekeep14.py new file mode 100644 index 0000000..3be32c4 --- /dev/null +++ b/scratchpad/night14/housekeep14.py @@ -0,0 +1,299 @@ +"""Night 14 (build 4.11.857) housekeeping: close what the field confirmed, reopen +#137 with evidence, and file the new reports. ASCII only.""" +import sys +sys.path.insert(0, r"C:\git\bt411\scratchpad\night7") +import gitea + +FIELD = ("Field-verified on **4.11.857** (playtest 2026-08-08, 4 testers: Oracle/SCREECH, " + "Sauron/XIAOLONG, santo/MS-FIREFLY, RajelAran/GAMERSLAB).") + +# ---------------------------------------------------------------- CLOSE ---- +CLOSE = { + 52: "**CONFIRMED FIXED.** " + FIELD + "\n\nOracle: *\"no skating observed\"*.\n\n" + "Cross-check: the `[skate]` detector fires zero times across all four logs.\n\n" + "**#130 (Vulture skating) should be re-tested against this build** -- it was always " + "suspected to be the same defect.", + 108: "**CONFIRMED FIXED.** " + FIELD + "\n\nOracle: *\"Lynx panic ejected and didn't ghost\"*.\n\n" + "The eject path now runs the full death tail, so the respawn trigger fires.", + 142: "**CONFIRMED FIXED.** " + FIELD + "\n\nOracle: *\"Fixed, button indicating state and mech " + "is standing after respawn\"* -- both halves: the indicator animates, and the " + "`Mech::Reset` posture clear brings you back standing.", + 140: "**CONFIRMED FIXED.** " + FIELD + "\n\nOracle: *\"It is not overwriting the saved settings\"*.", + 141: "**CONFIRMED FIXED.** " + FIELD + "\n\nOracle: *\"Fixed\"*. VGL Lynx, independently and " + "before seeing the notes: *\"Missiles seem to be launching from weapon ports\"* -- which is " + "the symptom stated positively.\n\n" + "Worth noting the same stale-segment-cache defect was fixed on the **beam muzzle** path in " + "the same sweep; nobody had reported that one, and a peer's beams would have had the " + "identical wrong origin whenever the shooter was twisted.", +} + +# --------------------------------------------------------------- COMMENT ---- +COMMENT = { + 147: "**Not reproduced on 4.11.857** -- Oracle: *\"I have been unable to recreate the range caret " + "issue today ... but only tried in Solo\"*, and later *\"Not observed\"*.\n\n" + "Cross-check: zero `NaN TRAPPED` receipts in any of the four field logs, so the trap never " + "had to fire either.\n\n" + "**Keeping this OPEN.** One clean night is not proof for a defect whose whole signature is " + "'rare, and sticky once it happens' -- and solo exercises far less of the targeting path " + "than a 4-way drop. If the caret dies again, `BT_RANGE_LOG=1` now names the frame.", + 146: "**Working on 4.11.857, with a nuance worth recording.** Oracle: *\"Initial spawn/respawn " + "throttle is idle and then begins to respond to match my throttle position on my X56 " + "without moving it.\"* That is the fix behaving correctly on a PHYSICAL throttle: the " + "virtual lever is released at respawn, then re-syncs to where the hardware lever actually " + "sits.\n\n" + "**But see the new report about being unable to move after respawn until the throttle is " + "cycled.** A HOTAS user who respawns with the lever already forward now gets no motion " + "until the axis next changes -- that may be this fix's side effect rather than a separate " + "bug, and the two need separating before either is 'fixed'.", + 135: "**Related field report on 4.11.857** (Oracle): *\"buttons for gens are not flashing when " + "they leak\"* -- observed in GLASS mode this time, where this ticket was originally about " + "the normal (non-glass) screen path. Same annunciator chain, so treat them together: the " + "coolant-leak condition (cond 2) is supposed to light the per-generator lamps.", +} + +# ------------------------------------------------------------------ NEW ---- +NEW = [ + ("REOPEN #137 -- placeholder", None), # handled separately below +] + +def main(): + for num, body in CLOSE.items(): + gitea.close(num, body) + for num, body in COMMENT.items(): + gitea.comment(num, body) + + # ---- #137: reopen. I closed this wrongly; the field disproved my analysis. + gitea.comment(137, + "**REOPENING -- I closed this incorrectly, and the field data disproves my analysis.**\n\n" + "I closed it as 'not a bug: the mech respawns still under throttle and earns the heat " + "honestly'. Oracle pushed back: *\"not sure if the bug report was understood ... the mech " + "is initially unable to move until it cools off sufficiently to start moving. This is " + "abnormal.\"* He is right, and 'unable to move' is the detail that kills my explanation -- " + "a mech that cannot move cannot be earning heat by running.\n\n" + "## Measured on 4.11.857, all four field logs\n\n" + "Scanning every respawn for the freeze signature (throttle up, speedDemand pinned at 0):\n\n" + "| player | respawns | FROZE |\n|---|---|---|\n" + "| Oracle / SCREECH | 16 | **2** |\n| Sauron / XIAOLONG | 19 | **2** |\n" + "| RajelAran / GAMERSLAB | 16 | **1** |\n| santo / MS-FIREFLY | 10 | 0 |\n\n" + "**5 of 61 respawns (~8%)**, across three independent machines.\n\n" + "The sequence at one of them (Oracle, log line 48584) is unambiguous:\n\n" + "```\n" + "[mppr] thr=0.847 -> speedDemand=44.87 <- moving normally, pre-death\n" + "[respawn] Mech::Reset 2:21 healed+moved\n" + "[techstat] Myomers condition 1 CLEARED <- Damaged cleared OK\n" + "[techstat] Myomers condition 2 CLEARED <- Leaking cleared OK\n" + "[techstat] Myomers condition 3 SET <- OVERHEATING, AT the reset\n" + "[mppr] thr=0.762 -> speedDemand=0 <- FROZEN\n" + "```\n\n" + "The reset clears the damage and leak flags correctly and then the myomers come up " + "**already overheating**, in the same breath as the reset -- before any running could have " + "happened. The myomer heat-freeze (`speedEffect` -> `speedDemand *= it`) then pins speed " + "at zero, which is exactly the reported 'cannot move until it cools'.\n\n" + "## Why my bench missed it\n\n" + "It is **intermittent (~8%)**. My synthetic bench reset cleanly every single time and " + "reported `T=77 start=77` for every heat-bearing subsystem including all six Condensers -- " + "so I concluded the reset path was correct and closed the ticket. A bench that never " + "reproduces the failure is not evidence the failure does not exist; I treated it as such.\n\n" + "## Next\n\n" + "The temperature is NOT logged in the field (`BT_HEAT_LOG` is off), so the next step is a " + "bench that reproduces the freeze rather than the happy path -- repeated death/respawn " + "under load until a reset lands hot -- and then reads `[heat-reset]` on the failing one. " + "The ~8% rate suggests a race or an ordering dependency rather than a plain missing reset, " + "since the plain path demonstrably works.") + gitea.call("/issues/137", method="PATCH", payload={"state": "open"}) + print("REOPENED #137") + + made = [] + def new(title, body, ): + i = gitea.create(title, body) + made.append(i["number"]) + + new("PERFORMANCE REGRESSION 817 -> 857: hard stalls at mission load (glass)", + "Oracle: *\"frame rate very poor with glass cockpit starting with this build. Only " + "observed by Oracle, Sauron using glass had no issue. Oracle had no performance issues in " + "past with glass.\"*\n\n" + "**Confirmed, and it is a real regression -- but it is STUTTER, not low framerate.**\n\n" + "## Same machine, previous build vs this one (Oracle / SCREECH)\n\n" + "| build | median frame | stalls >50ms | worst |\n|---|---|---|---|\n" + "| 4.11.817 (Aug 6) | 5.79 ms | **0** (0.00%) | 15.4 ms |\n" + "| 4.11.857 (Aug 8) | 5.87 ms | **97** (6.70%) | 103.7 ms |\n\n" + "His steady state is **identical** (5.79 -> 5.87 ms). 817 had literally zero stalls; 857 " + "has 97, and the worst frame went 15 ms -> 104 ms.\n\n" + "## Why only Oracle noticed\n\n" + "| player | median | stalls >50ms |\n|---|---|---|\n" + "| Oracle | 5.87 ms (170 fps) | 97 |\n| santo | 3.55 ms | 0 |\n" + "| Sauron | 12.53 ms (80 fps) | 0 |\n| RajelAran | 6.70 ms | 0 |\n\n" + "Oracle has the **best median of the group** and Sauron -- who reported no problem -- has " + "the worst. Smooth-but-slower reads as fine; fast-with-hitches reads as broken. The " + "distribution is bimodal: **all 97 of Oracle's slow blocks are >50 ms**, nothing in " + "between.\n\n" + "## Where\n\n" + "All 97 stalls are one contiguous window (log lines 30307-32979, 30-32% through the " + "session), and it begins exactly at **mission load**, as peer mechs stream in:\n\n" + "```\n" + "[clipfix] mech 15A1FF38 -> EXTERIOR (lean)\n" + "[loadclips] end: fScale=0.8 ...\n" + "[spike] dt=0.356 turn=0 thr=0\n" + "[rstat] frames=10 avg=103.713ms maxDraw=518.497 maxPresent=7.046 batches=547 culled=226\n" + "```\n\n" + "`maxDraw=518ms` against `maxPresent=7ms` -- it is **draw time**, not vsync/present.\n\n" + "## NOT the instrumentation\n\n" + "The standing theory was that accumulated logging is slowing things down. The data says " + "no: the **median frame time is unchanged between builds** (5.79 -> 5.87 ms) and log " + "volumes are comparable across players (6.1-6.9 MB). Logging would raise the floor " + "everywhere, not add isolated 100 ms draw spikes in one window.\n\n" + "## Prime suspect\n\n" + "The #141 stale-segment-cache fix in this same build. It routes muzzle/beam queries " + "through `JointedMover::GetSegmentToWorld`, which -- when joints are modified, i.e. every " + "animating frame -- walks the whole segment table and marks every segment dirty, forcing " + "the hierarchy to re-derive. That is now on per-frame paths (`BTResolveWeaponMuzzle`, and " + "the energy-beam gun-port loop which runs per weapon per mech per frame). With several " + "mechs newly loaded it multiplies out. Faithful to the binary, but the binary was not " + "calling it this often.\n\n" + "**Next:** time `GetSegmentToWorld` per frame and count calls per mech; if it is the " + "cause, cache the resolved frame per (mech, segment) for the duration of a frame rather " + "than re-deriving per weapon.") + + new("Double KILL credit: one kill counted twice", + "Two independent reports on 4.11.857:\n\n" + "* RajelAran: *\"in match beginning 20:33, I got a double kill on Oracle. One kill, " + "counted twice\"*\n" + "* Oracle: *\"12:12AM ET - Oracle killed Conn Man and got 2 kills credited. Rajel also " + "the same when killing me.\"*\n\n" + "Log cross-check (Oracle/SCREECH): the scoreboard `kills=` reading jumps **2 -> 4**, " + "skipping 3.\n\n" + "## Suspect (identified 2026-08-07, never fixed)\n\n" + "In the type-2 (Kill) arm of the score handler:\n\n" + "```c\n" + "++killCount; // this player\n" + "if (sender_owner) ++sender_owner->killCount; // the mech named by senderMechID\n" + "```\n\n" + "For type 2, `senderMechID` is the **victim**. The second increment is justified in the " + "comment by the SOLO case, where the dummy target has no owning player -- but in MP the " + "victim *does* have an owner, so the credit lands twice. In a 1v1 exchange both " + "increments can even land on the same scoreboard row, which is what 'one kill counted " + "twice' looks like.\n\n" + "Needs a 2-node bench confirming the victim's `killCount` moves on a kill.") + + new("PANIC eject scores -499 instead of 0 (double-charged)", + "Oracle, 4.11.857, **confirmed twice**: *\"Had 1000 points, leaked out all coolant, hit " + "'panic' and ended up with -499 points. Should it have been zero points because " + "1000 - 1000 = 0 for ejecting? Why the extra -499 points?\"*\n\n" + "The shipped `Role::Default` carries `deathPenalty=500`, and the death tail applies " + "`-specialCaseDeathPenalty`. 1000 - 500 = 500, so -499 is roughly **1000 - 500 - 999**, " + "i.e. the penalty looks like it is being applied more than once, or the eject path " + "charges both the normal death cost and a separate panic cost.\n\n" + "Note this is the tail of **#134** (panic eject carried NO score penalty) -- that fix " + "landed and now over-charges. The two should be read together.\n\n" + "Also from the same report, lower confidence / subjective: *\"Missiles seem to be scoring " + "a little low (twin LRM15s scored ~30-40 points)\"* -- worth a damage-vs-score comparison " + "rather than a code change on its own.") + + new("REGRESSION: torso no longer auto-recentres in ANY control mode", + "Oracle, 4.11.857: *\"Torso is no longer recentering on its own in any mode " + "Bas/Mid/Adv.\"*\n\n" + "**This is a regression from the control-mode fix in this build.** That change replaced " + "the Basic-mode re-centre write from `centerCommand` (@0x208, the HELD-button cell that " + "nothing released -- the bug where the centering *fought* the pilot) with " + "`recenterActive` (@0x274), a ONE-SHOT that self-clears on settle, matching @004afbe0.\n\n" + "The one-shot is what the binary does on the mode CHANGE. What it does not do is provide " + "the CONTINUOUS auto-centring that Basic mode is supposed to have per the 1995 manual " + "(BAS = joystick turns the mech, **no torso twist**). So the fix removed a behaviour that " + "was previously coming -- incorrectly, but coming -- from the stuck cell.\n\n" + "Both halves need to be true at once: Basic must hold the torso centred, without the " + "held-cell latch that made it fight the stick in Standard/Veteran.\n\n" + "The original complaint (Sauron: cycling to advanced and back made the centering fight " + "the controls) is fixed and should stay fixed -- verify any change against both.") + + new("Basic-mode elevation limit does not clamp the CURRENT view", + "Oracle, 4.11.857: *\"Basic mode does limit downward view to 'half', but only after " + "cycling off 'Basic' and then back to 'Basic'. If in Mid or Advanced and move view past " + "'half' down and then switch to Basic, nothing happens until I move the control stick in " + "the pitch axis and then the view immediately snaps up to 'half' limit.\"*\n\n" + "The elevation-limit swap (Basic gets @0x228/@0x22C = full top, HALF bottom; " + "Standard/Veteran get @0x230/@0x234) is new in this build and previously was never " + "implemented at all. It writes the LIMITS but does not re-clamp `currentElevation`, so an " + "already-out-of-range view stays until the next pitch input clamps it.\n\n" + "Small fix: clamp current elevation into the new pair at the moment of the swap. Worth " + "checking against the binary whether it clamps on switch or leaves it to the sim -- the " + "snap-on-next-input behaviour may be authentic.\n\n" + "Also: Oracle asked what 'settles the HUD horizon' meant in the release note -- that was " + "my wording for Basic raising the HUD's `flickerActive` (@0x2A0) so the horizon " + "re-settles with the re-centred torso. Needs a plainer description for testers.") + + new("Overheated generator never came back online; no generator-out alarm on thermal trip", + "Oracle, 4.11.857: *\"Noticed a generator that overheated never came back online even " + "after cooling off completely. Also noticed the generator out message doesn't sound after " + "a generator fails due to overheat. The second and third time I overheated a generator " + "for the test it did come back online after cooling halfway, and I heard the generator " + "out warning upon the generator coming back online.\"*\n\n" + "Two defects, and the intermittency is the interesting part -- the same test gave a stuck " + "generator once and a recovering one twice.\n\n" + "1. **Stuck offline after thermal trip.** The thermal breaker in `GeneratorSimulation` " + "produces `stateAlarm 4` (GeneratorOut); recovery should re-arm once temperature falls. " + "Related known nuance (context/decomp-reference.md): the generator sim has NO Ready-case " + "recompute, so a generator can hold stale state until *some* transition recomputes it.\n" + "2. **Alarm timing.** The generator-out warning did not sound on the trip, but DID sound " + "later on the way back online -- so the annunciator appears tied to the wrong edge.\n\n" + "Cross-check available: `[techstat] GeneratorX condition 3` (Overheating) transitions are " + "in the field logs and are balanced overall, so this is about the stateAlarm/voltage path " + "rather than the heat flag.") + + new("PANIC lamp lit: rapid flicker, and engineering + weapon MFD buttons stop responding", + "Oracle, 4.11.857: *\"When the panic button lights it flickers very rapidly and the " + "engineering and weapon MFDs buttons stop responding. Other MFDs continue to respond to " + "button presses (using mouse). I also have mapped controls on my HOTAS for some of those " + "MFD buttons and they also stop working when the panic button is lit. Radar, Scoring and " + "coolant MFDs keep working.\"*\n\n" + "Two symptoms, probably one cause. Arming eject raises the panic-armed mode " + "**0x200000**, which drives the physical PANIC lamp (`MakeLinkedLamp`), the eject-mode " + "gauge elements, **and keypad routing** -- so eng/weapon buttons going dead while radar/" + "scoring/coolant keep working is consistent with the eject mode capturing exactly those " + "banks. That part may well be AUTHENTIC (the pod wants your hand on the eject decision, " + "not the weapon page).\n\n" + "The **rapid flicker is not** authentic: per the decode, the panic lamp is SOLID on arm " + "(engine linked-lamp semantic); FLASH is the GaugeAlarm `SetAlertState` overlay, which is " + "not authored for panic. A flickering panic lamp suggests the arm state is oscillating -- " + "and if it is oscillating, the keypad routing is being torn down and rebuilt repeatedly, " + "which would also explain buttons that 'stop responding' rather than cleanly switching.\n\n" + "Check `EvaluateEjectPermission` for a condition that chatters at the threshold " + "(coolantFrac < 0.05 is a likely candidate while coolant is draining).") + + new("Fade-to-black at mission end is not happening", + "Oracle, 4.11.857: *\"Fade to black effect when mission ends is not happening\"*.\n\n" + "No log signature to cross-check against -- filing on the report. Worth confirming " + "whether this ever worked in a recent build or has been absent for a while.") + + new("Crash at drop end (~23:59 ET, MS-FIREFLY / santo)", + "Conn Man / santo, 4.11.857: *\"Did not exit cleanly\"*, and Oracle: *\"Conn Man crashed " + "when drop ended ~11:59PM ET\"*.\n\n" + "`lastrun_steam.txt` is staged with the field logs. The launch bracketing shows the " + "process reaching WinMain normally, so this is a crash at teardown rather than a blocked " + "launch.\n\n" + "Teardown crashes have bitten this project before (the P5 teardown path). Needs the log " + "tail read against the mission-end sequence; the field log for that machine is staged as " + "`scratchpad/night14/steam_20260808_b_santo_MSFIREFLY.log`.\n\n" + "Also reported for the same player: *\"Conn Man was lagging sometimes during drops and " + "that caused the effect of missiles or direct fire exploding/hitting empty space\"* -- " + "likely a separate networking symptom, noted here only so the two are not conflated.") + + new("Cannot move after respawn until the throttle is cycled (Abandoned Arena)", + "Sauron, 4.11.857: *\"respawned several times in Abandoned Arena and couldn't move until " + "throttle down/up or reversing out. Was near map edge and structure.\"*\n\n" + "**Two candidate causes, and they must be separated before either is called fixed:**\n\n" + "1. **A side effect of the #146 throttle fix in this build.** The virtual lever is now " + "released at respawn; a pilot whose PHYSICAL throttle is already forward gets no motion " + "until the axis next changes -- i.e. exactly 'couldn't move until throttle down/up'. " + "Oracle described the same mechanic positively (*\"throttle is idle and then begins to " + "respond to match my throttle position\"*), so the behaviour is real; the question is " + "whether it should re-sync immediately instead of on next change.\n" + "2. **Geometry.** 'Near map edge and structure' suggests spawning into or against " + "collision, which would also read as being stuck.\n\n" + "Note this is NOT the same as #137: there the mech is frozen by myomer heat with the " + "throttle up, and cycling the throttle does not help. Here cycling the throttle DOES " + "free it. The two will look identical to a player, so keep the distinguishing test in " + "mind: does throttle-cycling free it (this) or not (#137)?") + + print("created:", made) + +main()