Spike: main menu shell and safer save management

[tajemniktv]

Idea

Add a real-ish main menu / save management layer for Upload Labs, or at least investigate how far a mod can safely go without fighting the game like it owes us rent.

The rough feature idea:

• A main menu-style screen for starting/continuing a session.
• Better save management: save slots/profiles, backup/restore, duplicate/rename/delete saves, maybe import/export/open save folder.
• A safer path for players who want to manage progression without manually poking files.

This is likely Core-scoped first, because it touches boot/runtime/UI/save hooks and could become shared infrastructure for other Taj's Mods. If the final UX ends up being a QoL-specific panel, create a follow-up QoL issue after the Core feasibility/API is clear.

Initial feasibility read

This is probably possible as a save manager panel / overlay, but a full replacement main menu is uncertain until the base game save/load flow is inspected.

Known Core hooks and services that may help:

• core/hooks/save_load_hooks.gd already listens to base game signals: Signals.saving, Signals.boot, and Signals.desktop_ready, then emits Core events like game.saving, game.started, and game.desktop_ready.
• core/hooks/hook_manager.gd installs save_load_hooks as part of the Core hook stack.
• core/ui/ui_manager.gd can inject UI once Main/HUD exists and already exposes popup/confirmation/input helpers.
• core/storage.gd provides safe-ish JSON storage, module data/state/cache paths, and backup helpers under user://mods.
• core/features/boot_screen_feature.gd already demonstrates that Core can observe/patch the Boot node, so a boot/main-menu-adjacent overlay might be technically reachable.

Things not confirmed yet:

• Whether Upload Labs exposes a clean save-list/load-slot API.
• Whether changing saves while a session is already loaded can be done safely without restarting the game.
• Where the actual game save files live and what their format is.
• Whether vanilla supports multiple saves internally or only one active save.
• Whether a mod can prevent/replace the default auto-load/start flow without breaking boot.

Recommended approach

Do this as a staged feasibility spike, not as a giant “rewrite the game’s frontend” adventure. That path has spikes, cliffs, and probably one cursed singleton named Data.

Stage 1 — Investigate base save/load behavior

• Find the actual base game scripts/autoloads responsible for save/load.
• Identify save file paths, naming, format, and autosave timing.
• Inspect available signals/methods around:
  • boot
  • save
  • load
  • desktop ready
  • new game/session reset
  • quit/restart
• Confirm whether saves can be loaded after boot without process restart.
• Confirm whether save files can be copied/restored while the game is running.

Stage 2 — Core save management service MVP

Create a Core service, tentatively core/save_manager.gd, that exposes safe operations:

• list_saves()
• get_active_save()
• create_backup(save_id, reason)
• duplicate_save(save_id, new_name)
• rename_save(save_id, new_name)
• delete_save(save_id) with confirmation requirements
• restore_backup(backup_id)
• open_save_folder() if feasible

The service should avoid direct destructive writes until it has created a backup.

Stage 3 — Minimal UI panel

Before attempting a true main menu, add a regular Core/QoL-style UI panel accessible after game load:

• Current save/profile summary.
• Save list.
• Duplicate, rename, backup, restore, delete.
• Manual backup button.
• “Open save folder” button if supported.
• Warnings for actions requiring restart.

This gives most of the value without betting the entire mod on boot-order wizardry. Humans do love turning “save file exists” into a UX problem, but here we are.

Stage 4 — Optional main menu shell

Only after Stage 1 proves the flow is safe:

• Show a main menu-style overlay after boot or before desktop becomes interactive.
• Options:
  • Continue
  • Load save/profile
  • New save/profile
  • Save Manager
  • Mods / Core Settings
  • Quit
• If live loading is not safe, loading a different save should clearly say restart required and optionally stage the selected save for next launch.

MVP proposal

The first shippable version should not try to fully replace vanilla boot.

MVP should be:

• A Save Manager window available from Core settings / HUD / command palette.
• Manual backup creation.
• Save list with metadata if detectable.
• Duplicate/rename/delete with confirmations.
• Restore from backup with very explicit warnings.
• All destructive operations create a backup first.
• Emits Core events so QoL/Command Palette can add actions later.

Core API/events to consider

Potential events:

• game.save_manager.ready
• game.save_manager.saves_changed
• game.save_manager.backup_created
• game.save_manager.restore_requested
• game.save_manager.restore_completed
• game.save_manager.operation_failed

Potential command registrations:

• core.save_manager.open
• core.save_manager.backup_current
• core.save_manager.open_folder

Safety requirements

• Never delete/overwrite a save without confirmation.
• Never restore/delete without first creating a timestamped backup if possible.
• Use atomic writes/copies where possible.
• Detect malformed or unsupported save files and show warnings instead of pretending everything is fine like a corporate dashboard.
• Do not run destructive file operations while the game is actively saving.
• Subscribe to game.saving or base Signals.saving and lock the UI/actions during saves.
• Log every operation through Core diagnostics/logger.

Acceptance criteria for the spike

• Document the base game save/load flow.
• Identify save file path(s), format, and active-save semantics.
• Confirm whether live loading/switching saves is possible.
• Confirm whether pre-desktop main menu injection is possible and safe.
• Produce a recommendation:
  • A: full main menu feasible
  • B: save manager feasible, main menu limited/restart-gated
  • C: only backups/export/import are safe
  • D: not worth doing because save corruption risk is too high

Acceptance criteria for MVP implementation

• Save manager opens from Core UI or a registered command.
• Current save/profile is shown when detectable.
• Player can create a manual backup.
• Player can duplicate/rename/delete saves when supported.
• Restore requires explicit confirmation and backup creation first.
• UI disables dangerous actions while a save is in progress.
• Restart-required operations are clearly labeled.
• Operations survive game restart and do not corrupt the current save.
• Diagnostics include recent save-manager operations.

Open questions

• Should the user-facing window live in Core, QoL, or both?
• Should this be branded as Main Menu, Save Manager, or Profile Manager?
• Does Upload Labs currently have one save, multiple saves, or session/profile-like data?
• Can the game load a different save without restarting?
• Is it possible to intercept boot early enough for a polished menu without visible flicker?
• Should Command Palette expose save actions after the Core service exists?
• Should backups live under user://mods/TajemnikTV-Core/... or next to vanilla saves?

Not in scope for the first pass

• Cloud sync.
• Save editing/cheating.
• Cross-version migration tools.
• Rewriting the entire Upload Labs startup flow before proving it is safe.