Skip to content

Lay the config persistence foundation for runtime mod settings - #278

Closed
Guffawaffle wants to merge 20 commits into
STFC-Mod:devfrom
Guffawaffle:fix/config-save-safety
Closed

Guffawaffle wants to merge 20 commits into
STFC-Mod:devfrom
Guffawaffle:fix/config-save-safety

Conversation

@Guffawaffle

@Guffawaffle Guffawaffle commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor

This lays the persistence groundwork for mod settings that can be changed while the game is running.

The foundation has three layers:

  • Checked file transactions stage and validate output before replacement, preserve supported file permissions, and report commit, failure or recovery outcomes.
  • A bounded save service owns registered destinations and background workers, serializes writes per destination and retains completion results for callers.
  • A lazy Windows runtime host coordinates the service with normal game shutdown, keeping storage waits and worker joins off the game thread. Failed saves do not prevent exit once the workers finish.

Windows F10 remains a force-close path independent of Unity: it cancels queued saves and allows active work up to 500 ms to finish before terminating. It closes immediately when there is no active save supervisor. A separate native deadline thread enforces the grace period without joining writers or requiring another Unity update. The normal shutdown coordinator applies to the game's quit lifecycle, including window close. The host uses the existing Update dispatcher and validates the build261 Windows x64 quit method before enabling runtime registration. macOS startup transactions are supported; runtime registration remains unavailable until its lifecycle seam is validated.

Startup user-config creation is create-only, and generated runtime-vars output uses checked replacement. The preserving TOML editor and the first mod-owned settings control follow separately on a child branch. Runtime consumers will reuse this service; none ship in this foundation. PR267's JSON state work remains independent.

The service supports up to four destinations/workers, 32 retained tickets and 32 MiB of snapshot capacity. It rejects ambiguous destination/lock aliases. On Windows, supported inherited permissions are retained; ambiguous legacy security descriptors and unsupported inherited ACL forms are rejected before staging rather than migrated by a save.

Validation:

  • At foundation head c4095c7, three review lanes, Windows/macOS ARM/macOS Intel builds, macOS packaging, native persistence fixtures and example validation passed. Builds, fixtures.
  • A reviewed instrumented child exercised two successful saves and two locked-file failures. Captures showed worker joins, service destruction and native supervisor exit before resumed normal quit. The failed-save run preserved the baseline file and closed normally. The earlier success run used the then-graceful F10 path; it is evidence for normal shutdown coordination, not the restored force-close shortcut.
  • The 500 ms F10 grace period at a5ccdd8 passes native subprocess tests for idle exit, a permanently blocked writer, an active write that finishes, and cancellation during an existing normal drain. The simulated owner stops updating after F10; the queued second write never executes. All three correction review lanes, the local Windows release build, and Windows/macOS native fixture CI pass. The cancellation contention regression holds the host lock until workers join. Windows/macOS production builds and macOS packaging pass; the reviewed release is deployed and the user reports live F10 works and then relaunched. The user confirmed F10, normal game quit and window-X all passed on their client. A separate leftover test instance complicated process attribution; that observation is not treated as a confirmed shutdown regression. These tests do not claim forced-write durability or live-game input validation.

The implementation and tests document platform support, permission compatibility and filesystem recovery limits. Result presentation, targeted TOML editing and macOS runtime lifecycle support remain follow-on work.

@Guffawaffle Guffawaffle changed the title Add checked config transactions and bounded snapshot worker foundation Add checked config transactions and bounded save service foundation Sep 11, 2026
@Guffawaffle
Guffawaffle marked this pull request as ready for review September 12, 2026 00:07
@Guffawaffle Guffawaffle changed the title Add checked config transactions and bounded save service foundation Lay the config persistence foundation for runtime mod settings Sep 12, 2026
@Guffawaffle

Copy link
Copy Markdown
Contributor Author

Closing in favor of a narrower rewrite based on the lessons from this implementation. The branch is retained as a reference for code, tests, and review evidence. The replacement will focus on established config paths, typed TOML encoding, same-file save coordination, and the agreed shutdown behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant