Files
BT411/scratchpad/night6/file_81update.py
T

38 lines
2.9 KiB
Python

"""#81 zombie wreck -- add the new field observation (it SHOOTS)."""
import base64
import json
import subprocess
import urllib.request
REPO = r"C:\git\bt411"
BASE = "https://gitea.mysticmachines.com/api/v1/repos/VWE/BT411"
out = subprocess.run(["git", "credential", "fill"],
input="protocol=https\nhost=gitea.mysticmachines.com\n\n",
capture_output=True, text=True, cwd=REPO)
cred = dict(l.split("=", 1) for l in out.stdout.strip().splitlines() if "=" in l)
AUTH = "Basic " + base64.b64encode(
(cred["username"] + ":" + cred["password"]).encode()).decode()
def call(method, path, payload=None):
data = json.dumps(payload).encode() if payload is not None else None
r = urllib.request.Request(BASE + path, data=data, method=method)
r.add_header("Authorization", AUTH)
r.add_header("Content-Type", "application/json")
return json.load(urllib.request.urlopen(r))
BODY = """**Second sighting, build 4.11.642, and it narrows the bug a lot:** the zombie wreck was observed **moving AND SHOOTING**.
That removes the main ambiguity. A wreck that fires weapons is a fully ALIVE entity under its pilot's control -- so this is not "a dead mech that failed to stop." Only the **death/wreck VISUAL state** is stale on the replicant: the burning effect and the destroyed-skin graphic swap get applied at death and are never cleared when the respawn arrives. The pilot sees themselves normally; peers see a flaming wreck driving and firing.
That reframes the hunt: not "why is a dead mech alive" but "**which wire mechanism is supposed to tell a peer that a zone's destroyed graphic state and burning effect are OFF again, and why doesn't it fire on respawn?**" Relevant known facts: the port deliberately never issues DestroyEntityMessage on death (the wreck stays as scenery -- removing it caused the P5 teardown crash), so respawn must explicitly un-dress the entity; zone GRAPHIC-state changes do force a DamageZone update record on a master (`engine/MUNGA/EXPTBL.cpp` ~537-550) whereas zone damage LEVELS replicate only when the explosion table's tier is crossed; and mech message ids 0x17/0x18 are Set/ClearBurningState.
Likely sibling of the "respawn does not reset X" family: #38 (colors), #55 (coolant/heat), #70 (torso twist). Also relevant from tonight's logs: **every one of the five tester machines logged a `death for player N:1 SWALLOWED -- a death cycle is already pending` warning** (#57's latch dedup), and the host's respawn bookkeeping showed one stranded death cycle plus three spurious drop-zone RESETs with the death tally reverted to `#0`. If a respawn's visual reset runs inside a cycle that got swallowed or re-fired, that would explain both the stale wreck and why it self-corrects after a later clean respawn.
A code + log investigation is running now; I'll post the root cause and a fix proposal here."""
call("POST", "/issues/81/comments", {"body": BODY})
print("#81 updated")