Building System

Build Catalog window — owner selected 2026-10-14

[OWNER APPROVED] Build Catalog replaces the hold-R Command Ring for player construction. While holding a usable Hammer such as WoodenMallet, tap R once to open or close the window. Releasing R does nothing. The Night Ops centered window shows a left category rail, a scrollable three-column piece grid with thumbnails, and a right Resource / Appearance inspector. Owner revision on 2026-10-14 removes the separate selected-piece preview below the grid; the grid now uses the full central height. Piece and Appearance thumbnails remain. Only player-selectable catalog entries are offered. Resource eligibility, actual completion bills and named appearances come from the existing shared Piece Definition / Appearance Set data. The selected preview renders the actual compatible mesh with its independent slot materials in an isolated, non-PIE preview scene.

Changing category, piece, Resource or Appearance only changes the local window selection. Incompatible options fall back to the existing piece default. Press Select & Place to close the window, restore the HUD and cursor-free gameplay input, and enter the existing local hologram placement. The confirming mouse event is consumed; a subsequent LMB places the site. Tap R during placement to reopen selection. R or Esc closes selection without creating a preview. RMB / Esc retain the existing placement cancellation behavior. The selected piece, Resource and Appearance remain available locally when reopening; they are not a new durable setting.

Opening the catalog shows the cursor and blocks movement/look/gameplay keys while retaining mouse selection and keyboard navigation. Normal gameplay HUD is temporarily hidden and restored on close. Losing the held usable Hammer closes the window. Firearm R Reload and the aimed-player Squad invitation Command Ring are separate and retained. Without a Squad, Select & Place is disabled and the window offers Open Squad; it does not create a Squad or a site automatically.

The ordinary HUD shows R — Build structures whenever the living local player holds a usable Hammer, including WoodenMallet, outside selection/placement and blocking UI. The guide has English and Thai string-table text, uses the existing Google Sans font and Night Ops colors, and disappears when the tool/context no longer qualifies.

Persistence: window navigation, preview textures and pre-placement selection are transient presentation. Confirmed world placement still carries the same PieceId, Tier and VariantId through the current server validation, replicated construction site and USaveSubsystem / ULambeerWorldPersistenceSubsystem records. Bills, contributions, Squad ownership, support identities, refunds and schema remain the existing contract; no separate SaveGame path is introduced.

Owner-reported selection flicker — 2026-10-14: selecting a piece visibly refreshed the category sidebar and Esc Close control. The previous selection path replaced the full window child tree. The corrected native catalog constructs its header, sidebar/category buttons, footer and scroll hosts once per Slate lifetime; selections replace only the piece-grid and inspector content. Category styles/title change only when the category changes. Sidebar scroll is retained; piece-grid scroll is retained within a category, and Appearance scroll is retained within the same piece/resource. Verified locally: Editor and Game Win64 Development builds pass. Four focused non-PIE checks pass with zero errors/warnings. The stable-selection regression compares real native pixels: sidebar and Esc Close have zero changed pixels after piece, Resource or Appearance selection; Esc Close also remains unchanged when the category changes. Widget identities and sidebar scroll offsets remain stable. Owner live PIE flicker confirmation remains pending. Focused verification.

Verified locally 2026-10-14: Editor and Game Win64 Development builds pass. The broad Building/Squad/HUD/persistence and interaction batch passes 145 tests; six final focused input, selection, repeated-placement, Squad and native-raster checks pass with zero errors/warnings (146 unique checks across the runs). Native renders at 1920×1080 and 1280×720 show actual compatible meshes, aspect-preserving imagery, independently bound appearances and the decorated +X Wall face. BP_PlayerCharacter, BP_LambeerPlayerController, WBP_HUD and WBP_HUDRoot compile with warnings as errors; scoped Save leaves all six affected Blueprint/StringTable assets clean. Both exact guide keys/texts are verified in the live tables and serialized asset files; a metadata modification corrects the CSV import tool's missing dirty mark before Save. All 48 canonical HTML documents validate cleanly. The exact project is reopened on L_Dev_Sandbox with MCP ready and PIE off. Actual native Wall catalog · Plaster selection · Roof Metal selection. Owner-only Dedicated Server + two-client PIE and packaged cook/performance acceptance remain pending. Evidence: verification record.

Production context

Verified implementation evidence

• Not verified for this documentation pass.

Owner revision, 2026-10-11: ManualHouse inter-storey floors use the selected Light Wood, Dark Wood or Concrete structural Ceiling, 10 cm thick downward with the walking face flush at the lower Wall top. Both Wall-stack placement orders and Single/Rectangle are supported; old ManualHouse Ceiling Finish selections/records migrate. The 78 upper Slabs in L_GeneralHouse are replaced with LightPlanks while preserving all 1,335 identities/poses. PCG/player legacy definitions remain unchanged. Canonical workflow, actual mesh review and validation.

Owner-approved automatic Ceiling clipping — 2026-10-12: ManualHouse derives Wall-aware closed floor edges and matching convex collision from existing records, preserving grid/IDs, exact flush top, 10 cm downward thickness and direct upper-Wall stacking. Both placement orders, live Wall edits, Undo/Redo and saved-state reconstruction are covered. Canonical behavior and validation.

Owner-approved next-piece compatibility — 2026-10-08: ManualHouse preserves supported settings and automatically chooses existing defaults for incompatible Resource, Appearance and Placement Mode selections. Changing the target/settings cancels transient area state and retains only compatible active sources. Authored piece records and world persistence are unchanged. See the canonical automatic-default contract and validation.

Owner-approved automatic L joints — 2026-10-08: ManualHouse Wall Solid end joins derive complementary 45-degree surfaces and restore square ends when a neighbour is removed. Stable authored records, materials and original transforms remain authoritative; current central world tombstones/replication reconstruct surviving geometry. This applies to ManualHouse authoring and its runtime representation; player construction placement is unchanged. No mid-wall T snap is introduced. Ordinary pieces retain ISM batches; joined walls use closed procedural surfaces and clipped convex collision. Owning workflow, rendering limitations and validation.

Window base-seam follow-up — 2026-10-11: fixed windows expose extra 25 cm shifts above/below Solid Wall and fixed Window sources with at least 25 cm edge contact, including equal-width Wall100/Window100 beside an existing jamb. Full overlap/fresh commit checks remain. No durable state or save schema changes. Canonical cause, workflow and validation.

Window snap correction — 2026-10-11: the shared Editor/player pair resolver supplies 25 cm intermediate alignment for both fixed window sizes and reciprocal wall joins. A Window100 can fit either end of a 125 cm bay selected from its Wall50 base, with collision and fresh commit checks retained. Existing authored/save records are unchanged; no durable state or schema is added. Canonical workflow and validation.

Owner revision, 2026-10-06: Slab 100 → 25 provides four fitted positions per edge. The shared selected-size resolver covers all 55 authored definitions; Window/Louver joins wall edges/tops without cutting solids, Infill follows the gable end, and trim requires a completed matching roof. Authored extras resolve independently of the unchanged player radial selection; player validation still enforces selectable entries. L/U stair arrival poses follow the source geometry. Garage panel/track parts remain inside BP_SectionalGarageDoor; the legacy standard leaf remains manual by owner choice. Roof attachment dependencies persist through the existing support IDs and central world save path. TH/EN compatibility matrix and workflow.

Manual houses with ISM — 2026-10-05

2026-10-08 Rectangle input repair: a source mesh click activates early viewport input. The first snap click remains an unlocked draft; the opposite-corner click or a multi-cell drag release locks it before Enter commits. Slab and Wall areas preserve per-piece identities, grouped ISMs and one-step Undo. See current workflow and scoped validation.

Implemented locally; owner PIE/cook/profiling pending. Hand-place Editor-only BP_ManualBuildingPiece handles in L_GeneralHouse and bake them into BP_ManualHouse. Shared mesh/resource/appearance components batch completed geometry. Each piece retains a stable house/local-piece identity for inspect focus, weapon damage, support/snapping, demolition and central persistence; runtime instance indices are never save keys. Garage assemblies retain their existing Actor behavior. This does not convert PCG structural visuals.

The owner-selected Editor snap tool starts from a slab handle using Start Snap House, or adopts a starting handle on an existing house using Use Starting Piece. With the house selected, choose a definition/resource/appearance in Snap Placement, click an existing mesh to select its snap source, then click one of its green viewport points. Each accepted click validates collision/dependencies and bakes the new piece into existing ISM batches. Small green points remain clickable; only the hovered point shows a bounds preview. Enable Show Blocked Snap Points for red rejection diagnostics. Cached previews invalidate on Editor geometry/configuration/asset edits and Undo/Redo; clicking independently resolves and validates the current seam. Records, mesh bounds and repeated source-pair matrices are shared within a validation pass. Editor Undo/Redo preserves stable piece IDs. The component visualizer and placement settings are Editor-only. See the TH/EN Viewport workflow and snap optimization and owner checks.

Owner correction: unowned houses cannot be refund-demolished. Damage destruction is still allowed and yields no refund. Completed pieces with a valid owner Squad require current membership, held Hammer, reach and visibility for X demolition; half the bill is returned rounded down. This supersedes the former everyone-can-demolish PCG finish exception, including completed replacements. Ordinary player-built and authored finish Actors now have real editable HP too.

Initial per-resource HP was delegated by the owner, stored in all 55 Piece Definition Data Assets and applied by direct weapon damage. Final resistance, repair, upgrade, locks, claim UI, structural collapse and packaged performance remain pending. TH/EN authoring steps, HP starting factors and owner checklist · persistence fields and restore rules.

Editor piece deletion — 2026-10-06: Piece Removal Mode selects visible baked meshes directly, including houses without authoring handles. Only hovered/selected pieces have outlines by default; Show All Points restores cyan diagnostic markers. Click selects one; Ctrl+click adds/toggles more; Enter removes the set in one transaction, Escape clears and Ctrl+Z/Ctrl+Y restore the whole operation. Every selected piece is outlined, with selected/removal counts. Delete and Remove Selected Pieces remain alternatives. Selection is transient and clears after Undo/Redo or tool changes. Removal uses local GUIDs and existing explicit-support cascades, preserves all unrelated IDs/transforms, rebuilds ISM hit mappings and invalidates snap caches. Undo/Redo restores the same identities; deleted mixed-size slots reopen at their original poses. Save the authored level. Runtime demolition/weapon damage and durable save fields remain unchanged. Ctrl/Enter workflow and validation. Owner-approved mesh selection, source-specific points and Show All Points diagnostics are implemented locally; physical input acceptance remains owner-pending.

Named ManualHouse authoring groups — owner revision, 2026-10-15: the owner replaces physical ISM-batch editing with explicitly named groups containing stable local piece IDs. A piece belongs to at most one group; adding it elsewhere reassigns membership, and deleting a group retains its building pieces. Resource/Appearance edits target those explicit members across render batches. Selecting a group highlights its members; per-group visibility allows several upper-floor groups to be hidden together, and Hide Whole House Outline suppresses the selected house's global yellow outline. Names, membership and display preferences are Editor authoring state saved with the Level; no automatic floor/room grouping or new gameplay persistence schema is introduced. Canonical controls, first-floor isolation example and validation status.

ManualHouse Undo visual correction — 2026-10-07: owner Ctrl+Z restored piece records/snap points while stale registered ISMs remained visible. Generated references/components now stay outside Undo snapshots; rebuild removes scoped tagged/legacy generated components and restores meshes/hit mappings from authoritative records. The regression checks actual native/Blueprint registered instances rather than only reported counts. Diagnosis, validation and owner checks.

Bulk manual floors — 2026-10-07: owner correction removes Array; Single and Viewport Rectangle remain. Rectangle dimensions/directions derive from viewport corners and are read-only. ManualHouse additionally offers slab-top slots computed from actual mesh faces for full/mixed-size stacking; player snap rules retain their current behavior. See top-face authoring. The shared area pipeline previews cells in the snapped local basis, checks current collision and each finish support, then commits all records in one Undo transaction using direct ISM batch appends. Bulk records have independent GUIDs and matching render ISM batches; handles are materialized only when requested. Existing records and gameplay persistence remain unchanged; draft anchors are transient. TH/EN workflow, local evidence and owner acceptance.

Wall Rectangle and incremental placement — 2026-10-07: the owner selected a width × height area on the vertical Wall plane. Bulk Placement → Placement Mode → Viewport Rectangle supports Walls as well as horizontal floors; mesh size and snapped axes determine spacing, with one fresh atomic commit and Undo. Single and area placements append independent records/instances directly to matching ISM batches without a temporary authoring Actor. The owner confirms the initial stall fix is much faster but still reports 1–2 second manual clicks; current isolated live Wall append improves from 0.070 to 0.022 seconds, while complete owner click/redraw acceptance remains pending. Editor/Game builds, 70 regressions and live Rectangle checks pass. Wall Rectangle workflow and validation · Current operation measurements.

Large-house Wall placement correction — 2026-10-07: baking skips unnecessary structural-piece dependency searches and resolves required attachments from one current record snapshot. A 765-slab production Blueprint fixture measures the before/after Wall click and validates actual meshes/identity/Undo/Redo; owner viewport responsiveness acceptance remains pending. Measurements and owner check.

100 × 50 × 25 cm short stair — 2026-10-11

Owner-selected production: concrete two steps (01) and wood two steps (03). The logical definition is /Game/Lambeer/World/Environment/ModularKit/Data/Pieces/DA_Piece_Stair_100x100x25, PieceId SM_Stair_100x100x25, category Stair. Its resource-specific shared Appearance Sets expose Concrete / LightCastConcrete and Wood / DarkBrownStairWood; Wood resolves a separate compatible render mesh. No Brick variant is introduced. Canonical surfaces, sources and actual UE review.

Wood geometry revision — 2026-10-11: rounded nosings, thick separate tread boards, inset risers and stepped timber stringers replace the rejected sharp block appearance. This changes only the compatible wood render mesh; logical identity, appearance, structural collision envelope, snap contacts and persistence transforms remain unchanged. Current actual UE images and editable construction. Twelve focused checks passed again with zero errors/warnings; owner visual/PIE acceptance remains pending.

Concrete geometry revision — 2026-10-11: rounded cast nosings, recessed risers, continuous shadow lines and shallow tread grooves replace the former sharp block. The logical mesh retains its exact corner bounds, two continuous tread collision hulls, existing slots and resource appearance. Snap offsets and durable placement records are unchanged; Wood remains the preceding revised timber assembly. Actual current geometry and sources. Twelve focused non-PIE checks passed again with zero errors/warnings.

Owner depth correction — 2026-10-11: both resource meshes now measure 100 × 50 × 25 cm. Existing PieceId and asset names remain stable; the original size suffix is historical. Snap offsets use actual mesh bounds, so the outward run is now 50 cm and reciprocal upper arrival is local Y=50 cm. Existing authored transforms and persistence identities retain their values.

Snap contract: choosing the short stair against a structural Slab 25/50/100 exposes all four rim directions, with mixed-size width offsets. The stair descends outward; its upper tread meets the slab top and its lower entry is exactly 25 cm below. Explicit South/North/East/West markers retain the contact direction. Reciprocal Slab placement attaches to the short stair's lower front or upper rear at the corresponding walking elevation. Rotated source poses retain these joins. Existing tall-stair contacts remain unchanged.

Scope: ManualHouse authored-only catalog entry, Single placement; requiredUnits=0 is an authoring sentinel, not an approved free gameplay bill. The owner has not supplied player build cost/HP balancing for this new piece, so it is excluded from the player radial catalog. Existing central ManualHouse capture/restore retains its stable local ID, logical piece, resource, appearance, support and transform; no new persistence schema is introduced. Central persistence contract.

Verification: Editor/Game builds and all 12 focused tests pass, including new ShortStairAssets, ShortStairSlabContacts and Persistence.ShortStairAppearances. Test results · Authoring workflow and owner checks. Existing GameplayCue path warning and owner visual/PIE/cook/performance limits remain recorded separately.

Relationships

• FEAT-WEAPON-CUSTOMIZATION
• FEAT-INVENTORY tool roles
• FEAT-LOCK-ACCESS — canonical door, window and storage lock rules
• FEAT-WORLD-DESIGN — ordinary-house versus POI destruction boundary
• TECH-NETWORK-ARCH — durable state and authority boundary

Modular destructible houses — [CONFIRMED DESIGN 2026-09-29]

Ordinary authored houses in the world and player-built structures share one building-piece gameplay model. A house is a reusable layout of pieces, not one HP pool. A hit damages the resolved wall, floor, roof or other eligible piece; only that piece changes state. Ordinary authored houses may have destructible structural pieces. POI and progression-lock structures keep their existing protected map rule; ordinary destruction must not bypass a special lock. This is a design contract for later building gameplay, not a claim that the existing P13, House 01 or Modern Farmhouse mesh/Blueprint assemblies already implement damage.

Reusable catalog naming — 2026-10-01: shared geometry and archetypes use neutral asset names in ModularKit; house assemblies reuse this catalog. See the naming and legacy-save compatibility contract.

Definitions, identity and ownership

• A reusable piece definition describes geometry and snap data. A separate material definition selects presentation and gameplay properties. An authored house definition or Level Instance supplies the layout; each placement has its own stable house-instance ID. The same layout may be placed more than once without sharing damage state.
• Every authored house piece has a stable piece ID within its house. The save identity is HouseInstanceID + PieceID; a player-built piece receives an equally stable system-owned piece identity. Unreal Actor names, transient ISM/HISM instance indices and the shared house-definition asset are not save IDs.
• World-placed and player-built pieces use the same damage, repair, destruction and material rules. Ownership and build authorization differ: world pieces have world ownership; player pieces retain the player/base ownership and privilege contract. An ordinary house does not become player-owned merely because a player damages it.
• Geometry may be reused across Wood, Brick and Concrete when its shape is actually identical. Material data and visual material instances are separate from the mesh. Existing kit-specific geometry, surface slots and approved dimensions remain as authored; the guide's sample mesh names, material assets and numeric HP/resistance values do not rename or retune them.

Guide component candidates — [RECOMMENDATION, NOT VERIFIED ASSETS]: a piece definition Data Asset for mesh/snap data; a material definition Data Asset for visual material, HP, resistance, impact sound and destruction FX; a house definition for stable piece entries and relative transforms; a house-placement Actor for per-instance identity; one interactive piece Actor/interface shared by world and player pieces; and a runtime service for static-instance mapping and promotion. Suggested guide labels include DA_BuildingPiece, DA_BuildingMaterial, DA_HouseDefinition, BP_HouseInstance, BP_BuildingPiece and BPI_DamageableBuilding. These are role examples, not approved package paths, created assets or a mandate to implement gameplay in Blueprint. Avoid separate gameplay Blueprints for each material or owner type.

Level Instance may help level designers reuse an authored layout, but its asset ID alone cannot identify a placement's state. A Packed Level Actor can carry static visuals; it is not the authoritative gameplay object for individually damaged, repaired, upgraded and persisted pieces. Master/instance materials may expose color, roughness, normal, dirt, damage, moss and wetness parameters where the final art pipeline needs them; these are optional shader controls, not a reason to duplicate identical geometry.

Representation and interaction

Keep authoritative per-piece state independent of its rendering form. Inactive ordinary walls, floors and roofs can use ISM/HISM with a maintained instance-to-piece lookup. When interaction requires an Actor, resolve the hit to the stable piece ID, remove its static instance, activate an interactive representation carrying the same state, and apply server-authoritative damage. Promotion, demotion and streaming must not create a new gameplay identity or reset HP. Doors, storage and other inherently interactive objects retain the Actor policy in Networking & persistence. Exact activation distance, demotion policy and HISM grouping are TBD pending profiling and implementation.

Damage and destruction

The server validates attacks and owns HP, material, repair, upgrade, ownership and destroyed state. Damage type and material resistance are data-driven; the guide's base damage × weapon factor × material factor is an illustrative calculation shape, not approved coefficients. Clients never set HP or destroyed state. On destruction, disable the affected piece's gameplay collision and representation, update its durable state, then play suitable sound/FX. Temporary debris or Chaos substitution is an optional presentation path; the guide's 10–60-second example is not a Lambeer timer. Structural support/cascade collapse is also optional and remains TBD; removing one piece does not implicitly approve collapse of connected pieces.

Durable state and production boundary

World-house instances restore each modified piece independently; default, untouched authored pieces may be derived from their definition while changed HP, destruction or material state is saved. Every player-placed site/piece and its applicable ownership, material contributions and placement state must remain durable. All capture/restore runs through USaveSubsystem / ULambeerWorldPersistenceSubsystem, not a separate authoritative BuildingSaveSubsystem or ad-hoc SaveGame. The P16 slice has added Squad and player-built site records to the existing world-state payload, with codec automation coverage; owner restart/rejoin PIE verification is pending. P17 extends records for raid and authored-house deltas.

Authoring and implementation status — 2026-09-29: The Modern Farmhouse kit has 41 Static Mesh types, nine saved Actor Blueprints and one material-definition Blueprint under /Game/Lambeer/World/Environment/ModularKit/. The garage Blueprint installs its frame, track and five rigid panels as one assembly; the owner will author its Timeline track. Red/green/blue tier material instances remain placeholders. The first P16 gameplay slice now lists 29 selectable assemblies, tags the WoodenMallet as a Hammer, and provides Brick and Concrete resource Data Assets. Native input opens a paged radial with tier costs while Hammer-held R is down, then creates a local non-colliding preview; server placement validates Squad, range, center-ground floor slope, no-build volume, obstruction and physical or completed-point support. Free placement has no world-grid gate. Server-owned site Actors restrict unfinished replication to current Squad members, accept inventory contributions through Interact, complete at the full bill, and refund to ground pickups on cancellation. An unfinished site uses the saved translucent hologram material; completed garage sites instantiate the existing sectional-door Blueprint. Squad/site records are captured in world persistence. LambeerEditor build, catalog-asset automation and persistence-codec automation pass; owner PIE, remote visibility, input and restart/rejoin verification remain open. Native compatible snap-marker matching is implemented under the owner revision above; this dated snapshot is superseded for HP/damage and manual-house destruction by the 2026-10-05 section above. Repair/upgrade, full progression and PCG structural conversion remain later work; do not count P16/P17 as complete.

Door, window and storage locks — [CONFIRMED 2026-09-17]

FEAT-LOCK-ACCESS is canonical. World-existing doors/windows roll a one-time 30% built-in locked state; player-built doors/windows start unlocked. Built-in locks follow inside/outside and auto-unlock-on-open rules. Doors, windows and Player-built Storage may also carry an independent installed Lock item; installed access requires owner/current Squad or Lockpick. Player-built Storage has no built-in lock. Lock state and item identity are later P16/P17 durable base state, not part of the implemented P07 record set.

Building UI contract — [CONFIRMED]

FEAT-HUD-UI defines the owner-selected Build Catalog window for piece, Resource and Appearance selection, followed by existing hologram placement and contextual failure feedback, plus an action radial for Upgrade, Repair, Demolish, and Authorize.

Historical radial confirmation correction — 2026-09-30; superseded by Build Catalog 2026-10-14: Confirming the piece/material-tier choice immediately closes the radial and enters preview without waiting for R release. The same LMB press must not place the preview. See radial confirmation contract and validation.

Owner request — 2026-09-30: The owner selected Night Ops Build Card option 02 with a separate row per material. The native panel is anchored above the centered piece bounds, faces the viewing client's camera, and shows the actual tier bill within the existing interaction range. Current recipes still require one resource per tier; several-row rendering is supported as presentation without approving new recipes. The closed-Editor build and native UMG layout automation pass; owner PIE validation remains pending. See material UI proposals and implementation status.

Agriculture and livestock interfaces

[CONFIRMED 2026-09-13] FEAT-AGRICULTURE first increment plants on valid landscape/physics soil, not as a building piece. Collision overlap with building pieces fails placement. Plant records follow the same SQLite persistence pattern as placed pieces. Planters/pots are a later agriculture increment and are not added to the v1 piece set here. FEAT-LIVESTOCK enclosure pieces remain unapproved.

PCG modular house authoring

[OWNER CONFIRMED 2026-10-04] Current guide-only contract: the owner retired automatic room and stair layout. A house always has one shared closed FootprintSpline for all 1–3 floors. Rectangle mode and Width/Depth controls are retired by the 2026-10-05 owner correction. Open Wall Guides author physical interior wall centrelines exactly once; closed Room Guides classify Bedroom, Bathroom, KitchenLiving or Corridor zones but never emit wall geometry. Zone boundaries are independent of physical walls: wall coverage is not required and partition endpoints may remain free inside the house. Adjacent zones may share one authored wall without duplicate meshes. Door and Window Guides explicitly author every opening; windows use exterior walls only. Stair Guides are optional: each authored adjacent-floor transition has its own marker and independent position/yaw. Missing transitions produce neither stairs nor slab openings. Missing Room Guides or exterior entrances do not block generation; each supplied guide is still validated. Wall Guides snap to the nearest existing house floor; the generator validates room polygon geometry, overlapping walls, openings and stair containment, while circulation/reachability no longer block user-authored layouts. It preserves the last valid geometry on failure. It never silently creates a missing wall, door, window or stair. Existing finish tiles retain their gameplay and persistence contract. The Details guide gives the current authoring procedure.

[OWNER CORRECTION 2026-10-05] Spline-only footprint: every new or existing house generates directly from its closed, linear, planar FootprintSpline; there is no authoring mode selection. Footprint Source, Width/Depth and Reset Footprint To Rectangle are removed from Details. On load, an unedited legacy Rectangle is converted once to actual spline points using its saved dimensions. Any already edited spline is preserved, including edits previously ignored by Rectangle generation. Hidden legacy fields remain solely for package compatibility. Subsequent regeneration never reads dimensions or replaces edited points. Baked geometry, house IDs, guides, appearance choices and finish persistence remain intact; save the level after regeneration. No runtime generation is introduced.

[OWNER CORRECTION 2026-10-05] No minimum size for authored rooms: guide-only regeneration no longer checks minimum Bedroom, Bathroom or KitchenLiving clear area, or a minimum bedroom shortest side. This also applies to zones adjusted after footprint changes. The four obsolete size controls are hidden from actor/SplineSurfaces Details and Blueprint authoring; their serialized values remain for old-package and legacy automatic-layout compatibility only. Room type, simple polygon, inset/containment and overlap checks remain. No zone is enlarged or automatically added. Baked map save/reload and existing finish persistence are unchanged.

Authored-room size verification — 2026-10-05: closed-Editor LambeerEditor and Lambeer Win64 Development builds succeeded. All 32 scoped automation tests passed with zero errors/warnings: 29 PCG Building and 3 persistence checks. New coverage accepts 1 m² clear Bedroom, Bathroom and KitchenLiving zones with 100 cm sides despite unusable legacy limits, preserves authored points and retains invalid-polygon rejection. Footprint adaptation also accepts a zone below the retired minimum. Blueprint compilation with warnings as errors passed; the four obsolete controls are absent from live Details property schemas. Both preview houses regenerated and retained their 18/22 planned pieces, house identities, room references and appearance selections through scoped map save/reload. The map is saved clean. Build, automation and Editor readback evidence. No agent PIE or packaged cook was performed.

What a window crossing a zone boundary means: the existing window-fit check samples a 150 cm span along the exterior wall: the 100 cm opening plus 25 cm on each side, just inside the wall. That span must lie wholly inside each touched Room Guide, or wholly outside it. If part lies in a Bedroom zone and part in a KitchenLiving zone (or unclassified space), the current check rejects it with the combined opening/junction/stair diagnostic, even when no physical Wall Guide divides those zones. Example: a window centred on the logical shared Bedroom/Living boundary is rejected despite an otherwise uninterrupted exterior wall. This is a classification-based restriction, separate from real door/window overlap, corner fit or stair geometry. The owner requested explanation, not removal; its behavior remains pending a separate decision.

Wall-floor snap and authored-circulation verification — 2026-10-05: Editor/Game Development builds passed. Initial 31 checks yielded 30 passes; one new stair fixture assertion was corrected to include an actual disconnected upper entrance, with no implementation change. The corrected AuthoredCirculation rerun passed, yielding 31 distinct passing PCG/persistence checks with no final errors/warnings. Snap regression covers below-floor/nonplanar points, translated/rotated house coordinates, finished movement, explicit Floor selection, highest-floor clamp, reduced floor count, unchanged X/Y/types and repeated idempotence. The owner's existing partition now regenerates successfully with 18 parts and the same house identity/appearances. Live Floor 1 selection moves points to 320 cm; a 355 cm offset regenerates on nearest Floor 1 at 320 cm, then original Floor 0/point positions are restored. BP compile with warnings-as-errors and scoped BP/map save/reload passed; house properties and full spline readback match before/after reload. The reloaded partition collision trace hits 46.69449 cm along a 120 cm crossing, and the map is clean. All 46 HTML checks pass. Build, test, snap and reload evidence. Owner-only PIE/multiplayer and packaged cook remain unverified.

Spline-only verification — 2026-10-05: final closed-Editor Editor and Game Development builds passed. All 28 existing PCG/persistence checks passed; the new SplineOnlyFootprint regression passed after correcting its test assertion to sum the interior floor and perimeter rim. The 29 distinct checks report no errors/warnings. Coverage confirms unconditional spline generation despite stale legacy dimensions/mode, preservation of edited points, idempotent old-Rectangle migration and removal of editable controls/reset reflection. Live BP compile with warnings-as-errors passed. A temporary newly placed Blueprint generated its guide-free shell (16 parts) from a closed 10 × 8 m spline without a mode choice, then was removed. The owner's edited 10 × 12.96319 m house regenerated, saved and reloaded with all spline points, house ID, appearances and 18 parts preserved; the existing guided house retains its identity/successful status/22 parts. Details schema and Slate show no Footprint Source, Width/Depth or rectangle reset. Only the affected Blueprint and preview map were saved. Build, automation and live readback evidence. Owner-only PIE and multiplayer acceptance remain unverified.

[OWNER CORRECTION 2026-10-04] Free interior wall ends: the owner cancelled the requirement for full physical-wall coverage of every Room Guide boundary. Removing or shortening an interior Wall Guide must not fail because a zone edge is uncovered. Room Guides remain independent classification polygons; wall geometry comes only from Wall Guides. Geometry validity, footprint clearance and authored opening placement remain; room gameplay-size minimums are retired by the 2026-10-05 correction. The 2026-10-05 correction below removes circulation/reachability gates entirely from guide-only generation. Open passages and enclosed spaces do not require a Door Guide to generate. The earlier uncovered-boundary rejection test below is historical and superseded by this correction. The owner subsequently authorized angled endpoint clipping.

Construction-type and optional-guide verification — 2026-10-04: final closed-Editor Editor and Game Win64 Development builds passed. All 23 PCG tests and CatalogAssets passed with zero errors/warnings. Coverage includes the three game types, Data Asset resolution for every construction piece, ignored legacy house MI overrides, retained window glass, door-only three-storey generation, one authored stair with another transition missing, complete uncut slabs where stairs are absent, and rejection of invalid supplied stair transitions. MCP created, configured, read back and saved 55 Building Piece Data Assets for the existing ModularKit meshes. The owner's two-storey house regenerated from 16 to 18 planned parts with an actual door frame and leaf while Room/Stair Guides remained empty. A Brick-wall/Concrete-floor trial produced the expected Data Asset MIs; trial choices were restored to Wood. The original guided example still generates 22 parts. Blueprint compile with warnings-as-errors and map save/reload passed; type choices, house identity, door components and successful status survive reload. House property inspection exposes no MI/pool fields. Build, automation, definitions, material-slot and reload evidence. Existing gameplay placeholder visuals remain provisional. Owner-only PIE, final art and multiplayer/rejoin acceptance are unverified.

Historical pool evidence: the earlier editable/random MI implementation passed its then-current tests and shell checks, but its pool, reroll, manual-override and complete-guide validation rules are superseded by the owner correction above. Historical evidence.

[OWNER DECISION 2026-10-04] New houses start with an exterior shell: a house with all four guide collections empty generates its exterior walls, complete floor slabs, ceiling and roof for the selected 1–3 storeys. It creates no room zones, interior partitions, openings, stairs or stair holes. An empty gable-wing list receives the existing fitted-roof starting design, saved only after valid generation; authored roof wings are retained. This supersedes the former rejection of a freshly placed BP_PCG_ModularHouse for a missing entrance. Guides can be added incrementally. Door/Window Guides generate before room zones or stairs exist. Only authored stairs create slab holes; missing stairs are permitted. Invalid supplied guides still preserve the last valid house. Shell mode still validates the footprint and roof geometry. Validation Status distinguishes the authoring shell from a complete connected house. Construction attempts initial generation once rather than repeatedly retrying an invalid empty actor. Regenerate remains an Editor action; save the level for runtime.

[OWNER REVISION 2026-10-04] Shared construction resources and named appearances: the earlier house MI pools remain retired. PCG selects a permitted resource and named appearance per part; MI assignment belongs to shared Appearance Set Data Assets referenced by Building Piece Data Assets. Wall, floor, finish, ceiling, gable, door, window, stair, porch and vent parts retain Wood/Brick/Concrete; roof covering, valleys and bundled roof trim use Wood/Tile/Metal. Gable infills follow the wall policy even though the older catalog groups them under Roof. The former one-MI-per-tier placeholder migration is historical and superseded by the shared appearance contract.

Material persistence boundary: PCG piece-type choices and baked material references serialize in the level. Runtime performs no PCG regeneration or randomization. Player construction and restored replacements resolve their existing saved PieceId/Tier through the same Data Assets; authored finish records retain their established tier/tombstone fields. No gameplay save schema changes are introduced. Structural authored-house durability remains later work under the persistence contract.

[OWNER REQUEST 2026-10-04 · IMPLEMENTED] Angled interior wall ends: Editor regeneration intersects each authored wall strip with the exterior structural wall's centreline envelope. End caps follow the actual footprint edges and remain concealed within the exterior wall thickness, preventing interior wall geometry from protruding outside. Polygon intersection supports concave and L-shaped footprints. An endpoint meeting the exterior wall receives enough concealed overlap to close both sides at a shallow angle; free endpoints retain their existing square caps. Cutting itself does not relocate guide splines; the separate footprint adaptation option controls authoring changes. Authored door apertures are preserved. The clipped polygons also drive circulation obstacles; mesh triangles provide matching complex-as-simple collision. Save the regenerated map to retain the geometry and collision for runtime. Cutting does not run every frame or at BeginPlay. No measured frame-time or regeneration benchmark is claimed.

[OWNER DECISION 2026-10-04 · IMPLEMENTED] Preserve the interior layout when the footprint changes: the owner selected boundary-only adaptation rather than proportional scaling of the whole plan. Auto Adapt Guides To Footprint defaults on and runs during Editor regeneration. Saved footprint geometry identifies prior exterior contacts; older maps recover that reference from the baked ground-slab perimeter. Points wholly inside remain fixed. Attached wall endpoints extend/shorten along their existing segment direction where possible; free endpoints remain free. Room-zone corners at the exterior follow the changed boundary, and outside portions are clipped. Room zones remain independent of physical walls. Windows and entrance markers are planned together on the new structural wall centrelines and rotated to follow the wall, retaining their fixed opening dimensions. Interior doors follow their authored walls. A stair that no longer fits may translate at its existing yaw/type; roof-wing centres outside the interior are constrained while existing yaw/design controls remain. Room polygon validity, stair containment and opening checks still apply; guide-only circulation checks are retired by the 2026-10-05 correction. The complete candidate is validated before guide changes commit in an undoable transaction; an erased/split zone or an invalid complete layout retains existing guides and generated output with an actionable diagnostic. This is Editor authoring work; save the map for runtime, with no new per-frame recalculation.

Footprint-adaptation verification — 2026-10-04: closed-Editor LambeerEditor and Lambeer Win64 Development builds succeeded. All 21 Lambeer.PCG.Building tests passed with zero errors; one unrelated Editor HTTP connectivity timeout warning was captured during the full run. The two new tests cover coupled window/entrance adjustment, fixed interior/free endpoints, boundary extension and contraction, repeated repair without drift, concave footprints, baked-outline recovery, retained minimum room area and compact-stair translation. A transient EditorPreview-world solver test repairs an overlapping Window/Entrance using the adjusted layout while leaving authored actors untouched during calculation. The owner's edited five-point preview regenerated successfully: two exterior opening markers moved, five of six Wall Guide splines and the Bathroom zone stayed identical, and the remaining wall changed only its exterior endpoint. Bedroom and KitchenLiving boundary zones adapted; all three room classifications and 22 planned pieces remain. A repeated regeneration and map save/reload kept every adjusted spline and the footprint identical. After reload, the tangent trace 1.5 cm outside the new angled exterior missed; contact and interior partition traces hit. Build, automation, guide-coordinate and collision evidence. Owner-only PIE traversal, visual Undo, multi-floor stair adjustment and multiplayer acceptance remain pending; no runtime FPS benchmark was performed.

Free-wall-end verification — 2026-10-04, before angled cuts: Editor and Game Win64 Development builds succeeded; all 18 Lambeer.PCG.Building automation tests passed with zero errors/warnings. Regression coverage accepts a shortened partition, an uncovered shared zone edge, a freestanding partition with both ends inside the house and open access without a Door Guide; it still rejects a solid partition that blocks circulation. Uncovered zone edges do not synthesize walls. The preview house regenerated with Valid layout and 22 planned pieces and was saved. No PIE acceptance or angled endpoint cutting was performed in that earlier check. Automation evidence.

Angled-cut verification — 2026-10-04: Editor and Game Win64 Development builds succeeded. All 19 Lambeer.PCG.Building automation tests passed with zero errors/warnings. The new test covers tilted exterior contacts, reversed guide direction, a 15° shallow junction, a two-plane exterior corner, a concave L wing, unchanged free caps, preserved door apertures and matching render/collision vertex positions. The guided preview regenerated with Valid layout and 22 planned pieces; all six Wall Guide splines stayed unchanged. A tangent trace 1.5 cm outside the angled exterior contact missed, while traces through the wall/contact and the interior partition hit. Saving and reloading the map retained validation and the same three trace results. Owner-only PIE acceptance remains open: inspect both faces of the junction and walk around free wall ends and through authored doors. Build, automation and map evidence.

Preview map migration: PCG_GuidedRooms_Example is the saved guide-only example with a five-point footprint, six open Wall Guides, three closed Room Guides and five explicit opening markers. The owner authorized removal of PCG_House_10x8, PCG_SplineHouse_L and PCG_SplineHouse_L_2Floors; those three legacy examples were deleted from the preview map. Earlier dated paragraphs below record historical implementation and test evidence; any statement there about automatic authoring controls, generated room counts, a shared stair pose, or those deleted map actors is superseded by this 2026-10-04 decision. Only the owner may perform PIE acceptance.

Guide-only Editor verification — 2026-10-04: closed-Editor LambeerEditor and Lambeer Win64 Development builds succeeded. All 18 Lambeer.PCG.Building automation tests passed with zero errors or warnings, including one physical shared wall, rejection of uncovered room boundaries, open-plan floors without interior walls, separate stair poses and missing-transition rejection. The saved preview map was reloaded after deleting the legacy houses; the guided example regenerated successfully with three room zones, six wall guides, five openings and a read-only summary showing one bedroom, one bathroom and one kitchen/living zone. The 46 standalone HTML documents validate with zero errors/warnings. These checks do not establish PIE traversal or multiplayer acceptance.

Owner configuration — 2026-10-01: two open-plan storeys, an existing L stair, a 10 × 8 m footprint and a gable roof. The actual stair has 20 risers of 16 cm, so the fixed floor-to-floor height is 320 cm; the earlier 300 cm description was corrected before implementation.

Assets: /Game/Lambeer/World/Environment/Procedural/BP_PCG_ModularHouse inherits ALambeerPCGBuilding. Its saved graph PCG_ModularHouse connects the native Lambeer Building Layout node to Static Mesh Spawner and Output. The preview map is /Game/Lambeer/World/Maps/L_PCG_BuildingPreview/L_PCG_BuildingPreview; the owner saved the initial level. Existing ModularKit geometry and the owner's separate BP_House2Floor are preserved.

Owner-approved floor count — 2026-10-02: the owner requested more than two floors and selected a maximum of 3 floors. Select the house actor's Self row, then edit Layout → Number of Floors to 1, 2 or 3. Searching Number of Floors in Details also exposes this control. The serialized native field remains Layout.Storeys, preserving existing actor and Blueprint values; the initial default remains 2. Rectangle and Spline modes repeat the same footprint and windows at 320 cm floor-to-floor spacing. Each upper slab leaves the full 3 × 4 m stair hole, and the existing unscaled L stair connects each adjacent pair of floors at the configured XY/yaw. One floor has no stair. The ceiling and roof move above the selected top floor; horizontal overhang and roof guides retain their existing plan dimensions. Exterior entrances remain ground-floor-only.

Floor-count validation — 2026-10-02: Editor and Game Win64 Development builds succeeded. All five PCG automation tests pass with zero errors/warnings. The new MultiStorey test checks 1–3 floors in Rectangle and L Spline modes, one unscaled stair per adjacent pair, unique piece keys, exact upper-floor hole areas, full ground/ceiling coverage, top-roof elevation, ground-floor-only entrances, stair clearance and rejection of 0, 4 or oversized counts. Live Rectangle generation at 3 floors reports 1096 pieces, with actual stair instances at local Z=0 and Z=320; a third-floor slab trace hits Z=640 and a short trace through its opening has no hit. Saving and reloading retained the 3-floor value, valid generation and both stairs; the Rectangle was then restored to its existing 2-floor setting. Native Number of Floors is visible in Details. Floor-count evidence.

Latest owner-edited L example: before the build the owner had selected 1 floor, moved its left edge to X=180 and point 3 to approximately (599,400), and changed the entrance to edge 2. Those exact six points, door, roof guides and materials were saved and preserved. Testing 3 floors with the unchanged stair start (100,300) correctly reports The rotated stair, 1 m approach and +X upper landing must fit inside the wall perimeter. That historical increment retained the owner's 1-floor selection. The later floor/ceiling refinement retains the same footprint and generates 2 floors with an authorized relocated stair. To author 2 or 3 floors on that edited outline, adjust the footprint or stair location/yaw until the full stair and approach/landing fit inside the walls; this increment does not redesign the owner's outline automatically. Owner-only PIE check: review a valid 3-floor house, ascend and descend both stair flights, check each landing and verify floor/wall collision. Traversal acceptance is pending; no agent PIE pass is claimed.

Ground perimeter, circulation, rooms and exterior finishes — in progress

Owner report and scope — 2026-10-02: the lowest floor must meet the exterior wall edge. The two-floor L has areas blocked by the stair. Generate interior rooms with doors connecting every room; coordinate exterior windows with those rooms so partitions never meet window openings. Add exterior wall finish with a separate material from the inside wall face. This request supersedes the earlier open-plan exclusion of room partitions.

Ground perimeter implementation: Rectangle and Spline layouts now extend the lowest 20 cm structural slab beneath the exterior wall to the exact footprint, including the nonparallel L corner. Its FloorPerimeter section uses Floor Material. The interior floor remains the contact profile for gameplay finishes, preventing tiles under the exterior walls. Upper slabs and ceilings retain concealed edges. The code builds in Editor and Game; the new GroundSlabPerimeter test passes area, corner, thickness and finish-boundary checks. The final 10 PCG tests pass with zero errors/warnings. All three preview houses were regenerated, saved and reloaded: rectangle ground area is 80 m2; each L is 49.58 m2. Collision hits beneath the wall and remains clear outside the footprint and in the removed L corner. House IDs, floor counts, outlines and current owner materials are preserved.

Circulation diagnosis: the earlier stair validation checks footprint, approach and upper landing containment, not whole-floor reachability. A read-only 2-degree / 10 cm candidate search finds 539 contained placements but no connected upper-floor walking area around the existing full 3 x 4 m hole for either a 42 cm capsule radius or the proposed 50 cm corridor radius. This sampled search is not a proof of arbitrary-angle infeasibility, and is not a PIE test. The owner subsequently authorized a redesigned stair while retaining the exact footprint. Diagnostic search and limits.

Historical automatic room program — [OWNER CONFIRMED, 2026-10-02]: The current guide-only contract retires its room-size minimums. default total per house is 3 bedrooms, 1 bathroom and a combined kitchen/living area, with corridors. The accepted two-floor starting distribution is 1 bedroom, bathroom and kitchen/living downstairs, and 2 bedrooms upstairs. Adjustable minimums: bedroom 9 m2 and 240 cm shortest side; bathroom 3 m2; combined kitchen/living 12 m2; corridor 100 cm wide. Updated owner decision, 2026-10-03: room counts are targets; generate the closest feasible program even when the requested counts cannot all be met. This supersedes the previous prohibition on automatic count reductions. Minimum room dimensions and safe circulation remain constraints. Owner-confirmed priority: retain kitchen/living and at least one bathroom, then reduce bedrooms while preserving minimum areas and corridor width; show actual generated counts in Details. Allow Fewer Rooms enables this behavior; disabling it retains exact-count validation. Ground Floor Bedrooms remains the preferred per-floor target. The bounded stair search retains the valid candidate with the most bedrooms, then bathrooms, without moving authored exterior entrances. This is the best result among tested candidates, not a proof of a globally optimal floor plan. Larger houses may expose larger counts and room sizes. The owner authorizes a redesigned stair while preserving the exact house footprint. Exterior finish is owner-confirmed: include gables, 1 cm thickness, independent player build/remove/replace, completed wall support, support-removal cascade, and 50% rounded-down completed refund. Unfinished cancellation remains 100%. Agent may set initial material costs.

Historical automatic room generation and circulation — 2026-10-03: the saved one-floor L uses its existing one-bedroom preset; the 10 x 8 m rectangle generates the confirmed three-bedroom program across two floors. Every private room has a separate frame/open leaf and a clear approach connected to the common circulation. Window positions are derived after partitions, with a 25 cm junction margin; they may not straddle a room boundary. Details exposes Generate Rooms, Bedrooms, Bathrooms, Ground Floor Bedrooms, minimum room areas/bedroom side and Corridor Width. Rejected requests retain the last valid geometry and counts. The search is bounded and uses rectangular private rooms in actor-local coordinates; a failed search is not a proof that no architectural solution exists.

Exact-width correction: circulation samples include exact clearance boundaries and required entrance/landing coordinates, so a valid 100 cm passage is not missed merely because its centre lies between the 10 cm lattice columns. Link clearance remains checked against the actual polygon edges. The living-area calculation now reserves the same shortest routes instead of using a second, inconsistent walking grid. It measures the largest remaining connected area conservatively; corridor area is excluded. Search diagnostics report candidate and connected-layout counts and the largest living area tested for the reported arrangement.

Two-floor L - flexible generation validated, final acceptance pending: with the saved edge-5 entrance at 475 cm and stair preference (210,420), yaw 0 unchanged, the bounded search generates one upstairs bedroom, a downstairs bathroom and kitchen/living, preserving minimums and 100 cm circulation. Door capsule sweeps and all 20 stair tread/head checks pass in Editor. Windows intersecting the stair or its reserved margin are now omitted; all generated window margin probes pass after rebuilding and reloading. This is not a globally optimal room count or a PIE result.

Historical guided-room authoring — 2026-10-03, superseded by the current guide-only contract: the owner selected closed per-room splines with floor/type assignments and optional door/window markers. Enable Use Room Guides on the house. Add Room Guide, Add Door Guide and Add Window Guide create attached editor-only actors and register them on that house. Select a room child and edit RoomSpline in the viewport. Lines follow wall centres; adjacent rooms must share the same line, and perimeter room lines follow the exterior wall centre, 12.5 cm inward from the footprint. Actual clear room dimensions exclude the 25 cm walls. Arbitrary straight polygon edges are supported; curved, crossing, overlapping and undersized guides are rejected instead of replaced by bounding boxes.

1. Choose each guide's Room Type: Bedroom, Bathroom, KitchenLiving or Corridor. Floor is zero-based (0/1/2). Use Make Linear And Set Floor Height explicitly after changing floor or importing curved/nonplanar points. It sets the selected room's points to the house-local floor height; it does not resize the room.
2. Keep at least one ground-floor Bathroom and KitchenLiving guide. Leave common circulation between rooms or author Corridor guides. Authored guides are never dropped to satisfy automatic count targets.
3. Place each Opening Guide near the intended wall at house-local Z = Floor × 320 cm. Door frames stay 100 × 200 cm; windows stay 100 × 150 cm with a 75 cm sill. Ground-floor exterior Door Guides replace the exterior Doors list for generation. Snap Opening To Nearest Valid Wall explicitly positions and rotates a selected Door or Window Guide against complete-house validation. Door candidates use same-floor room walls or a ground-floor exterior wall; windows use exterior walls only. Snap Status reports the result.
4. Auto Snap Invalid Opening Guides defaults on. If regeneration fails on an opening guide, it tests nearby wall positions, then moves and rotates the necessary markers only when the complete house validates. Room and footprint splines stay authored. Disable this option to require exact marker locations. Enable Auto Connect Room Guides separately to fill missing door connections, or disable it to require explicit Door Guides. When any Window Guide exists, only marked windows are generated. Two adjacent rooms can share a wall when their boundary lines coincide exactly and their interiors do not overlap; the shared interior wall is split at room junctions and emitted once.
5. Use Regenerate House on a guide or Regenerate Building on the house. Read Validation Status and Generated Room Summary. Invalid layouts preserve the previous generated house. Guide edits do not launch an expensive search on every spline drag.

Guided validation status - 2026-10-03: final Editor/Game builds succeed and all 39 PCG/Building/Persistence tests pass, including closed outlines, explicit doors/windows, non-axis-aligned edges, shared adjacent walls, reduced targets and invalid-guide rejection. One existing GameplayCueNotifyPaths fallback warning remains. The saved PCG_GuidedRooms_Example at (0,1800,0), unit scale, contains three editable room guides and four opening markers. All four preview houses pass door/window geometry probes; both two-floor houses pass 20 stair tread/head checks. Save/reload preserves all four distinct house IDs, settings, guide references and room results; the preview map is saved clean. Details exposes the three Add Guide buttons and the linked arrays. These are Editor checks, not CharacterMovement or PIE acceptance. Final evidence.

Runtime boundary: guides are editor-only authoring inputs. Saved house geometry and the existing central finish-tile persistence remain authoritative in gameplay. This feature does not introduce runtime PCG regeneration, new structural ownership, or an ad-hoc save path. Owner-only PIE traversal remains required.

Compact stair: the reusable U module measures 225 x 350 cm, with two 100 cm clear flights, 20 risers at 16 cm, 25 cm treads and a 100 cm turn landing. The earlier open-plan L at (840,40), yaw 90 degrees passed 29 Editor capsule checks; that historical result does not validate a new room layout. Current rectangle tread/head checks and the rectangle/one-floor-L door and window collision probes pass. Only the owner tests CharacterMovement, step-up, navigation and multiplayer in PIE.

Exterior finish — implemented: separate 1 cm decorative surfaces cover exterior walls and gables, clipped around actual door/window/louver openings. Enable Layout > Finishes > Exterior Wall Finish and choose Building > Piece Types > Exterior Wall Finish Type. Wall Type controls room-facing structural walls independently; MI assignments belong to the corresponding piece Data Asset. The 100/50/25 cm modules are separate construction items, with completed-wall support and support-removal cascade. Costs are Wood/Brick/Concrete 2/3/4 for 100 cm and 1/1/1 for 50/25 cm. Authored house surfaces use clipped 1 m2 cells, including partial gable/opening cells; unowned original cells cannot be refund-demolished, but can be destroyed by weapon damage without refunds. Completed demolition returns 50% rounded down, unfinished cancellation 100%. Tombstones and replacements use the existing central persistence path. No new material instance was authored.

Reference: the owner supplied Procedural Room Generation with Splines and PCG. Its page body was unavailable to the reader; the author's Epic Forum summary describes spline shape definition, directional offsets/set differences and oriented perimeter placement. Those boundary concepts inform this implementation; the summary does not establish a whole-house room-connectivity solver.

Earlier validation before guided authoring: final Editor and Game Win64 Development builds succeeded; all 37 PCG/Building/Persistence tests pass. One existing GameplayCue path-fallback warning remains. All 45 HTML documents validate with zero errors/warnings. A temporary distinct existing MI verified independent exterior/inside bindings; owner overrides were restored. Three saved house IDs remain distinct. Build/test/status evidence. Geometry inspection is Editor-only. Door/window/stair geometry · Per-house generation status. Owner-only acceptance: start Dedicated Server plus two clients, traverse every generated room and stair in both directions, check windows and inside/outside materials, verify X denial, then damage-destroy/replace an exterior finish on an unowned house, verify the second client, then restart/rejoin to verify persistence. Flexible-target and guided-authoring Editor validation is recorded above; owner PIE acceptance remains outstanding.

Independent 200 x 200 cm door kit — 2026-10-08

Owner-authorized addition, correction and retirement: SM_DoorFrame_200x200 and SM_DoorLeaf_200x200 extend the retained 100 x 200 cm pair. Names describe the compatible frame outer size. The frame now measures 15 cm deep x 200 cm wide x 200 cm high, with 5 cm jambs/head and a 190 x 195 cm inner opening. The owner corrected the initial wide single leaf to two half-leaves on opposite jambs: each solid panel measures 4 x 94.55 x 194 cm, with a 3 mm centre gap in the fitted closed dimensions, 3 mm side gaps and 5 mm top/bottom gaps. Both panels use the existing static 90-degree open pose; the open assembly bounds are 189.4 x 94.55 x 194 cm. The retained 100 cm door stays a single leaf. Both assets have unit transforms, named DoorFrame/Door slots, metre UV0 and complex-as-simple collision. Existing Door Appearance Sets supply Wood, Brick and Concrete choices and defaults.

Construction and authoring: both sizes are separate player catalog entries and ManualHouse Piece Definitions. Each new frame and complete leaf assembly uses the owner-selected temporary bill Wood 4 / Brick 6 / Concrete 8; this bill covers both half-leaves in the 200 cm assembly. The assembly remains one Piece Definition, one placement and one durable record. Its original left-hinge pivot and snap transform are preserved, so existing placed 200 cm doors update through the same mesh reference. Resource health and appearances inherit the current 100 x 200 definition. Slabs and walls expose dimension-aware frame seams; a leaf assembly snaps only to the completed frame of its matching nominal size. Exact support, duplicate/obstruction checks, frame-removal cascade, refunds and central BuildingSites/SupportSiteId persistence apply to both sizes. No new save field or schema version is required. Current PCG generation continues to use its existing 100 x 200 pair.

Removed from current production assets: SM_Opening_ExteriorDoor_200, SM_Opening_InteriorDoor_200, SM_Opening_InteriorPassage_200, SM_DoorLeaf_Standard and their four Piece Definitions. MCP reference inspection found only BP_OpeningPiece's default exterior-opening mesh; its default now uses the retained 100 x 200 frame with matching Run Cm/Height Cm. No saved Lambeer level or current ManualHouse record used the retired IDs. The retired IDs are removed from native catalogs rather than mapped onto geometrically different pieces. Older external saves containing them are outside the retained compatibility set. Dated source catalogs and previous audit evidence remain historical references; they are not current selectable assets.

Current inventory: 53 ModularKit Static Meshes, 53 Piece Definitions and 39 player-selectable catalog entries. Shared Appearance Sets remain unchanged.

Sources: 200 x 200 Blender source · Frame FBX · Leaf FBX. The active Blender scene/file was restored after isolated export.

Initial addition/retirement validation: final Editor/Game Development builds pass. All 77 distinct Building/PCG/Persistence checks pass after correcting two older fixtures that assumed a 20 cm slab; the final focused rerun passes all 9 checks. Coverage includes both door sizes, actual doorway/jamb/header collision, wall seams, cross-size rejection, exact rotated completed-frame support, duplicate/obstruction checks, cascade/refunds, both durable IDs/parent links and automatic defaults across all 53 current definitions. The full run reported an RHI reserved-resource-budget warning and the existing GameplayCueNotifyPaths fallback warning; neither produced a test error. Three authoring Blueprints compile with warnings treated as errors. Scoped save/reload preserves all 948 owner records and reported 948 instances/5 batches. Only the next-piece target is set to the new frame, retaining Wood/LightWood/Single. The eight retired packages are absent. All 47 canonical HTML files validate. Build, automation, reference cleanup and save/reload evidence. Physical viewport input, PIE/multiplayer and packaged cook remain owner acceptance work.

Double-leaf correction validation — 2026-10-08: the updated Editor Development build and all 11 scoped Building/Persistence automation checks pass. Traces hit the two opposite open half-leaves and keep the central passage clear; matching-size snaps, duplicates, refunds, support links and save codecs remain valid. The existing GameplayCueNotifyPaths fallback warning appears in ManualHouseLifecycle, with no test error. The source frame geometry is unchanged; material slot, Nanite/build/lightmap settings and collision policy are retained. Scoped save/reload preserves the latest 948 owner records, including the owner's placed 200 cm frame/leaf IDs, transforms, appearance and parent link, with 948 instances/5 batches and Leaf200/Wood/LightWood/Single next-piece settings. Both leaf solids are visible in the actual GeneralHouse viewport capture. Current correction evidence. Interactive opening/closing is outside the current static-pose kit; owner PIE and packaged cook remain unperformed.

Wood door redesign — authored; owner visual review pending

[OWNER SELECTED — 2026-10-10] Retain concept 02, Crafted Two-Panel Wood, for the independent wood door frame and leaf at both existing nominal sizes. Correct its horizontal dividing rail to the exact midpoint of each leaf height, giving equal-height upper and lower recessed panels. Apply the correction to the single leaf and both opposite-jamb leaves of the double assembly. The original concept image below is historical reference: its low dividing rail is superseded by this explicit owner correction.

[OWNER PRODUCTION AUTHORIZATION — 2026-10-10] The owner's instruction to start supersedes the earlier deferred status. The owner also requested black handles and hinges. Four editable Blender meshes and three wood finishes plus matte black hardware are authored and integrated. Keep the existing two-size dimensions, fit, pivots, placement and persistence contract. These are Wood Appearance render meshes; the five legacy Door Wood choices are retired by the 2026-10-12 owner decision. Brick/Concrete choices remain available. Follow the material quality workflow; the new finishes remain provisional until owner visual acceptance.

[OWNER COLOR AND MESH DECISION — 2026-10-10] Produce exactly three selected wood finishes together: the original medium warm wood from concept 02, B — Pale Honey Wood and C — Whitewashed Ash. Reuse the same geometry across all three finishes: one frame mesh and one leaf mesh/assembly per existing nominal size, shared by the color variants. Change material/Appearance bindings, not geometry, when switching color. The two sizes and the separate frame/leaf assets remain distinct; this is not one stretched mesh for all pieces. All three use the centered dividing-rail correction. A — Light Natural Oak is retained only as an unselected proposal. Color selection does not establish actual UE material acceptance.

Retained selection: Original selected concept 02 · Selection, correction and production record. The rail position in the written decision takes precedence over the original image.

Authored geometry: SM_DoorFrame_TwoPanel_100x200, SM_DoorFrame_TwoPanel_200x200, SM_DoorLeaf_TwoPanel_100x200 and SM_DoorLeaf_TwoPanel_200x200 live under /Game/Lambeer/World/Environment/ModularKit/Meshes. Each leaf's rail is centered at local Z=97.5 cm between Z=0.5 and 194.5 cm; upper/lower clear panels are both 82 cm tall. Front and back are recessed; fine bevels and metre UV0 cover faces, rails, stiles and ends. Frames have 180 triangles each; revised single/double leaves have 7,336/14,672 source and full-detail fallback triangles. All are closed manifold, unit scale, Nanite enabled and complex-as-simple collision. Slot 0 is DoorFrame or Door; leaf slot 1 is DoorHardware. Black levers/backplates on both faces and three complete butt hinges per leaf are static hardware, owned by Leaf. The 4 cm wooden body and logical placement envelope remain unchanged; handles project 2.5 cm beyond each face and the Leaf-owned jamb plate projects 3.52 cm beyond the local minimum-Y edge, onto the frame contact surface. Native validation permits these exact render extensions only for the two logical DoorLeaf IDs with an explicitly bound DoorHardware slot. Opening/locking gameplay is outside this static-pose authoring change.

[OWNER SELECTED AND REVISED — 2026-10-10] The owner selected A — matte-black butt hinges and requires no visible hinge when only Door Frame is placed. This supersedes the earlier proposed Frame/Leaf hardware split. Both mounting plates, interleaved cylindrical knuckles, pin and screw heads are now owned by the Door Leaf render mesh, with three complete hinges per leaf and six on the double assembly. Bare Frame remains wood-only and byte-identical to its prior asset. Adding/removing a Leaf adds/removes the complete hinge assembly, including the visually frame-mounted plate. Original, B and C retain the same revised per-size render meshes and existing black hardware MI. This remains the existing static open pose; interactive swinging/locking is outside scope. A future moving-door implementation must keep the jamb plate fixed and condition its visibility on Leaf presence, rather than rotating this entire static assembly.

Hinge concept references — 2026-10-10: A — Butt hinge (owner selected) · B — H hinge (unselected) · C — Strap hinge (unselected) · Original prompts. These AI concepts are shape references; selection does not establish acceptance of the actual Unreal result.

Hinge revision delivery: the two existing Leaf render packages now contain 7,336 / 14,672 source and full-detail fallback triangles. Wood geometry, UV0, centered rail, handles, pivots and fitted placement transforms remain unchanged. The authored hinge barrel radius is 0.55 cm, height is 8 cm and centers remain at Z=22, 97.5 and 173 cm. In the double assembly the opposite-jamb axis is mirrored at local X=189.4 cm. Leaf/jamb plate faces project 0.08 / 0.02 cm beyond the corresponding wooden contact surface to avoid depth fighting. Logical placement/support bounds remain unchanged; the narrowly scoped DoorHardware render validation now permits exactly 3.52 cm beyond the hinge edge (local minimum Y) for the corrected jamb plate described below. Nanite remains enabled, with full fallback geometry, position precision 8 and maximum edge-length factor 1 to retain small hinge detail and verified bounds. Existing Frame packages, shared Appearance Set, MIs/maps and master remain unchanged.

Revision evidence: Editable revised Blender source · Hinge geometry and axes · Wood/UV preservation · Both sizes/all colors: Frame only → Leaf added → removed → restored → Frame only · Save/package and level reload, independent bindings and owner preservation · 16 passing scoped tests. Editor/Game Development builds pass. The final test run also recorded tool-schema delegate warnings; no test errors or failures occurred. Six pre-existing door/window review assemblies and 988 GeneralHouse owner records remain unchanged. Three additional bare-frame review assemblies and three local neutral 15-lumen inspection lights are confined to the review map; production house lighting is unchanged.

First hinge revision views (before the jamb-direction correction below): Original · B · C · Butt hinge detail · Opposite jamb of double assembly · Both bare frame sizes: no hinges. These are Unreal Editor captures, not PIE. Owner visual acceptance, gameplay PIE/rejoin, packaged cook and performance remain pending; source triangle counts and enabled Nanite do not establish a performance budget or pass.

[OWNER REPORTED OCCLUDED JAMB PLATE; DIRECTION CORRECTED — 2026-10-10] The owner still could not see the frame-side plate in GeneralHouse. The first hinge revision placed the jamb plate toward the open Leaf, where the leaf-side plate occluded it from the owner's view. Source ray checks reproduced that occlusion. The jamb plate, its screws and its knuckle connectors are now reversed across the barrel, onto the opposite portion of the existing inner jamb face. At the verified fitted 90-degree pose, its frame-local X span is 5.88–9.02 cm and near-jamb Y span is 4.82–5.02 cm, with the opposite double jamb mirrored. Both sizes retain 7,336/14,672 triangles; wood geometry/UV, barrel, leaf plate, handles, pivots, placements, three shared wood finishes and all materials are unchanged. The complete assembly remains Leaf-owned, so bare Frame and Leaf removal show no hardware. Native render validation permits exactly 3.52 cm beyond local minimum Y for this plate; logical placement/support bounds are unchanged.

Current correction evidence: GeneralHouse before · GeneralHouse after, same view · Both mounting plates on the actual house · Single door · Opposite jamb of double door · Bare frames · Source/wood preservation · 27 visibility ray checks · All sizes/colors add/remove and Save/reload · 16 passing scoped tests. Both Editor/Game Development builds pass. The passing tests retain the existing GameplayCue search-path warning; zero-warning native testing is not claimed. GeneralHouse retains all 988 intake records/settings; Frame, Appearance Set and master package hashes are unchanged. Actual GeneralHouse evidence uses its existing lighting. The owner clicked Save Selected when the Editor close opened a modal Save Content dialog that blocked MCP; no unsaved work was discarded. Editable Blender source and both FBXs are updated in the existing ButtHinge production folder. Actual owner visual acceptance, owner PIE/rejoin, cook and performance remain pending; these are Editor captures.

Wood Door appearance retirement — owner confirmed 2026-10-12

Selectable choices: DA_Appearances_Door_Wood contains exactly TwoPanelWarmWood, TwoPanelPaleHoney and TwoPanelWhitewashedAsh, in that order. LightWood, DarkWood, AshVeneer, OldPlywood and FlakeBoards entries are removed from the shared set. Both Frame and Leaf sizes (100x200 and 200x200) default to TwoPanelWarmWood. ManualHouse Snap/ISM/authoring-handle options and player Building's Build Catalog/authoritative validation use this same set. Shared material assets used by other piece families remain available; Brick/Concrete resources and appearances are unchanged.

Fallback and existing data: absent or retired Door Wood appearances resolve to the surviving warm finish and its two-panel render mesh. Recognized retired IDs repair in map-authored ManualHouse records and stale Snap/handle settings on load/rebuild. Central world restore uses the existing USaveSubsystem/ULambeerWorldPersistenceSubsystem codec/catalog migration; site/local identity, pose, support links, ownership, resource, HP, contributions and removal state are retained. Current Pale Honey/Whitewashed Ash selections remain selected. New authoritative placement rejects retired IDs. No save field, schema, bill, health, placement envelope or mesh source changes are introduced.

Verified — 2026-10-12: Editor/Game Win64 Development builds pass; all 12 scoped automation tests pass without errors/warnings. Coverage includes all four Frame/Leaf definitions, exact three-choice ManualHouse/player menus, rejection/render fallback of all five removed IDs, stale snap repair, and central codec restore of 12 current plus 20 retired door records with identity, pose, support, HP, contributions and removal state retained. Restarted Editor disk readback confirms the exact retained bindings and four defaults, unchanged Brick/Concrete data, both Blueprints compiled/saved clean and all 1,408 current owner records/settings retained (16 ISM batches). No current owner record required migration. Verification evidence. Owner-only Dedicated Server/two-client PIE, rejoin, visual acceptance and packaged cook remain unverified.

Shared Appearance bindings: DA_Appearances_Door_Wood contains only TwoPanelWarmWood, TwoPanelPaleHoney and TwoPanelWhitewashedAsh, displayed as Crafted Wood - Warm / Pale Honey / Whitewashed Ash. All three bind the same four render meshes to the retained logical IDs. Slot 0 uses MI_WoodDoor_Original, MI_WoodDoor_PaleHoney or MI_WoodDoor_WhitewashedAsh; slot 1 shares MI_WoodDoor_Hardware. All four MIs live under /Game/Lambeer/World/Environment/Materials/Instances and directly inherit /Game/SenseiMaterials/Materials/M_BlendMaster_Nanite. Separate BaseColor, DirectX Normal, AO, Roughness and Metallic textures use the audited inputs; Specular/AO switches and their overrides are explicit, Mask is disabled, UV tiling is one, displacement is zero and tessellation is disabled. The parent master disk asset is unchanged.

Editable source: Blender source and four FBXs/20 final texture maps are retained beside it. Painter source projects are in D:/Substance/Projects/WoodDoor_TwoPanel_20261010: Original.spp, B_PaleHoney.spp, C_Whitewashed.spp and Hardware_Black.spp. The editable bundled wood_plain material supplies all three colors; wood species and physical scan calibration are unverified. The authored UV tile is one metre. Wood maps are 2K and constant hardware maps are 256px. Geometry checks · Final Painter settings · Texture provenance.

Validation and review: Editor and Game Development builds and 16 scoped automation checks pass, including the two new shared-geometry/hardware and central persistence checks. All 12 frame/leaf color records retain logical IDs, VariantId and frame SupportSiteId through the existing world codec; no save field/schema change is required. The existing GeneralHouse's 988 owner records and next-piece settings match the pre-authoring snapshot. The dedicated /Game/Lambeer/World/Maps/L_WoodDoorReview_20261010 presents all three finishes at both sizes with actual ManualHouse ISM/material bindings and clapboard context. Automation results · Owner record readback · UE mesh and independent slot checks · Scoped Save/reload evidence.

Initial production views (before the hinge revision above): Original · B Pale Honey · C Whitewashed Ash · Rail, panel relief and hardware · Back, ends and frame joins. These are Editor captures, not PIE. AI concept boards above remain shape/color references. Owner visual acceptance, owner PIE, packaged cook and performance acceptance remain pending. Color names describe the selected direction and do not establish wood species.

Wood window finishes — integrated; owner visual review pending

[OWNER REQUEST — 2026-10-10] Reuse the three authored door wood finishes on both window sizes: Original medium warm wood, B Pale Honey and C Whitewashed Ash. The owner additionally authorized replacing the 75 × 75 window's WorldGrid glass placeholder with the existing glass used by the 100 × 150 window. No new window shape or opening behavior was requested.

Selectable shared integration: /Game/Lambeer/World/Environment/ModularKit/Data/Appearances/DA_Appearances_Window_Wood contains the three new variants, with the matching existing BaseColor previews. Each variant uses the same two size-matched render meshes: SM_Window_Wood_100x150 and SM_Window_Wood_75x75 under /Game/Lambeer/World/Environment/ModularKit/Meshes. Logical IDs remain SM_Window_100x150 and SM_Window_75x75. The five legacy Window Wood variants are retired and both sizes now default to CraftedWarmWood; Brick/Concrete sets are unchanged. See the shared retirement and save migration contract. Building/ManualHouse resolve the shared variants, and native PCG Window options expose all three IDs.

Target mapping: the render meshes preserve the original source geometry, pivots, centimetre bounds, unit transforms, two slots and source convex collision; triangle counts remain 84 and 60. Only wood UV0 is fitted per connected member: longitudinal grain runs vertically on jambs/vertical mullions and horizontally on rails/horizontal mullions, at one UV repeat per metre. Glass UVs are unchanged. Nanite stays disabled on these mixed wood/translucent-glass meshes. The original logical meshes retain their UVs and geometry; the 75 × 75 logical mesh's glass slot is updated under the explicit owner instruction.

Independent glass: slot 0 is MF01_Trim and slot 1 is MF01_Glass. Both piece definitions' fixed slot 1 now references /DatasmithContent/Materials/FBXImporter/VRED/Glass.Glass, the existing 100 × 150 resolved glass material. The same glass is bound on both new render meshes. Selecting a wood finish never assigns wood or door hardware to glass. The existing MIs and texture maps are reused directly; their master/input/displacement settings and editable Painter provenance remain canonical in the door record. Source physical scan dimensions remain unverified; the one-metre tile is the authored test scale.

Editable source and evidence: WoodWindow Blender source and two FBXs in the adjacent Export folder. Source geometry/UV checks · Render mesh and Appearance readbacks · Owner-authorized glass correction. No additional texture download was needed.

Actual UE review: the existing /Game/Lambeer/World/Maps/L_WoodDoorReview_20261010 now includes three window assemblies against SmoothPlasterPartition, each containing both nominal sizes at unit scale. Existing door review records are retained. Review lighting/exposure is inherited unchanged from the door review map. Original · B Pale Honey · C Whitewashed Ash · Grain, mullions and reveals · Back faces and frame/wall fit.

Validation boundary: six existing scoped automation checks pass without warnings/errors, covering all catalog definitions/variant eligibility, appearance menus, shared PCG resolution and Building/ManualHouse persistence codecs. Five authored/changed packages and the review level are scoped-saved and disk-reloaded; native components retain each wood MI independently from the common glass. All three window assemblies' records, the existing door review records and the original GeneralHouse's 988 owner pieces/settings match their baselines. The shared master disk asset is unchanged. Automation results · Native slot/mesh/PCG options · Save/reload and preservation proof. This is asset authoring with the existing persistence contract; no C++ or save-schema change. Fresh PCG house generation for every new window finish, owner visual acceptance, owner PIE/rejoin and cook/performance remain unperformed. These finishes remain provisional under the material quality workflow.

Two-pane window 200 × 150 — owner revision, 2026-10-12

[OWNER SELECTED AND AUTHORIZED] Rectangular proposal 01 is revised to two large equal left/right glazing panes, with one vertical centre mullion and no horizontal centre rail. Overall dimensions are 200 cm wide × 150 cm high × 15 cm deep. The existing 100 × 150 source supplies the 5 cm perimeter profiles, 4 cm centre mullion and 0.3 cm glass thickness. Source members are closed; UV0 follows each wooden member at one repeat per metre, with the existing provisional procedural-map scale retained. This new piece does not replace the existing 100 × 150 or 75 × 75 windows.

Shared integration: logical/player ID SM_Window_200x150 and Wood render mesh SM_Window_Wood_200x150 live in /Game/Lambeer/World/Environment/ModularKit/Meshes. DA_Piece_Window_200x150 in the sibling Data/Pieces folder references the same Window Appearance Sets. The Wood set retains exactly CraftedWarmWood, PaleHoney and WhitewashedAsh, all referencing the same new size-specific render mesh. Slot 0 reuses MI_WoodDoor_Original, MI_WoodDoor_PaleHoney or MI_WoodDoor_WhitewashedAsh; fixed slot 1 reuses /DatasmithContent/Materials/FBXImporter/VRED/Glass.Glass. Existing MIs, texture maps, master and older window bindings are retained. Brick/Concrete keep their existing Window set contracts.

Owner-approved bill and durability: each resource uses 1.5 × the existing 100 × 150 definition, rounding upward: Wood 12 units / 600 HP, Brick 18 / 1,350, Concrete 24 / 2,400. These editable Data Asset values are the runtime source of truth; no new balance values are inferred from area. The native catalog now has 39 player-selectable pieces. Building lists the wide window under Window; ManualHouse selects DA_Piece_Window_200x150, Resource Wood and one of the three existing appearances. Both use the shared bounds-based snap/overlap resolver; place into a prepared 200 × 150 bay, including across adjoining base-wall modules. Placement does not cut a solid wall.

Persistence: player sites and authored ManualHouse damage/removal deltas use the existing USaveSubsystem / ULambeerWorldPersistenceSubsystem schema-1 world-state path. The new catalog ID, existing VariantId, rotated transform, contributions, partial HP, stable SiteId/HouseInstanceId and tombstones use the existing record contract. No schema or alternate SaveGame path is introduced. New focused Lambeer.Persistence.WideWindow200x150 coverage exercises all three colors for player and ManualHouse records.

Editable production source: Blender source · Logical FBX · Wood FBX · Geometry, UV, two-pane and collision evidence.

Verified and saved: final closed-Editor Win64 Development Editor and Game builds pass. The 72 distinct Building/ManualHouse/building-persistence regression checks pass without errors or warnings, including two new wide-window checks. Actual player menu/site and ManualHouse component bindings resolve all three colors independently from glass; rotated two-module bay commit and occupied duplicate rejection pass. Fresh Editor asset disk loads and review-map reload retain the new definitions, geometry and all three 25-record wall assemblies. GeneralHouse retains all 1,298 authored records and stored authoring settings; transient status strings reset normally on reload. Existing master and four WoodDoor MI disk hashes remain unchanged. Editor returns to the original GeneralHouse/camera with the new Piece Data Asset selected in Content Browser. Validation summary · 72 clean automation results · Save/reload and preservation.

Actual target and assembled-bay evidence: review map /Game/Lambeer/World/Maps/L_Window200Review_20261012/L_Window200Review_20261012 contains three complete 400 × 300 cm plaster wall bays, each with a 200 × 150 cm fixed window at unit scale. All three assemblies · Warm front · Pale Honey front · Whitewashed Ash front · Warm reveal and joints · Pale reveal · Ash reveal · Member grain and glass detail · Opposite/shaded faces · Recorded unchanged template lighting/exposure. Images are actual UE Editor captures, not the AI concept boards.

Owner-only acceptance still pending: visually review the three colors; in Dedicated Server + two client Preview windows, choose Building → Window → Window_200x150 → Wood → each color, construct in a clear 200 × 150 bay and verify both panes/independent glass, blocked duplicate rejection and both clients. Save/restart/rejoin and check the selected color, HP and placement; separately select the new Data Asset in ManualHouse and confirm viewport placement. Packaged cook and performance are unperformed. Reused wood finishes remain provisional under the material quality workflow; no owner PIE or final visual acceptance is inferred from automation.

PCG runtime visibility and standalone doors — implemented; owner PIE pending

[OWNER CONFIRMED 2026-10-02] The owner reports the L house showing only floor/ceiling finishes in a Client 1 PIE screenshot; the old combined door-wall appearance motivates the independent frame/leaf. Live reflection finds bHidden=true on the house. Its inherited ABrush default hides the house's procedural surfaces and attached PCG instances while independent finish actors remain visible. Native constructor, PostLoad and BeginPlay repair that visibility; saved house/Blueprint settings are repaired. Runtime continues to use baked level geometry, without PCG regeneration or resetting durable finish deltas.

Independent reusable meshes: SM_DoorFrame_100x200 has overall width 100 cm, height 200 cm and the revised 15 cm depth. Existing 5 cm trim thickness gives a 90 × 195 cm inner opening. SM_DoorLeaf_100x200 fits that frame at 89.4 × 194 cm with the existing 4 cm thickness, 3 mm side gaps and 5 mm vertical gaps. Its name identifies the compatible frame size, not leaf bounds. The frame and leaf are independent unit-scale mesh instances. Walls beside the frame and the 100 cm-high header are separate wall patches/modules, with no combined wall-and-door-opening mesh. The leaf is static and open 90° into the house at its fitted hinge; interactive E open/close and lock changes are outside this approved increment. Door Frame Type and Door Type independently choose Wood/Brick/Concrete; their piece Data Assets own the MI assignments.

Player construction: the Command Ring lists Door Frame and Door separately. Each costs Wood4 / Brick6 / Concrete8. Aim near the completed frame's hinge jamb at mid-height to snap its open leaf. A leaf must match the completed frame's exact hinge position and orientation; an unfinished frame or unsupported/misaligned leaf is rejected. Duplicate leaves and unrelated solid obstructions remain rejected. Frame demolition cascades its attached leaf, using the existing Squad permissions, X input and atomic 50% rounded-down refund; unfinished cancellation returns 100%. SupportSiteId persists the frame relationship through the central BuildingSites capture/restore path, with no schema change. The former combined exterior/interior definitions were removed by the 2026-10-08 owner-authorized retirement. PCG frame/leaf geometry itself remains baked authoring geometry, without new structural demolition/ownership behavior.

Latest owner-confirmed preview arrangement: keep the existing PCG_SplineHouse_L at one floor. A separate PCG_SplineHouse_L_2Floors review copy sits at (2700,0,16) cm, using the same exact footprint/materials and original-sized stair at local (840,40), yaw90. Rectangle remains two floors. Each saved house has a distinct HouseInstanceId; the original identity is unchanged, so finish deltas remain independent. Both L variants and all material/visibility settings survive map reload.

Source and verification: Blender door kit; two imported meshes use named slots and complex-as-simple collision. Native PCG tests cover frame size, independent open leaf, all entrance edges/counts and visibility defaults. Building tests cover completed-frame fit, wrong position/angle, confirmed refunds and parent removal. Persistence tests cover independent frame/leaf IDs and parent links alongside legacy records. Final build, automation and saved-state evidence.

Owner-only PIE acceptance: start Dedicated Server with two client previews in L_PCG_BuildingPreview. Check walls, gables, roof, louvers and mutable finishes on both L variants. Walk through the new open doorway and ascend the stair in PCG_SplineHouse_L_2Floors. In the Command Ring build a frame, snap its leaf, reject a second leaf/misalignment, and remove the frame with X; verify both refunds and removal on both clients. Restart/rejoin and verify frame/leaf/support state. No agent PIE pass is claimed.

Floor and ceiling refinement — implemented; owner PIE acceptance pending

Owner decisions — 2026-10-02: retain one structural slab between storeys. Its top supports the upper floor; its underside is the lower room ceiling. Add a separate 1 cm Floor Finish above every floor and 1 cm Ceiling Finish below every room ceiling, including the top ceiling below the roof. These are independent player construction/removal/decoration items. The owner also explicitly requires finishes generated on authored PCG houses to be removable and replaceable at runtime; the confirmed tile authority and persistence rules are implemented below. The owner withdrew the lowest-floor/ground request as a misunderstanding; retain the existing slab elevation.

Exact owner L, 2 floors: the former stair start (100,300), yaw 0, lies outside the narrowed footprint. An initial sampled search found no pose for a conservative 400 × 500 cm rectangle; that result applied only to the oversized clearance box. Inspection of the unchanged Blender stair confirms the final flight occupies local Y=275–400, 125 cm wide. Clearance now tests the whole fixed 3 × 4 m stair hole, full 1 m front approach and 1 m +X landing beside that actual final flight, with concave-wall intersections rejected. The owner authorized a new position/yaw while preserving footprint and stair size. The chosen (840,40), yaw 90° passes the exact six-point owner L regression and live generation. The spline points, entrance, ridge directions, roof guides and owner materials remain unchanged. Baseline · Actual-flight search.

Slabs, concealed edges and materials: both Rectangle and Spline modes generate interior-clipped upper slabs and ceilings. The later ground-perimeter correction extends the lowest slab beneath the walls to the exterior footprint. Structural upper-floor undersides have the Ceiling role; upper floor tops and rims have Floor. The ground slab has no underside Ceiling Finish. Independent Floor, Ceiling, Floor Finish and Ceiling Finish material controls are available. Empty Ceiling follows Floor; empty Floor Finish follows Floor; empty Ceiling Finish follows Ceiling, then Floor. The existing 300 cm wall/opening modules remain unscaled. A wall-material strip covers local Z=300–320 of each storey across every perimeter edge, hiding the slab/ceiling edges outside. Finish layers preserve each full stair opening. Stairs retain unit scale and shift upward 1 cm when Floor Finish is enabled, aligning the existing 16 cm risers to finished walking levels 1/321/641.

Reusable Blender modules: six imported meshes SM_FloorFinish_100/50/25 and SM_CeilingFinish_100/50/25 live under /Game/Lambeer/World/Environment/ModularKit/Meshes. Each is a fixed square 1 cm thick with a corner/contact-face pivot, named preview material slot and complex-as-simple collision. The Blender source has 8 vertices, 6 manifold faces, positive closed volume, UVs and identity scale per module. UE import readback verifies the dimensions and pivots: Floor Finish Z=0–1, Ceiling Finish Z=-1–0. Editable source · Import evidence.

Player-built finish slice — implemented, owner PIE pending: the Command Ring catalog now contains 35 definitions, including separate FloorFinish and CeilingFinish categories with three fixed sizes. Finishes require full contact with the correct face of one completed player-built slab; unfinished slabs and other finishes cannot support them. The slab archetype exposes named anchors for all three finish sizes. Free-angle off-grid placement is retained, ceiling previews attach by their top face, and coincident 1 cm layers cannot bypass the previous thick-piece overlap tolerance. The owner delegated initial costs: each 100 cm finish costs Wood 2 / Brick 3 / Concrete 4; each 50 or 25 cm finish costs 1 unit in any tier. Existing tier visuals remain provisional.

Removal and persistence — owner confirmed: use the existing X aimed-removal key and current Squad/member/reach permissions. Cancellation of an unfinished site returns 100% of contributed units; demolition of a completed piece returns 50%, rounded down to integer units. Removing a slab also removes its attached unfinished or completed finishes. All group refund pickups must spawn successfully before any group piece is destroyed; otherwise the drops roll back and the pieces remain. The optional SupportSiteId links each player-built finish to its structural parent in the existing BuildingSites world payload. Capture/restore continues through ULambeerWorldPersistenceSubsystem / USaveSubsystem; older payloads without this field remain readable. No separate SaveGame or new schema version is introduced. Completed attached finishes also check support loss.

Authored PCG finish tiles — owner confirmed and implemented: the 2026-10-05 owner correction denies X refund demolition on unowned houses; weapon damage can destroy individual nominal 1 m² tiles without refund. A valid owner Squad is required for current members to use Hammer + X within the existing 3 m reach. Default tiles use the owner-delegated initial Wood bill of 2 units; independent Initial Floor Finish Tier and Initial Ceiling Finish Tier controls may select Brick or Concrete. Floor/Ceiling Finish Type selects both the original visual MI and resource tier from the piece Data Asset. Boundary tiles are clipped to the baked interior footprint and stair holes, remaining 1 cm thick without stretching a mesh. BeginPlay reads saved contact faces and replaces only aggregate finish visibility/collision with individual replicated construction actors; it does not regenerate the PCG house. HouseInstanceId plus room/face/cell key produces a stable original tile ID. Untouched originals derive from saved geometry; demolition stores a tombstone and player replacements retain their own site IDs, tier and contributions. Stream unload preserves replacements without demolition/refunds; restore reconciles correctly whether the house loads before or after save records. Player replacement placement/contribution retains the existing Squad and Hammer rules; completed replacements on an unowned house are also protected from refund demolition but accept weapon damage. Manual-house and native-piece HP are implemented; PCG structural HP, locks, house claims and structural PCG gameplay conversion remain separate later work.

Validation status — 2026-10-02: the eight PCG automation tests pass, including exact owner L stair clearance, interior clipping, structural underside roles, 1 cm finishes, disabled-finish behavior and unchanged full stair holes. Live L generation reports Valid layout at 2 floors with seven surface sections. Collision traces hit the upper walking finish at Z=321, first room ceiling finish at Z=299, top ceiling finish at Z=619 and the exterior wall cover at Z=310; the upper stair hole and removed L corner remain clear. Temporary independent material overrides survive save/reload and are then restored to empty, preserving the owner's other selections. The earlier eight material rows are extended by Door Frame and Door in the standalone-door refinement; generic material elements remain hidden. Focused automation additionally covers tile area conservation, thin-layer geometry, authored tombstones/replacements and central SQLite unload/reopen/reconciliation without BeginPlay. Final Editor/Game builds and saved-state results are recorded in the evidence. Current validation.

Owner-only PIE checklist: ascend/descend the relocated L stair and review landing clearance; inspect exterior concealment and room finish surfaces; on a player-built completed slab, place each finish size above/below, reject duplicate/overhanging finishes, contribute materials, cancel unfinished pieces, demolish completed pieces with X and verify rounded refunds. Remove the supporting slab and verify both finishes disappear with their refunds. Check other-Squad denial and restart/rejoin retention. On an unowned PCG house, verify X denial on original and replacement tiles, then weapon-destroy one original floor and ceiling tile from each client, verify neighboring tiles remain, replace through the Command Ring, reject occupied tiles and check stream unload/reload plus restart/rejoin retention. Damage destruction gives no refund. Owner-authorized X demolition returns half rounded down; decoration does not assign house ownership. No agent PIE or multiplayer acceptance is claimed.

Procedural roof refinement — implemented; owner review pending

Owner decisions — 2026-10-02: add adjustable Roof Pitch with a 30° default. Derive ridge rise from the actual top-wall span: smaller spans produce lower ridges at the same pitch. Anchor the eave roof plane at the top-wall boundary and continue that slope through the existing 50 cm horizontal overhang; the overhang must not increase ridge height. Split the upper half of each gable by height into a separate material region. Use complete fixed-size louver modules, including their frames. The later clearance decision below supersedes the initial single-size fit rule.

Owner scope correction: retain UE5 procedural house generation and the existing ModularKit. Blender MCP is for additional or changed reusable mesh pieces, such as the louver vent. A complete house assembly in Blender is unnecessary for this refinement. The incidental Blender house prototype is not a production deliverable or an import target. Roof shape, footprint-dependent heights, gable material regions and vent placement/fit belong to the UE5 authoring system. The identity-transform vent source is exported and imported as /Game/Lambeer/World/Environment/ModularKit/Meshes/SM_AtticVent_Louver_50x100. Frame and louver slots use an authorized white preview; the owner selects final materials in Details. Earlier 2:3 descriptions are historical and superseded by the 30° default.

Additional owner decisions — 2026-10-02: nonparallel walls may use triangulated roof surfaces following actual spans while retaining the authored ridge/cross-gable direction. Place a fixed-size louver at the horizontal centre of every fitting gable. Start at half gable height and adjust only as needed within the confirmed roof and lower-wall clearances below; omit it if neither module fits. The owner will choose both new material overrides in Details.

Details controls: Layout → Roof Pitch defaults to 30°, accepting finite angles strictly between 0° and 90°. Building → Piece Types → Upper Gable Type controls the upper half of each gable by height. Attic Vent Type uses the vent piece definition; all MI assignments are made on Data Assets. Rectangle structural modules, openings and stairs remain unscaled; adjustable roof and gable surfaces use the same procedural construction as Spline mode.

Actual-wall supports: each wing centre/yaw identifies its intended interior wing and ridge direction. The nearest opposing actual exterior wall supports facing the slope sides determine eave planes. Ridge rise follows wall separation and pitch; Width/Length are legacy read-only guide extents. Nonparallel supports meet along their geometric ridge, partitioned into triangles at ridge/valley transitions. Cross gables join through their upper envelope, clipped to the exact offset footprint. The 50 cm horizontal wall offset continues the same slope without increasing ridge rise. Keep centres inside their intended wing; missing supports or invalid roof geometry report actionable roof-only warnings while preserving valid structure. No spline points are snapped, reset or replaced.

Louver clearance revision — [OWNER CONFIRMED, 2026-10-02]: keep the whole frame at least 10 cm from the roof underside, measured normal to the slope, and at least 10 cm above the gable base / top of the lower-storey wall. Prefer the original 50 × 100 × 15 cm module. If it cannot fit both clearances, use the actual smaller 25 × 75 × 15 cm module (owner-approved Grid 25 revision, 2026-10-06; stable asset ID retains 35x70); never scale either instance. Keep horizontal centering, clamp the preferred half-height placement to the permitted vertical interval, and omit only if neither complete module fits. The full box is partitioned at all roof-plane intersections, including interior intersections, so every planar-cell vertex participates in the fit test. Concave footprint edges cannot cross the frame. Openings through both gable faces use the selected module width and height.

Smaller louver source: /Game/Lambeer/World/Environment/ModularKit/Meshes/SM_AtticVent_Louver_35x70, editable Blender source and FBX. The Grid 25 revision retains the 5 cm frame and proportionally fits the internal blade geometry to the new opening, with eight blades, two named material slots and complex-as-simple collision. Blender MCP resized this module in an isolated source copy; the original source remains retained. PCG clearance and cutout dimensions use the new actual size. Both houses in L_PCG_BuildingPreview were refreshed and verified through scoped save/reload on 2026-10-06 without changing their configuration or identity. Other existing PCG houses need regeneration to refresh previously baked cutouts. Refresh evidence. PCG material metadata controls both frame and blade slots for either size.

Named piece-type rows: the Spline Surfaces component exposes the owning house's construction-type fields instead of generic Element slots. All MI selections are centralized in Building Piece Data Assets. Self exposes the same type fields; regeneration and map reload retain type choices.

Clearance and named-material validation — 2026-10-02: Editor and Game Win64 Development builds passed, and all six PCG automations passed without test errors or warnings. Coverage includes large-module preference, smaller-module fallback, omission when neither fits, 10 cm roof-normal and lower-wall clearances, unit scales, both-face openings and semantic slot lookups. The live owner L uses four 35 × 70 cm louvers; Rectangle uses two 50 × 100 cm louvers. The owning actor material overrides reach the upper-gable section and both slots of either module; temporary verification choices were restored. Native Slate inspection confirms all five named rows with the generated override array hidden. Blueprint compile and save/reload preserve exact owner geometry, materials, counts and vent transforms without duplicates. The preview map and Blueprint are saved clean. Validation evidence · Louver clearance view · Named Details rows. Owner visual acceptance and any PIE traversal remain owner-only.

Initial refinement validation — 2026-10-02 (before the clearance revision): Editor and Game Win64 Development builds succeeded; all six PCG automation tests passed with zero errors/warnings. RoofRefinement covers 15°/30°/45° pitches, different spans, zero/50 cm overhang, wall-top anchoring, half-height gable faces, fixed-size lowered vents, real openings through both faces and the owner's nonparallel L regression. Live Rectangle retains 2 floors, 644 instances and 3 surface sections with 2 vents; the exact owner L retains 1 floor, 12 instances and 4 sections with 4 vents. Details material overrides were verified on the upper gable and both vent slots, then restored to empty for owner selection. Blueprint reconstruction no longer leaves duplicate PCG instances: generation waits until resource restoration finishes and removes only this component's leftover generated ISMs. Blueprint compile and map save/reload preserve configurations, materials, counts and vent transforms without duplicates. The map, Blueprint and graph are saved clean. Validation evidence, exterior and fitted louver. Owner visual and PIE acceptance remain pending; no agent PIE pass is claimed.

Free-angle spline footprint and cross-gable roofs

PCG reuse clarification — 2026-10-02: the owner pointed to the Engine PCG plugin Content folder shown in a YouTube example. This tool already uses Unreal's PCG Framework: APCGVolume, UPCGComponent, graph evaluation, UPCGStaticMeshSpawnerSettings and mesh selection by attributes. The custom Lambeer Building Layout node computes project-specific footprint/opening/stair/roof data; it does not replace the framework. Spline surfaces use Unreal's ProceduralMeshComponent and GeometryCore triangulation. No specific asset/class from that video has been identified or adopted; the screenshot only identifies the PCG plugin Content folder.

Owner-authorized decisions — 2026-10-02: roof overhang uses 50 cm horizontal plan distance from exterior wall faces on every side, including gable rake ends. Details exposes ground-floor Doors: array length sets count, Edge follows the original footprint direction, and Offset Cm starts the independent 100 cm-wide frame; a negative value centres it. Empty means no entrances. The earlier 200 cm combined entrance assembly is superseded by the confirmed standalone frame/leaf refinement. Legacy single-entrance settings migrate once and remain read-only; an intentionally empty list survives reload.

Confirmed spline drag diagnosis — 2026-10-02: the owner reproduced the failure on the L example by moving point 3 from (600,400,0) to (748,703,0). The original roof guides stayed unchanged; Validation Status reported uncovered roof area and generation cleared the whole house. Point arrays remained synchronized, Linear and planar; arbitrary angles were not the cause. Generation now retains valid floors, walls, windows/entrances and the stair when only roof validation fails, discards incomplete roof/gable output, and reports Structure generated. Roof not generated: .... Structural/door/stair failures remain fatal. This historical stale-guide failure is superseded by actual-wall support fitting above. Explicit Fit Roof Wings changes wing seeds/directions; ordinary spline edits retain them while recalculating wall supports. Rectangle mode ignores spline edits. Owner reproduction evidence; earlier read-only baseline.

Architectural realism assessment: a 50 cm overhang is plausible as a visual house detail: gable overhangs shade openings and reduce rain exposure on walls. The PNNL Building America guide describes fascia, supporting framing and soffit closure; in high-wind applications it recommends outrigger framing for gable overhangs deeper than 12 inches. At approximately 19.7 inches, this requested projection should visually read as supported construction rather than an unsupported thin sheet. This is an art/geometry assessment, not structural approval or a new framing-asset requirement. At the current 30° default, 50 cm horizontal eave projection follows approximately 57.7 cm of slope and drops approximately 28.9 cm from the wall-side roof plane. Gable rake ends extend along the ridge. Framing, gutter and fascia assets are not added by this authoring extension.

Owner decisions — 2026-10-01: draw the house outline using a spline with straight segments at arbitrary angles, including diagonals; use cross-gable roofs with separate joined wings. The owner selected cross-gable after comparing search terms for cross-gable and single-ridge layouts. Curves are outside this straight-segment request.

Authoring workflow: select the placed house, then select FootprintSpline in its Components list. Move points in the level viewport; right-click a segment to add a spline point, use Duplicate Spline Point or Delete Spline Point as needed. Keep a closed, non-crossing outline on actor-local Z=0 with Linear point types. Make Footprint Linear And Planar converts point types and projects to this plane. Dragging a point commits regeneration when the drag ends. Regenerate Building rebuilds manually; save the level to retain spline points, generated geometry and configuration.

Current footprint controls: edit FootprintSpline directly or explicitly apply Footprint Point Import with Apply Footprint Points. Make Footprint Linear And Planar repairs point types and local height. Ordinary regeneration never replaces edited points. Door/Window/Stair Guides retain the current guide-only contract above. Earlier rectangular assembly controls and automatic opening rules are historical.

Cross-gable controls: click Fit Roof Wings To Footprint for a rotated rectilinear outline such as L/U. This finds maximal covered rectangles and sets overlapping gabled wings. For freely angled outlines it supplies one bounding wing as a starting guide; configure additional Spline Roof Wings in Details to choose each interior wing centre and ridge yaw. Legacy ridge length/width remain visible as read-only guide history. The footprint alone does not determine a unique ridge design. Wing dimensions use centimetres; ridge yaw is actor-local, with 0° along +X. Roof Pitch defaults to 30° and uses actual opposing wall supports. Roof faces are clipped to the footprint's outward mitered offset at Roof Overhang Cm (default 50), and joined by their upper envelope without buried overlapping sheets. Ridge height and planes are preserved when extending the overhang; wall/gable infills remain at the original wall perimeter. A recess that closes/crosses under this offset needs a smaller overhang or a wider recess. Roof errors retain valid structure with an actionable warning. Fit is an explicit authoring action; changing the outline does not silently redesign the roof guides.

Representation: arbitrary-angle Spline mode uses saved procedural surface sections for exact floor/ceiling boundaries, 15 cm mitered solid walls, gable infills and 5 cm roof sheets. Floors retain 20 cm thickness and the 320 cm floor-to-floor rise. Existing unscaled ModularKit meshes supply windows, entrance and stairs through the PCG graph. Wall/Floor/Roof material controls also apply to their procedural surface sections, using 1 m UV scale. The original 41 imported ModularKit meshes were normalized to the same metre UV density on 2026-10-08; shared MI scan-area tiling and projection limits are recorded in the environment material contract. Planned Piece Count includes the actual grouped sections plus authored mesh instances, including fitting vents; it is not a per-wall gameplay piece count. Rectangle mode now uses the same exact footprint pipeline for its 15 cm inset; existing unscaled meshes supply openings and stairs, while structural shell and roof/gable surfaces are procedural.

Validation guards: outline closure, linear/planar finite points, self-crossings, wall offset collapse, opening corner clearance, door overlap and rotated stair clearance are checked before committing output. Editor work guards limit an outline to 3–64 points within a 100 m envelope and a roof to 1–8 wings; these are implementation safeguards, not approved gameplay budgets. Invalid structural/opening configuration clears generated output; a roof-only error preserves the complete valid structure and discards partial roof/gables. Serialized procedural sections and collision are authored in the Editor; runtime rebuilding, gameplay damage identities and persistence deltas remain outside this tool.

Surface rendering correction — 2026-10-01: the owner reported black/inverted Spline wall, roof and floor surfaces. Generated triangles now follow UE's front-face convention while keeping outward shading normals. Each face also supplies a UV-derived tangent and bitangent handedness for normal-mapped materials, retaining hard architectural edges. Existing shape, UV scale and material assignments are preserved. Editor/Game Development builds and all three PCG automations pass; SplineFootprint checks front-face/normal agreement, tangent orthogonality and UV handedness for every L/rotated-L triangle. Exterior and roof-hidden interior captures were inspected, and the corrected exterior survives save/reload. Surface correction evidence, exterior, interior. Owner visual and PIE acceptance remain pending.

Editing in Details

Place the Blueprint or select PCG_House_10x8 in the preview map. Edit its Layout, Openings, Stairs, Roof and Building categories. Auto Regenerate rebuilds after committed layout/material changes and completed moves; Building > Inspection checkboxes only change Editor visibility. Regenerate Building rebuilds manually; Clear Generated Building removes generated visuals. Save the level after configuration changes. Clear the Details search filter if controls are hidden. The PCG House Details Guide explains every authoring control and worked examples.

Rectangle geometry — revised 2026-10-10: the 15 cm wall inset uses the exact footprint pipeline shared with Spline mode; floors and wall shells are procedural, while stair and openings retain their authored size. Adjustable roofs and gables use procedural surfaces with actual-wall supports. Wall boundaries use the shared 15 cm thickness so their mitered surfaces meet the slab edges and gable ends. The upper floor leaves a stair opening and a landing at the fixed walking height. Furniture remains excluded. Interior room partitions are now requested in the room/circulation refinement; room counts, minimums and generation controls are owner-confirmed and implemented; the compact two-floor L now generates a reduced feasible program; the guided-authoring workflow and current validation are described there.

Spline validation — 2026-10-01: the additional SplineFootprint automation passes alongside the two rectangle/config tests, including L outlines rotated 17.5°, exact floor/ceiling projected areas, rotated stair holes, non-overlapping upper cross-gable surfaces, winding reversal, rejected concave-stair placement and crossing outlines, and a diagonal trapezoid. Atomic spline point changes synchronize positions, rotations and scales. The initial MCP attempt to write the underlying SplineCurves arrays crashed the Editor because reflection updated those arrays separately; that path was replaced with the explicit ApplyFootprintPoints authoring action, which calls SetSplinePoints atomically. The optional advanced Footprint Point Import array is only applied by that button; normal viewport editing uses the engine's spline visualizer.

Initial saved example — historical 2026-10-01 evidence: PCG_SplineHouse_L is placed beside the original rectangle in the preview map. Its six-point outline fits two cross-gable wings and reports 21 existing mesh instances plus three grouped procedural sections. The example uses the original preview house's current wall/floor/roof overrides without changing that house. Live Editor traces hit the upper slab at Z=320 and the concave solid wall, while the stair opening and removed L corner stay clear. Save/reload retains all six Position/Rotation/Scale points, the roof guides, generated output and those trace results. Spline evidence. Final owner visual and PIE traversal acceptance remain pending.

Gameplay and persistence boundary: this is an Editor authoring tool with saved level visuals and Details configuration. Generation is on demand, with no BeginPlay regeneration. PieceKey metadata is deterministic authoring identity, not the durable gameplay BuildingId/LocalPieceId contract. Independent replicated finish removal/replacement and durable tile deltas are implemented in the floor/ceiling refinement. PCG structural authored-house HP, destruction, locks and their save deltas remain later P16/P17 work; manual-source HP and deltas are implemented in the ISM manual-house path under the canonical building persistence contract and world persistence. Do not classify this preview as a completed destructible house.

Validation: Editor and Game Win64 Development builds succeeded. Two non-PIE layout/config automation tests passed with zero warnings; they cover actual mesh availability, stable keys, even/odd footprints, stair hole/landing, wall perimeter and corner contacts, and invalid configuration. Live Editor Details changes produced a 9 × 8 m roof-hidden layout with relocated stairs and 534 instances; invalid stairs cleared all instances with an actionable message. Restoring the 10 × 8 m configuration returned 766 instances across 11 components with no duplicates; save/reload retained the configuration and all counts. MCP exterior and roof-hidden interior captures were inspected after correcting the owner-reported 25 cm corner gaps. Validation evidence. Owner-only PIE traversal/collision and final visual acceptance remain pending.

Owner PIE checklist: walk through the entrance, ascend/descend the L stair, step onto the upper landing, inspect corner/roof contacts and confirm collision from both sides of the wall. Only the owner may start or perform PIE; no agent PIE pass is claimed.

Extension validation — 2026-10-02: Editor and Game Win64 Development builds succeeded. All four PCG tests passed with zero errors/warnings: legacy rectangle/layout validation, every-triangle winding/UV tangent checks on L and rotated L at zero/50 cm overhang, exact offset roof areas without overlapping sheets, and the owner's actual dragged-point regression. The new AuthoringExtension test covers roof-error structural recovery, adjusted cross-gable guides, ground-floor-only multiple entrances, empty lists, overlaps, clockwise offsets, all rectangle edges, exact 50 cm roof plan bounds and one-time legacy migration. Live MCP verified two entrances, zero entrances retained through save/reload, then restored the existing single front entrance. The owner's six actual points and all material choices survived. The main wing was explicitly adjusted to centre (500,400), width 1000, ridge length 800, yaw 90; the second wing is unchanged. The Spline example reports Valid layout with 22 planned pieces/sections; the original Rectangle reports 813 with its new 50 cm projection. Upper slab trace distance remains 180 cm and the stair hole has no hit. The preview map is saved clean, and native Doors/Edge/Offset controls were visually inspected. Validation evidence and corrected exterior with Doors controls.

Owner checks for this extension: review the adjusted cross-gable silhouette and overhang around the diagonal walls; select the actor's Self row, search Doors, and use + or the element menu to add/remove entrances. Expand each index to set Edge and Offset Cm. To edit the outline, clear the Details search, choose FootprintSpline, select a point and move its XY handles while keeping actor-local Z=0 and Linear type. After releasing the drag, read Validation Status. A roof-only warning means the visible structure is usable for further authoring; adjust the roof guides deliberately (an arbitrary-angle Fit can replace them with one bounding wing). Only the owner starts PIE to walk through entrances and the stair/upper landing. No owner visual or PIE acceptance is recorded yet.