[JimmyfaQwQ]

Fixes #20.

An install never received changed defaults for the shipped lighting profiles under rtx-remix/mods/minecraft-logic/. NativeExtractor skipped every author-owned file that already existed, because it could not tell an untouched default from an author's edit, so a retuned profile reached a player only after they deleted their copy.

The JAR now carries rtx-remix-shipped-payload.sha256, the SHA-256 of every version of each payload file that has shipped, seeded with the 0.1.0 payload. extractAuthorTree replaces an existing file only when its hash is a shipped version of that same path; any other content is an edit and is kept, as before. Missing files are still written, so deleting a file still restores its default. A file already matching the current default is not rewritten.

Hashes fold CRLF to LF. The .conf payload has no .gitattributes rule, so the line endings packaged into the JAR depend on the builder's git configuration, and editors convert them; neither is an edit.

The list lives in the JAR rather than in the game directory, so there is no install-side state to lose, and 0.1.0 installs, which recorded nothing at extraction, still receive the next release's defaults. A payload change must append its hash: ShippedPayloadHistoryTest walks packaging/rtx-remix/ and fails with the exact lines to append, and verifyPackageJar requires the list in the JAR, since extraction refuses to run without it. This change edits the payload README, so it appends that file's new hash.

The 0.1.0 hashes come from packaging/rtx-remix/ at the import commit; the payload has not changed since, and the v0.1.0 release archive was built from 170197a.

AGENTS.md, PLAYING.md, TUNING.md, INSTALL.md, the payload README, and the changelog describe the new behaviour.

Verification:

• .\gradlew.bat build test package -Parch=win64 passes, including verifyPackageJar.
• New NativeExtractorTest cases cover: an earlier shipped default is updated on a version change; content matching no shipped version is kept; another path's shipped content is not accepted; CRLF-only differences are not an edit; a file already matching the current default is left byte-for-byte alone.
• Changing water.conf without appending its hash makes ShippedPayloadHistoryTest fail with the line to append.
• Simulated upgrade with the packaged win64 JAR on the classpath (its own zip paths and bundled list): a game directory holding the 0.1.0 payload from git archive (CRLF), with day.conf edited and a 0.1.0 marker. After extractIfNeeded, the payload README took the new default, the edited day.conf kept its edit, and the marker moved to the new version.
• Not done: the same upgrade through a launcher with the game running. tools\rtx.bat check --tests was not run locally (uv below the required 0.13); the changed files were scanned against the public-boundary patterns by hand.

Not changed: tools\rtx.bat install still copies the payload with copytree(dirs_exist_ok=True), which overwrites edited profiles. That is the developer install path and is left for a separate change.

🤖 Generated with Claude Code

[sambvfx]

Thanks, nice approach. I tested it as a real upgrade: a Prism instance holding the 0.1.0 profiles, an old version marker and a hand-edited day.conf, launched with the packaged JAR from this branch. The log showed the README being updated and 1 edited file kept. On disk the README matched the current default, day.conf kept its edit, and the marker moved to the new version. The renderer and all 11 profiles loaded. I also checked that the 0.1.0 hashes match the v0.1.0 tag.

Two optional nits, fine as a follow-up:

• The comment in rtx-remix-shipped-payload.sha256 says NativeExtractorTest fails with the line to append; it's ShippedPayloadHistoryTest.
• The # Unreleased heading in that file will need relabelling when we cut the release.

This conflicts with #61 in CHANGELOG.md (both add a Fixed entry). I'll resolve that on the branch when I merge.

[sambvfx]

I merged #61 first, and it also adds a Fixed entry under Unreleased in CHANGELOG.md, so this now conflicts with main. Could you merge main and keep both entries? I'll merge as soon as CI is green. CHANGELOG.md goes away in an upcoming release change, so the order and wording don't matter.

[JimmyfaQwQ]

I merged #61 first, and it also adds a Fixed entry under Unreleased in CHANGELOG.md, so this now conflicts with main. Could you merge main and keep both entries? I'll merge as soon as CI is green. CHANGELOG.md goes away in an upcoming release change, so the order and wording don't matter.

Thanks for the review! I merged the main branch while keeping both 'Fixed' entries in the changelog, and the ShippedPayloadHistoryTest nit you mentioned has also been addressed in the latest commit. The build and tests are still clean on my end, pending your approval to run the remote CI. Let me know if you spot anything else!

[sambvfx]

Thanks for merging main and keeping both entries. CI is green, so merging now.