Grid Placement

GridPlacement / Godot — _Legacy classes migration priority (6.0)

Goal: produce an actionable per-file score and recommendation indicating how urgent / necessary it is to port, rewrite, or remove each _Legacy C# class from the Godot layer into the 6.0 GridBuilding.Godot architecture.

Scoring legend (0-10):

  • 9–10 “Must port / Re-implement”: core runtime or adapter that is still required for behaviour in 6.0, or necessary for migration compatibility.
  • 7–8 “High priority”: important helpers/adapters used often; porting recommended soon.
  • 4–6 “Medium priority”: useful helpers, data classes, or partial adapters that can be migrated later.
  • 1–3 “Low priority”: small utilities, tests, or rarely-used helpers — optional to port.
  • 0 “Obsolete (remove/move to legacy addon)”: UI/visual or old DI components which are replaced by 6.0 POCS services or new UI flows. Keep in a legacy-addon or delete.

Notes

  • Many system nodes (GridTargetingSystem, ManipulationSystemNode, etc.) have largely been replaced by POCS service architecture in 6.0. Where a service equivalent exists, the node may be either (A) required as a lightweight adapter node, or (B) obsolete and can be removed from the core plugin and retained only in a legacy-addon for backwards compatibility.
  • This document scores all files discovered under Godot/_Legacy/ and groups them by subsystem. For each file: short description, score, concise justification and recommended next step.

Parity policy note

  • Parity is NOT required for Nodes and Resources.
    • This doc may describe node/resource mappings for developer clarity.
    • Parity and migration tooling should primarily enforce Core/service/domain mappings.

Targeting / Positioning

  • _Legacy/Systems/GridTargeting/GridTargetingSystem.cs — Score 3

    • Status: Core POCS replacement available.
    • Mapped to: Core/Services/Targeting/GridTargetingService.cs (Service) & Core/Services/Targeting/IGridTargetingService.cs.
    • Why: Core service patterns in 6.0 cover most targeting responsibilities (cursor→grid, snapping). The old system is largely replaced and often redundant.
    • Next step: Keep for reference only; port only if there’s unique logic not covered by the new GridTargeting service adapter.

  • _Legacy/Targeting/TargetingShapeCast2D.cs — Score 0

    • Status: Replaced by 6.0 sensor adapter.
    • Mapped to: Godot/Targeting/ITargetSensor.cs + Godot/Targeting/TargetSensor2D.cs.
    • Why: A dedicated TargetSensor2D node now implements the minimal 6.0 ITargetSensor contract for grid coordinate conversion; heavier physics behaviours are owned by targeting services and future adapters.
    • Next step: Keep only in legacy addon or remove from core plugin.

  • _Legacy/Systems/GridTargeting/TargetingShapeCast2DRefactored.cs — Score 0

    • Status: Superseded by 6.0 targeting controller + sensor pattern.
    • Mapped to: Godot/Targeting/TargetingController2D.cs + Godot/Targeting/TargetSensor2D.cs.
    • Why: 6.0 uses service-driven targeting with a thin sensor interface rather than a monolithic ShapeCast node.
    • Next step: Treat as historical reference only; remove from core plugin once 6.0 Godot integration tests are stable.

  • _Legacy/Systems/GridTargeting/TargetingShapeCast2DSimplified.cs — Score 8

    • Status: Missing in 6.0.
    • Why: Useful lightweight implementation that may be preferred for simple demos and tests.
    • Next step: Port as simplified adapter or retain as example in legacy-addon.

  • _Legacy/Systems/GridPositioner/GridPositionerLogic.cs — Score 8

    • Status: Core POCS replacement available.
    • Mapped to: Core/Services/Targeting/GridNavigationData.cs or Core/Systems/Grid/IGridPositioner.cs (Incomplete).
    • Why: Positioner logic is a core piece of cursor-to-grid movement; newer versions may have refactored movement, but careful porting is needed for parity.
    • Next step: Extract pure logic into Core-compatible service code or adapter backed by ICursorController.

  • _Legacy/Utilities/GridPositioner2D.cs — Score 7

    • Status: Missing in 6.0.

    • Why: Godot-side node for positioners — useful to maintain a minimal node adapter for 6.0.

    • Next step: Port to a small Godot Node adapter that uses 6.0 service APIs and tests.

    • Mapping note (human docs only):

      • 5.1 GDScript GridPositioner2D (node) corresponds most closely to the 6.0 Godot adapter TargetingController2D.
      • Do not treat this as a parity requirement for nodes/resources.

  • _Legacy/Systems/GridPositioner/GridPositionerUtils.cs — Score 5

    • Status: Partially covered by Core math.
    • Mapped to: Core/Math/GridMath.cs / Core/Systems/Grid/Math.cs.
    • Why: Helper utilities; useful but not critical.
    • Next step: Port only what’s used by new services or move to shared utils in Core if appropriate.

  • _Legacy/Systems/GridPositioner/TargetingController2D.cs — Score 7

    • Status: Ported.
    • Mapped to: Godot/Targeting/TargetingController2D.cs.
    • Why: Historically important controller node — but there is a new Godot/Targeting/TargetingController2D.cs adapter in 6.0. Evaluate whether legacy controller contains unique knobs.
    • Next step: Compare with new adapter; port specific missing features or mark obsolete.

  • _Legacy/Systems/GridTargeting/UserTargetingCursor.cs — Score 6

    • Status: Missing in 6.0.
    • Why: UI cursor state for targeting flows. Some of this is now covered by new controllers.
    • Next step: Migrate focused cursor display logic to new indicator/adapter nodes or mark legacy.

  • _Legacy/Systems/GridTargeting/GridTargetingCoordinator.cs — Score 5

    • Status: Replaced by Service Registry / Composition Root.
    • Mapped to: Godot/Bootstrap/ServiceCompositionRoot.cs (Orchestration).
    • Why: Orchestrator for legacy flows; replaced by service & coordinator in 6.0.
    • Next step: Port pieces that drive important flows; otherwise mark for deprecation and move to legacy-addon.

  • _Legacy/Systems/GridTargeting/GridTargetingState.cs — Score 4

    • Status: Core POCS replacement available.
    • Mapped to: Core/State/Targeting/GridTargetingState.cs.
    • Why: State model — useful reference. Many parts are replaced by the core service state; port only when needed.
    • Next step: Keep as reference and re-implement missing parts in the new state model when needed.

Test boundary note (Targeting)

  • Core tests (e.g. GridTargetingServiceTests) own targeting and pathfinding behaviour: grid setup, path shape, and distance semantics.
  • Godot tests for targeting are kept as thin wiring smokes that verify adapters and harnesses resolve services and return usable paths, without re-encoding full behaviour.

Placement / Collision / Validation

  • _Legacy/Systems/Manipulation/Internal/PlacementManager.cs — Score 9

    • Status: Core POCS replacement available.
    • Mapped to: Core/Services/Placement/PlacementService.cs (Service) & Core/Services/Placement/IPlacementService.cs.
    • Why: Central orchestrator for placement workflows (validation, preview, commit). The replacement must be present in 6.0 to avoid regressions.
    • Next step: Port/refactor into the 6.0 Placement managers or provide an adapter that composes placement service + indicator manager.

  • _Legacy/Systems/Placement/Processors/CollisionProcessor.cs — Score 9

    • Status: Core POCS interface available; implementation incomplete.
    • Mapped to: Core/Interfaces/ICollisionProcessor.cs (Interface). Implementation in Core/_incomplete/Systems/Geometry/CollisionProcessor.cs.
    • Why: Collision processing is crucial for placement validation and performance-sensitive logic.
    • Next step: Port and unify with 6.0 collision interfaces so PlacementValidator and Indicator services can reuse them.

  • _Legacy/Systems/Placement/Processors/CollisionMapper.cs — Score 8

    • Status: Missing in 6.0.
    • Why: Maps scene geometry → collision structures; core function for placement checks.
    • Next step: Port with unit tests and benchmark to ensure parity.

  • _Legacy/Systems/Placement/Processors/CollisionCoreStubs.cs — Score 4

    • Status: N/A (Test stubs).
    • Why: Support/test stubs — low priority for final port; useful for early testing migration.
    • Next step: Keep in tests or adapt to new test harness.

Test boundary note (Placement & Manipulation)

  • Core tests (for example, ManipulationService2DTests, PlacementServiceTests, and their command tests) define placement and manipulation behaviour: workflows, validation rules, and result semantics.
  • Godot tests in these areas should remain thin adapter smokes that verify nodes and harnesses call the right services and propagate results, without re-encoding full business rules.

  • _Legacy/Systems/Placement/Validators/PlacementRules/PlacementRule.cs — Score 7

    • Status: Core POCS interface available.
    • Mapped to: Core/Interfaces/IPlacementRule.cs.
    • Why: Foundational validation rule base class; 6.0 requires consistent rule API.
    • Next step: Port into the 6.0 validators subsystem; add unit tests.

  • _Legacy/Systems/Placement/Validators/WithinTilemapBoundsRule.cs — Score 7

    • Status: Missing in 6.0.
    • Why: Concrete placement rule; important for correctness.
    • Next step: Port to 6.0 validator framework and add tests.

  • _Legacy/Systems/Placement/Validators/TileCheckRule.cs — Score 6

    • Status: Missing in 6.0.
    • Why: Validates tile-based constraints — mid priority.
    • Next step: Port as needed for parity tests.

  • _Legacy/Systems/Placement/Utilities/CollisionScenarioBuilder2D.cs — Score 6

    • Status: Missing in 6.0.
    • Why: Utility for building collision test scenarios — useful for tests and integration.
    • Next step: Port to test helpers or keep in legacy tests depending on coverage needs.

  • _Legacy/Systems/Placement/Managers/CollisionGeometryCalculator.cs — Score 8

    • Status: Missing in 6.0 (Likely Core/_incomplete/Systems/Geometry/GeometryMath.cs).
    • Why: Geometry calculations underpin collision detection performance.
    • Next step: Port with tests and validate performance/precision parity.

  • _Legacy/Systems/Placement/Adapters/GridOccupancyAdapter.cs — Score 7

    • Status: Core POCS interface available.
    • Mapped to: Core/Interfaces/Placement/IGridOccupancy.cs.
    • Why: Adapter for occupancy queries — useful to map Godot data → core occupancy API.
    • Next step: Port as adapter implementing 6.0 occupancy interface.

  • _Legacy/Systems/Placement/Adapters/PreviewCalculationWrapper.cs — Score 6

    • Status: Core POCS service available.
    • Mapped to: Core/Services/Placement/PreviewCalculationService.cs (Incomplete) / IPreviewCalculationService.cs.
    • Why: Helper wrapper to calculate previews; if 6.0 has improved preview systems this may be lower priority.
    • Next step: Port minimal features or migrate logic into new PreviewBuilder.

  • _Legacy/Systems/Manipulation/Internal/PhysicsLayerManager.cs — Score 7

    • Status: Core POCS service available.
    • Mapped to: Core/Services/Manipulation/PhysicsLayerManager.cs.
    • Why: Manages physics layers for placement; important to ensure collisions/validation operate in same layers.
    • Next step: Port the parts required to map tilemap/scene layers to collision processors.

  • _Legacy/Systems/Placement/Processors/CollisionShapeProcessor.cs — Score 7

    • Status: Missing in 6.0.
    • Why: Shape-to-tile mapping is central to collision tests.
    • Next step: Port with unit tests.

  • Various placement helpers/utilities (CollisionUtilities, CollisionExtensions, CollisionTileFilter) — Scores 4–6

    • Status: Partially covered by Core math/utils.
    • Mapped to: Core/Math/GridMath.cs, Core/Utilities/GridUtilities.cs.
    • Why: Small utilities — port selectively when needed, or re-implement in the Core/Utilities namespace.

UI / Visual / Previews (Candidates for Obsolescence)

These primarily orchestrate pre‑6.0 ModeState-based UI, preview factories and high-level UI routing. Modern 6.0 has indicators, preview builder services and mode-aware UI flows — move these to a legacy-addon or remove from core.

  • _Legacy/UI/UIManager.cs — Score 0 (Obsolete)

    • Why: Legacy UI coordinator replaced by new UI flows. Do not port to core; move to legacy-addon or delete.

  • _Legacy/UI/UICoordinator.cs — Score 0 (Obsolete)

    • Why: Old top-level router; replaced by modern UI architecture.

  • _Legacy/UI/PreviewFactory.cs / PreviewFactoryIntegrated.cs — Score 0 (Obsolete)

    • Why: Legacy preview builders that bind old DI; replace with new PreviewBuilder / indicator managers.

  • _Legacy/Visualizers/BuildingVisualizer.cs — Score 0 (Obsolete)

    • Why: Superseded by new visualizer/indicator services in 6.0.

  • _Legacy/UI/GridOverlay.cs — Score 0 (Obsolete)

    • Why: Legacy overlay that couples to old ModeState UI.

  • _Legacy/UI/PlaceableList.cs, PlaceableGrid.cs, PlaceableListEntry.cs — Score 2

    • Why: UI controls that were used by the older flows — keep in legacy-addon or rebuild as decoupled UI components in 6.0 if needed.

  • _Legacy/UI/ActionBar.cs, ActionButton.cs, ActionLog.cs, ActionTooltip.cs — Score 1

    • Why: UI helpers — not required in core 6.0 plugin. Move to addon or replace by game-specific UI.

  • _Legacy/UI/NameDisplayer.cs, DragManager.cs, DragPathVisualizationNode.cs — Score 1

    • Why: Editor or UI helper widgets — very low priority.

  • _Legacy/UI/TargetInformerWidget.cs — Score 3

    • Why: Can be replaced by indicator-based info. Low priority to port.

Input / Bootstrap / Infrastructure / Logging

  • _Legacy/Input/InputManager.cs & InputManagerNode.cs — Score 4

    • Status: Core POCS interface available.
    • Mapped to: Core/Systems/Input/IInputManager.cs & Core/Systems/Input/InputManager.cs.
    • Why: Input handling moved into more focused controllers and positioner nodes in 6.0; keep only adapters required for compatibility.
    • Next step: Migrate minimal adapter nodes for input mapping or route into the new Input subsystem.

  • _Legacy/Bootstrap/ServiceCompositionRoot.cs — Score 6

    • Status: Ported.
    • Mapped to: Godot/Bootstrap/ServiceCompositionRoot.cs.
    • Why: Legacy DI composition root — new 6.0 uses POCS service registration; we only need a small Godot bootstrap adapter.
    • Next step: Replace with a smaller bootstrap adapter that wires service adapters for Godot, or remove if POCS removes this need.

  • _Legacy/Infrastructure/SecurePreloader.cs, Internals.cs, ClassCountLogger.cs — Score 5

    • Status: Partially covered by Core logging.
    • Mapped to: Core/Systems/Logging/CoreLogger.cs / ClassCountLogger.cs (Incomplete).
    • Why: Useful infra code. Port selectively to new logging/infra pattern, or move to legacy-addon when not needed.

  • _Legacy/Logging/GodotLogger.cs, DemoDiagnostics.cs, Diagnostics.cs, FallbackLogger.cs — Score 4

    • Status: Core POCS interface available.
    • Mapped to: Core/Interfaces/ILogger.cs & Core/Services/Logging/Logger.cs.
    • Why: Logger adapters may be required by the Godot integration; port a minimal adapter for ILogger contract.
    • Next step: Port concise logger adapters (thin wrappers) that satisfy new 6.0 logging contracts.

Data Models / Resources / Persistence

  • _Legacy/Data/Placeable.*, PlaceableDefinition.cs, PreviewDataGodot.cs, BuildingDataGodot.cs, PlacementPersistence.cs — Scores 5–7

    • Status: Core POCS models available.
    • Mapped to: Core/Data/Placeable/..., Core/Data/Placement/BuildingData.cs.
    • Why: Data classes underpin placement/domain objects. Many will be replaced by Core POCS models or re-implemented, but some Godot wrappers may be necessary.
    • Next step: Reconcile with Core placeable data types — port only adapters and wrappers that are required by Godot scenes.

  • _Legacy/Resources/PlaceableResourceHandler.cs — Score 6

    • Status: Missing in 6.0.
    • Why: Resource-to-core mapping is necessary for loading placeable definitions and other data.
    • Next step: Port a thin adapter into Godot 6.0 that maps resources to core models.

Manipulation / Workflow

  • _Legacy/Systems/Manipulation/Internal/MoveWorkflowManager.cs — Score 7

    • Status: Core POCS service available (Incomplete).
    • Mapped to: Core/_incomplete/Services/Manipulation/MoveWorkflowManager.cs.
    • Why: Workflow orchestration for moves/demolish is core behavior and should be preserved or ported.
    • Next step: Port/modernize as part of manipulation system migration.

  • _Legacy/Systems/Manipulation/Internal/DemolishManager.cs — Score 7

    • Status: Core POCS service available (Incomplete).
    • Mapped to: Core/_incomplete/Services/Manipulation/DemolishManager.cs.
    • Why: Important manipulation flow; port or adapt to service architecture.

  • _Legacy/Systems/Manipulation/ManipulationData.cs, Manipulatable.cs — Score 6

    • Status: Core POCS models available.
    • Mapped to: Core/State/Manipulation/ManipulationData.cs.
    • Why: Domain objects for manipulation — port alongside manipulation services.

  • _Legacy/Systems/Manipulation/Internal/ManipulationTransformHandler.cs — Score 6

    • Status: Core POCS service available.
    • Mapped to: Core/Services/Manipulation/ManipulationTransformHandler.cs.
    • Why: Handles transform changes in the manipulation flow; port if the new architecture doesn’t offer a replacement.

  • _Legacy/Systems/Manipulation/Internal/PlacementManager.cs — noted above (9)

Behaviors & Node Patterns

  • _Legacy/Behaviors/INodeBehavior.cs — Score 6

    • Status: Missing in 6.0.
    • Why: Behavior interface abstraction is useful but may not be required in core 6.0. Remains medium priority.
    • Next step: Reconcile with new engine-specific node behavior patterns and port if necessary.

  • _Legacy/Behaviors/BuildingBehavior.cs / BehaviorManager.cs — Score 5

    • Status: Missing in 6.0.
    • Why: Patterns for node behaviors; low-mid priority to port or replace with new patterns.

Navigation / Pathing

  • _Legacy/Navigation/AStarPathManager.cs — Score 5
    • Status: Missing in 6.0.
    • Why: Not strictly core to placement; useful for tests or optional features — medium priority.

Utilities / Helpers

Large group of utilities — most are mid-to-low priority and should be ported only if they provide non-trivial logic not already present in Core/6.0.

Examples:

  • CollisionGeometryUtils.cs — Score 6
  • Positioning2DUtils.cs — Score 6
  • PlacementShapeUtils.cs — Score 5
  • MetadataUtils.cs, MessageBatcher.cs — Score 4–5
  • NodeSearchLogic.cs — Score 4
  • PhysicsMatchingUtils2D.cs — Score 6

Status: Partially covered by Core/Math/GridMath.cs and Core/Utilities/GridUtilities.cs.

Next step: For each utility, evaluate whether Core already supplies equivalent helpers; if not, port small set of well-tested functions into Godot/Utilities or Core helpers and add unit tests.

Tests & Stubs

  • _Legacy/Systems/Placement/Processors/CollisionCoreStubs.cs — Score 1
    • Why: Test stub, keep in test harness or remove after tests are migrated.

Top-priority grouped recommendations (first 3 release actions)

  1. Targeting adapters (score 9/8)

    • Files: TargetingShapeCast2DRefactored/Simplified, TargetingShapeCast2D, TargetingArea2D
    • Action: Port to Godot/Targeting adapter folder, add ITargetSensor tests and scenes.

  2. Placement core collision + placement manager (score 9/8)

    • Files: CollisionProcessor, CollisionMapper, CollisionGeometryCalculator, PlacementManager
    • Action: Port processors into Godot/Systems/Placement/Processors, ensure validator test parity.

  3. Positioner + Grid cursor adapters (score 7/8)

    • Files: GridPositioner2D, GridPositionerLogic, TargetingController2D
    • Action: Provide node adapters that consume 6.0 ICursorController and positioner interfaces.

Obsolescence candidate list (move to legacy-addon or delete)

  • UIManager.cs (UIManager) — 0
  • UICoordinator.cs — 0
  • PreviewFactory.cs & PreviewFactoryIntegrated.cs — 0
  • BuildingVisualizer.cs — 0
  • GridOverlay.cs — 0
  • PlaceableList/PlaceableGrid UI components (evaluate as addon) — 1–2

Follow the pattern: prefer moving to a gridplacement-legacy-addon package rather than deleting immediately. Mark with [Obsolete] attribute and an explanation in the code base once the replacement adapter exists.

Final notes & lifecycle

  • Port in small, test-first batches with the top group first (targeting, placement collision). Each PR should include:

    • Unit tests and minimal integration test (GdUnit/Godot test scene) demonstrating unchanged functional behavior.
    • Adapter interfaces (ITargetSensor, ICollisionProcessor, etc.) consistent with 6.0 service contracts.
    • Migration instructions and a short dev scene to verify runtime behavior.

  • After port: remove or mark [Obsolete(“Legacy — moved to adapter/legacy-addon; remove”)], and do a small cleanup PR moving code paths to the legacy add-on.

If you want, next I can:

  • Produce an automated CSV/MD table containing every _Legacy file with its exact score (complete list included in this doc group), or
  • Start a first PR scaffold that ports TargetingShapeCast2DRefactored into Godot/Targeting and adds tests.