Technical Debt¶
This document records known cleanup, refactor, and temporary implementation topics for Andromeda.
Keep descriptive walkthroughs focused on how the current code works. Put forward-looking cleanup notes here so temporary choices are visible without mixing plans into architecture explanations.
Text Localization Asset Workflow¶
Shared prompts, scanner status labels, fallback UI copy, and enum display labels now flow through the ST_AndromedaText string table keys and the narrow C++ helpers:
The current source-controlled table source is:
The Andromeda/Localization/StringTables folder is staged through Additional Non-Asset Directories to Package in Config/DefaultGame.ini, because CSV string tables are not staged automatically.
If the project later prefers a binary String Table asset workflow, import this CSV into Content/Andromeda/Localization/StringTables/ST_AndromedaText and keep the table ID/key contract stable. Avoid reintroducing local enum-label switches in UI or salvage .cpp files.
Item-specific copy still belongs in data assets. Do not move authored salvage content into the shared string table unless it becomes genuinely shared UI copy.
Station Databank Persistence¶
Scan memory is currently in-memory only on the station shell's native UAndromedaStationDatabankComponent.
That is enough for the vertical slice, but future save/load work should serialize scan records through Unreal USaveGame rather than storing scan state on salvage items.
Missing component guard/logging is intentionally minimal right now to avoid noisy PIE logs during rapid iteration. Add focused diagnostics once the station shell and workstation screen layouts stabilize.
Station And Workstation Volume Tuning¶
AAndromedaStation now owns the required station databank and station access sphere natively. AAndromedaWorkstation now owns the required root scene, placement validator, default placement volume, and screen socket natively. Blueprints should tune radius, transforms, widget classes, draw sizes, visibility, meshes, placement volumes, and authored presentation settings.
The workstation screen component is the operation surface and world-space widget host. Placement volumes are validation shapes for freeform-placed items, not handoff interactables. Packager screens may still need final visual widgets and precise placement once their industrial design settles.
Placement Release¶
Contextual drop has been replaced by a pre-v1 placement mode. The player toggles placement mode while carrying, previews a ghost, rotates the item, and commits a physics-enabled release inside station bounds.
The old fixed-distance drop API has been removed rather than kept as a hidden fallback. If an emergency release becomes desirable later, it should be designed as an explicit action with clear input, prompt, and physical behavior.
It still does not yet:
avoid clipping into walls
choose a clear nearby spot
play placement animation
display polished placement outline materials
support fine translation controls
This is enough for the placement foundation. The future warehouse direction depends on evolving this into a deliberate freeform storage system; see docs/design/future-warehouse-logistics.md.
Placement validation currently discovers station bounds by scanning station actors from the placement component. That is acceptable at prototype scale, but the warehouse/storage pass should replace it with an explicit current-station reference or provider so placement state ownership is clear.
Placement overlap also uses the held mesh's current bounds as a coarse box footprint. That is good enough for obvious blocker rejection, but rotated or irregular cargo will need a more deliberate footprint/collision query before storage layouts matter.
Audit defensive fallback values in gameplay APIs and prefer optional-returning C++ contracts where missing data is a real negative state. Handle unset values near the top-level decision point rather than hiding broken setup behind sentinel defaults such as zero vectors or generic collision channels.
AAndromedaHUD currently assumes the owning player controller keeps the same pawn after HUD startup. If future gameplay introduces respawn, vehicle/drone possession, cinematic control handoff, or player-character swapping, add possession-change handling back so HUD character delegates, focused prompt state, and station access state are rebound correctly.
Future Interaction Component Split¶
Pickup command ownership now lives on the player/carry side: the character resolves a salvage pickup capability and asks UAndromedaCarryComponent to pick up the item. This removes the old item-owned route where AAndromedaSalvageItem executed carry pickup itself.
Longer term, the character may still grow a dedicated interaction router component if focus/input routing becomes too large. Keep that as a separate architecture pass; the current split is good enough while the character owns camera traces and player input.
IAndromedaInteractableInterface::GetInteractionEvents is intentionally present for capability interface symmetry, even though current gameplay code does not call Execute_GetInteractionEvents. Prompt refresh currently subscribes through IAndromedaPromptableInterface::GetPromptEvents, while interaction execution is driven directly by focused input. Revisit this during the HUD or interaction-router review: either wire interaction-state subscribers through this hook if a real consumer appears, or remove it if the prompt/event split makes it permanently redundant.
Package Presentation¶
Packaging is currently a state flag:
The item does not yet visually become a package, spawn a package actor, receive a label, or move into a package container. This is enough for the first loop, but the eventual game should make packaging physical and visible.
Likely future direction:
item placed at packager workstation
-> package category/size selected or confirmed
-> visual package/label appears
-> packaged item can be carried to warehouse
Save And Progression¶
The current item state is runtime-only.
Longer term, a shift/save system will need to persist:
which items spawned
which items were scanned
which packages were assigned
where items were physically stored
which later cargo/consequence outcomes occurred
credits/reputation/story flags
Do not prematurely build a full save system yet, but keep gameplay state ownership clear so it can be saved later.