Skip to content

Fork setup says what a dtk hash mismatch means - #125

Merged
n-delic merged 2 commits into
mainfrom
fix/gc-fork-dol-mismatch
Oct 29, 2026
Merged

n-delic merged 2 commits into
mainfrom
fix/gc-fork-dol-mismatch

Conversation

@n-delic

@n-delic n-delic commented Oct 26, 2026

Copy link
Copy Markdown
Owner

Closes #97.

Some public dtk projects are set up from files the retail disc doesn't have (a main.dol made from an ELF, a .rel module), and dtk correctly stops at its hash check. The user only saw ninja's tail. When a setup step fails with dtk's Hash mismatch: expected …, but was … after While loading object '<file>', setup now says: your copy's <file> isn't the one this project was built against (both hashes), your dump is likely fine, check the project's README for where that file comes from, or start the game from your own copy (New project → Open a game file). dtk's output follows.

Where: forks/project.py (_hash_mismatch, used by ForkProject.setup). It reads dtk's output, so it applies to any dtk project (GameCube, Wii); other setup failures keep the old message.

Tests: two in tests/test_forks.py (main.dol and a .rel module; and a non-hash failure keeps the plain message); the first fails without the change. uv run pytest tests/test_forks.py -q: 39 passed; ruff clean.

Not done (from the issue): a button to start a scratch project from the same disc, and recognising the .sbss section-count error. Whether the scratch import handles that disc is a separate question.

Open PRs: merges cleanly with all of them (#114 also edits forks/project.py).

🤖 Generated with Claude Code

Some public dtk projects are set up from files the retail disc doesn't have (a main.dol made from an ELF, a .rel
module), and dtk stops at its hash check. Setup now says the user's dump is likely fine, points to the project's
README, and offers starting the game from their own copy, before dtk's own output.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added the bug Something isn't working label Oct 26, 2026
@n-delic
n-delic merged commit 1b8ee29 into main Oct 29, 2026
9 of 10 checks passed
@n-delic
n-delic deleted the fix/gc-fork-dol-mismatch branch October 31, 2026 00:17
Puyodead1 added a commit to Puyodead1/decompdecomp that referenced this pull request Nov 1, 2026
…n, turns per function

It took near misses of 400 instructions at most, a minute per turn, four turns: a PC game's near misses are often far
bigger, and stayed with agents. Settings sets each, within its range, from the next turn on. (Seen in
RetroReversing's fork, n-delic#125.)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGuayjEgmxyBFPme1S6JNB
Puyodead1 added a commit to Puyodead1/decompdecomp that referenced this pull request Nov 1, 2026
…n, turns per function

It took near misses of 400 instructions at most, a minute per turn, four turns: a PC game's near misses are often far
bigger, and stayed with agents. Settings sets each, within its range, from the next turn on. (Seen in
RetroReversing's fork, n-delic#125.)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGuayjEgmxyBFPme1S6JNB
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clearer failure when a public decomp's main.dol is not the retail disc's (GameCube fork setup)

1 participant