Correct on its own merits as a fidelity fix; it is NOT the cause of #148, and
I am not claiming it is.
Entity::Perform (ENTITY.cpp:733-793, real engine source [T0]) picks the
executable predicate BY INSTANCE:
if (GetInstance() != ReplicantInstance) IsNonReplicantExecutable()
else IsReplicantExecutable()
and the two differ exactly on the replicant case (SIMULATE.h:195-206):
NonReplicant : (flags & DontExecuteFlag) == 0
Replicant : (flags & DontExecuteFlag) == 0 || lastUpdate >= lastPerformance
`ExecuteOnUpdate()` SETS DontExecuteFlag -- it means "do not tick me every
frame, tick me when an UPDATE ARRIVES". Mech's reconstructed tick loop used
the NonReplicant predicate for EVERY mech, dropping the branch, so on a
replicant any ExecuteOnUpdate subsystem could never run however many records
arrived. Restored.
Measured: it does NOT move #148 (first TorsoCopySimulation call 1014 -> 1006,
noise). So the torso's own flag was not the gate. Keeping it because the
engine source is unambiguous about what the loop is supposed to do.
WHAT #148 ACTUALLY IS, now much better characterised:
* The record CADENCE is authentic -- my original "only 13 records" framing was
wrong. Payloads are the sweep EXTREMES with `rate` flipping sign each time
(atUpd 0.0437, 2.3558, -2.3928, 2.3854, ...): the master sends on RATE
CHANGE and the peer dead-reckons `atUpd + rate * elapsed` between them. 12
records for 12 direction reversals is correct, not starved.
* The real defect is that 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 integrated by nobody. 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, in replicant model/clip init.
Not yet found; #148 stays OPEN.
Also: [torso-copy] logs on call #0 (s_cl++ % 120), so its first line IS the
first Performance call -- that is what makes the 205-vs-1006 gap readable, and
it is why the earlier "first copy currentTwist != 0 at 1016" reading was a
SAMPLING artifact, not a measurement of when the twist started.
Probe additions kept: [torso-copy] now prints limL/limR/enab (which ruled out
the ComputeTargetTwist clamp -- limits load correctly at +/-2.44346 on the
copy), and [launchframe] now prints the shooter's live torso twist so
twistDelta and its driver sit on the SAME line. That pairing is what proved
#141 is fully fixed: every zero-twistDelta peer launch reads liveTwist=0, and
the first launch with liveTwist=-1.84061 reads twistDelta=-1.83813.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
