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:

Store a "Blueprint" as a list of StructureData references + Transforms.
Have a manufacturing machine consume resources to produce a "Crate" containing a StructureData item.
Have the player pick up that item and use it to place the ProceduralPiece.

5.0 KiB Raw Blame History