# Development Status Report - 2025-11-21

## Overview

Significant progress was made on the Unified Build System and the In-Game Builder, moving away from purely editor-based construction. We successfully implemented procedural geometry generation for structural pieces and refactored the snapping logic to support the upcoming geodesic structures. Networking logic also saw crucial stability fixes.

## Completed Features & Implementations

### 1. Unified Build System Foundation

- StructureData Resource: Implemented a robust resource-based definition system for ship parts. This decouples the "DNA" of a part (mesh, collider, mounts, health) from its scene instantiation, allowing shared logic between the Editor Plugin and the In-Game Builder.

- PieceMount Logic: Formalized attachment points into a dedicated PieceMount class (inheriting Area3D). This replaced the ad-hoc dictionary system, providing type safety and better collision filtering.

- ProceduralPiece Generator: Created a script that dynamically generates 3D meshes and collision shapes based on parameters (e.g., triangle vs. square, size, thickness) defined in StructureData. This supports:

- Extruded 3D geometry (thickness) rather than flat planes.

- Convex collision hull generation.

- "Opaque Blueprint" preview materials (semi-transparent, emissive).

### 2. In-Game Builder (PlayerController3D)

- Build Mode State: Implemented a toggleable Build Mode (B key) in PlayerController3D.

- Piece Selection: Added logic to select pieces via hotkeys (1 = Square, 2 = Triangle), instantiate a preview "ghost," and switch its material.

- Raycast Snapping: Implemented a physics-based raycast/sweep to detect existing ship modules and mounts.

- Visual Feedback: Added color-coded feedback for the preview ghost:

    - Cyan: Floating (no snap target found).

    - Geen: Snapped (aligned with a valid mount).

### 3. Snapping Logic Refactor

- SnappingTool Class: Created a dedicated static helper class for snapping math.

- Shape Cast Sweep: Replaced simple raycasting with a sphere_cast (radius 0.2m). This adds "thickness" to the cursor, making it much easier to hit thin structural elements like struts or small mounts.

- Transform Alignment: Implemented matrix math to align a new piece's mount with a target mount, respecting position, normal (facing direction), and up-vector (roll/orientation).

### 4. Networking Stability (Previous Session)

- Server Authority Enforcement: enforced strict server authority on CharacterPawn3D, removing client-side overrides that caused "fighting" and stutter.

- Relative Velocity Sync: Implemented logic to sync local_velocity relative to the parent ship instead of global velocity. This prevents pawns from "falling out the back" of moving ships during network jitter.

- Input Serialization: Fixed RPC errors by converting custom KeyInput objects to Dictionaries before transmission.

## Pending / In-Progress

- Mount Orientation Constraints: The snapping tool currently aligns normals but needs refinement to strictly enforce edge length compatibility and specific mount types (e.g., preventing a 2m edge from snapping to a 1m edge).

- Module Persistence: The logic for creating a new Module when building in empty space works in memory but needs testing for persistence and saving.

- Collision Layers: Need to verify that all PieceMount nodes are consistently on the correct physics layer (1 << 14) to ensure the snapping sweep always finds them.

## Discussion & Direction Changes

### Shift to "Geodesic & Procedural" Building

We moved away from the initial "Voxel Grid" concept for ship hulls.

- Old Direction: Ships built on a strict integer grid (Minecraft-style but with slopes).

- New Direction: A node-based "Geodesic" system. Pieces connect Node-to-Node (Mount-to-Mount) at arbitrary angles. This allows for complex shapes (hexagonal cylinders, spheres, rings) and supports the "Industrial/Hard Sci-Fi" aesthetic better.

- Implication: The building tool no longer relies on grid_step for positioning. It relies entirely on the SnappingTool to calculate transforms based on the geometry of the mounting points.

### Shift to "Server Authoritative" Networking

We abandoned the "Client Authoritative" movement for pawns to solve synchronization issues.

- Old Plan: Client moves pawn, Server accepts pos. (Caused hacking risks and desync with physics objects).

- New Plan: Server simulates physics. Client sends inputs. MultiplayerSynchronizer interpolates the result. To combat latency feel, we are using Visual Interpolation (detaching camera/mesh from the physics body) rather than full Client-Side Prediction (CSP) for this milestone.

### Manufacturing & Blueprints

We discussed that the StructureData resource is the key enabler for the manufacturing gameplay loop. By defining parts as data (Resources), we can easily:

1. Store a "Blueprint" as a list of StructureData references + Transforms.

2. Have a manufacturing machine consume resources to produce a "Crate" containing a StructureData item.

3. Have the player pick up that item and use it to place the ProceduralPiece.