Joe DiPrimaandClaude Fable 5
546aabd5ba
Night-12 field report (Ronin/Conn Man/Oracle, blackhawk-correlated): lock ring lit with the reticle visibly off the mech + no-reg complaints. Root cause: TWO port stand-ins answered where the 1995 card (which cast against the DRAWN geometry) would miss -- the pick's any-object sphere fallback and the caller's whole-mech AABB fallback. The regime that exposes them: a LEVEL boresight over a SHORT mech -- the blackhawk's mesh tops out below eye-ray height, so the ray clears every triangle but pierces the fat cull spheres; the ring lights with the reticle above the mech's head (the operator watched exactly this on the sweep bench). Careful aimed-down fire rides triangles, which is why Oracle's per-panel audit passed on the same build. Fix: MechSegmentPick returns 1=drawn-geometry hit / 0=TRUE MISS / -1=no render tree; the sphere may answer ONLY for a mesh the reader cannot parse (pm==0 -- currently none exist: counters objs/invFail/noTri all clean); the AABB survives ONLY as the pre-tree replicant grace. A readable mesh the ray misses is a MISS -- no lock. Verified (2-node vs bhk1 at 100u, all runs on force-relinked string- verified exes after today's stale-link flake): - LEVEL lock-sweep: 0 locks all run (pre-fix: lock band from 168 sphere answers; picksrc tri=0 sphereFB=168). - DOWN-PITCHED sweep: locks return 100%% tri-sourced (tri=158 sphereFB=0), landing on real parts (rarm/ldleg/rdleg) with honest gaps. - Full zone-walk matrix: tri=18874 sphereFB=0 box=0; victim took 156 hits across 16 zones incl. both side torsos -- combat un-regressed. New instruments (all env-gated): BT_LOCK_SWEEP=<axis> torso pan (the operator-visible lock-envelope bench), [locksweep] transition log, BT_LOCK_ENVELOPE synthetic unit-sweep probe, [picksrc]/[pickbox] source telemetry with objs/invFail/noTri localization counters. Bench: scratchpad/night12/zonewalk_bhk.sh. NOTE for the field: locking is now strictly TIGHTER (ring = reticle truly on the machine). If era testers feel the pods were more forgiving, Draco's "slight lock linger" memory becomes a deliberate investigation (sourced hysteresis), not an accidental sphere halo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
93 lines
11 KiB
Python
93 lines
11 KiB
Python
import sys
|
|
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
|
|
import gitea
|
|
|
|
new_ids = {}
|
|
|
|
# ---------- NEW ISSUES ----------
|
|
i = gitea.create(
|
|
"Reticle shows LOCK with no mech under it + no-reg with reticle ON mech -- multiple testers, stationary targets; BLACKHAWK-correlated (774)",
|
|
"""Source: playtest night 12 (2026-08-04, build **4.11.774 (8b887f6)**), Discord #play-testing.
|
|
|
|
Ronin (screenshots x2): "Showing lock without actually having reticle on mech" and the inverse "Reticle on mech, but no reg". Multiple testers reproduced on STATIONARY mechs. Conn Man: two more screenshots of an active reticle while not on the target. Oracle's correlation: "the blackhawk side torso panels are really weird ... It was the only one where several observed and reported the weird locking off the mech."
|
|
|
|
Draco's era memory (evidence, not confirmed): "I recall a slight delay that lock would stay as you moved crosshairs off" -- possible authentic lock-linger. Ronin's counter: multiple testers, stationary mechs, and BOTH directions (false lock off-mech AND no-reg on-mech), so linger alone does not explain it.
|
|
|
|
**Investigation leads [T4, flagged]:** 774 changed the pick twice (08-03 triangle-accurate + 08-04 patch-zone attribution). (a) The SPHERE FALLBACK still answers when the ray misses every triangle -- a ray that pierces cull spheres but no mesh returns a hit with a zone = "lock off-mech". (b) BTGetPickMesh returns NO TRIS for objects whose VB layout it cannot read -- those segments are invisible to the triangle pass and fall to spheres; if the BLACKHAWK's meshes trip this, both symptoms concentrate there ("no reg" on-mesh where tris are missing + sphere lock off-mesh). [picktri]/BT_PICK_LOG logs the NO TRIS case. (c) What drives the LOCK UI (PipColor/TargetWithinRange attrs) vs the pick designation -- they may disagree.
|
|
|
|
Field logs from the night are staged (scratchpad/night12/, 3 players). First step: bench a blackhawk target with BT_PICK_LOG and count NO TRIS + sphere-fallback picks.""",
|
|
labels=[1,2])
|
|
new_ids['reticle'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Persistent YELLOW LINE on the HUD in every mech (Conn Man, 774)",
|
|
"""Playtest night 12 (774). Conn Man: "I also have a yellow line on my HUD that was in every mech I piloted tonight" (screenshots in Discord). Machine MS-FIREFLY (user santo); his log is staged in scratchpad/night12/. Not reported by other testers so far -- may be layout/aspect specific.""",
|
|
labels=[1,4])
|
|
new_ids['yellowline'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Do generators X out on the MFD when shut down / overheated? (era-behavior question)",
|
|
"""Oracle, night 12: "I don't think they are X'ing out when overheated / when shutting down / can't remember if they only X out when destroyed." Operator does not know the proper behavior either. Needs grounding: the manual + the gauge stream (engineering panel X-out overlay conditions -- destroyed only, or also offline/thermal-breaker states?). Pure authenticity question before any code is touched.""",
|
|
labels=[2,4])
|
|
new_ids['genx'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Panic eject carries NO score penalty (774) -- death-without-honor cost not observed",
|
|
"""Oracle, night 12, twice: "my score did not go negative" / "Panic test - It worked but there is no penalty on the score." The #118 tail shipped a death score cost + the DeathWithoutHonor console notice (1efe8ef); the notice ("dunce cap") IS confirmed working, the SCORE COST is not observed. Candidates: the cost never applies, applies to a different counter, or the scoreboard clamps at zero and Oracle was at 0. Check the cost path vs the score attribute the KILLS panel reads, then bench a panic with a positive score.""",
|
|
labels=[1])
|
|
new_ids['penalty'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Coolant leak with NO flashing annunciators -- normal (non-glass) screen mode (RajelAran, 774)",
|
|
"""RajelAran, night 12: "Had a coolant leak with no flashing at the end of the last match. I'm running in normal screen mode, NOT glass." His log is staged (scratchpad/night12/, GAMERSLAB). Distinct from the glass-window throttling item (that one is glass-specific and root-caused); this is the docked/normal layout. Compare his log's [techstat]/lamp lines around the leak window.""",
|
|
labels=[1,4])
|
|
new_ids['leaklamp'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Leaking loop responds to COMPONENT coolant toggles while the loop is SHUT -- leak/alarm stops and restarts with component toggle (774)",
|
|
"""RajelAran, night 12: "toggling off components on a leaking loop after shutting off the loop would shut off the leak and alarm, and toggling the components back on would cause the loop to start leaking again even when shut. No leak indicators were present on the components. Not clear whether effects were coincidental, will try to replicate tomorrow." Awaiting his repro; when it lands, bench with the valve/heat-family logs. May be authentic plumbing (component flow draws through a shut loop?) -- ground in the heat-family decomp before calling it a bug.""",
|
|
labels=[2])
|
|
new_ids['leaktoggle'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Respawn came back with MYOMERS heat MAXED, dumping into coolant loop 5 (Oracle, 774)",
|
|
"""Oracle, night 12, final drop: "I had a respawn where my myomers started overheated (maxed) and dumped all their heat into the cool loop 5 which then became moderately warm." One occurrence. The respawn-reset audit (RESPAWN_REARM_PLAN addendum) verified valves/coolant/gen resets, and the heat family has DeathReset coverage since #55 -- so either the myomer heat member misses the reset chain, or the heat arrived post-spawn (gimp/overdrive in the drop). Check the myomer RTIS body vs the binary and Oracle's staged log at the respawn timestamp.""",
|
|
labels=[1,2])
|
|
new_ids['myoheat'] = i['number']
|
|
|
|
i = gitea.create(
|
|
"Glass panels: Windows throttles unfocused windows' repaint timer -- buttons flash at 0.166 Hz unless a window is dragged (Cyd fixing)",
|
|
"""Oracle, night 12: "Buttons still flash at .166 Hz in glass cockpit. Flash at normal rate if I drag a window" + earlier "all buttons flash at correct rate if I drag a window." Cyd root-caused same night: "windows deprioritizing non-focused windows, fixing..." -- the 62ms WM_TIMER repaint in the per-display glass windows gets throttled by Windows for unfocused windows, so the wall-clock flash animation only samples ~every 6s. Cyd has the fix in progress (also adding vPlasma noframe to the .cfg + making the 0x3D panic button red). This issue tracks his branch landing.""",
|
|
labels=[1,4,3])
|
|
new_ids['glassflash'] = i['number']
|
|
|
|
# ---------- CLOSES with receipts ----------
|
|
gitea.close(124, """**FIELD-ACCEPTED -- closing (night 12, 774).** Oracle re-ran the audit: "targetting is super precise right now ... I can move a few pixels over on the panel lines and it detects perfectly on all panels." Full chassis sweep ALL PASS: Thor, Sunder, Madcat, Avatar, Loki, Vulture (incl. searchlight panel), Owens, Blackhawk. The per-panel patch-zone model (the 08-04 correction) is the accepted behavior. Residuals filed separately: the Blackhawk side-torso weirdness + reticle false-lock (#%d), which correlate and get their own dig.""" % new_ids['reticle'])
|
|
|
|
gitea.close(16, "Subsumed by the #124 field acceptance (night 12, 774): per-panel precision verified on all 8 chassis -- the one-band-low signature is gone. Closing.")
|
|
|
|
gitea.close(73, "Closing against the #124 field acceptance (night 12, 774): aimed damage credits the exact panel under the reticle on all chassis (Oracle: 'detects perfectly on all panels'). The original 'aimed at right arm, reported elsewhere' cannot survive that matrix; the weighted-lottery base rate note stands for unaimed weapons.")
|
|
|
|
gitea.close(87, """**FIELD-VERIFIED -- closing (night 12, 774).** Oracle: "armor panels are darkening and smoke is emitting properly ... Darkened panels showing and showing consistently? Yes including smoke of varying intensities being emitted as well from those damaged panels. Working very well." All 8 chassis.""")
|
|
|
|
gitea.close(129, "FIELD-VERIFIED -- closing (night 12, 774). Oracle's checklist: 'Smoking mech on respawn? None observed. Good.'")
|
|
|
|
gitea.close(92, "FIELD-VERIFIED -- closing (night 12, 774). Loki full armor-panel pass ('Avatar and Loki armor are perfect'); the foot zones resolve + take damage per the #124 per-panel matrix and the zone-walk bench receipts earlier on this issue.")
|
|
|
|
gitea.close(91, "FIELD-VERIFIED -- closing (night 12, 774). Oracle: 'thor bowtie worked' -- the pod-plate renders as cockpit structure. Reopen if Ronin (the detailed reporter) sees otherwise on his rig.")
|
|
|
|
gitea.close(55, """FIELD-VERIFIED -- closing (night 12, 774). Oracle: "confirm all coolant loops reset on respawn with panic / and gen assignments remain" + checklist "Valves reset on respawn? Yes. We are hearing the balance coolant loop sound when respawning. Gen assignments and seek levels remain on respawn? Yes." The one respawn-heat anomaly from the night (myomers maxed on spawn) is filed separately (#%d) -- single occurrence, distinct mechanism.""" % new_ids['myoheat'])
|
|
|
|
gitea.close(68, "FIELD-VERIFIED -- closing (night 12, 774). Oracle: 'Someone trying to join with wrong build - Works.' The build-gate rejection is player-visible (message box with both versions) instead of the silent exit this issue reported.")
|
|
|
|
gitea.close(118, """**FIELD-VERIFIED -- closing the core (night 12, 774).** Oracle's checklist: Panic arms + works on ALL THREE authored conditions -- coolant bleed-out, all 4 generators offline, leg-gimp (Novice only). Respawn cycle clean. The DeathWithoutHonor notice ("dunce cap") confirmed working. The one missing tail -- NO SCORE PENALTY observed -- is filed as its own bug (#%d) so this monster can finally close. Operator note from the night: the panic arm reads as a subtle color change, could be more obvious -- Cyd already made the 0x3D button red on his branch.""" % new_ids['penalty'])
|
|
|
|
# ---------- COMMENTS / sightings ----------
|
|
gitea.comment(52, """Night 12 (774) sightings -- skating is BACK (or never fully left): Oracle saw Ronin skating ~9:50 PM ET, RajelAran ~10:15 PM ET, and Sauron in the final drop. Three distinct victims in one night. Field logs staged (scratchpad/night12/, 3 players incl. two of the observers); the new [ghost]/GHOST forensics shipped in this build, so if any skater's replicant was record-starved the logs will say -- if they were receiving records while skating, this is the gait-replication path (#130 family), not starvation.""")
|
|
|
|
gitea.comment(24, "Night 12 (774): RajelAran's hat stuck to the right again -- POV changed views but re-centered back to the right; wiggling the hat several times cleared it. New data: recovery IS possible now (the original report had no recovery), so the stuck state is a latched axis, not a latched mode.")
|
|
|
|
gitea.comment(108, """Night 12 (774) status: the build gate held (a wrong-build join was rejected, visibly) so the version-skew confound is retired in the field. NO ghost-mech report tonight across a full session -- the night's replication anomaly was SKATING (#52, three sightings), which is a different signature (mech moves but slides; a ghost is a dead mech never removed). The [ghost]/GHOST forensics were live in every player's log; staged logs (scratchpad/night12/) get scanned next.""")
|
|
|
|
print("NEW:", new_ids)
|