53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
|
# Project "Millimeters of Aluminium" Development Log
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
The project is undergoing a major architectural refactor to move from a monolithic Spaceship class to a fully modular, component-based system. The foundation for this new architecture, centered around Module, Component, and Station classes, is now in place. The next steps involve migrating legacy systems into this new paradigm.
|
||
|
|
|
||
|
|
## I. Fully Implemented & Stable Systems
|
||
|
|
|
||
|
|
Custom Physics Core: All physical objects now inherit from a custom OrbitalBody2D class, which handles mass aggregation and force integration. The physics loop is correctly disabled in the editor to prevent errors.
|
||
|
|
|
||
|
|
Modular Ship Construction:
|
||
|
|
|
||
|
|
Module as Root: The Module class now serves as the root for ship assemblies, managing its own list of structural pieces and components without needing container nodes.
|
||
|
|
|
||
|
|
Builder Plugin: The editor plugin is updated to work with this new architecture, allowing the placement of StructuralPiece nodes directly onto Module nodes.
|
||
|
|
|
||
|
|
Character & Interaction Foundation:
|
||
|
|
|
||
|
|
Zero-G Movement: The PilotBall character has a state machine for handling movement inside ship interiors, including sluggish zero-G floating and direct control on ladders.
|
||
|
|
|
||
|
|
Generic Station Component: A StationComponent class has been implemented. It serves as a generic hardware terminal that characters can interact with.
|
||
|
|
|
||
|
|
Data-Driven UI Architecture:
|
||
|
|
|
||
|
|
Databank Resource: A Databank Resource class has been created. It acts as "software," holding a reference to a UI scene that can be loaded by a station.
|
||
|
|
|
||
|
|
## II. Work-In-Progress (WIP) and Planned Systems
|
||
|
|
|
||
|
|
This list details systems we have designed but are not yet fully implemented in the code.
|
||
|
|
|
||
|
|
System Migration to Databanks:
|
||
|
|
|
||
|
|
Helm/Flight Controls: The logic from the old ThrusterController.gd needs to be moved into a HelmUI.tscn scene and driven by a HelmDatabank.
|
||
|
|
|
||
|
|
Navigation Computer: The UI has been moved, but the extensive planning and calculation logic from NavigationComputer.gd needs to be transferred to NavUI.gd.
|
||
|
|
|
||
|
|
Fuel and Life Support: The FuelSystem and LifeSupport nodes are still part of the old Spaceship.tscn. They need to be fully redesigned as Component classes (e.g., FuelTank, AtmosphereProcessor).
|
||
|
|
|
||
|
|
Component Wiring System:
|
||
|
|
|
||
|
|
Signal/Socket Advertising: Components and Databanks need to be updated with get_input_sockets() and get_output_signals() functions.
|
||
|
|
|
||
|
|
Wiring Data Storage: The Module class needs a wiring_data array to store the connections made in the builder.
|
||
|
|
|
||
|
|
Builder UI: A visual wiring interface needs to be added to the module builder plugin.
|
||
|
|
|
||
|
|
Orbital Stability Test:
|
||
|
|
|
||
|
|
Ghost Simulator: A GhostSimulator class needs to be created to run predictive, in-memory physics calculations.
|
||
|
|
|
||
|
|
Test Runner: An orbital_stability_test.tscn scene and script are needed to orchestrate the test, compare live vs. ghost results, and generate a report.
|
||
|
|
|
||
|
|
Full Spaceship Class Retirement: The final step will be to delete Spaceship.tscn and Spaceship.gd once all their logic and systems have been successfully migrated to the new modular architecture.
|