Skip to content

Week 2026-W37 — Ricky Lu

  • [2026-09-07 12:55] Per-Act WP Maps - DONE, submitted as CL 114554.

  • Created Content/Rephrased/Levels/Act1/Lvl_Act1 and Act3/Lvl_Act3 as World Partition worlds.

  • Used the Empty Open World template deliberately (not Open World): skips the Landscape, sky atmosphere, clouds and directional light. Art direction is cliff-anchored modeled geometry, top-down Death's Door - not sculpted terrain.
  • Verified Enable Streaming ON in World Settings and the WP Editor grid on both maps.
  • Verified OFPA from disk, not just the UI: per-actor files under ExternalActors/Rephrased/Levels/Act{1,3}/, plus engine-generated _HLODLayer_Instanced/_Merged assets per map (only WP creates those).
  • Naming: went with short Act1/Act3 over Act1_Archive/Act3_CascadeTown. Cascade Town is a codename likely to change, and shorter paths buy MAX_PATH headroom once Level Instances nest. Decided while each map had only 2 OFPA files - renaming later would move hundreds under an exclusive lock.
  • Empty Rooms/ folders created under each act for 003.3 Level Instances; empty dirs do not submit.
  • PIE smoke test only: empty worlds, no lights or PlayerStart, so black screen is expected. Confirms load + no WP errors, nothing more. Real streaming walkthrough waits on 003.5.

The two-designer ownership test - NOT run as written. Only a solo convert/revert sanity check. Reasoning for dropping it: Perforce binary+l makes .uasset merge conflicts structurally impossible. That holds for actors, but does not cover the .umap itself (single exclusive lock - World Settings, Data Layer instances, HLOD assignment, i.e. all of Data Layer/HLOD work), nor partial submits where a .umap ships without its external actors. The Level Instance acceptance criterion is the same two-designer test, so its result should be cited to close 003.1 rather than asserting it was unnecessary.

Open, needs lead input:

  • Vertical stacking. WP runtime grid is 2D by default; cells are unbounded in Z, so Cascade Town's 5 stacked sheets share a cell. Options weighed: 2D grid, 3D grid, Data Layer per sheet, separate map per sheet. The overlook requirement (whole town readable as one rune from the sky layer) needs lower sheets renderable via distance-driven HLOD, which rules out separate maps and fights per-sheet Data Layers. Recommend staying on 2D and revisiting at 003.5 with measurements - grid settings are near-free to change, splitting maps is not. Also avoids a 3rd Data Layer axis (5 sheets x ruins/repaired x gameplay/environment = 20 combos).
  • Ruins/repaired authoring model. If rooms are Level Instances, the natural 003.4 shape is a pair per room (LI_X_Ruined / LI_X_Repaired) on separate Data Layers. Needs deciding BEFORE designers author rooms - retrofitting variants onto finished rooms is a duplication slog.
  • Design still owes the per-room ownership plan (2026-09-02 sync section 8 action item, still unassigned).

Next: Level Instances. Conventions to settle first - Level Instance not Packed Level Actor (runes are interactive); Partitioned runtime behavior with puzzle-critical actors marked not spatially loaded; whether room levels get OFPA themselves (leaning yes, allows a designer+artist pair on one room); LI_ prefix, short names for path length.

  • [2026-09-10 14:24] Level Instances for per-designer room ownership - DONE. [AMENDED 2026-09-10 - the non-OFPA room ownership decision below is SUPERSEDED; see the amendment entry at the end of this file.]

Scaffolding submitted as CL 114744 (pending 114561 renumbered on submit): LI_Test01 and LI_Test02 under Content/Rephrased/Levels/Act3/Rooms/, 3 cubes each, placed into Lvl_Act3 at world origin and (5000,0,0).

Two-designer concurrent test - PASSED:

  • CL 114779 khanlon@khanlon_FinalBoss_Laptop edited LI_Test01.umap#2
  • CL 114780 rsafadi@rsafadi_withr_rephrased edited LI_Test02.umap#2
  • Submitted 38s apart. Each changelist touched exactly one file - its own room. Disjoint. Lvl_Act3.umap appears in neither.
  • Caveat for the record: the 38s gap infers rather than measures overlapping checkouts. Under binary+l a file is locked from checkout through submit, so both succeeding in that window means both locks were held concurrently.

Editing paths (Test C) - PASSED:

  • "Edit" on a placed Level Instance checks out the ROOM's .umap, not Lvl_Act3. This was the risk case; if in-context editing had checked out the parent map it would have serialised the whole team on the act map.

Ownership seam confirmed in both directions:

  • Room CONTENTS = the room's own .umap, one exclusive lock, owned by whoever builds it.
  • Room PLACEMENT in town = one external actor file under ExternalActors/Rephrased/Levels/Act3/Lvl_Act3/, separate lock.
  • So one person can rearrange the town layout while another builds a room interior. No contention.

Design decisions locked by this task:

  • Room levels are PLAIN levels, not World Partition. Level Instances are meant to be non-WP levels embedded in a WP world.
  • [SUPERSEDED 2026-09-10 - rooms are now World Partition, which forces OFPA on. See amendment at end of file.] Rooms are NOT OFPA: one room = one .umap = one lock, ownership enforced by Perforce itself. Revisit only if a designer+artist pair needs to share a single room simultaneously.
  • Pivot = centroid in X/Y, floor level in Z. Rotation about a centred pivot spins a room in place instead of swinging it through an arc; Z=0 at the floor means placing a room is "set Z to surface height" with no half-height offset, which matters for 5 stacked sheets. Revisit if the town moves to a strict square-tile grid, where min-corner would beat centroid.
  • Naming: LI* prefix for room assets vs Lvl* for act maps. Short names for MAX_PATH headroom.

Open / next:

  • Vertical stacking still unresolved for the lead. WP runtime grid is 2D by default, cells unbounded in Z, so Cascade Town's 5 stacked sheets share a cell. Recommendation stands: stay on the 2D grid, revisit at 003.5 with measurements. Grid settings are near-free to change; splitting into separate maps is not, and the overlook requirement (whole town readable as one rune from the sky layer) needs lower sheets renderable via distance-driven HLOD, which argues against separate maps and against per-sheet Data Layers.
  • LI_Test01 / LI_Test02 are disposable and should be deleted before real rooms land.

  • Data Layer scope has changed from the earlier summary. Ruins/repaired is now explicitly OUT of scope unless design confirms the state. The task is now: define an Editor vs Runtime Data Layer policy, a naming policy, validate editor workflow separation for art / gameplay / triggers / audio-VFX / blockout / debug, and spike a runtime layer ONLY if design has a real state-swap need. First thing to test there: whether actors INSIDE a Level Instance can be assigned to the parent world's Data Layers - if not, layering happens at room granularity and the per-discipline plan changes shape.

  • [2026-09-10 15:31] Data Layer Phase 0 result — Data Layers do NOT reach inside Level Instances. FOR ENG LEAD REVIEW. [SUPERSEDED 2026-09-10 - this headline finding was correct only for NON-WP room levels. With a World Partition room that has streaming DISABLED, Data Layers DO reach inside Level Instances. See the RESOLVED entry at the end of this file before acting on this.]

FINDING Actors inside a Level Instance cannot be assigned to the parent world's Data Layers. Data Layers operate at room granularity only.

HOW IT WAS TESTED (Lvl_Act3, probe asset DL_Test, type Editor) - Test 1 — the room as a whole: dragged the LI_Test01 LevelInstance actor onto DL_Test. WORKS. Adds an element to the actor's "Data Layer Assets" array (membership is stored on the actor as a list of asset refs, which is why an actor can be in several layers). - Test 2 — an actor inside the room: entered Edit on LI_Test01, selected a cube. FAILS. The Details panel offers no Data Layers section at all, and the layer cannot be dragged onto the cube.

WHY (this is not a bug or a 5.8 limitation) Data Layers are a World Partition feature. Room levels are plain, non-WP levels — a decision made deliberately in 003.3, because Level Instances are meant to be non-WP levels embedded in a WP world. Plain levels have no Data Layer system, hence no section in the Details panel. The Phase 0 result follows directly from the 003.3 architecture.

PERFORCE OBSERVATIONS (good news) - Creating the Data Layer Asset = one new file under Content/Rephrased/DataLayers/, opened for add. No contention with anyone. - Assigning the Level Instance to a layer checked out ONLY the placement actor's external file under ExternalActors/Rephrased/Levels/Act3/Lvl_Act3/. Lvl_Act3.umap was NOT touched. So layer assignment costs one actor-level lock, not a map-wide one.

WHAT THIS MEANS FOR THE TICKET The ticket's six categories (art/set dressing, gameplay runes, trigger/script, audio/VFX, blockout, debug) were written on the assumption that a designer could hide art clutter INSIDE a room while inspecting rune logic (acceptance criteria 2 and 3). Data Layers cannot do that. The policy is not dead, but its scope is narrower than the ticket assumes.

PROPOSED REVISED POLICY (needs lead confirmation) - Actors authored directly in the act map (town set dressing, ambient audio across the streets, map-wide debug helpers) -> Data Layers, six categories as written. - Actors inside a Level Instance -> Outliner FOLDERS for the discipline split. Editor-only, nest with slashes, support hide/show per folder, cost nothing and check out nothing. This still satisfies AC 2 and 3, just with a different mechanism inside rooms. - Whole-room show/hide and any runtime state swap -> Data Layers on the LevelInstance actor. This keeps the policy "small and minimal" as the ticket asks, and does not multiply assets.

ALTERNATIVE CONSIDERED, NOT TAKEN Split each room into per-discipline Level Instances (LI_Garden_Art, LI_Garden_Gameplay, ...), each assignable to its own Data Layer. Would give true per-discipline Data Layer control, and as a side effect would let an artist and a designer own SEPARATE FILES for the same room — which is the designer+artist pairing problem deferred in 003.3. Cost: multiplies room assets, complicates the one-room-one-owner model, and works against the ticket's "keep it minimal" instruction. Flagging it because it solves a real second problem, not because I recommend it for this milestone.

DECISIONS NEEDED FROM LEAD 1. Confirm the narrower Data Layer scope above (Data Layers outside rooms + folders inside), or direct otherwise. 2. Say whether the per-discipline Level Instance split is wanted for the designer/artist pairing problem — that is an architecture call, not a 003.4 call, but 003.4's policy shape depends on the answer. 3. Still outstanding from 003.2: vertical stacking for Cascade Town. WP runtime grid is 2D by default, cells unbounded in Z, so the 5 stacked sheets share a cell. Recommendation stands — stay on the 2D grid and revisit at 003.5 with measurements, because grid settings are near-free to change while splitting maps is not, and the overlook (whole town readable as one rune from the sky layer) needs the lower sheets renderable via distance-driven HLOD.

STILL OPEN IN 003.4 - Phase D: design has not yet been asked whether a real runtime state-swap need exists (Fake World / True World, puzzle phase change, hidden rune reveal). Note the 2026-09-02 sync section 4 says the mind-world is a load-a-new-level approach, so that one is probably not a Data Layer case. Explicit rejection is a valid outcome per the ticket's AC 5. - Probe cleanup: DL_Test is a throwaway. Either delete it and strip the assignment off the LI_Test01 placement actor, or rename it to the first real layer. The assignment must be removed either way or we submit a reference to an asset that may not exist. - LI_Test01 / LI_Test02 remain disposable and should be deleted once 003.3 and 003.4 are signed off.

  • [2026-09-10 16:01] AMENDMENT to the Level Instance entry above — the non-OFPA room decision is SUPERSEDED.

WHAT CHANGED 003.3 recorded: "Rooms are NOT OFPA: one room = one .umap = one lock, ownership enforced by Perforce itself." That is no longer the plan.

WHY - Lead decided artists should NOT have to lock a whole room to work in it. - Team wants Data Layers usable INSIDE rooms. Phase 0 of 003.4 proved Data Layers are a World Partition feature and do not reach into non-WP levels, so rooms must be World Partition. - World Partition REQUIRES OFPA — it is not optional, since WP streams by loading individual actor files per cell. So choosing Data Layers inside rooms necessarily chooses per-actor room files.

EVIDENCE (2026-09-10) - Created LI_Test03 as a new Empty Open World (World Partition) level under Content/Rephrased/Levels/Act3/Rooms/. - Placed it into Lvl_Act3 as a Level Instance: works in the editor. - Runtime check: detached editor shows the cube from the WP room rendering correctly. A WP level nested inside a WP world does function. - This contradicts the prior expectation that Level Instances must be non-WP levels. That assumption was wrong and should not be carried forward.

CONSEQUENCE — read this before relying on the 003.3 ownership model Room ownership is NO LONGER enforced by Perforce. With per-actor files, two people can work in the same room simultaneously; only edits to the SAME ACTOR are blocked by the exclusive lock. Ownership becomes a social convention, not a mechanical guarantee. This is the intended trade — it is what unblocks a designer and an artist working one room together — but it is the exact opposite of the rationale recorded in 003.3, so nobody should cite that entry's ownership argument any more.

COSTS THIS BUYS - Every room carries its own WorldDataLayers, its own ExternalActors tree, and auto-generated _HLODLayer_Instanced/_Merged assets. Across ~30 rooms in Cascade Town that is 30 sets of that overhead. - Path length pressure is now real rather than theoretical: roughly 153 chars for a room's external actor file from this workspace root. Teammates must keep workspace roots short; long user paths will approach the Windows 260 limit. - Data Layer Assets may need instancing into every room individually rather than being defined once in the act map. UNVERIFIED — see pending below.

UNCHANGED BY THIS AMENDMENT - Level Instances remain the room mechanism. - Pivot policy stands: centroid in X/Y, floor level in Z. - Naming stands: LI_ prefix for rooms, Lvl_ for act maps, short names. - The 003.3 two-designer test result (CL 114779 khanlon / 114780 rsafadi, disjoint files, Lvl_Act3.umap untouched) still holds — it just now proves less than it did, since separate-room editing was never the hard case once rooms are per-actor.

PENDING - Test C: with a WP room, do its actors offer a Data Layers section, and are the layers offered the ROOM's own or the parent act map's? This decides the per-room overhead above. In progress. - Full PIE pass beyond the detached-editor check. - LI_Test01 (non-WP) is being kept as a control for comparison. LI_Test01/02/03 and DL_Test all remain disposable.

NOTHING SUBMITTED for this amendment yet — DL_Test, the LI_Test01 placement actor, and this devlog edit are open in the default changelist.

  • [2026-09-10 16:11] RESOLVED — room configuration that gives Data Layers inside rooms AND in-place editing AND no whole-room lock. This SUPERSEDES the headline finding of the 003.4 Phase 0 entry above.

THE WORKING RECIPE for a room level - World Partition: ENABLED - Enable Streaming (World Settings > World Partition Setup): DISABLED - OFPA: on automatically — World Partition forces it and the checkbox cannot be turned off

VERIFIED WORKING with LI_Test03 in Lvl_Act3 (2026-09-10) - Places into the act map as a Level Instance. - Edit in place works (right-click > Level > Edit). Note Ctrl+E is the wrong affordance — it opens the asset, it does not enter in-place edit mode. - Individual actors inside the room can be selected from the Act3 view once in edit mode. - A cube inside the room can be assigned to DL_Test directly from the Act3 map. - Toggling DL_Test's visibility in Act3 hides the cube. Still works after streaming was disabled.

WHY STREAMING HAD TO BE OFF With streaming enabled the editor refuses in-place editing outright: "Level Instance can't be edited in place because it has streaming enabled (/Game/Rephrased/Levels/Act3/Rooms/LI_Test03)". Two nested streaming World Partition grids conflict — both want to own streaming. The parent act map's grid already streams the Level Instance as a whole, so the room's own grid is redundant machinery. Turning it off resolved in-place editing, actor selection from the parent view, and layer assignment from the parent map, all at once.

POLICY ASYMMETRY — easy to get backwards, write it down - ACT MAPS: Enable Streaming ON (verified in 003.2). - ROOM LEVELS: Enable Streaming OFF. Same checkbox, opposite answers.

DATA LAYER ASSETS DO NOT NEED PER-ROOM INSTANCING An actor stores its membership as a "Data Layer Assets" array — a reference to the ASSET, not to a per-map instance. So the actor carries "I belong to DL_X" wherever it lives, and that reference resolves against whatever map the actor is loaded into. Define the layers once in the act map; assign actors inside rooms; resolution happens on load. This removes the ~30x per-room layer-instancing overhead that was feared earlier in this file.

WHAT THIS CORRECTS - 003.4 Phase 0 entry above concluded "Data Layers do NOT reach inside Level Instances." That was correct ONLY for non-WP room levels, which is what 003.3 had specified at the time. With a WP room that has streaming disabled, Data Layers DO reach inside. If that Phase 0 entry has already been sent to the eng lead, it needs this correction attached. - The earlier expectation that Level Instances must be non-WP levels was wrong.

SIDE BENEFIT With streaming off, a room loads as a unit. This removes the half-loaded-puzzle risk flagged in 003.3 — a puzzle whose far-side actor had not streamed in would have been broken.

OWNERSHIP — unchanged from the 003.3 amendment Rooms are per-actor files, so two people can work the same room; only same-actor edits are blocked by the exclusive lock. Ownership is a social convention, not a mechanical guarantee. This is the intended trade and it meets the lead's requirement that artists not have to lock a whole room.

COSTS THAT REMAIN - Every room carries its own ExternalActors tree plus auto-generated _HLODLayer_Instanced/_Merged assets. Observed for LI_Test03: 3 assets plus one file per actor, for a room containing one cube. Multiply across ~30 Cascade Town rooms. - Path length is load-bearing now, roughly 153 chars for a room's external actor file from this workspace root. Keep room names short; teammates must keep workspace roots short.

STILL UNVERIFIED — do before relying on this in production - [NOW VERIFIED 2026-09-10 - PIE passed with streaming off; all rooms render, log clean. See the verification entry at the end of this file.] PIE with streaming disabled. The earlier detached-editor check that showed the cube rendering was done while streaming was still ON. - Runtime Data Layer state on room contents. Runtime layers depend on streaming, and the room now has streaming off, so runtime toggling of a room actor's layer may not behave. Editor visibility is confirmed working and is what 003.4 mostly needs, but this constrains any future runtime layer work on room interiors and must be tested before Phase D commits to anything.

CLEANUP PENDING DL_Test, LI_Test01 (non-WP, kept as control), LI_Test02, LI_Test03 are all disposable. Nothing submitted yet — all open in the default changelist.

  • [2026-09-10 16:56] Verification update on the WP room + streaming OFF configuration (2026-09-10).

PIE with streaming DISABLED — PASSED - Opened Lvl_Act3 and ran PIE. All rooms render: LI_Test01 and LI_Test02 (non-WP control) and LI_Test03 (WP, streaming off). - Output Log clean. No LogLevelInstance / LogWorldPartition / LogStreaming errors. - This closes the gap flagged in the RESOLVED entry above, where the earlier detached-editor check had been done while streaming was still ON. The configuration is now verified at runtime, not just in the editor viewport.

DATA LAYER VISIBILITY TOGGLE COSTS NO CHECKOUT — CONFIRMED - Toggling DL_Test visibility in the editor produced NO Perforce file state change. - This had been an assumption up to now, not a measured result. It is the mechanical basis for the entire editor-collaboration case: layer visibility is per-user session state, so two people can hide different layers in the same map at the same time without contending for any file. Had it written to the Data Layer Instance, every visibility toggle would have been a checkout on a shared file and the policy would not have been viable.

STILL UNVERIFIED — one item remains, and it is the high-severity one - Runtime Data Layer state on room contents. Runtime layers depend on streaming, and rooms now have streaming OFF. Everything verified so far is EDITOR-side visibility, which is what 003.4 mainly needs, but the runtime capability inside rooms is still completely untested. - This must be settled before Phase D commits to anything, and before design is asked whether they want a runtime state swap at room granularity (ruins/repaired, puzzle phase, hidden rune reveal). If design says yes and runtime layers do not work inside streaming-off rooms, the configuration in the RESOLVED entry does not hold for that use case.