Add save-file aware research progress and ship preset import

[FennexFox]

Problem

The current chart mainly answers the question:

How much total research is required to reach this drive from a neutral baseline?

That is useful for general planning, but it becomes less accurate once a campaign is already underway. In a real save, many prerequisite technologies or projects may already be completed, some projects may be partially researched, some projects may be visible and researchable, and others may not yet be available to the player's faction.

Because Terra Invicta uses project unlock and availability mechanics, two drives with similar total research cost can have very different practical costs in a specific save. A drive may also be theoretically on the chart but not currently researchable at all.

The chart should support a save-aware view that answers:

Given this save file, how much research remains before this drive can actually be used, and is the required project currently available?

Direction

Do not require users to run TI_Parser or any external command-line tool. Engine Charts is a static web page, and the save-aware workflow should preserve that user experience.

The default implementation should parse Terra Invicta .gz save files directly in the browser. The save should remain local to the user's machine and should not be uploaded to a server in the default path.

The browser parser should be intentionally minimal. It should not attempt to replicate the full TI_Parser planning model. It only needs to extract the subset of save data required by Engine Charts.

Initial browser-native scope

The first implementation should support:

• Local .gz save upload in the browser
• Local gzip decompression
• Parsing in a Web Worker to avoid blocking the UI
• Extraction of the player faction or selected faction where possible
• Completed global technologies
• Completed faction projects
• Currently available faction projects where possible
• Active research progress
• Stored or partial project progress where possible
• Mapping extracted research state to the existing Engine Charts drive/project catalog
• A chart mode that can switch between total research and remaining research
• Visual status for each drive/project based on save state

Save-derived statuses

Each drive or drive-unlocking project should be classified into a status such as:

• Already researched
• Researchable now
• Partially completed
• Global prerequisite available but faction project not yet acquired
• Missing prerequisite technology
• Blocked or unavailable
• Unknown / unsupported save format

These statuses should be visible in the chart, tooltip, or detail panel. The UI should avoid implying that a drive is immediately researchable when the save data does not support that conclusion.

Ship preset import scope

Existing ship design import is useful, but it should be secondary to research-state import.

The first ship import pass should only extract enough information to create or suggest dry mass / ship assumption presets, such as:

• Ship design name
• Hull type where available
• Drive name
• Reactor / power plant name
• Radiator name where available
• Dry mass / wet mass / propellant mass where recoverable
• Utility modules where relevant

Full reconstruction of every ship stat should not be required for the first pass.

Performance and operational requirements

• Save parsing should run in a Web Worker.
• Large save files should not freeze the main UI thread.
• The UI should show parsing progress or at least a clear loading state.
• The parser should return a compact context object to the main thread rather than exposing the entire parsed save object to the chart UI.
• The parser should fail gracefully on unsupported or changed save formats.
• Save files should not be uploaded to a server in the default implementation.
• The page should clearly communicate that parsing is local.

Browser compatibility notes

The preferred path is:

1. Read the uploaded .gz file as binary data.
2. Decompress it locally using browser-supported gzip handling where available.
3. Fall back to a bundled gzip library if needed.
4. Parse the decompressed JSON inside a Web Worker.
5. Extract only the compact Engine Charts context needed by the UI.

The implementation should avoid parsing large saves on the main thread.

Acceptance criteria

• Users can upload a Terra Invicta .gz save file directly in the Engine Charts page.
• The save is decompressed and parsed locally in the browser.
• Parsing work runs in a Web Worker or equivalent non-blocking path.
• The page extracts completed global technologies from the save where possible.
• The page extracts completed faction projects from the save where possible.
• The page extracts active or partial research progress where possible.
• The page maps extracted research state to drive unlock requirements in the chart data.
• The chart can switch between total research cost and save-relative remaining research cost.
• Drives/projects are visually marked as researched, researchable, partially complete, blocked, unavailable, or unknown.
• The UI explains when a drive cannot be evaluated because the save format or project state is unsupported.
• Save files are not uploaded to a server in the default workflow.
• Existing chart behavior remains unchanged when no save file is loaded.

Out of scope for MVP

• Requiring users to run TI_Parser locally.
• Server-side parsing as the default path.
• Full TI_Parser feature parity.
• Full strategic research recommendation.
• Full ship design stat reconstruction.
• Complete validation of every project unlock edge case.
• Persisting uploaded save contents in localStorage.

Optional future backend fallback

If browser-native parsing proves too slow, too memory-heavy, or too difficult to maintain, a Python backend can be considered as an optional fallback. The cheapest practical backend shape would be a small FastAPI service that reuses TI_Parser internals and returns only a compact Engine Charts context object.

However, a backend should not be the default unless necessary, because it introduces:

• Save file upload and privacy concerns
• Hosting and operating costs
• CORS and abuse-prevention requirements
• Failure modes outside GitHub Pages
• A more complex deployment model

If implemented later, the backend should:

• Enforce upload size limits
• Avoid storing save files
• Avoid logging save contents
• Return only compact derived chart context
• Be clearly labeled as optional server-side parsing

Suggested implementation phases

Phase 1: Research-state import MVP

• Add save upload control.
• Add Web Worker parser shell.
• Decompress and parse .gz saves locally.
• Extract completed techs/projects and partial progress.
• Add remaining research axis mode.
• Add drive/project status display.

Phase 2: Better availability classification

• Improve faction project availability detection.
• Show missing prerequisites in tooltip/detail panel.
• Distinguish unavailable, not yet acquired, and blocked states more clearly.

Phase 3: Ship design preset import

• Extract existing ship design names and major components.
• Convert imported designs into dry mass / ship assumption presets.
• Preserve imported presets through existing preset storage if available.

Phase 4: Optional backend fallback

• Evaluate whether browser parsing has unacceptable performance or compatibility issues.
• If necessary, add an optional Python backend parser endpoint.
• Keep browser-native local parsing as the preferred path if practical.

[FennexFox]

Save-aware Best Available follow-up

The Power view work now has a Best Available comparison path built around sortedChartPowerOptions(...) / bestAvailablePowerSteps(...).

When this save-aware issue is implemented, reuse that calculation path by passing a save-derived project availability predicate into sortedChartPowerOptions(...). That predicate should restrict candidate power plants to what the loaded campaign has completed, can currently research, or can otherwise obtain according to the parsed save context.

This keeps Best Available from overvaluing theoretical later power plants that are not actually available in the current save, and should become the basis for a future save-aware best-available comparison.