BT411

697 Commits 3 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Joe DiPrimaandClaude Opus 5	da70bd58b2	#84 : the replicant salvo now HOMES AT THE LIVE TARGET -- the stale-point double detonation is gone Oracle (674): "missile appear to register hit explosions twice, once where target was and again where the target is". Rajel (693): "once where the mech was when I fired and on the expected impact". MECHANISM, measured on two nodes (BT_PROJ_LOG "DET at" now logs EVERY contact detonation, including damage-0 rounds, which were invisible before): the replicant salvo mirror pushed rounds with NO entity handle at the FROZEN fire-time aim point, and the pool's contact test is proximity to p.targetPos -- so mirror rounds "contacted" the empty air where the target USED to be and detonated there, on every peer, every salvo (45 salvos -> 234 frozen-point air bursts in a 200s bench). The true impact appears at the live position (the shooter's own homing rounds on his node; the victim's damage reaction on peers) -- two sites per salvo, exactly as reported. THE BINARY'S MODEL (CLASSMAP, Missile flight-entity cluster): missiles are ENTITIES with authoritative/GHOST Performance variants (Projectile PTR_LAB_005129e8 / 005129f4) and their own WriteUpdateRecord (@4bef4c, slot 7) -- peers ran ghost missiles updated from the wire and saw the TRUE trajectory. One explosion, correct place, every node. The frozen-point mirror is the port infidelity (the entity Missile itself stays blocked by the documented 2007 Entity-base mismatch; mislanch.cpp:301). FIX: the MissileLauncher update record now carries the locked target's EntityID (salvoTargetID; EntityID::Null = point fire). The mirror resolves it on the receiving node via HostManager::GetEntityPointer (engine T0, an index-socket Find -- NULL-safe on any ID), refuses non-mechs via BTIsRegisteredMech, and pushes the mirror rounds WITH the handle -- they re-lead on the live local replicant exactly as the master's own rounds do, and detonate at the true position. Guards: record-length gate (a short record from an older build has no ID field -- its tail would be garbage and must not resolve) + Null check + registered-mech check. VERIFIED (two nodes, 200s, missile autofire both ways): * every record arrives len=52/52 with sane aims ([mlrec] diag) * 22/46 salvos resolve (tgtID=3:22 -> the victim's local master) and their mirror rounds home: the frozen-air DET population fell 234 -> 102, the live-homing population rose to 155/207 per node * the unresolved remainder is BENIGN and correct: EntityID::Null point fire plus hostID=-1 LOCAL entities -- i.e. the victim's WRECK, which autofire keeps shooting after the kill; a wreck does not move, so the frozen aim IS its true position Downstream expectations: Ronin's smoke-screen (#114) should drop by ~the mirror half, and the audio census (#32) loses the duplicate Static3DPatchSource explosion sounds on peers -- both to be read from the next field logs. Also in this commit: [projectile] DET diagnostic (every contact detonation with position/damage/handle/aim), [mlrec] record-arrival diagnostic (len/recID/ subsys/counter/aim, capped 200), scratchpad/night9/mp_double.sh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 02:29:58 -05:00
Joe DiPrimaandClaude Opus 5	3354db4bd1	#32 : RETRACT the retention diagnosis; count what matters (steals + true drops); name the saturating class The reopen said "the pool fills and never returns a source". The 30s census in the SAME field logs disproves it: free returns to ~227-230 between bursts and reuses climbs ~20/s all session. free=0 on the failure line is true by DEFINITION at the instant of a failed acquire -- the third instance of the counter-sampling trap (live=256-vs-6, then hsparm greps, now this), read off the alarm line instead of the trend line. WHAT THE LOGS ACTUALLY SHOW * The pool cycles; release-on-stop exists and works (the engine steal loop). * During firefights CONCURRENT demand exceeds 240 and the priority steal loop services each new sound by killing an old one -- continuously through combat (failures spread across every decile of every combat session). * Idle standing demand is ~13 sources. My "each component holds its SourceSet to entity teardown, ~20-25 per mech" narrative was wrong. * The raw ACQUIRE FAILED line count (6.8k-19k per log) is NOISE: the steal loop retries after every failed attempt, so lines accumulate per EVENT and most events still play via a steal. True drops were never counted. CHANGES 1. Census now carries steals= and drops= (drops = the steal loop ran dry and the sound NEVER played) plus a per-class drop histogram ("[audio] dropped by class: {class 1005 x4v: N} ...") -- all ungated, so the next field logs are decisive instead of suggestive. 2. The ACQUIRE FAILED print is rate-limited to 1/30s and now names the requesting class + voice count. 19k-line log spam distorted this triage. 3. BT_AUDIO_SOURCES=<n> now raises the POOL cap too (it previously raised the AL context budget while the pool stayed at 240, making the field experiment impossible to run). MEASURED (9 mechs, missile autofire, 150s) * cap 240: peak 130 sources, 0 fails -- demand tracks SHOOTER count, not mech count; one shooter cannot saturate. A 6-shooter lobby pins 240. * cap 48 (BT_AUDIO_SOURCES=64): saturation reproduced -- census steals=223 drops=455, histogram names the classes. * Dominant field requester (requested=4) = class 1005 Static3DPatchSource: world-placed effect sounds, i.e. EXPLOSIONS. 1001 DirectPatchSource x1v dominates drops at low cap; 1002 Dynamic3DPatchSource x3v present. CONSEQUENCE FOR THE FIX ORDER: #84's stale-aim double detonation duplicates exactly the saturating class on observer nodes. Fix #84 FIRST, then re-read the field census; only if it still saturates does the budget experiment (BT_AUDIO_SOURCES with frame time measured) become the play. KB: the wrong night-9 entry in open-questions.md replaced with the corrected diagnosis; gotcha candidate noted -- an alarm-line counter is not a trend. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 01:42:10 -05:00
Joe DiPrimaandClaude Opus 5	202ebbf84a	KB + tracker: night-9 playtest (build 4.11.693) CONFIRMED FIXED and closed: #95 (missile salvo damage), #97 (leak gauge 3 levels), #98 (loop-6 lamp), #99 (leak alarm audible). #95 deserves a note: a tester reported "LRMs still doing 3.3 damage", but that is the PER-MISSILE figure. 382 impacts across three 693 logs show the cluster being delivered correctly -- LRM20 3.25 x burst 5..20 (total up to 65), LRM15 3.33 x 3..15, LRM10 3.50 x 2..10 -- and those burst ranges match the binary's Random(n)+n/4 roll exactly. #32 REOPENED. The pooling change removed the alloc/free churn (the ~10% frame time is real) but every 693 field log still shows ACQUIRE FAILED (requested=4 live=240 pooled=240 free=0 ...) 19,182 fails (Sauron) / 15,333 (Rajel) / 6,818 (Ronin), high-water 225 of 240, starting ~1% into every session. `free=0` is the diagnosis: sources are never returned. This is precisely the risk flagged when the fix landed -- retention, not pool size. Players called audio "fine" the same night; the log disagrees. #84 still present, but the surviving explosion is a DIFFERENT mechanism from the bundled one that was fixed: "where the mech was when I fired" is the stale fire-time aim point already recorded as an open in rendering.md, i.e. an MP visual, not the message-manager path. Needs a two-node bench logging the OBSERVER -- the earlier two-node run verified damage delivery but never the visual. New: #108 ghost mech (peer never sees the death; shots still register, so it is a visual/replication desync, the inverse of #94), #109 panic/eject, #110 arm parent/child linkage (gun pod survives its mount -- three chassis, both arms; parentArtifactZone exists but only drives LOD), #111 death warp bubble shown to peers, #112 AFC shotgun spread (may be authentic Ultra-AFC burst), #113 LRM burn duration, #114 missile smoke as a smoke screen, #115 hot box, #116 Standard-vs- Expert heat gating, #117 per-chassis cockpit bounce. ⚠ A MEMBER OF THE ORIGINAL TEAM IS NOW TESTING -- "Ronin" (log user torak). He worked on the 1995 game and has played the pods recently. Treat his pod comparisons as primary evidence above reconstruction inference. First two contributions recorded in the KB: per-chassis cockpit bounce was deliberate, and NARC likely shipped as data without an implementation. ⚠ Conn Man ran the OLD build (.674) for all seven of his sessions, so his reports are not evidence about 693. His arm-linkage audit is still valuable -- nothing in 693 touched that path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 01:15:45 -05:00

Author

SHA1

Message

Date

Joe DiPrimaandClaude Opus 5

da70bd58b2

#84 : the replicant salvo now HOMES AT THE LIVE TARGET -- the stale-point double detonation is gone

Oracle (674): "missile appear to register hit explosions twice, once where
target was and again where the target is".  Rajel (693): "once where the mech
was when I fired and on the expected impact".

MECHANISM, measured on two nodes (BT_PROJ_LOG "DET at" now logs EVERY contact
detonation, including damage-0 rounds, which were invisible before): the
replicant salvo mirror pushed rounds with NO entity handle at the FROZEN
fire-time aim point, and the pool's contact test is proximity to p.targetPos --
so mirror rounds "contacted" the empty air where the target USED to be and
detonated there, on every peer, every salvo (45 salvos -> 234 frozen-point
air bursts in a 200s bench).  The true impact appears at the live position
(the shooter's own homing rounds on his node; the victim's damage reaction on
peers) -- two sites per salvo, exactly as reported.

THE BINARY'S MODEL (CLASSMAP, Missile flight-entity cluster): missiles are
ENTITIES with authoritative/GHOST Performance variants (Projectile
PTR_LAB_005129e8 / 005129f4) and their own WriteUpdateRecord (@4bef4c, slot 7)
-- peers ran ghost missiles updated from the wire and saw the TRUE trajectory.
One explosion, correct place, every node.  The frozen-point mirror is the port
infidelity (the entity Missile itself stays blocked by the documented 2007
Entity-base mismatch; mislanch.cpp:301).

FIX: the MissileLauncher update record now carries the locked target's EntityID
(salvoTargetID; EntityID::Null = point fire).  The mirror resolves it on the
receiving node via HostManager::GetEntityPointer (engine T0, an index-socket
Find -- NULL-safe on any ID), refuses non-mechs via BTIsRegisteredMech, and
pushes the mirror rounds WITH the handle -- they re-lead on the live local
replicant exactly as the master's own rounds do, and detonate at the true
position.  Guards: record-length gate (a short record from an older build has
no ID field -- its tail would be garbage and must not resolve) + Null check +
registered-mech check.

VERIFIED (two nodes, 200s, missile autofire both ways):
  * every record arrives len=52/52 with sane aims ([mlrec] diag)
  * 22/46 salvos resolve (tgtID=3:22 -> the victim's local master) and their
    mirror rounds home: the frozen-air DET population fell 234 -> 102, the
    live-homing population rose to 155/207 per node
  * the unresolved remainder is BENIGN and correct: EntityID::Null point fire
    plus hostID=-1 LOCAL entities -- i.e. the victim's WRECK, which autofire
    keeps shooting after the kill; a wreck does not move, so the frozen aim IS
    its true position
Downstream expectations: Ronin's smoke-screen (#114) should drop by ~the mirror
half, and the audio census (#32) loses the duplicate Static3DPatchSource
explosion sounds on peers -- both to be read from the next field logs.

Also in this commit: [projectile] DET diagnostic (every contact detonation with
position/damage/handle/aim), [mlrec] record-arrival diagnostic (len/recID/
subsys/counter/aim, capped 200), scratchpad/night9/mp_double.sh.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-02 02:29:58 -05:00

Joe DiPrimaandClaude Opus 5

3354db4bd1

#32 : RETRACT the retention diagnosis; count what matters (steals + true drops); name the saturating class

The reopen said "the pool fills and never returns a source".  The 30s census in
the SAME field logs disproves it: free returns to ~227-230 between bursts and
reuses climbs ~20/s all session.  free=0 on the failure line is true by
DEFINITION at the instant of a failed acquire -- the third instance of the
counter-sampling trap (live=256-vs-6, then hsparm greps, now this), read off the
alarm line instead of the trend line.

WHAT THE LOGS ACTUALLY SHOW
  * The pool cycles; release-on-stop exists and works (the engine steal loop).
  * During firefights CONCURRENT demand exceeds 240 and the priority steal loop
    services each new sound by killing an old one -- continuously through
    combat (failures spread across every decile of every combat session).
  * Idle standing demand is ~13 sources.  My "each component holds its SourceSet
    to entity teardown, ~20-25 per mech" narrative was wrong.
  * The raw ACQUIRE FAILED line count (6.8k-19k per log) is NOISE: the steal
    loop retries after every failed attempt, so lines accumulate per EVENT and
    most events still play via a steal.  True drops were never counted.

CHANGES
  1. Census now carries steals= and drops= (drops = the steal loop ran dry and
     the sound NEVER played) plus a per-class drop histogram
     ("[audio] dropped by class: {class 1005 x4v: N} ...") -- all ungated, so
     the next field logs are decisive instead of suggestive.
  2. The ACQUIRE FAILED print is rate-limited to 1/30s and now names the
     requesting class + voice count.  19k-line log spam distorted this triage.
  3. BT_AUDIO_SOURCES=<n> now raises the POOL cap too (it previously raised the
     AL context budget while the pool stayed at 240, making the field
     experiment impossible to run).

MEASURED (9 mechs, missile autofire, 150s)
  * cap 240: peak 130 sources, 0 fails -- demand tracks SHOOTER count, not mech
    count; one shooter cannot saturate.  A 6-shooter lobby pins 240.
  * cap 48 (BT_AUDIO_SOURCES=64): saturation reproduced -- census
    steals=223 drops=455, histogram names the classes.
  * Dominant field requester (requested=4) = class 1005 Static3DPatchSource:
    world-placed effect sounds, i.e. EXPLOSIONS.  1001 DirectPatchSource x1v
    dominates drops at low cap; 1002 Dynamic3DPatchSource x3v present.

CONSEQUENCE FOR THE FIX ORDER: #84's stale-aim double detonation duplicates
exactly the saturating class on observer nodes.  Fix #84 FIRST, then re-read the
field census; only if it still saturates does the budget experiment
(BT_AUDIO_SOURCES with frame time measured) become the play.

KB: the wrong night-9 entry in open-questions.md replaced with the corrected
diagnosis; gotcha candidate noted -- an alarm-line counter is not a trend.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-02 01:42:10 -05:00

Joe DiPrimaandClaude Opus 5

202ebbf84a

KB + tracker: night-9 playtest (build 4.11.693)

CONFIRMED FIXED and closed: #95 (missile salvo damage), #97 (leak gauge 3 levels),
#98 (loop-6 lamp), #99 (leak alarm audible).

#95 deserves a note: a tester reported "LRMs still doing 3.3 damage", but that is
the PER-MISSILE figure.  382 impacts across three 693 logs show the cluster being
delivered correctly -- LRM20 3.25 x burst 5..20 (total up to 65), LRM15 3.33 x
3..15, LRM10 3.50 x 2..10 -- and those burst ranges match the binary's
Random(n)+n/4 roll exactly.

#32 REOPENED.  The pooling change removed the alloc/free churn (the ~10% frame
time is real) but every 693 field log still shows
    ACQUIRE FAILED (requested=4 live=240 pooled=240 free=0 ...)
19,182 fails (Sauron) / 15,333 (Rajel) / 6,818 (Ronin), high-water 225 of 240,
starting ~1% into every session.  `free=0` is the diagnosis: sources are never
returned.  This is precisely the risk flagged when the fix landed -- retention,
not pool size.  Players called audio "fine" the same night; the log disagrees.

#84 still present, but the surviving explosion is a DIFFERENT mechanism from the
bundled one that was fixed: "where the mech was when I fired" is the stale
fire-time aim point already recorded as an open in rendering.md, i.e. an MP
visual, not the message-manager path.  Needs a two-node bench logging the
OBSERVER -- the earlier two-node run verified damage delivery but never the visual.

New: #108 ghost mech (peer never sees the death; shots still register, so it is a
visual/replication desync, the inverse of #94), #109 panic/eject, #110 arm
parent/child linkage (gun pod survives its mount -- three chassis, both arms;
parentArtifactZone exists but only drives LOD), #111 death warp bubble shown to
peers, #112 AFC shotgun spread (may be authentic Ultra-AFC burst), #113 LRM burn
duration, #114 missile smoke as a smoke screen, #115 hot box, #116 Standard-vs-
Expert heat gating, #117 per-chassis cockpit bounce.

⚠ A MEMBER OF THE ORIGINAL TEAM IS NOW TESTING -- "Ronin" (log user torak).  He
worked on the 1995 game and has played the pods recently.  Treat his pod
comparisons as primary evidence above reconstruction inference.  First two
contributions recorded in the KB: per-chassis cockpit bounce was deliberate, and
NARC likely shipped as data without an implementation.

⚠ Conn Man ran the OLD build (.674) for all seven of his sessions, so his reports
are not evidence about 693.  His arm-linkage audit is still valuable -- nothing in
693 touched that path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-02 01:15:45 -05:00