291 lines
18 KiB
Python
291 lines
18 KiB
Python
# -*- coding: utf-8 -*-
|
|
"""Night 7 (2026-07-30) field-report housekeeping: new issues."""
|
|
import gitea
|
|
|
|
SRC = ("Source: playtest night 7 (2026-07-30, build **4.11.659 (e91d447)**), Discord "
|
|
"#play-testing -- SAURON (Michael), RajelAran, **Oracle (Dave -- NEW tester, "
|
|
"hands-on experience with the original pod game)**, Draco.\n\n")
|
|
|
|
NEW = []
|
|
|
|
NEW.append((
|
|
"No INCOMING MISSILE alarm -- the warning annunciator is missing entirely",
|
|
SRC +
|
|
"Oracle: \"no incoming missile alarm\" ... \"I am pretty sure I lost some hearing from "
|
|
"the incoming missile alarm\" (i.e. in the original pod it was LOUD and impossible to "
|
|
"miss). SAURON concurs and explains why it was never reported before: \"none of us "
|
|
"reported that because we did not know that was supposed to be there, but 100% this is "
|
|
"missing in current build\".\n\n"
|
|
"So this is a first-report from a tester who knows the original: an inbound missile "
|
|
"should raise an audible warning in the cockpit. Right now there is no cue of any kind.\n\n"
|
|
"**Where to look:**\n"
|
|
"- The warning is presumably an alarm-driven sound like the other annunciators (the "
|
|
"MessageManager / alarm family that drives the jam + bay-fire cues -- see #47), not an "
|
|
"ad-hoc play call. Find the alarm level the missile-threat sensor raises.\n"
|
|
"- Sensor side: does anything on the receiving mech observe an inbound missile at all? "
|
|
"If no threat detection exists yet, the alarm has no source and this is a two-part gap "
|
|
"(detect, then annunciate).\n"
|
|
"- Check the sound bank for an authored incoming/lock warning wav (content audio "
|
|
"inventory, `docs/AUDIO_FIDELITY.md`) -- if the asset exists, the trigger is the only "
|
|
"missing half.\n\n"
|
|
"Related: #47 (missing jam/bay-fire annunciation) -- likely the same annunciator "
|
|
"machinery."))
|
|
|
|
NEW.append((
|
|
"Missiles fly far too slowly, and the impact explosion plays BEFORE the missile reaches "
|
|
"the target",
|
|
SRC +
|
|
"Oracle: \"def missiles are very slow and I usually see an 'impact' explosion on my "
|
|
"target despite the missiles not reaching the target yet\". RajelAran concurs: \"yeah "
|
|
"the missiles are slow for sure\".\n\n"
|
|
"Two symptoms that are probably one root cause:\n"
|
|
"1. **Flight speed is too low** vs the original.\n"
|
|
"2. **The hit is resolved independently of the projectile** -- the detonation FX and "
|
|
"(presumably) the damage land while the visible missile is still in flight, which means "
|
|
"the visible missile is a cosmetic tracer rather than the thing that scores the hit, or "
|
|
"it is being flown at the wrong velocity while the impact is timed from something else.\n\n"
|
|
"The ordering matters more than the speed: if damage is applied at fire time, then "
|
|
"missile speed is cosmetic and dodging/cover cannot work the way the original played.\n\n"
|
|
"**Where to look:** the missile launcher fire path (`mislanch.cpp`) and the projectile "
|
|
"entity's velocity source -- the authentic muzzle speed should come from the weapon's "
|
|
"streamed data, not a port constant. Then find who triggers the impact effect and "
|
|
"whether it is the projectile's own collision or the firing-side resolution."))
|
|
|
|
NEW.append((
|
|
"Myomers generate NO heat -- ice cold at seek 4 under load",
|
|
SRC +
|
|
"Oracle: \"Myomers are not generating heat\" ... \"definitely not generating heat on "
|
|
"myomers I have them at seek 4 / they remain ice cold\". Explicitly re-checked against "
|
|
"the engineering panel readout on request, so this is a panel-confirmed observation, not "
|
|
"a guess from feel.\n\n"
|
|
"The myomers are the mech's muscle bus -- driving them (especially at a raised seek "
|
|
"voltage) is supposed to be one of the pilot's main heat costs, and the whole coolant "
|
|
"loop / seek-level tradeoff depends on it. With them producing zero heat, the heat "
|
|
"economy is missing a major term and expert play cannot be balanced.\n\n"
|
|
"**Where to look:** `Myomers` derives from the heatable subsystem family -- check "
|
|
"whether its per-tick heat generation is actually computed and pushed into its heat "
|
|
"zone / the heat-sink bank, or whether the generation term is a stub returning 0. "
|
|
"Compare against a subsystem that DOES heat correctly (weapons heat visibly), and check "
|
|
"the seek-voltage multiplier is applied.\n\n"
|
|
"Related: #75 (myomer damage does not affect speed -- the same class is half-wired on "
|
|
"the locomotion side), #19 (seek level select), `context/subsystems.md` heat model."))
|
|
|
|
NEW.append((
|
|
"Destroyed weapons keep FIRING and scoring -- limb blown off, X on the MFD, launcher "
|
|
"still launches",
|
|
SRC +
|
|
"Reported by all three testers, with screenshots.\n\n"
|
|
"Oracle: \"I was still able to fire my missing x'd out weapons on my missing right arm "
|
|
"just now (Thor)\" ... \"When limbs or weapons (missile launchers) are visibly destroyed "
|
|
"the weapons continue to function and score damage (score increases)\" ... \"opponents "
|
|
"can see each others weapons continue to fire\". RajelAran: \"destroyed weapons do seem "
|
|
"to cycle still\". SAURON posted two screenshots of Oracle's Thor with a destroyed "
|
|
"missile pod and a missile visibly leaving the mech.\n\n"
|
|
"So all three layers agree the weapon is dead -- the limb is visually gone, the MFD "
|
|
"draws the X, the subsystem is marked destroyed -- and the fire path ignores all of it. "
|
|
"Peers see the phantom shots too, so this is not a local-display artifact: the shot is "
|
|
"real and it scores.\n\n"
|
|
"**Where to look:** the trigger/fire path does not consult the weapon's destroyed state. "
|
|
"The state machine already raises weaponAlarm level 7 (unavailable) -- see #30, which "
|
|
"covers the *presentation* of level 7. This issue is the *enforcement* half: level 7 "
|
|
"(and destruction of the mounting zone) must veto the fire, the recharge cycle, and the "
|
|
"ammo draw.\n\n"
|
|
"Related: #30 (level-7 presentation), #22 (destroyed weapons do not reset on respawn)."))
|
|
|
|
NEW.append((
|
|
"Damaged armor panels never DARKEN -- own doll and the target's damage panel both read "
|
|
"100% fresh",
|
|
SRC +
|
|
"SAURON: \"no damage displaying on enemy mech panels that have been damaged / looks 100% "
|
|
"fresh on all panels\". Oracle: \"I'm not seeing darkening panels due to damage\" and "
|
|
"later \"also not seeing panels darken from damage / even when red/flashing red\".\n\n"
|
|
"In the original, an armor zone progressively DARKENS as its armor is stripped, so the "
|
|
"pilot can read the state of a zone (and of the target) at a glance. Currently the panel "
|
|
"will go to its red/flashing state but never shows the graded darkening in between.\n\n"
|
|
"Two sub-reports that may or may not be the same widget -- worth separating during the "
|
|
"fix:\n"
|
|
"1. **Own damage doll** -- no progressive tint as a zone loses armor (Oracle).\n"
|
|
"2. **Target/enemy mech panel** -- reads completely fresh even after confirmed damage "
|
|
"(SAURON).\n\n"
|
|
"**Note -- this contradicts a claim in #80**, which states \"the paper doll (Damage view) "
|
|
"shows per-ZONE armor tint\" as the known-good baseline. Three testers say it does not. "
|
|
"Verify which is true before building on #80's layering.\n\n"
|
|
"Confirmed as a real port gap by the operator during the session (\"i definitely never "
|
|
"implemented that\"), so treat as unimplemented rather than regressed.\n\n"
|
|
"Related: #80 (critical panel never lights), `context/gauges-hud.md`."))
|
|
|
|
NEW.append((
|
|
"Coolant LEAKS are not implemented -- heavy damage never produces a leak",
|
|
SRC +
|
|
"Oracle: \"are coolant leaks implemented? having heard or seen any evidence of it\" ... "
|
|
"\"seems missing after being hit so much\". He explicitly confirmed the rest of the "
|
|
"coolant system is alive around it: \"yes flush is working / loop prioritization is "
|
|
"working too / I can see the response of the loops and the sub-systems\".\n\n"
|
|
"So the pilot-driven half of the coolant system works; the DAMAGE-driven half (a hit "
|
|
"opening a leak that bleeds the reservoir over time, with its cue) appears to be absent. "
|
|
"That removes the main reason the coolant reserve is a finite resource in a fight.\n\n"
|
|
"**Where to look:** `Reservoir` / the coolant loop family -- does damage to a coolant "
|
|
"zone set a leak rate at all, and is there an annunciation for it? Manual coolant flush "
|
|
"is known-working, so the drain mechanism exists; the question is whether damage ever "
|
|
"arms it.\n\n"
|
|
"Related: #55 (respawn does not restore coolant -- the same family has no DeathReset), "
|
|
"#51 (flush sound loops forever), the original manual's coolant-loop section "
|
|
"(`reference/manual/Tesla40_BT_manual.pdf`)."))
|
|
|
|
NEW.append((
|
|
"No SPLASH damage from nearby mech explosions (advanced damage is ON) -- possible "
|
|
"regression",
|
|
SRC +
|
|
"Oracle: \"advanced damage not implemented? / not seeing splash damage from nearby mechs "
|
|
"exploding\" and in his written notes: \"Advanced damage does not seem to be implemented "
|
|
"even though it is turned on\". SAURON: \"no splash damage at all so far\".\n\n"
|
|
"**Possible regression, not a gap.** Draco (from earlier sessions): \"I'm not sure if "
|
|
"100% working but did get some splash kills a few builds ago at least one or two\" ... "
|
|
"\"I remember when you nathan and I were doing drops more than once we had double kills "
|
|
"seemingly due to splash\". So splash appears to have worked at some point.\n\n"
|
|
"**Prime suspect to check FIRST [T4]:** commit `14ff351` (\"the COLLISION DIVERT -- "
|
|
"type-0 damage prices as internal rattle, never armor\"), which shipped in this exact "
|
|
"build. That change routes **type-0** damage away from armor and into internal rattle "
|
|
"hits. If explosion/splash damage also arrives typed 0, the divert would silently eat it "
|
|
"-- splash would still be 'applied' but land as invisible internal rattle instead of "
|
|
"armor damage and kills. Verify the damage type the mech-death explosion emits before "
|
|
"assuming this is unimplemented.\n\n"
|
|
"Also untested per Oracle's notes: whether cultural objects (props/scenery) cause damage.\n\n"
|
|
"Related: #27 (ballistic weapons deal Explosive-type damage -- damage typing is already "
|
|
"known-shaky), `context/combat-damage.md`."))
|
|
|
|
NEW.append((
|
|
"Flames and smoke from serious damage render less often and for less time than the "
|
|
"original",
|
|
SRC +
|
|
"Oracle: \"flames and smoke not pouring out of damaged mechs\", refined in his written "
|
|
"notes to: \"Flames and smoke from serious damage not rendering as often nor for as long "
|
|
"as I recall. I do hear roaring/crackling sound\". RajelAran: \"yeah we saw it "
|
|
"yesterday\" (i.e. the effect is not entirely absent).\n\n"
|
|
"So the effect EXISTS and the audio layer is present, but the visual is thinner and "
|
|
"shorter-lived than the original -- consistent with some trigger conditions or duration "
|
|
"being missing rather than the whole effect.\n\n"
|
|
"**[T4 -- recollection-based]** Calibrate against the authored effect data before "
|
|
"tuning: which damage states are supposed to arm a persistent burn (zone destroyed? "
|
|
"internal crit? engine?), and what the authored lifetime is. The audio playing without "
|
|
"the matching visual is a useful lead: find what the sound trigger is bound to and check "
|
|
"whether the particle effect is bound to the same event.\n\n"
|
|
"Related: #79 (particles.png never existed -- billboard particles draw untextured; that "
|
|
"fix landed, so re-baseline what the effect looks like now)."))
|
|
|
|
NEW.append((
|
|
"Thor: black rectangle slides up and down in the forward view while moving",
|
|
SRC +
|
|
"Oracle (written notes, item 6): \"Thor - rectangle moving up and down in front view "
|
|
"when moving\". RajelAran independently concurs: \"concur on the thor black rectangle "
|
|
"moving in the main view\".\n\n"
|
|
"Thor-specific (not reported on the other chassis tonight) and motion-linked -- it moves "
|
|
"with the walk/bob rhythm, which points at cockpit geometry rather than a HUD widget.\n\n"
|
|
"**Where to look:** the Thor cockpit model (`*_cop`) and the eyepoint camera -- an "
|
|
"untextured or wrongly-ordered canopy/frame quad that rides the cockpit bob and swings "
|
|
"through the view. Check the Thor's cop geometry against a chassis that is clean (the "
|
|
"Loki/Hellbringer and Sunder were not reported).\n\n"
|
|
"Related: `context/cockpit-view.md`, #23 (MFD/world-view overlap)."))
|
|
|
|
NEW.append((
|
|
"Loki/Hellbringer FOOT zones cannot be damaged by direct fire (the Thor's can)",
|
|
SRC +
|
|
"Oracle (written notes, item 7): \"Unable to damage the foot panels on Loki via direct "
|
|
"fire from front or side. Was able to damage on Thor\". Live: \"I was unable to hit the "
|
|
"Loki foot / but my Thor foot could be hit\".\n\n"
|
|
"A per-chassis asymmetry with a clean control (same tester, same session, same weapons, "
|
|
"the Thor works) -- so this is the Loki's foot zone specifically, not the foot-damage "
|
|
"path in general.\n\n"
|
|
"**Where to look:** the Loki's zone/collision geometry for the foot -- either the pick "
|
|
"ray never intersects a foot volume (missing or mis-sized collision stream on that "
|
|
"chassis, cf. #17's pick-transparent geometry) or the hit lands but maps to the leg zone "
|
|
"instead of the foot. A shot-by-shot damage log while aiming at each chassis's foot will "
|
|
"separate 'no hit' from 'hit, wrong zone'.\n\n"
|
|
"Related: #17 (geometry with no collision stream is pick-transparent), #73 (damage "
|
|
"credited to the wrong zone), `context/combat-damage.md`."))
|
|
|
|
NEW.append((
|
|
"CRASH in Mech::PerformAndWatch -- call through a garbage vtable at end of round "
|
|
"(0xC0000005, target=0x65676769)",
|
|
SRC +
|
|
"RajelAran: \"game crash on exit for me / fine until then\". Oracle, separately: \"I had "
|
|
"a crash after the game ended\". Two players, two machines, same build, both at the end "
|
|
"of a round.\n\n"
|
|
"**Tester's crash line (RajelAran):**\n"
|
|
"```\n"
|
|
"[crash] UNHANDLED EXCEPTION code=0xc0000005 addr=0x65676769 access=8 target=0x65676769\n"
|
|
"[crash] stack: 0x65676769 btl4+0x2b91a btl4+0xaae4f btl4+0xd5934 btl4+0x991f2 "
|
|
"btl4+0x6c67d btl4+0xa5e9 btl4+0x1040ed 0x76905d49 0x7763e00b 0x7763df91\n"
|
|
"```\n\n"
|
|
"**Symbolized against `dist/BT411_4.11.659.map`** (`python tools/symcrash.py "
|
|
"dist/BT411_4.11.659.map \"...\"`):\n"
|
|
"```\n"
|
|
"btl4+0x2b91a Mech::PerformAndWatch +0x10a\n"
|
|
"btl4+0xaae4f Entity::Execute +0x16f\n"
|
|
"btl4+0xd5934 UpdateManager::Execute +0x194\n"
|
|
"btl4+0x991f2 Application::ExecuteForeground +0x92\n"
|
|
"btl4+0x6c67d ApplicationManager::RunMissions +0x10d\n"
|
|
"btl4+0xa5e9 WinMain +0x2af9\n"
|
|
"btl4+0x1040ed __scrt_common_main_seh +0xf8\n"
|
|
"```\n\n"
|
|
"**Reading:**\n"
|
|
"- `access=8` is EXECUTE and `addr == target == 0x65676769`, so control was TRANSFERRED "
|
|
"to that address -- an indirect call through a corrupt function pointer, and "
|
|
"PerformAndWatch+0x10a is the return address of that call (the call site is a few bytes "
|
|
"earlier, early in the function).\n"
|
|
"- `0x65676769` is **ASCII text**: bytes `69 67 67 65` = `\"igge\"` -- the middle of a "
|
|
"word (\"trigger\"/\"bigger\"). A vtable slot holding string data means the object is "
|
|
"**freed or overwritten**, not merely null. (An unresolved `/FORCE` external would land "
|
|
"near `__ImageBase`, not in text data -- so that class of bug is ruled out.)\n"
|
|
"- This is NOT a shutdown path: the frames are `RunMissions -> ExecuteForeground -> "
|
|
"UpdateManager::Execute -> Entity::Execute`, i.e. a **normal game tick**. So at end of "
|
|
"round something is torn down while still in the update roster and gets ticked once "
|
|
"more -- a use-after-free on a mech or one of the objects it calls virtually early in "
|
|
"PerformAndWatch.\n\n"
|
|
"**Suspects, in order:**\n"
|
|
"1. A mech (or its controls mapper / player) released at round end but not removed from "
|
|
"the UpdateManager -- classic P5 teardown hazard (`CLAUDE.md` DO-NOT: removal on death "
|
|
"is the P5 teardown crash).\n"
|
|
"2. **[T4]** Build 4.11.659 modified `Mech::PerformAndWatch` (the #82 peer body-channel "
|
|
"fix touches the peer pose block and dereferences the replicant's mapper). If that "
|
|
"pointer can be stale during teardown, the new code is on the suspect list -- but note "
|
|
"the fault is an indirect CALL early in the function, and the #82 block is a data read "
|
|
"further in, so this most likely predates it. Check the 641/642 logs for the same "
|
|
"signature before blaming 659.\n\n"
|
|
"Both testers' full session logs are archived (`steam_20260730*.log`, 3 machines) -- the "
|
|
"tail of each will show what was being destroyed in the seconds before the fault."))
|
|
|
|
NEW.append((
|
|
"Peer sees a LIVE mech as WRECKAGE after a mech-to-mech collision (no death) -- it keeps "
|
|
"maneuvering and fighting",
|
|
SRC +
|
|
"**This is a wreck-graphic bug with a NEW trigger: a collision, with no death and no "
|
|
"respawn involved.** Filed separately from #81 (which is the respawn-triggered zombie "
|
|
"wreck) for that reason.\n\n"
|
|
"SAURON: \"BUG NOTE: reported by both Oracle and Rajel that I appeared as wreckage moving "
|
|
"and shooting aok\" -- \"I was in a Loki HELLBRINGER\". Oracle posted a screenshot "
|
|
"captioned \"wrecked Sauron moving around the map\".\n\n"
|
|
"Oracle's written notes (item 8) give the trigger precisely:\n"
|
|
"> Sauron's Hellbringer crashed into RajelAran's Sunder, Hellbringer rendered as "
|
|
"wreckage (did not die) and continued to manuever and fight back. When the two mechs "
|
|
"initially collided, Sunder started skating and resumed normal animation after coming to "
|
|
"a stop.\n\n"
|
|
"So a **collision** put the peer-side Hellbringer into the death/wreck graphic while the "
|
|
"mech was alive and fully functional -- and the same collision knocked the other mech's "
|
|
"gait into the ski state (that half is #52, commented there).\n\n"
|
|
"**Where to look:** what the collision path does to the replicant's graphic state. The "
|
|
"wreck look is the burning/death graphic (graphicAlarm 9, plus the burning-state "
|
|
"flag) -- something in the collision/impact handling is selecting it on the peer. Note "
|
|
"the prior art in #81's notes: graphicAlarm 9 was previously corrupted to 3/4 by the leg "
|
|
"branch. A collision-driven graphic selection that lands on the wreck index is exactly "
|
|
"the same class of bug at a different call site.\n\n"
|
|
"**RajelAran has video of the event** -- ask him for it, it captures both this and the "
|
|
"#52 ski.\n\n"
|
|
"Related: #81 (respawn-triggered zombie wreck -- closed as clean this session), #52 "
|
|
"(collision-triggered ski, same event), #83-family collision work in build 659 "
|
|
"(`14ff351`/`9c83a46` changed collision damage handling -- check whether the collision "
|
|
"now sets a damage/impact state the graphic selector misreads)."))
|
|
|
|
for title, body in NEW:
|
|
gitea.create(title, body)
|