Joe DiPrimaandClaude Opus 5
202ebbf84a
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>
106 lines
8.8 KiB
Python
106 lines
8.8 KiB
Python
"""Night-9 (build 4.11.693) bug-report housekeeping."""
|
|
import sys
|
|
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
|
|
from gitea import comment, close, create, call
|
|
|
|
BUG, HUD, AUDIO, INVESTIGATE, AWAIT = 1, None, None, None, 8 # only bug/await ids are known-good
|
|
|
|
# ---------------------------------------------------------------- CONFIRMED FIXED
|
|
close(95, """**VERIFIED FIXED from the field logs — closing.**
|
|
|
|
@RajelAran reported *"LRMs still seem to be doing 3.3 damage, at least the LRM10"*. That number is the **per-missile** figure, not the delivered total. The 4.11.693 logs carry the burst count on every impact, and the cluster is being applied correctly:
|
|
|
|
| weapon | per missile | burst range observed | total delivered |
|
|
|---|---|---|---|
|
|
| LRM20 | 3.25 | 5 .. 20 | 16.2 .. **65.0** |
|
|
| LRM15 | 3.33 | 3 .. 15 | 10.0 .. **50.0** |
|
|
| LRM10 | 3.50 | 2 .. 10 | 7.0 .. **35.0** |
|
|
| SRM (8.75) | 8.75 | 1 .. 4 | 8.8 .. **35.0** |
|
|
| direct fire | 7 / 13 / 25 | 1 | unchanged |
|
|
|
|
382 impacts across Rajel's, Sauron's and Ronin's logs. The observed burst ranges match the binary's authentic `Random(n) + n/4` roll **exactly** — n=20 gives 5..20, n=15 gives 3..15, n=10 gives 2..10, n=4 gives 1..4. So a full LRM20 salvo now lands 65 points, up from the 3.25 it delivered before the fix.
|
|
|
|
The `[projectile] IMPACT damage=X ... burst=N` line shows **X = per missile**; total is `X * N`. Worth knowing when reading logs.""")
|
|
|
|
close(97, """**CONFIRMED FIXED by two testers — closing.**
|
|
|
|
@Oracle: *"observed a stage 3 coolant leak"* (twice), then *"I experienced a three stage coolant leak in the new build, so I'll call that fixed"*.
|
|
@RajelAran: *"#97 seems to be fixed, I got tier-3 coolant leak"*.
|
|
|
|
Cause was the dropped x87 normalisation around `__ftol` in `BitMapInverseWipe::Execute` (KB gotcha #19): the gauge rounded the raw leak rate instead of `round(fullWidth * rate / fullScale)`, so it could only ever show one triangle.""")
|
|
|
|
close(98, """**CONFIRMED FIXED — closing.**
|
|
|
|
@RajelAran: *"#98 - cooling loop 6 lamp flashes"*.
|
|
|
|
Root cause was a 0-based bound (`n >= 0 && n < 6`) on a 1-based index, so condenser 6 was rejected and annunciated nothing. Loops 1-5 were never broken. The lamp table itself was byte-accurate all along and is now pinned to the image by `scratchpad/night8/lamptable_check.py`.""")
|
|
|
|
close(99, """**Audible alarm CONFIRMED WORKING — closing this issue.**
|
|
|
|
@RajelAran: *"#32 and #99 - audio seems to be working fine"*.
|
|
|
|
Both halves are now settled:
|
|
- **No alarm at all** — was the OpenAL source starvation, not a missing feature. The alarm chain is fully implemented and was traced firing end to end (`8daac37`).
|
|
- **Does not re-assert for a second leak** — verified AUTHENTIC in the arcade image: `ReceiveControl @0043d3a4` case 2 is an unconditional `call StopSequence @0043d2d4`, which tests only its own `isRunning` with no refcount. 19 subsystems share one alarm sequence, so any one clearing its leak stops it. The cabinet did this too.
|
|
|
|
⚠ Note the audio pool is **not** actually healthy — see #32, which I am reopening with the log evidence. The alarm being audible tonight does not mean source starvation is solved.""")
|
|
|
|
# ---------------------------------------------------------------- NOT FIXED (escalate)
|
|
comment(32, """**REOPENING — the field logs say this is NOT fixed. The pooling change removed the churn but replaced it with permanent retention.**
|
|
|
|
@RajelAran said *"audio seems to be working fine"*, and subjectively it may have been. Objectively, every 4.11.693 log is still saturated:
|
|
|
|
| player | build | ACQUIRE FAILED | pool high-water |
|
|
|---|---|---|---|
|
|
| Sauron | 693 | **19,182** | 225 of 240 |
|
|
| Rajel (part 1) | 693 | **15,333** | 225 of 240 |
|
|
| Ronin | 693 | **6,818** | 225 of 240 |
|
|
| Conn Man | 674 (old) | 13,238 | — |
|
|
|
|
The failure line has changed shape, and that is the diagnosis:
|
|
|
|
```
|
|
[audio] ACQUIRE FAILED (requested=4 live=240 pooled=240 free=0 fails=N)
|
|
```
|
|
|
|
`pooled=240 free=0` — the pool fills to its cap and **never returns a source to the free list**. Before the fix it was `live=256` churning against the OpenAL driver limit; now we allocate 240 once and hold all of them. The alloc/free churn is genuinely gone (that bought ~10% frame time, which is real and worth keeping), but availability is no better — and it starts **~1% into every session** and continues to 94-99%.
|
|
|
|
This is exactly the risk flagged when the fix landed: *"if next session's logs show that climbing past ~200, the remaining work is RETENTION — reclaiming sources from finished one-shots instead of holding them to entity teardown — not a bigger pool."* High-water 225 of 240 with `free=0` confirms it.
|
|
|
|
**The real fix is retention**, not a bigger cap: each audio component reserves a SourceSet of up to 25 voices and holds it until entity teardown, so peak demand scales with the number of live audio components rather than with audible sounds. Raising the cap would just delay the wall.""")
|
|
call("/issues/32", "PATCH", {"state": "open"})
|
|
print("REOPENED #32")
|
|
|
|
comment(84, """**Still present in 4.11.693 — and the surviving explosion is a DIFFERENT mechanism from the one that was fixed.**
|
|
|
|
@RajelAran: *"still getting the double missile explosion - once where the mech was when I fired and on the expected impact"*. @Conn Man saw it too (though he ran the old .674 build all night, so his sighting is not independent evidence for 693).
|
|
|
|
What was fixed in `3b7c19c` was the **message manager's bundled explosion** — projectiles now dispatch damage directly at the victim, as the binary does, so they no longer touch the consolidation path that produced a second blast. Verified on the bench: 10 projectile impacts, zero bundled explosions.
|
|
|
|
The description now points somewhere else. *"Where the mech was when I fired"* is a **stale fire-time aim point**, which is a known open already recorded in the KB (`context/rendering.md`): *"replicant visual salvo chases the stale fire-time aim point (no re-lead without a target handle)"*. That is a **multiplayer visual** issue — the salvo re-simulated on another node flies at where the target was at launch, detonating there, while the authoritative impact happens at the real position.
|
|
|
|
That also likely explains @Ronin's separate report that missile smoke *"effectively functioned as a smoke screen"* — two detonations per missile means roughly double the smoke.
|
|
|
|
**What would settle it:** a two-node bench with projectile logging on the OBSERVER, not the shooter. The earlier two-node run verified cross-pod *damage* delivery but never looked at the visual. That is the next step.""")
|
|
|
|
comment(96, """**Halving confirmed; still over-tuned per the testers.**
|
|
|
|
@RajelAran: *"confirm #96 - myomer heat seems to be halved-ish"*.
|
|
@Oracle: *"The myomer heat was toned down and still seems like too much heat generation rate for seek 3"* ... *"I trust it was half, but will need further tuning"*.
|
|
|
|
So the frame-rate normalisation landed as intended and the remaining gap is calibration, not mechanism. Two things bear on it:
|
|
|
|
1. **The reference rate is not proven.** The kinetic term is scaled by `dt * 30`, and 30 Hz is the documented i860 **board** frame; the host simulation rate was never established, and there is no fixed-timestep constant anywhere in the image. If the host ticked slower than 30 Hz we are still over. **`BT_MYO_HZ=<n>` retunes this live with no rebuild** — @Oracle, if you want to experiment, lower values mean less heat (try 20 or 15).
|
|
|
|
2. @Oracle's *"I wish there was a more objective reference for myomer heat rate"* is the right instinct, and it is now partly answerable: the myomer record is **identical on every chassis** (velEff 0.995, accEff 0.8, gears 3000/5000/7000/9999, degradeT 1000, failT 2000, thermalMass 250000), and so is every cooling parameter. Per-mech differences come only from **mass and speed**, through `heat ~ m*v^2`.
|
|
|
|
Also relevant: @RajelAran noted *"we're testing on standard, not expert, so heat isn't expected here"*, while @Conn Man reported *"some of us in Standard mode were still experiencing heat build up"*. Those conflict, and it matters for interpreting any heat report — filed separately.""")
|
|
|
|
comment(104, """**Provenance from @Ronin, who worked on the original:**
|
|
|
|
> *"I don't think that narcs were ever implemented, as I don't recall talking/working with Mike L. on these at the time, so I suspect that they may have been 'cool if we can get this working' and listed as a hope on the 'mech weapons. However, in order to confirm this Mike will have to be contacted."*
|
|
|
|
@VGL Lynx counters that the Mad Dog loads with NARC on the missile MFD and that it appears in the final build notes on the original site.
|
|
|
|
Both can be true: the **loadout data shipped** (which is why we render it) while the **weapon behaviour was never implemented**. That matches what we see — the authored record exists and resolves, and there is no distinct NARC behaviour to reconstruct. Worth confirming with Mike L. if a contact is possible.""")
|