"""Night-9 (build 4.11.693) new bug registrations."""
import sys
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
from gitea import create

SRC = ("Source: playtest night 9 (2026-08-01, build **4.11.693 (5a1a407)**), Discord #play-testing.\n"
       "Testers: VGL Lynx, Oracle, RajelAran, SAURON (Michael), Conn Man, Draco, "
       "**Ronin (NEW -- worked on the ORIGINAL game)**.\n\n")

create("Ghost mech returned: a dead mech is not removed/respawned on a peer's screen -- everyone shoots thin air",
SRC + """@VGL Lynx: *"Ghost mechs. Returned today."*
@RajelAran: *"there was one instance where a mech did not explode/respawn on my screen, I saw everyone shooting at thin air / **they were hitting something though**"*.

Rajel's second clause is the important one: the other players' shots were **registering**, so the mech existed and was being hit — his client was rendering it in the wrong place / wrong state, not failing to simulate it. That makes this a **replication/visual** desync, not a dead-entity leak.

Distinct from the two closed ghost issues:
- #81 was the local player respawning as sliding wreckage.
- #94 was a peer seeing a LIVE mech as wreckage after a collision (zone-less death), fixed by the `MechDeathHandler::Tick` exit-edge watcher.

This one is the inverse of #94: the peer never sees the death **at all**. Worth checking whether the death record simply never reached that node, or arrived and was dropped — `MovementMode` death modes {2,9} ride the record header, and `simulationState` rides every record.

Logs staged: `rajel_GAMERSLAB_693_part1/2`, `sauron_XIAOLONG_693`, `torak_TOWEROFTERROR_693`.""",
[1, 6])

create("PANIC / EJECT does nothing",
SRC + """@VGL Lynx: *"Confirmed, PANIC/Eject not working."*

The panic/eject control produces no effect. Needs the input path traced (CONTROLS.MAP binding -> handler) and then whatever the binary does on eject reconstructed. Check first whether the button even reaches a handler, since several eng-page/console buttons are still unreconstructed (#14, #53).""",
[1])

create("Destroying an upper arm leaves the gun pod alive and still firing (no parent/child zone linkage)",
SRC + """@VGL Lynx: *"Arms do not seem to have parent/daughter linkage. You can destroy an upper arm, and the gun pod is intact and can still fire."*

@Conn Man ran a methodical audit and confirmed it (note: **on build .674**, but nothing in .693 touched this):
> *"Test on Avatar, Sunder, and Vulture. Tested both legs on each ... Tested firing on upper arm sections until they were destroyed. The weapon pods on those arms were still functional until also destroying the lower arm sections. Same behavior on both left and right arms for all three 'mechs."*

Three chassis, both arms, reproducible — a strong report.

**Where to look:** the linkage exists structurally. `Mech__DamageZone` carries a `parentArtifactZone` socket and children register into it (`mechdmg.cpp`, `child->parentArtifactZone.Add(this)`). But on damage the only thing done with the parent is `parent->UpdateLODDamageLevel()` — a **level-of-detail** update. There appears to be no propagation of DESTRUCTION from a parent zone to its children, which is exactly this symptom.

Related: #86 (destroyed weapons could still fire) fixed the case where the WEAPON itself is destroyed; this is the case where the weapon is healthy but its mount is gone.

Same audit also confirmed a fix, worth recording: *"Confirmed that the correct gimped leg animation played after the destruction of the appropriate leg."*""",
[1])

create("Dying mech shows the translocation warp bubble to OTHER players -- peers should just see the explosion",
SRC + """@VGL Lynx: *"Other players see a dying mech's blue bubble as they die. It should not be reading like an explosion shockwave. Mech death should just be the big boom from other POV."*
Confirmed in follow-up: warp bubble **only** for the mech that is dying, and only wrong from the observer's view.

So the tsphere translocation warp (`context/translocation-warp.md`) is being played on the **replicant**, where the original showed only the death explosion. The warp is the first-person respawn effect for the pilot being translocated, not a world effect other pilots should see.

Likely the same class as #94 — an effect fired on the peer path that should be viewpoint-only. Check the instance test around `BTStartWarpEffect` (`mechdmg.cpp`): the un-wreck path deliberately gates on `Entity::ReplicantInstance`, so the gating convention exists; the death-warp path may be missing an equivalent viewpoint check.""",
[1, 6])

create("AFC rounds spread damage across multiple hit zones (shotgun) instead of landing as one projectile",
SRC + """@VGL Lynx: *"Confirmed that AFC are doing shotgun. Area damage, not single projectile damage. Can see AFC damage in multiple hit zones."*

@Draco pushes back, and may be right:
> *"I dont recall for sure which mechs have what type of AFC but ultra afc should register kinda like shot gun because there are 2 rounds firing correct? so lead is important to get both rounds on same panel"*

So the question is whether this is a defect or authentic Ultra-AFC behaviour.

**Note this is the same mechanism as the (correct) missile cluster.** A `burstCount > 1` damage record is applied N times with the hit zone **re-rolled per burst** (binary `@0x4a0439`), which by design sprays across zones. Tonight's logs show an 8.75-per-round weapon delivering burst 1..4 — i.e. something IS bursting up to 4. If AFC is authored with a burst count, the spread is authentic and the only question is the count.

**Next step:** dump the authored `burstCount` for each AFC variant and compare against the published weapon table @Oracle mentioned; that settles defect-vs-authentic without guessing.""",
[2])

create("LRM burn / hit state lasts too long",
SRC + """@VGL Lynx: *"LRM burn/hit state is now too long."*

Follows the missile thrust work (#84) which gave missiles a real burn phase. The authored burn durations were read from the BTL4.RES type-15 model records: SRM 2.5s @600, **LRM 10s @300**, Streak 3s @300, NARC 10s @300.

A 10-second LRM burn is what the data says, but it is long, and it is worth re-checking whether that field is a burn DURATION or something else (e.g. a range/lifetime cap) before treating the authored value as settled. Tonight's logs show `burnLeft` values around 8.9-9.7 on impact, i.e. most of the 10s budget unused at contact — consistent with the field being a lifetime cap rather than a thrust duration.""",
[2])

create("Missile impact smoke is far too thick and long-lived -- acts as a smoke screen from the cockpit",
SRC + """@Ronin — **who played the original pods, including in Japan last year** — on 4.11.693:
> *"When I got hit with missiles, the smoke emitted as a result seemed to last A LOT longer and thicker than what I experienced in the pods (this is from the cockpit view), so much so that it effectively functioned as a smoke screen - blocking my view of the battlefield. Again, much different from what I experienced in the pods."*

@RajelAran: *"that may be related to bug #84, the double missile explosion"* — plausible, since two detonations per missile is roughly double the smoke.

Two other known contributors, both already recorded as open in `context/rendering.md`:
- particle **trail density is frame-rate dependent** (2/frame at 60fps = 2x pod density) — the same bug class as the myomer heat term, and untouched;
- the i860 board ran its particle heat model per **30 Hz** frame.

So there are at least three candidate multipliers stacking. Worth fixing the frame-rate dependence first since it is a known defect with a known shape, then re-asking @Ronin.

⚠ @Ronin is a first-hand reference for what the pods looked like — his comparisons are high-value evidence.""",
[1])

create("Hot box / target select not connected",
SRC + """@VGL Lynx: *"Hot box/target select not connected."*

Consistent with an earlier note that the hot box is not functional (mentioned alongside the sensor-panel work, #105). Registering separately so it is not lost inside the sensor issue.""",
[1])

create("Standard mode: players report heat build-up where none is expected",
SRC + """@Conn Man: *"Some of us in Standard mode were still experiencing heat build up, including me."* (his session ran on **.674**)
@RajelAran, the same evening: *"well we're testing on standard, not expert, so heat isn't expected here"*.

These two statements conflict, and the answer matters for reading every heat report we get.

`context/experience-levels.md` records the heat model as gated by experience level, with novice gates. Needs a definitive answer to: **which heat sources are active in Standard vs Expert?** — specifically whether myomer drive heat, weapon heat and coolant leaks are each gated. `HeatSink::GetStatusFlags` already gates the leak bit on `HeatModelActive()`, so at least one gate exists; the question is whether drive heat honours the same gate.

Cheap to settle on the bench: run the same profile at each experience level and diff the temperature traces.""",
[2])

create("KB: per-chassis cockpit BOUNCE was deliberate -- each chassis has its own (from Ronin, original team)",
SRC + """Not a bug — durable design knowledge from @Ronin, who worked on the original:

> *"Also, in interest of making sure that all 'lost' info is shared or assumed to be known: you may all be aware of this, but all of the chassis have different cockpit 'bounce' - this was made so to help give the 'mechs some individuality."*

So the first-person cockpit shake/bob is **per-chassis authored**, not a single shared curve, and it was an intentional identity cue. Worth checking what our port does — if we apply one shared bounce, every mech feels the same from the seat and a deliberate piece of the original's character is missing.

Relevant files: `context/cockpit-view.md` (the eyepoint camera), `context/locomotion.md` (gait). The skeleton's `jointshakey` segment is the obvious candidate for where per-chassis bounce data would live — note its pick sphere radius already differs per chassis (Loki 2.767 vs Thor 2.561), so the segment is not shared.""",
[2])