FORKC_ANALYSIS_ENGINE_REALITY_2026-07-27.md

pipelines/FORKC_ANALYSIS_ENGINE_REALITY_2026-07-27.md

FORK C — ENGINE REALITY

The challenge (Josh, 2026-07-27): *"why does it need a map change cover instead of a playable

loading transition?"* — can the player keep playing through the Flores→Bali→Sumatra seams and the

CH_05 four-map belt, with no cover at all?

Axis: what a playable transition actually costs in UE 5.8, and what our build does today.

Every claim about our code is read from the file; every claim about the engine is read from the

installed C:\Program Files\Epic Games\UE_5.8\Engine\Source. Absence claims are positive-controlled.

---

§0 THE HEADLINE THE FORK TURNS ON

There is no cover today. The thing Josh is challenging is a *plan item*, not a built thing.

PresentTravelCard() is a UE_LOG and nothing else

(Source/Humanity/Private/Quest/HumanityQuestSliceDriver.cpp:356-365), and the whole project

contains zero loading-screen, level-streaming, or seamless-travel code:

grep -rIni "loadingscreen|streamlevel|seamlesstravel|movieplayer|LoadPackageAsync"
      Source/ Config/ Tools/    ->  0 hits
POSITIVE CONTROL: same grep for "OpenLevel|UGameplayStatics" over Source/ -> 87 hits

Config/DefaultEngine.ini [/Script/EngineSettings.GameMapsSettings] sets EditorStartupMap and

GameDefaultMap only — TransitionMap is unset and bUseSeamlessTravel appears nowhere.

So the honest framing is not "replace the cover with a transition." It is **"we have not built

either one yet; which one do we build first."** Nothing is thrown away by choosing the transition.

The cover is docs/PRE_5090_BUILD_PLAN_VOL2.md U11.26 ("Loading / level-streaming /

transition-screen UX — loading screen + hitch-masking across the Flores→Bali→Sumatra map changes"),

still BUILD-NOW, unstarted.

The second headline: the expensive thing people mean by "seamless streaming" (two region maps

resident at once) is not what the engine-native path does. UWorld::SeamlessTravel goes

source → *tiny* transition → destination, so the two big maps are never co-resident. The

double-occupancy cost belongs to a different option (level-instance streaming), and conflating them

is what makes the playable transition look unaffordable when it isn't.

---

§1 WHAT THE BUILD ACTUALLY DOES TODAY (read, not remembered)

1.1 The seam

UHumanityQuestSliceDriver (a UTickableWorldSubsystem) owns it.

The CH_05 four-map belt is not seamed at all. :51-53 says so explicitly: *"the intra-CH_05 map

hops (Samosir→Palembang→Borobudur→Angkor) are a further seam layer, not this pass."* Only the

*arrival* map (SamosirToba) is wired.

1.2 What carries, and what silently dies

This is the table the fork actually turns on. Scopes read from the class declarations:

GameInstance-scoped — survives any map change:

UWorldStateSubsystem (ws.*), UQuestSubsystem, UHumanityClueSubsystem, UCombatTelemetrySubsystem.

World-scoped — destroyed and rebuilt at every map change, including under seamless travel:

UHumanityAudioSubsystem, UHumanityCombatFeelSubsystem, UHumanityDensitySubsystem,

UHumanityStatusSubsystem (burn/poison/bleed), UHumanityGatherLedger,

UHumanitySceneSubsystem, UHumanityQuestSliceDriver, UHumanityQACaptureSubsystem,

UHumanityTerrainShotSubsystem.

Actor-scoped — destroyed with the level: the ASC and attribute set live on the pawn

(Public/Core/HumanityCharacter.h:340,343 — AbilitySystemComponent / AttributeSet as

TObjectPtr members, resolved through the PlayerState per the header comment at :26).

Neither savegame persists player state. Positive-controlled:

grep -rn "Health|Vril|Transform|Location|Attribute"
     Public/Quest/QuestSaveGame.h  Public/WorldState/WorldStateSaveGame.h   ->  0 hits

**Therefore: today every cross-map seam silently resets the player's health, vril, cooldowns, active

status effects, gather ledger, ambient audio bed, and world position.** Under a cover, nobody sees

it. Under a playable transition, all of it is on screen. *This — not streaming — is the real cost of

the fork, and it is not in any plan item today.*

1.3 The maps on disk — measured

Content/Maps/AngkorKhmer.umap      377,431,173 B     Content/ total: 776 MB / 317 files
Content/Maps/FloresIsland.umap      80,767,015 B     Maps/ alone:    470 MB
Content/Maps/Bali.umap              28,077,397 B
Content/Maps/BorobudurMerapi.umap    5,172,269 B
Content/Maps/SamosirToba.umap          225,808 B   <- stub terrain
Content/Maps/PalembangMusi.umap        192,854 B   <- stub terrain
Content/Maps/GreyboxArena.umap          24,245 B

None of the six region maps is World Partition. Content/__ExternalActors__/Maps/ and

__ExternalObjects__/Maps/ contain only LiangBua_TerrainSmoke (139 files). Cross-checked by

scanning the packages themselves:

grep -ac "WorldPartition" per .umap:
  FloresIsland 0 · Bali 0 · SamosirToba 0 · AngkorKhmer 0 · BorobudurMerapi 0 · PalembangMusi 0
  LiangBua_TerrainSmoke 3   <- the only WP map, and it is the retired smoke test

Correction to a comment in our own code.

Private/QA/HumanityQuestAutomationTests.cpp:1264 says the full PIE travel is *"a real OpenLevel

across World-Partition maps."* That is false — the region maps are monolithic non-WP levels

with the landscape serialized inline. Worth fixing so no later agent plans against it.

Real-world extents, computed from Saved/Terrain/*_terrain_meta.json (1 uu = 1 cm, landscape

centred on origin, import_flores_landscape.py:138,147-148):

A non-WP landscape has no partial residency: all 608 Angkor components, with every heightmap and

weightmap texture, must be resident before BeginPlay. That is the whole story behind §1.4.

1.4 Measured load times — the only real numbers we have

Parsed from every Saved/QA/capture_run*.log (LogLoad: Took N seconds to LoadMap(...)), n = 115:

Read these honestly, in both directions:

• *Pessimistic:* these are Editor -game runs. Our own capture log line 512 reads

`AsyncLoading2 - Created: Async Loading Thread: false, Async Post Load: false, Multithreaded:

false` — the editor runs the loader single-threaded on uncooked assets. The shipped defaults are

s.AsyncLoadingThreadEnabled=True / s.EventDrivenLoaderEnabled=True /

s.UseBackgroundLevelStreaming=True (Engine/Config/BaseEngine.ini:1712,1713,1717). A cooked

IoStore build will be materially faster.

• *Optimistic:* these maps are empty greybox — landscape, a material, a handful of site-marker

posts. Content/ is 776 MB across 317 files with essentially no meshes, textures, foliage, NPCs,

or audio. Content-complete Ch 2-5 is a different order of magnitude.

• No cooked build has ever been produced. Saved/StagedBuilds and Saved/Cooked are both

ABSENT; Binaries/Win64 holds only HumanityEditor.target + editor DLLs. There is no Shipping

target and no packaging config. Every number on this page is an editor number.

1.5 Memory — we have none

Saved/QA/Soak/soak_2026-07-27_040011.md: *"psutil memory sampling: OFF (psutil not installed —

memory n/a)."* The peak RSS (MB) column reads n/a for all 21 runs across both existing soak

reports. run_soak.py:70 has the poll_peak_rss collector wired and ready.

The dev box is also the wrong instrument: the capture log reports

Memory total: Physical=15.6GB with 14428.70 MB used, 1565.15 MB free at editor start. We cannot

credibly measure a double-occupancy peak on a 16 GB machine that is already full.

pip install psutil + one soak re-run is the cheapest highest-value action on this entire axis.

It converts every memory claim below from reasoning to evidence, costs zero tokens, and needs no

5090.

1.6 The declared perf floor

_source/01_Tier_1_Foundation/T1_Build_Pipeline_Contracts [ACTIVE v1.0].md §1.7:

• steam_deck_minimum — *"Lowest polygon and draw call budget tier. Asset streaming budget

tightest. Used as floor for build viability."*

• Vril Sites / Architectural Features at that tier: ~2,000 draw calls per rendered view and a

~1.0 GB VRAM streaming-pool budget.

• §1.7 also records an open veto surface: *"confirmation that the steam_deck_minimum floor is a

real ship commitment."* It is declared, not yet ratified.

The Deck is 16 GB unified LPDDR5 (CPU + GPU share it), and its storage floor is eMMC or UHS-I

microSD, roughly an order of magnitude slower than this box's NVMe. A 377 MB package is single-digit

seconds of *pure I/O* there before any deserialize or GPU upload. That is the number that decides

between option (b1) and option (b2) below.

---

§2 WHAT A PLAYABLE TRANSITION REQUIRES IN UE 5.8

Every primitive below was read from the installed engine — none of this needs building from scratch.

The three engine facts that decide this fork

FACT 1 — seamless travel is asynchronous and the transition world is live.

FSeamlessTravelHandler::StartLoadingMap calls LoadPackageAsync (World.cpp:8493). The transition

world ticks and renders the entire time the destination streams in. That is precisely "a playable

loading transition," and it is engine-native, not a bespoke system.

FACT 2 — seamless travel does NOT double-occupy the two big maps.

StartTravel loads the *transition* map first (World.cpp:8330-8380); only once

bSwitchedToDefaultMap is true does StartLoadingDestination() fire (:8508). The sequence is

source → transition → destination, so the resident pair is always {big, tiny} then

{tiny, big} — never {big, big}. Peak ≈ max(region map) + vessel, essentially the same peak we

already pay with OpenLevel.

FACT 3 — the mechanism can land with zero content.

If TransitionMap is empty the engine *"create[s] a dummy World of the right type to use as the

transition"* (World.cpp:8367-8370). So bUseSeamlessTravel + ServerTravel + the actor-carry

lists can ship before any vessel level is authored, and the vessel drops in later by setting one

ini key. The state-carry work (§1.2) and the art are fully decoupled.

---

§3 THE FOUR OPTIONS, HONESTLY COSTED

(a) Hard OpenLevel + a cover — TODAY (minus the cover)

State: the OpenLevel exists; the cover does not (§0).

To finish: enable the MoviePlayer module, hook FCoreUObjectDelegates::PreLoadMap /

PostLoadMapWithWorld, author one widget. ~1-2 days. Cheapest option on the board.

Player cost: a screen at every region boundary — median 3-6 s on Flores/Bali *today, empty,

uncooked, on NVMe*; ~20 s on Angkor; unknown and worse on the Deck's eMMC.

What breaks: nothing new. ws.* already carries (§1.1). The world-scoped resets (§1.2) stay

invisible because the cover hides them — which is the honest engineering argument *for* (a) and the

honest design argument *against* it.

Build size: +0 MB content.

Verdict: the correct fallback, and the correct thing to keep as the slow-storage escape

hatch. Not a reason to skip the transition.

(b) Seamless streaming with a playable interstitial — SPLIT THIS IN TWO

These two are constantly conflated and have opposite cost profiles. Naming them separately is the

single most decision-relevant thing in this brief.

(b1) UWorld::SeamlessTravel + a TransitionMap — the engine-native path

How: GameMode bUseSeamlessTravel = true; set TransitionMap; swap the OpenLevel call at

HumanityQuestSliceDriver.cpp:402 for World->ServerTravel(DestMap); implement

GetSeamlessTravelActorList on GameMode + PlayerController to carry the pawn (with its ASC),

companions, and the camera; hold with SetSeamlessTravelMidpointPause(true) and release on the

LoadPackageAsync completion.

Memory: peak = max(region map) + vessel. No double occupancy (FACT 2). Safe on the Deck floor

by construction — it is the same peak OpenLevel already pays.

Load time: unchanged in wall-clock; entirely hidden behind live gameplay. Angkor's 20 s stops

being a 20 s screen and becomes 20 s of a river approach.

Engine cost: ~2-4 days for the travel mechanism itself. The real cost is §1.2 — every

world-scoped subsystem and all actor state must be promoted or handed over, because seamless travel

replaces the world too. Concretely:

• promote or hand off UHumanityStatusSubsystem, UHumanityGatherLedger, UHumanityAudioSubsystem;
• carry the pawn + ASC via the keep-list (this is what the keep-list is *for*, so it is cheap);
• a real, specific new bug to pre-empt: TryRestorePendingSeam() runs from

UHumanityQuestSliceDriver::OnWorldBeginPlay (:117-124), and the driver is a

UTickableWorldSubsystem — so under seamless travel it fires on the transition world, which

would consume the pending seam in the vessel and leave the destination with nothing. Gate it on

map identity, or move consumption into PostSeamlessTravel.

Build size: +one small level per seam *class*, not per seam (see (d)).

Verdict: this is the answer to Josh's question. Supported, affordable, memory-neutral.

(b2) ULevelStreamingDynamic::LoadLevelInstance — the expensive one

How: stream the destination map *into the live world* as a level instance, teleport the player,

unload the source.

Memory: genuine double occupancy. Bali + Angkor co-resident = 405 MB of *uncooked greybox*

today; at content-complete that pair alone is the whole Deck budget. This is the option that breaks

the declared floor.

Also breaks: two ALandscape actors in one world at multi-million-uu offsets (UE5 LWC handles

the precision, but nothing handles the memory); level-instance name collisions; and the source

unload needs a GC that hitches — precisely the thing the transition was supposed to remove.

Verdict: reject. It buys nothing (b1) doesn't, and costs the floor. Its only genuine use is

*within* a region (streaming a sub-area), which is really option (c).

(c) World Partition single persistent world — SPLIT THIS IN TWO AS WELL

(c1) Convert each region map to WP — recommended on its own merits, independent of the seam

Why: the landscape becomes ALandscapeStreamingProxy per cell, so Angkor's 608 components stop

being an all-or-nothing 377 MB resident block and become near-cell residency. That is the *actual*

fix for the 20 s Angkor load and the *actual* thing the Deck floor needs. It also unlocks HLOD and

data layers (the era/world-state axis) and PCG-at-scale.

Cost: re-run import/staging per map through WorldPartitionConvertCommandlet or the importer;

re-point stage_ch05.py / stage_bali_ch04.py / stage_flores_ch0*.py actor placement at OFPA;

re-baseline the capture drive (site markers become external actors); absorb the git churn — OFPA

means thousands of small files per map (LiangBua alone is 139 files for a *smoke* map).

Caveat that matters: WP does not remove the seam. Crossing from the Flores partition to the

Bali partition is still a world change. WP makes each side cheap; it does not join them. (c1) and

(b1) are complements, not alternatives.

Where the evidence comes from: BUILD_PLAN_END_TO_END.md rank 25 already orders *"World

Partition + PCG runtime cost at the 1 m hero tier"* as a 5090-day benchmark, and

PRE_5090_BUILD_PLAN.md rank 1 (the X9.5 harness set) is the unmet P0 ENTRY criterion. This decision

is already scheduled; it just needs the numbers.

(c2) ONE partition for the 79-node world — not viable

Measured, from the region metas (haversine on region centres):

Flores  -> Bali        635 km      Palembang -> Borobudur    791 km
Bali    -> Samosir   2,212 km      Borobudur -> Angkor     2,440 km
Samosir -> Palembang   910 km
bounding box of the six STAGED regions:  ~2,449 km E-W  x  ~2,459 km N-S

And that is Ch 2-5 only. The full arc runs Flores → the Azores → Antarctica → the Atacama: a

planetary grid that would be ~99.9% empty ocean cells. Three independent blockers, any one of which

is sufficient:

1. Geography. 635 km of open sea between the first two nodes, 2,440 km between Borobudur and

Angkor. There is no contiguous playable ground to partition.

2. Era canon. T1_World_Geography_Master §11 + §"revisit band": time fluctuation is active

throughout, and Ch 59-65 carries five world-state versions per location. The *same ground*

must exist in multiple simultaneous states. A single static partition cannot represent that;

data layers could in principle, but 79 nodes × up to 5 states is a content combinatorics problem,

not a streaming one.

3. Design canon. WGM §7 L764 + §11 L985,997: free travel between all locations is

Vimana-gated at Ch 55. The world is deliberately sequential and non-traversable until then.

A single world would either have to fake that gate or throw it away.

Verdict: (c2) is a no on canon grounds before it is a no on engine grounds. T0_Region_Index is

76 rows covering all 79 nodes, so the world is up to ~75 region seams — which is exactly why the

per-seam cost model in (d) is the number that matters.

(d) The transition-level pattern (vessel / corridor) — the GoW / Ratchet shape

Engine-wise this is (b1) with an authored payload: same TransitionMap, same

SetSeamlessTravelMidpointPause. They should be costed as one decision, which is why (b1) is the

recommendation and (d) is its content plan.

Cost per seam — the honest breakdown:

• Engine: ~0 marginal after the first. The mechanism is built once.
• **Content: one vessel level per seam *class*, not per seam.** Our seam classes, from

WGM §11 L993-999:

1. sea crossing — Ch 2-37 coastal sailing (Flores→Bali is canonically *"Sea voyage westward to

Bali via Manggarai-Bali trade-network connection"*, WGM Ch 3 travel line);

2. river / riverine — the Musi at Palembang, the Tonlé Sap reach to Angkor;

3. overland / portage — already canon: stage_ch05.py:147 defines kra_traverse as *"an

OFF-MAP compressed portage transition seam … a transition scene site, never a landscape

placement."* We already have a canon precedent for exactly this pattern.

4. Vimana — Ch 55+, a different vehicle and a different presentation.

So roughly 4 vessel levels cover the large majority of ~75 seams, re-dressed per crossing

(skybox, water state, weather, the diegetic beat).

• Build size: a vessel level = boat + water + horizon + a light rig. Realistically **5-50 MB

cooked each; 4 shared vessels ≈ 20-200 MB** total, against a Content/ that is already 776 MB

of greybox and will ship at tens of GB. Negligible.

• The real per-seam cost is canon, not engine. T0_Vehicle_Registry [DRAFT v0.1] has 3 rows,

and the earliest water craft is VH_002 Coastal Skiff at CH_08 (Swahili). Positive-controlled:

there is no vessel row for the CH_03→CH_04 Flores→Bali sea voyage. The Manggarai/Austronesian

crossing craft would have to be minted — a canon-author item, and it lands squarely inside

window-plan rank 21 *"Between-site traversal design (route legs, paths/mounts/boats) — retire

the DEV teleport."*

• The real per-seam risk: the vessel must hold for an unbounded time on a slow drive.

SetSeamlessTravelMidpointPause(true) is exactly that lever — hold the crossing, release on the

async-load callback. Design the vessel beat as a *loop with an exit cue*, never as a fixed-length

cutscene, and the Deck's eMMC becomes a pacing variable instead of a failure.

A strong, cheap consequence: because seam legs are already canon travel (WGM §11 L993: Ch 2-37

is *"ground travel — walking, riding, river and coastal sailing"*), the vessel level is not overhead

invented to hide a load. It is content the plan already owes (rank 21), which the load happens to

hide. That is the difference between a mask and a scene.

---

§4 WHAT BREAKS — CROSS-CUTTING

ws.* carry — safe under all four, with one specific new bug

The GameInstance-scoped UWorldStateSubsystem outlives every option, and the

SaveSync/SetPendingSeam/LoadSync pattern is travel-mechanism-agnostic. The automation test

Humanity.Quest.CrossMapSeam asserts the round-trip directly

(HumanityQuestAutomationTests.cpp:1268-1332) and would keep passing unchanged.

But: that test never performs a real travel — it runs PrepareCrossMapSeam(..., bDeferOpenLevel=true).

Its own comment (:1264-1266) calls the real thing *"a PIE-MANUAL item, verified by the live capture

drive."* So the actual OpenLevel has zero automated coverage today, under either option. And

the new bug named in (b1): TryRestorePendingSeam firing on the transition world would consume the

seam early. Both point at the same missing tooth.

The soak — zero coverage of any option today

Tools/run_soak.py drives run_qa_pass.py --map <M> --skip-tests, one map per OS process

(:128-154), in a seeded shuffle over a 7-map belt. It never crosses a seam. Neither does the

capture drive. So:

• Today's green soak (21/21, soak_2026-07-27_040011.md) proves nothing about any transition.
• A playable transition needs a new soak leg that actually travels — and that leg is precisely

where a leak would show, because seamless travel's world teardown while keep-list actors survive is

a classic leak site. Right now the soak's own report disclaims this: *"each run spawns a FRESH

editor (dies per run), so cross-loop RSS growth reflects DDC/OS caching, not an in-process leak; a

persistent-session leak soak is a later enhancement."*

• Adding N transition levels adds N maps to the mandatory warm-up belt (run_qa_pass.py:783-815) and

N entries to the material-identity tooth's not-applicable list (:166-171).

The capture drive — structurally incompatible until taught

UHumanityQACaptureSubsystem is a UTickableWorldSubsystem armed from OnWorldBeginPlay when

-HumanityQAAuto=<script> is present (HumanityQACaptureSubsystem.cpp:107-134). Under seamless

travel it would arm on the transition world, run its stations there, finalize, and exit before

the destination ever loaded. Named, bounded work: make the subsystem transition-aware (skip arming

when World->IsInSeamlessTravel() or when the map is the transition map), and add an

await_arrival station action alongside the existing advance_to_ch03 (:372-377).

Note the precedent for getting this wrong: BUG-0017 was exactly a capture-drive state-blindness

class (the walk fired CH_03 shots while the CH_02 fork sat unresolved, so no shot ever reached CH_03

state) — discovered by a director frame re-read, not by the tests, which were green 27/0. A

transition adds a second world to be blind about.

BUG-0009 / the DDC contention class — bounded, already gated

BUG-0009's root cause is an unbounded teardown blocking in the DDC quiescence wait under concurrent

editor load; the fix is a detached 120 s watchdog plus a machine-wide single-instance lock

(LOCALAPPDATA/HumanityQA/qa_pass.lock), both landed and self-tested.

Relevance: adding vessel levels adds PSO/shader surface → more DDC writeback per session → more

teardown pressure, and the cold-warm belt grows by one entry per vessel. It does not change the

class — the lock still serializes QA-vs-QA, and the watchdog still bounds teardown. Cost is one

extra ~120 s cold warm-up per vessel, once. The DDC is 832 MB shared

(AppData/Local/UnrealEngine/Common/DerivedDataCache); a handful of small vessel levels is noise

against it.

BUG-0009's own residual note applies here too: the tests leg has the same theoretical teardown-hang

exposure with no in-engine watchdog. A new travel-soak leg inherits that exposure and should open a

new record rather than re-litigating BUG-0009.

---

§5 WHAT THE 5090-ERA BAKE CHANGES — AND WHAT IT DOESN'T

Changes:

• A cooked build, for the first time ever. No Saved/Cooked, no Saved/StagedBuilds, no

Shipping target exists today. Cooking turns on IoStore + the async loading thread

(s.AsyncLoadingThreadEnabled=True is the shipped default, and our editor runs it false —

verified both ways), which should cut the §1.4 numbers materially. **Every load-time figure on

this page is provisional until that first cook.**

• The X9.5 benchmark set can finally run (PRE_5090_BUILD_PLAN.md rank 1, the unmet P0 ENTRY

criterion), including BUILD_PLAN_END_TO_END rank 25's *"World Partition + PCG runtime cost at

the 1 m hero tier."* That is where option (c1) earns its ruling with evidence instead of argument.

• 128 GB RAM makes a double-occupancy experiment measurable — on a machine where it will always

pass. Useful for finding leaks, useless for the floor.

Does NOT change:

• The Steam Deck floor. A 5090 makes all four options look free and tells you nothing about

16 GB unified memory over eMMC. The floor decision (b1 vs b2) must be made on the Deck's numbers or

on the architecture, and (b1) wins it on architecture (FACT 2) without needing a Deck at all.

• The state-carry work in §1.2. No hardware fixes a world-scoped subsystem being destroyed.
• The canon gap. No vessel row exists for the Flores→Bali crossing regardless of GPU.

---

§6 THE ENGINE-AXIS READ

Josh's challenge is correct, and cheaper than it sounds — on one condition.

The playable transition must be UWorld::SeamlessTravel + a TransitionMap (b1/d), not

level-instance streaming (b2). Under b1 the two big region maps are never co-resident (FACT 2), so

the Deck-floor objection that makes "seamless" sound expensive **does not apply to the path we would

actually take**. The engine already ships every primitive: async destination load while the

transition world ticks (FACT 1), an actor keep-list built for carrying the pawn and its ASC, and an

explicit midpoint-pause lever for holding the crossing on slow storage.

Three things the fork should carry forward from this axis:

1. Nothing is being retrofitted. There is no cover to remove (§0), and TransitionMap can be

set to nothing and still work (FACT 3), so the mechanism and the art decouple cleanly.

2. The honest cost is not streaming — it is §1.2. Health, vril, cooldowns, status effects, the

gather ledger, the ambient bed and the player's position all silently reset at every map change

today, and no savegame persists any of them. A cover hides that; a playable transition exposes it.

That work is real, bounded, and currently in no plan item. It is also work we owe anyway the first

time a player dies and respawns across a boundary.

3. The cheapest place to prototype is the CH_05 belt, not Flores→Bali. The intra-CH_05 hops are

explicitly unbuilt (HumanityQuestSliceDriver.cpp:51-53), and three of the four maps are tiny —

Samosir and Palembang are 128×128 stubs at 4.4 km square, Borobudur is 31×16 km. Nothing is being

replaced, the loads are ~1.7 s so the vessel beat can be short, and the riverine class

(Musi → Tonlé Sap) plus the already-canon kra_traverse portage give two seam classes for the

price of one prototype. Angkor — 377 MB, 20 s median, 472 km wide — is the stress case to validate

against last, not first.

Two zero-token actions that should happen regardless of how the fork rules:

• pip install psutil, re-run Tools/run_soak.py --maps all. Converts every memory claim in this

document from reasoning to measurement.

• Fix the false comment at HumanityQuestAutomationTests.cpp:1264 ("World-Partition maps") before it

misleads a later agent into planning against a partitioning we do not have.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root