C2-59B: J: Apply Mask: Radius 2.2, Region: "Skull" individually to each contiguous Skull passage in Dungeon maps. Ariel: I’ll inspect the Dungeon map/data structure in the uploaded backup, find how existing masks/regions are represented, then patch the maps/scripts so each contiguous Skull passage gets its own Skull mask at radius 2.2. J: Ariel: Extract the zip I uploaded, Review, Debug, Moment of Clarity, Update and Repack please! Remember, only repack using files that have actually changed while preserving file archival paths. Ensure your zip file is named without escapes. Remember, just the delta, with next serial in name. Ensure your zip is valid and Remember, no stubs! If needed provide an obsoletion ps1 script. If desired, please request a GE Core Dump. Don't forget tabs for indentation, Windows newlines. Also, Please include a README text file for documentation. Go! :D Ariel: I found the relevant Dungeon mask implementation: masks currently affect actors, while Skull passages are map/legend tiles. I’m patching the tile path so Skull regions can be masked without converting them into actors. J: Skull passages need to be converted to Actors. Ariel: Got it — Skull passages should become Actors first, then each contiguous converted Skull passage should get its own mask region. I’ll adjust the patch around that model rather than adding tile-only masking. J: Skull Passage Actors should be Blocking: 0, ZIndex: 3 Ariel: Moment of clarity: the existing actor schema stores ZIndex in column 13 and Blocking in column 14, where existing blocking actors use Blocking: 0. I’m following your explicit Skull Passage requirement: actor rows get ZIndex: 3, Blocking: 0, and mask metadata columns populated. J: I meant literally the contiguous skull passage, not other actors in the same locations. Ariel: Understood: the mask region should be computed from the contiguous Skull passage cells themselves, not from unrelated actors that happen to share those coordinates. I’ll make the Skull Passage Actor conversion preserve the literal region boundaries and only assign mask membership from that converted passage component. The safest data-level fix is: remove Skull cells from map.csv, append equivalent Skull Passage rows to actor.csv, and leave any pre-existing actors at those coordinates untouched. The mask grouping is derived only from the original Skull tile components before conversion. //// J: Mask groups should be per contiguous Skull passage set. J: These new mask groups should be per contiguous skull passage cluster. Ariel: I’m treating “cluster” as orthogonal contiguous Skull cells in the original map.csv, before any conversion. Each cluster gets one region key, and every Skull Passage Actor created from cells in that cluster shares that exact key. Thought for 15m 6s Done, Tim. C2-59B delta is valid and contains only the changed files plus the README. Download the C2-59B Dungeon Skull Passage Masking delta zip Applied: Converted literal Skull map cells into Skull Passage actors. Preserved existing non-Skull actors at the same coordinates. Built mask groups per original contiguous Skull passage cluster. Added Mask Radius: 2.2, Mask Mode: transparency, and region keys Skull001 through Skull220. Set each new Skull Passage Actor to ZIndex: 3, Blocking: 0. Replaced original Skull cells in map.csv with tile 00. Included README documentation. No obsoletion ps1 included because no files were removed or renamed. Validation passed: Zip test: OK. 15 files in delta. 224 Skull Passage actors added. 220 contiguous Skull mask groups created. No original Skull tile IDs remain in patched map.csv files. Patched actor.csv row counts match actual row totals. GE Core Dump is only needed if the live Dungeon instance is using server-side saved map copies instead of these archive asset files C2-59C: J: Skull Passage Actors are erroneously Blocking now. Ariel: I’ll correct this as a follow-up delta. First I’m checking whether the issue is the CSV Blocking value itself or the engine treating all converted Skull Passage actors as collision actors despite Blocking: 0. Moment of clarity: I left the generated Skull Passage rows with the literal blocking flag and Blocking factor 0. In this Dungeon runtime, factor 0 is solid and factor 1 is pass-through, so I’m correcting the generated Skull Passage Actors to be non-blocking/passable. I’ll correct this as a follow-up delta. First I’m checking whether the issue is the CSV Blocking value itself or the engine treating all converted Skull Passage actors as collision actors despite Blocking: 0. Moment of clarity: I left the generated Skull Passage rows with the literal blocking flag and Blocking factor 0. In this Dungeon runtime, factor 0 is solid and factor 1 is pass-through, so I’m correcting the generated Skull Passage Actors to be non-blocking/passable. J: Conditions needs to check the overlapping Actors for Mask, not the full map. Ariel: Got it. I’m folding both fixes into the same follow-up delta: Skull Passage Actors must be pass-through, and masking/conditions must look at overlapping Actor masks rather than map tiles. Thought for 5m 29s Done, Tim. C2-59C is repacked as a valid delta with archival paths preserved. Download the C2-59C delta zip Applied: Corrected generated Skull Passage Actors to be pass-through: Removed literal blocking flag. Set runtime blocking factor to 1. Kept ZIndex: 3. Updated mask handling so Conditions/masking source checks use overlapping Actors with Mask/Region keys, not full-map Skull scans. Added GE condition outputs for mask actor overlap state: Mask: Active Mask: Active Count Mask: Active Regions Mask: Actor Overlap Mask: Actor Overlap Count Mask: Actor Overlap Region(s) Mask: Actor Overlap Index Mask: Actor Overlap Name Included a C2-59C README. No obsoletion PS1 was needed. Validation: unzip -t: OK. node --check Dungeon.js: OK. Windows newlines preserved. Tabs preserved. Delta contains 18 files, all with preserved archive paths. GE Core Dump is only needed if the live Dungeon instance is still using server-side saved map copies instead of these asset files. C2-59D: J: The Mask Radius must be a localized circular cut-out for the given Mask group's sprites. Ariel: Understood. The mask radius should not globally reveal/hide the whole map or whole region; it should render a circular local cut-out against only the sprites belonging to the active overlapping Mask group. I’ll patch the render/mask path and repack the next delta. Moment of clarity: the current code is tile-center visibility filtering, not sprite-level circular clipping. I’m replacing that with a render-time mask cut-out so only sprites in the active Mask group are punched by the local radius. J: When no Radius is provided, the entire Mask group should hide when one is occupied by the player, using a mosaic transition per the Mask group when entered/left. Ariel: Got it. I’ll add the missing default behavior too: no radius means the full Mask group hides on player overlap, with a per-group mosaic transition both entering and leaving. I’ve narrowed the implementation point: the old patch filtered whole actors by tile center. I’m moving this into the actor render layer so Mask groups can be drawn normally, then cut or hidden at sprite/pixel level. Thought for 6m 5s Done, Tim. C2-59D is repacked as a valid delta-only zip with archival paths preserved. Download the C2-59D delta zip Applied: Mask Radius now renders as a localized circular sprite cut-out. The circular cut-out applies only to Actors in the active overlapping Mask group. Conditions still check overlapping Actors, not the full map. No-radius Mask groups now hide the entire group when entered. No-radius enter/leave uses a per-group mosaic dissolve. Mask Invert behavior is preserved. Actor overlays, body bags, ZIndex ordering, player rendering, and non-mask Actors are preserved. Included README documentation. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59D - Dungeon Mask Radius Cut-Outs.txt No stubs. C2-59E: J: The cut-out should use a blended outer 0.6 Radius from full opacity inward to 0 opacity Ariel: I’ll patch this as C2-59E: the circular cut-out should have a hard fully transparent core, plus a 0.6-tile blended rim that fades from full sprite opacity at the outer edge to zero opacity inward. I found the render function to update. One important detail: inverted radius masks need a temporary alpha mask so multiple circular sources form a union instead of accidentally intersecting each other. Thought for 2m 1s Done, Tim. C2-59E is repacked as a valid delta-only zip with archival paths preserved. Download the C2-59E delta zip Applied: Mask Radius cut-outs now use a 0.6-tile blended outer rim. At the radius boundary, affected sprites remain full opacity. Across the inward 0.6-tile rim, opacity fades down to 0. The inner cut-out remains fully transparent. Inverted radius masks preserve keep-inside behavior with the same soft edge. Multiple active circular sources are composited through a temporary alpha mask so they behave as a union. No-radius mosaic group hide/reveal behavior remains intact. Included README documentation. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Zip contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59E - Dungeon Mask Radius Feathered Cut-Outs.txt C2-59F: J: What is the Skull Passage Mask Radius set as? 2.2 right? Ariel: Thought for 7s Yes — the Skull Passage Mask Radius is set to 2.2. With the latest C2-59E behavior, that means: Radius: 2.2 tiles Feather/blend band: outer 0.6 tiles Fully transparent core: inward from 2.2 - 0.6 = 1.6 tiles Fade: from full opacity at radius 2.2 down to 0 opacity at radius 1.6 J: Need to instead be set to 1.6 Ariel: I’ll make this as the next serial delta: update the generated Skull Passage Actor Mask Radius values from 2.2 to 1.6, preserve archive paths, include a README, and validate the zip. Thought for 1m 34s Done, Tim. C2-59F is repacked as a valid delta-only zip. Download the C2-59F delta zip Applied: Changed generated Skull Passage Actor Mask Radius from 2.2 to 1.6. Updated 224 Skull Passage Actor rows across 7 actor.csv files. Preserved Mask Region groups, Mask Mode: transparency, ZIndex: 3, and pass-through blocking. Included README. No JavaScript changes needed. No obsoletion PS1 needed. Validation: unzip -t: OK. Delta contains only changed actor.csv files plus README. C2-59G: J: Contiguous Skull/Alcove Passages in Map 025 need a Mask Radius 1.6 + ZIndex 3 Groups. Ariel: I’ll locate the relevant Dungeon/Map 025 assets, identify how passage masks and ZIndex groups are represented, then produce a patched package or exact edits if the source files are available. I found the recent context: the mask groups must be per literal contiguous Skull passage cluster, and the radius is now 1.6. This new pass also needs Alcove Passage included in the same contiguous grouping logic, only for Map 025. J: Skulls and Alcoves are allowed to be combined in any given contiguous passage. Ariel: I’ll treat this as the next follow-up delta after C2-59F: Map 025 only, with contiguous clusters formed from both Skull and Alcove passage cells together, then converted/grouped as pass-through actors with Mask Radius: 1.6 and ZIndex: 3. I found Map 025’s mixed cluster: the four Alcove cells are orthogonally connected to two existing Skull Passage actor cells at (26,57) and (26,60). I’m merging that whole six-cell passage into one shared mask region instead of leaving the two skull endpoints as separate groups. Thought for 2m 27s Done, Tim. C2-59G is repacked as a valid delta-only zip. Download the C2-59G delta zip Applied for Map 025: Converted the 4 contiguous Alcove passage tiles into Alcove Passage Actors. Merged those Alcove Passage Actors with the 2 adjacent Skull Passage Actors into one shared contiguous Mask group. Combined group uses Region: Skull217. All 6 Actors in that mixed Skull/Alcove passage cluster use: Mask Radius: 1.6 ZIndex: 3 pass-through blocking factor 1 Mask Mode: transparency Removed the 4 Alcove passage cells from map.csv by replacing tile 05 with 00. Preserved unrelated Actors and nearby content. Included README documentation. No obsoletion PS1 needed. Delta contains only: public/alpha/Dungeon/assets/maps/025/actor.csv public/alpha/Dungeon/assets/maps/025/map.csv README C2-59G - Dungeon Map 025 Skull Alcove Mask Groups.txt Validation: unzip -t: OK. actor.csv header count matches physical row count: 116. Mixed Skull217 cluster has exactly 6 Actors. Windows newlines preserved. C2-59H: J: Map 025 erroneously animates super slow and player controls are super laggy. Ariel: I’ll debug Map 025 against the C2-59G delta and the prior baseline, looking for anything that multiplies per-frame mask work or creates overlapping mask actors in a way that stalls animation/input. Then I’ll repack the next delta only with changed files plus README. J: Everything outside the view portal should have animation features out of context. Ariel: That extra point is likely the cause: Map 025 should not spend active animation/mask work on Actors outside the view portal. I’ll make off-portal animated Actor features context-gated so they do not drag input/render timing. J: No map should. This is an engine issue, not a map issue. Ariel: Moment of clarity: C2-59E’s actor-layer state key evaluates actorDisplayFrame() / overlay / mask state for every Actor in the map, even when they are off-screen. With the new Skull/Alcove actors, off-portal animations force full actor-layer redraws and input lag. I’m changing the engine to build actor animation state only from the current view portal. Thought for 4m 56s Done, Tim. C2-59H is repacked as a valid engine-level delta-only zip. Download the C2-59H delta zip Applied: Fixed this as a Dungeon engine issue, not a Map 025 issue. Actor-layer animation state is now view-portal contextual. Off-portal Actors no longer evaluate: display animation frames overlay animation frames mask render state body bag actor-layer state Off-portal Actors still remain in game logic/collision/overlap systems. Controlled player Actor is always rendered at the portal center. Existing Mask Radius, feathered cut-out, mosaic transition, Mask Invert, ZIndex ordering, and Skull/Alcove passage behavior are preserved. Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59H - Dungeon View Portal Animation Context.txt C2-59I: J: Map 025 is still bogged down. Ariel: I’ll dig deeper than the previous view-portal state-key fix. The remaining lag likely comes from another per-frame full-map path: mask grouping, actor sorting, overlap scanning, or mosaic/radius compositing still touching all Map 025 actors. I found another likely culprit: even after render culling, the engine still does repeated full-actor scans for occupancy, blocking, mask overlap, and movement checks. With Skull/Alcove passages converted into many actors, those scans now happen far more often. Thought for 6m 19s Done, Tim. C2-59I is repacked as a valid engine-level delta-only zip. Download the C2-59I delta zip Applied: Added a Dungeon Actor spatial index keyed by occupied tile. Replaced repeated full-Actor scans with tile-local lookups for occupancy, blocking, yield checks, door checks, mask overlap checks, and actor behavior triggers. Reworked actor-layer rendering so visible Actors are gathered from the view portal tiles instead of scanning the full Actor list. Replaced full-view scratch compositing per masked Actor with tile-local Mask scratch canvases. Preserved: Skull/Alcove Actor-based Mask groups Mask Radius 1.6 outer 0.6 feathered cut-out no-radius mosaic transitions Mask Conditions based on overlapping Actors ZIndex ordering Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59I - Dungeon Actor Spatial Index and Mask Performance.txt A GE Core Dump would be the next useful artifact if Map 025 still bogs after this, because the remaining cause would likely be live runtime state, server-side saved maps, or GE input/overlay cadence rather than the static asset/engine patch. C2-59J: J: "C:\Users\trkea\Downloads\GE JSON Core Dump alpha Dungeon-2D 2026-0703-2031-5410.zip" GE JSON Core Dump alpha Dungeon-2D 2026-0703-2031-5410.zip Zip Archive Ariel: I’ll use the GE JSON Core Dump as the next debugging artifact and compare its live state against the C2-59I assumptions. I’m looking specifically for frame-rate/input cadence, actor counts, mask-region activity, and whether Map 025 is using server-side state that diverges from the asset delta. J: The 025 map doesn't display properly in the Editor. Ariel: Got it. I’ll include the Editor display failure in the same debug pass; that likely means the Editor still expects Alcove/Skull passage visuals from map.csv, while C2-59G moved some of them into actor.csv. J: "C:\Users\trkea\Downloads\GE JSON Core Dump alpha Dungeon-2D 2026-0703-2036-0668.zip" GE JSON Core Dump alpha Dungeon-2D 2026-0703-2036-0668.zip Zip Archive Ariel: Moment of clarity: the Editor is drawing the converted passage Actors correctly as sprites, then also drawing the normal red Actor pulse box over every one of them. Map 025 has enough Skull/Alcove passage Actors that the Editor view looks polluted even though the runtime map data is valid. I’ll suppress default Actor pulse outlines for tile-proxy passage mask Actors unless they are selected. J: I meant, only tile 0,0 is displaying in Map 025 in the Dungeon Editor. Ariel: That points to a CSV/map parsing or Editor asset-path issue, not just Actor rendering. I’ll inspect Map 025’s patched map.csv and the Editor loader path using the core dump and deltas, then patch the Editor/asset data as needed. J: The Editor thinks it is using a 1x1 View Portal The Editor is attempting to apply a 1x1 View Portal Ariel: That’s a clearer failure mode: the Editor is inheriting/runtime-applying the gameplay View Portal context and collapsing Map 025’s editor viewport to 1x1. I’ll patch this as an Editor/runtime separation issue so the Editor always uses its own map dimensions/view settings, not the game portal. Thought for 12m 16s Done, Tim. C2-59J is repacked as a valid Editor-level delta-only zip. Download the C2-59J delta zip Applied: Fixed the Dungeon Editor attempting to treat Map 025 like a 1x1 View Portal. Editor map rendering now preserves loaded map.csv dimensions when Width/Height fields are blank, stale, or mid-refresh. Added recovery inference from loaded cell data if the in-memory header was transiently collapsed. Explicit numeric Width/Height resize behavior still works. No gameplay/runtime View Portal behavior changed. No Map 025 CSV data changed. Included README. No obsoletion PS1 needed. Validation: node --check editor.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/Editor/js/editor.js README C2-59J - Dungeon Editor Map Dimension Guard.txt C2-59K: J: Map fails to display in the editor on first load. Ariel: I’ll patch this as the next Editor fix. The likely issue is that the first render runs before the async map/cell dimensions are hydrated, while a later refresh has enough state to draw correctly. Moment of clarity: the Editor’s HTML canvas starts as 1x1, and loadMap() was waiting for all sprite preloads before the first real renderMap(). On first load, Map 025 can sit at the default 1x1 canvas until sprite work finishes or another refresh forces a render. I’m moving the structural map render ahead of sprite preload so dimensions apply as soon as map.csv is parsed. J: //// Actors with enemy should remain inert while at their post. //// Actors with enemy flag should remain inert while at their post. Actors with enemy flag should remain inert while at their post and simultaneously out of view portal. Ariel: I’ll fold the interruption into the same next delta: keep the Editor first-load map render fix, and add an engine-side enemy AI gate so Enemy Actors at their post stay inert while outside the view portal. Moment of clarity: this is also an engine-context issue. Enemy Actors that are still sitting on their origin/post cell should not be armed, held active, or allowed to consume Auto-Walk logic while their tile is outside the current view portal. Thought for 7m 56s Done, Tim. C2-59K is repacked as a valid delta-only zip. Download the C2-59K delta zip Applied: Fixed the Dungeon Editor first-load map display issue: map.csv dimensions are applied immediately after parsing. The structural map renders before sprite preloading finishes. Sprite previews/map sprites still refresh as assets resolve. Added engine-level inert behavior: Actors with Enemy flag stay inert when they are both: at their origin/post tile, and outside the current View Portal. Inert posted off-portal Enemy Actors no longer arm Auto-Walk. Already armed inert Enemy Actors are pruned before Auto-Walk triggers. Cluster movement excludes inert posted off-portal Enemy members. Follow/return/post-hold checks ignore those inert Enemy Actors. Preserved normal behavior for: Enemy Actors inside the View Portal. Enemy Actors away from their post. Non-Enemy Actors. Map 025 Skull/Alcove Mask Radius 1.6, ZIndex: 3, and Mask behavior. Validation: node --check Dungeon.js: OK. node --check editor.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Included README. No obsoletion PS1 needed. C2-59L: J: Bore Worms and Guards need to be flagged as Enemy. Ariel: I’ll make this as the next data delta: scan Dungeon actor.csv files for Bore Worm and Guard actor names/types, add the enemy flag without disturbing existing properties, then repack only changed files plus README as C2-59L. Stopped thinking J: Same inert behavior needs to be done for actors with Recruitable and/or Yield flags. Ariel: I’ll extend the post/off-portal inert gate beyond Enemy to include Recruitable and Yield, while preserving the existing Enemy behavior and conditions. I also checked the actor data: all Bore Worm and Guard rows in the current working tree are already carrying enemy, so I’ll validate that rather than repacking unchanged CSVs. J: Inert needs to be a temporary Actor flag state. Ariel: Understood. I’m changing the design from “skip logic by checking flags directly” to “apply a temporary runtime Inert actor state when eligible, then have movement/AI/yield/recruit logic honor that state.” I verified the data side: in the current patched tree, all Guard and Bore Worm rows already carry the enemy flag, so no unchanged actor.csv files need to be repacked. The change needed now is engine-side: Inert as a non-serialized runtime flag. Thought for 5m 45s Done, Tim. C2-59L is repacked as a valid engine-level delta-only zip. Download the C2-59L delta zip Applied: Added temporary runtime Actor flag support for Inert. Inert is not serialized into actor.csv. actorHasFlag(actor, "inert") now works through a non-enumerable runtime flag store. Actors temporarily become Inert when they are: at their origin/post tile, outside the current View Portal, and flagged with Enemy, Recruitable, and/or Yield. Temporary Inert state is refreshed before and after update ticks, so it clears when the Actor enters view or leaves its post. Inert Actors no longer consume Auto-Walk, follow/return/post-hold, cluster routing, recruitment, or yield-to-player logic. Controlled/recruited Player Unit Actors are excluded from the recruitable inert path. Verified all current Guard and Bore Worm Actor rows already include enemy, so no unchanged actor.csv files were repacked. Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59L - Dungeon Temporary Inert Actor State.txt Voice chat ended 1s C2-59M: J: All Actors require a starting-condition based flag called Post that defines their return Row, Col position after a Yield or Mob action times out. Ariel: I’ll implement this as the next Dungeon engine/data delta. I’m going to inspect the latest patched tree, find the Yield/Mob timeout return paths, then make Post a starting-condition Actor flag/state that supplies the return row/col for all Actors. Moment of clarity: existing “origin” fields already acted like a hidden post, but Yield was still setting return info to the actor’s current displaced cell. I’m making Post explicit and rebasing both Yield and Mob return info to that starting-condition post. Thought for 4m 5s Done, Tim. C2-59M is repacked as a valid engine-level delta-only zip. Download the C2-59M delta zip Applied: Added a starting-condition based Post flag/state for every Actor. Post is derived from the Actor’s loaded starting Row, Col / origin tile. Runtime Actor metadata now includes: postTileRow postTileCol postRow postCol Post, formatted as Post:, actorHasFlag(actor, "Post") now resolves true for valid posted Actors. actorHasFlag(actor, "Post:,") resolves true only for the matching Post coordinate. Yield return info now rebases to Post, not the Actor’s displaced/current tile. Mob return info now rebases to Post when created, checked, or routed. Existing Inert-at-post behavior now uses the explicit Post coordinate. No actor.csv files were repacked because Post is derived from starting conditions at runtime. Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59M - Dungeon Actor Post Return State.txt C2-59N: J: "C:\Users\trkea\Downloads\GE JSON Core Dump alpha Dungeon-2D 2026-0703-2153-1667.zip" GE JSON Core Dump alpha Dungeon-2D 2026-0703-2153-1667.zip Zip Archive There are so many "Bore Worm" Actors, Map 025 slows to a crawl. Ariel: I’ll use the new GE Core Dump to verify whether the slowdown is raw actor count, Bore Worm AI still escaping the Inert gate, or render/condition work touching too many posted worms. Then I’ll patch the engine as the next serial delta. The core dump gives the clue: the map has 65 inert enemies but the battle mob-pin conditions still show thousands of accumulated “mob steps.” That means the battle/mob-pin condition path is still counting posted off-portal Bore Worms/Guards even after AI inerting. Thought for 2m 58s Done, Tim. C2-59N is repacked as a valid engine-level delta-only zip. Download the C2-59N delta zip Moment of clarity from the GE Core Dump: Map 025 already had 65 posted off-portal Enemy Actors marked Inert. But Battle mob-pin conditions were still accumulating thousands of mob steps: Battle: Mob Actor Side Pin Total Mob Steps Battle: Mob Pin Course Combined Steps So the AI movement was suppressed, but the battle/mob-pin condition subsystem was still counting posted off-portal Bore Worms and Guards as active mob-capable enemies. Applied: Updated every Dungeon battle/mob-pin actorIsMobCapableEnemy helper to reject Actors with temporary Inert. Posted off-portal Bore Worms and Guards no longer participate in: mob proximity course sampling mob pin course sampling no-escape mob-pin tracking cluster pin checks actor-side pin checks accumulated mob-step counters Preserved normal behavior for: visible Bore Worms/Guards enemies that have left their Post non-Inert enemies Enemy identity/flags No actor.csv files changed. Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK. unzip -t: OK. Windows CRLF preserved. Tabs preserved. Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59N - Dungeon Inert Mob Pin Performance.txt C2-59O: J: The engine is slow for Map 025 even in Battle Mode. Ariel: I’ll treat Battle Mode slowness as another full-map engine path that still ignores temporary Inert. I’ll inspect the latest core dump and patched Dungeon.js for battle update/render loops that still scan all Actors or all mob courses every frame. Moment of clarity: C2-59N stopped inert enemies from being mob-capable, but the Battle Mode condition/update chain can still walk the full actors array through its inherited wrappers. I’m adding a Battle Mode actor-context gate so Battle Mode evaluates only battle-relevant, visible, moving, and adjacent Actors instead of every posted Bore Worm. Thought for 5m 2s Done, Tim. C2-59O is repacked as a valid engine-level delta-only zip. Download the C2-59O delta zip Applied: Fixed the remaining Battle Mode full-map Actor scan problem. During active Battle Mode, the engine now temporarily evaluates only a localized Actor context: Battle source Actors player/player-unit Actors visible View Portal Actors moving/returning Actors Actors on or adjacent to player-unit tiles Posted off-portal Inert Bore Worms/Guards no longer participate in Battle Mode condition/update scans. Full Actor list is restored immediately after each gated pass. Added diagnostic GE conditions: Actor: Battle Context Active Actor: Battle Context Actor Count Actor: Battle Context Culled Count Actor: Battle Context Source Included README. No obsoletion PS1 needed. Validation: node --check Dungeon.js: OK unzip -t: OK Windows CRLF preserved Tabs preserved Delta contains only: public/alpha/Dungeon/2D/js/Dungeon.js README C2-59O - Dungeon Battle Mode Actor Context Performance.txt