# Prison yard surface candidate

An ordinary-game screenshot after real admission showed the authored concrete prison standing in tall wheat. A bounded visual candidate adds one vanilla dirt decal as a child of the successor's `Prefabs/ERR/Prison.et`. Walls, gate, inventory, spawn coordinates, terrain and existing vegetation entities are unchanged.

The referenced installed resource is `{4AD6EB80A8B1FA3A}Prefabs/Decals/Dirt/Decal_Dirt_Patch_03.et`, verified against the vanilla resource database. Its authored `ClutterOccluder 1` property supplies clutter suppression. Vanilla's `CompositionDecal_Dirt_Patch_03.et` already uses this decal with a child `Hierarchy`, downward orientation and `FarPlane 1.5`; arsenal compositions use the same dirt-decal composition pattern for runtime objects. This candidate references the installed prefab rather than copying its material or texture.

The initial child (`FCFBA935CC13E016`) was centred at prison-local `0 0 0`, with angles `-90 0 0`, scale `3` and `FarPlane 1.5`. That initial scale was deliberately smaller than the stock composition's `10`, targeting the central yard for initial inspection. It is not a claim that the projection measures three metres or clears the entire 12×12m enclosure: native projection dimensions and the material's effective clutter mask have not been measured. The decal adds no scripted deletion, collider, floor or spawn-placement bypass.

The first ordinary-game candidate screenshot, taken with the unchanged north-facing prisoner camera, shows a small irregular dirt patch with wheat absent inside it; most of the enclosure still contains wheat. This establishes a visible local effect, not complete yard clearance. The next candidate restores the referenced vanilla prefab's authored scale `10`, keeping the same centre, orientation and projection plane. This is a reversible successor-only surface adjustment; its ordinary prisoner view requires fresh inspection. No exact projection size or full-yard coverage is inferred from scale.

The existing opt-in `errOrdinaryScreenshot=1` capture now also emits `ERR YARD:` read-only diagnostics after revalidating the same canonical local prisoner, controller and active prison round. It selects only registered `everon-prison-1` with the exact successor `Prison.et` identity in that world. The traversal stays within that owner's children, limits itself to 64 nodes and eight child levels, and reports partial measurement on a repeated entity or bound. It logs each native `DecalEntity` prefab/type, native `GetWorldBounds`, actual entity world basis/origin, and all eight world-AABB corners transformed with the prison owner's `CoordToLocal`. It creates no entity, camera or recurring callback and changes no transform, input, terrain or clutter. Existing mission/world cancellation still owns the one screenshot callback.

The [ordinary native bounds run](evidence/game-2026-09-19-123226-yard-bounds/console.log.txt) compiled and traversed 18 nodes with one native decal. At 12:32:59, `GetWorldBounds` returned identical minimum and maximum `<6090,211.444,7160>`, the decal origin; all eight transformed corners were `<0,0,0>`. Its actual basis had length three on each axis and the expected downward orientation. The child also exposed an empty prefab-name string. These results verify that the diagnostic reached the real native entity, **but its entity bounds do not expose the projector extent**. Zero bounds are not evidence of zero coverage, safe confinement, or complete clearance. The transform scale alone supplies no metre-to-footprint conversion.

Installed `DecalEntity` and `DecalEntityClass` API documentation lists no decal-specific public projection-width/height, FOV, near/far or clutter-mask getters. The installed `Decal_Entity_Base.et` supplies only native type, ID, flags and coordinates; the dirt prefab adds scale, `ClutterOccluder 1` and material. The stock composition adds downward rotation and `FarPlane 1.5`; it does not declare projection width, aspect or FOV. Their native defaults and mask extent cannot be reconstructed from these authored fields alone. `World.CreateDecal`/`CreateDecal2` expose size/stretch/clip *creation arguments* for a different visual-mark API, not measurements of this existing `DecalEntity`; `WorldDecal.GetSize` likewise belongs to a separate scripted entity. Neither establishes this prefab's clutter footprint.

Vanilla `SCR_EditableDecalComponent.c` explicitly recreates the native decal when the editor moves it because updating its entity transform does not move the rendered decal. This further rules out treating arbitrary live transform changes or inherited geometry getters as reliable projector measurements. No runtime transformation or replacement is proposed here.

A separate, explicitly diagnostic overhead image of the unchanged candidate can compare visible patch edges, wall inside faces and outside vegetation in the same view. Keep that inspection distinct from the unchanged real-prisoner screenshot. Only after observing that relationship should a bounded centre-yard scale or tiled placement be proposed and retested; the irregular clutter mask still requires visual inspection. No sizing, tiling, camera change or gameplay change is included in this follow-up.

Installed API usage follows `SCR_EditableDecalComponent.c` (`DecalEntity.Cast`), `SCR_EditableEntityComponent.c` (native type name), and vanilla entity `GetWorldBounds`/`CoordToLocal` call sites. Focused adapter checks execute the actual diagnostic's ownership selection, eight-corner projection and bounded hierarchy walk, alongside existing screenshot identity and cleanup tests. Native diagnostic compilation passed; a supported projector-extent getter was not found, and coverage decisions remain pending. This visual candidate does not qualify manual prison access, multiplayer rendering or performance.


The archived Chat Workbench validation plugin experiment accepted optional `errPrisonOverhead=1` together with its existing `errPlay=1`. Immediately before `SwitchToGameMode`, it calls the installed `WorldEditorAPI.SetCamera(vector pos, vector lookVec)` at `<6090,233.444,7160>`, looking straight down `<0,-1,0>`: 22m above the measured prison origin. The installed API explicitly describes this as the World Editor perspective-view camera, rather than a player camera. Without both exact opt-ins the existing editor view is unchanged. This affects only the private test editor's view, with no terrain, actor, gameplay camera, input or prefab mutation. Its requested `err-prison` capture was an authoring diagnostic, not the ordinary real-prisoner view. The native 2026-09-19 12:41:54 Chat run compiled this path and completed 48 assertions without script/VM errors, but did **not** produce a useful overhead image. Its console line 10 includes `-errPrisonOverhead 1`, and line 262 (12:42:24.048) contains the authoring-overhead marker immediately after the site survey. Thus the flag and plugin branch executed. The subsequent `err-prison.png` is a 501×225 horizontal wheat-field view; the requested editor framing was not the captured game-mode framing. `SetCamera` returns void and its installed documentation promises an editor perspective camera, not persistence into the game-mode viewport. `SwitchToGameMode(bool debugMode=false, bool fullScreen=false)` has no documented camera-transfer guarantee. A missing flag/source update is ruled out, but the available evidence does not distinguish view replacement from a rejected/singular straight-down orientation; no speculative post-switch reapplication or debug-mode change is included. The ordinary-game real-prisoner screenshot path is unchanged. Further camera investigation is optional authoring work, not a blocker for mission gameplay.

The ineffective `--prison-overhead-view` runner option and its editor-camera branch were removed after this attempt. The archived command and marker describe the historical experiment; they are not a supported current diagnostic. The genuine ordinary prisoner capture remains available.

The [125906 ordinary capture](evidence/game-2026-09-19-125906-integrated-prison/ordinary-prison-view.png) validates the stock-scale candidate in the actual prisoner view: a larger irregular bare patch is visible and the objective/walls remain correct; substantial wheat remains. The native startup has zero captured errors. Scale ten is retained as a modest visual improvement, with no full-yard-clearance claim.