erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

test(runtime): restore the world-frame precondition across first-entry fixtures

Browse source 
670f307c made remote first-entry placement resolve its landblock-local
CreateObject origin through Runtime's world frame
(RuntimeSetPositionState.PrepareMover:1526-1544) and return
RetrySetupUnavailable until that frame exists. Only the accepted local-player
Create publishes it (RuntimeEntityObjectLifetime.RegisterEntityCore:558-570 ->
RuntimePhysicsState.ObserveLocalWorldFrame).

Fixtures that drive remote conductors in a world with no local player - a
state production never occupies, since the player's own Create always precedes
broadcast Creates - therefore parked forever on RetrySetupUnavailable. Their
initial-create residences never retired, which cascaded into rejected
appearance updates, missing canonical bodies, unconverged ownership ledgers,
and a GameRuntime teardown that could not complete stage 10.

The measured blast radius was far larger than the handoff recorded. It claimed
"six selected fixture failures"; a baseline run found 43. The App suite was
fully green at 01f4791e and 670f307c broke 28 tests at once; the Runtime suite
lost 13, twelve of them in RuntimeRemoteFirstEntryStateTests - the exact
conductor that commit gated. Both commits were verified on focused runs only.

The production gate is correct, so nothing here weakens it. It matches App's
own coordinate owner: LiveWorldOriginState is initialized once from the local
player's spawn (LiveEntityHydrationPorts.cs:226) and rebased only by
StreamingOriginRecenterCoordinator.Advance at a teleport boundary - exactly
ObserveLocalWorldFrame's semantics. Every fixture is repaired by supplying the
missing precondition beside the resident landblock it already models, and not
one expected value or assertion was changed.

The mechanism shipped with zero tests. RuntimeWorldFrameTests now pins its
contract: the local player publishes the frame, remotes never do, neighbouring
landblocks convert at 192 m per step, ordinary movement across a landblock
boundary must NOT rebase it, an accepted teleport must, and a zero cell id
neither publishes nor resolves. That "no rebase on ordinary movement" rule is
load-bearing - if it and LiveWorldOriginState ever disagree, remote objects
are placed a multiple of 192 m from where the world is streamed.

Runtime 1,009/1,009; App 4,048 passed / 3 skipped.

Refs #281.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-03 13:32:28 +02:00
parent c7d5fc14b9
commit 6dcb94ac1b
6 changed files with 310 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

13
tests/AcDream.Runtime.Tests/Session/RuntimeLiveEntitySessionControllerTests.cs
View file

@ -400,6 +400,19 @@ public sealed class RuntimeLiveEntitySessionControllerTests
worldOffsetY: 0f);
runtime.EntityObjects.Physics.SetPosition.CommitCollisionGeneration(
landblockId, 1UL, ready: true);
// 670f307c: a remote conductor resolves its landblock-local Create
// origin through Runtime's world frame
// (RuntimeSetPositionState.PrepareMover:1526-1544) and parks on
// RetrySetupUnavailable until that frame exists. Production publishes
// it from the accepted local-player Create
// (RuntimeEntityObjectLifetime.RegisterEntityCore:558-570), which
// always precedes broadcast Creates. Model it with the resident
// landblock it belongs to, so these direct-sink tests keep asserting
// exact single-entity ledgers.
runtime.EntityObjects.Physics.ObserveLocalWorldFrame(
landblockId | 0x0001u,
teleportAdvanced: false);
}
private static RuntimeFirstEntryDriveController CreateDrive(