docs(overhaul): recover exact starter-dungeon gate pose

Verify source coordinates against an actual earlier materialization log. Record teleloc WXYZ ordering independently of the Position constructor; keep tutorial and combat coverage claims distinct.
This commit is contained in:
Erik 2026-09-05 10:36:18 +02:00
parent 1577298036
commit d575851665
2 changed files with 25 additions and 4 deletions

View file

@ -611,10 +611,12 @@ to the existing corpus ("you can use what you have"). Pin dungeon landblocks
Facility Hub or the Holtburg foundry. `0x01250126 [30 -60 6.005]` is the actual
meeting-hall-portal dungeon arrival in
`docs/research/2026-06-13-dungeon-g3-handoff.md` (71 EnvCells, no buildings).
`0x8C0401AD` is the starter-dungeon respawn in
`docs/research/2026-07-13-same-dungeon-respawn-landblock-identity-pseudocode.md`;
its exact full standing pose still needs recovery before a scripted launch
(the `(1,2,3)` values in unit tests are synthetic, not a gate location).
`0x8C0401AD [12.319900 -28.482000 0.005000]` is the starter-dungeon respawn
recorded in `docs/research/2026-07-13-same-dungeon-respawn-landblock-identity-pseudocode.md`,
with its complete source-backed pose recovered in S5 packet§48 below.
This is a training dungeon, explicitly not a claim of a combat-dungeon sample;
its sealed EnvCell traversal is the intended non-cathedral indoor control.
The `(1,2,3)` values in unit tests are synthetic, not gate locations.
These are selected inputs, **not current-binary PASS evidence**. Both still
owe the complete stairs/walls/portal, camera-seam and portal-in/out checks.

View file

@ -4526,3 +4526,22 @@ to the existing corpus. Plan§10 now pins0125 (recorded01250126 arrival) and
are not new PASSes or substitutions for Facility/cathedral rows. Recover the
starter's full standing pose before scripting; unit-test XYZ is not live
position evidence. No owner choice is blocking the portal repair.
Starter pose recovered and independently verified by the lead:
`0x8C0401AD [12.319900 -28.482000 0.005000]`. Existing local ACE reference
`C:\Users\erikn\.codex\worktrees\af5e\acdream\.test-out\ACE\Source\ACE.Entity\CharacterPositionExtensions.cs:2233`
maps Yaraq's starting-area case to2349072813 (=8C0401AD), then constructs
position12.3199,-28.482,0.0049999995 and quaternion(X,Y,Z,W)=
(0,0,-0.9408059,-0.3389459). Raw source SHA256
358156B9614D952699E4895FBD20477B5A8D459707B7172F2F9CFFE7A2D0A490.
`Position.cs:220228` confirms constructor order. The lead separately checked
`ACE.Server/Command/Handlers/AdminCommands.cs:919951`: **teleloc arguments
are W,X,Y,Z**, despite that file's stale preceding comment. A full command is
`/teleloc 8C0401AD 12.319900 -28.482000 0.005000 -0.338946 0 0 -0.940806`;
passing the constructor's XYZW order directly would be wrong.
The existing `C:\Users\erikn\.codex\worktrees\af5e\acdream\logs\respawn-gate-20260713-200900.out.log:4258`
independently records this cell and repeated materialization at
(12.3199,-28.482,0.01); retain source Z=.005, not the post-snap .01.
This is a starter/training dungeon, not a combat-dungeon proof. The selected
pair exercises independent sealed dungeon geometry; Tusker retains the
separate dense combat/casting requirement. No current-binary gate ran here.