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

15
tests/AcDream.Runtime.Tests/Entities/RuntimeRemoteFirstEntryStateTests.cs
View file

@ -923,6 +923,21 @@ public sealed class RuntimeRemoteFirstEntryStateTests
var generation = new RuntimeGenerationToken(1UL);
Lifetime.BindEventContext(() => generation, static () => 1UL);
// 670f307c: CreateObject frames are landblock-local, so a remote
// conductor's PrepareMover resolves them through Runtime's world
// frame (RuntimeSetPositionState.PrepareMover:1526-1544) and
// returns RetrySetupUnavailable until that frame exists. Only the
// accepted local-player Create publishes it
// (RuntimeEntityObjectLifetime.RegisterEntityCore:558-570 ->
// RuntimePhysicsState.ObserveLocalWorldFrame) — production always
// registers the player before any broadcast Create is driven.
// Model that ambient world fact here, alongside the resident
// terrain above, rather than registering a second entity that
// would perturb every ownership-ledger assertion in this class.
Lifetime.Physics.ObserveLocalWorldFrame(
Cell,
teleportAdvanced: false);
// The SAME conductor instance RuntimeEntityObjectLifetime itself
// constructs and wires into the residence's multicast retirement
// fan-out and BeginSessionClear — never a standalone copy — so