"""Night 13: correct #148's framing with the measured findings. ASCII only.""" import sys sys.path.insert(0, r"C:\git\bt411\scratchpad\night7") import gitea BODY = """**Investigated, narrowed a long way, NOT fixed. Correcting this ticket's own framing first.** ## The title/premise was WRONG -- the cadence is authentic I filed this as "only 13 update records across a 5-minute run". That is not a defect. Reading the payloads with line numbers: ``` 205 RECORD atUpd=0.0436769 rate=0.305433 502 RECORD atUpd=2.3558 rate=-0.305433 1150 RECORD atUpd=-2.39277 rate=0.305433 1698 RECORD atUpd=2.38543 rate=-0.305431 2044 RECORD atUpd=-2.39124 rate=0.305427 ... ``` Those `atUpd` values are the sweep's EXTREMES and `rate` flips sign at each one. **The master sends a torso record on RATE CHANGE**, and the peer dead-reckons `atUpd + rate * elapsed` in between (`ComputeTargetTwist`). 12 records for 12 direction reversals is exactly right -- this is extrapolation-based replication working as designed, not a starved channel. Also ruled out: the `ComputeTargetTwist` clamp. The copy's limits load correctly (`limL=2.44346 limR=-2.44346 enab=1 copy=1`), so `Min/Max` is not pinning `targetTwist` to zero. And the extrapolator itself is exact -- the copy reports `cur == target` on every sample. ## The real defect **The peer's copy torso Performance does not run at all until log line ~1006, while its first record arrived at line 205.** ~800 lines of correctly-replicated twist data integrated by nobody. This is now directly readable because `[torso-copy]` logs on call #0 (`s_cl++ % 120`), so its first line IS the first `TorsoCopySimulation` call. (That also means my earlier "first copy currentTwist != 0 at line 1016" was a SAMPLING artifact -- first *sample*, not first non-zero.) The first tick coincides with the replicant's MODEL bring-up, not with record arrival: ``` [loadclips] end: fScale=0.8 ... hasGimpClips=1 [clipfix] mech 05769358 -> EXTERIOR (lean) [torso] PushTwist COPY node=057A3C68 type=1 twist=-1.52319 ``` So the gate is **above the subsystem level**, somewhere in replicant model/clip initialisation. Not yet found. ## Tried and rejected `Entity::Perform` (ENTITY.cpp:733-793, real engine source) picks the executable predicate by instance -- `IsNonReplicantExecutable()` for masters, `IsReplicantExecutable()` for replicants -- and they differ exactly on `|| lastUpdate >= lastPerformance`, which is what makes an `ExecuteOnUpdate` subsystem run when a record arrives. Mech's reconstructed tick loop used the NonReplicant predicate for every mech, dropping the branch. That is a genuine fidelity gap and it is now **fixed** (`f36f013`) -- but it does **not** move this bug (first copy tick 1014 -> 1006, noise). The torso's own flag was not the gate. ## Consequence, and what it is NOT This is the tail of #141: the peer's missiles launch along the body facing until its torso starts ticking. #141's own fix is complete and verified separately -- every zero-`twistDelta` peer launch now reads `liveTwist=0` on the same log line, and the first launch with `liveTwist=-1.84061` reads `twistDelta=-1.83813`. The launch frame tracks the twist perfectly; there is simply no twist to track until the copy torso wakes up. Likely also relevant to **#37** (MadCat torso BACKWARDS) and **#70** (twist stops after respawn) -- a peer torso that does not tick would sit at its bind pose, and a respawn re-runs model bring-up. Re-test both once this is found. ## Diagnostics now in place `BT_TORSO_LOG`: `[torso-rec-rx]` (receive + raw payload), `[torso-copy]` (cur/target/atUpd/rate plus `limL/limR/enab`), `[torso] PushTwist master|COPY` (per instance-kind). `BT_PROJ_LOG`: `[launchframe]` now carries the shooter's live torso twist, so `twistDelta` and its driver appear on the same line.""" gitea.call("/issues/148", method="PATCH", payload={ "title": "Peer copy TORSO does not tick until replicant model bring-up -- ~800 lines of replicated twist integrated by nobody"}) gitea.comment(148, BODY) print("updated #148")