refactor(runtime): extract local teleport and player mode

Move local teleport, player-mode, animation, shadow, and sealed-dungeon lifetimes out of GameWindow. Make player-mode entry transactional and isolate approach completions by controller lifetime and approach generation so stale callbacks cannot affect replacements.

Co-authored-by: Codex <noreply@openai.com>
This commit is contained in:
Erik 2026-07-22 02:50:15 +02:00
parent c557038353
commit eeb0f6b45c
29 changed files with 3311 additions and 1073 deletions

View file

@ -27,6 +27,7 @@ public sealed class AutoEnterPlayerModeTests
// Defaults TRUE: the world-reveal hold is not under test in the
// original K.2 cases (see WorldNotReady test for it).
public bool WorldReady = true;
public bool PlayerModeActive;
public int EnteredCount;
public PlayerModeAutoEntry Build() =>
@ -35,7 +36,8 @@ public sealed class AutoEnterPlayerModeTests
isPlayerEntityPresent: () => PlayerEntityPresent,
isPlayerControllerReady: () => PlayerControllerReady,
isWorldReady: () => WorldReady,
enterPlayerMode: () => EnteredCount++);
enterPlayerMode: () => EnteredCount++,
isPlayerModeActive: () => PlayerModeActive);
}
[Fact]
@ -180,4 +182,25 @@ public sealed class AutoEnterPlayerModeTests
Assert.True(guard.TryEnter());
Assert.Equal(1, s.EnteredCount);
}
[Fact]
public void PortalEntryThatAlreadyActivatedPlayerMode_RetiresArmedGuard()
{
var s = new State
{
LiveInWorld = true,
PlayerEntityPresent = true,
PlayerControllerReady = true,
};
var guard = s.Build();
guard.Arm();
// F751/player-mode activation occurs before the auto-entry phase in
// the update graph. The guard must not rebuild that PortalSpace owner.
s.PlayerModeActive = true;
Assert.False(guard.TryEnter());
Assert.False(guard.IsArmed);
Assert.Equal(0, s.EnteredCount);
}
}