cecilarmitais 0fbdb57210 Decomp four more mission accessors; find the cause of the batch failure
Decompile from asm:

  ov29_02349688                 0x02349688
  SetTargetMonsterNotFoundFlag  0x023496C4
  GetTargetMonsterNotFoundFlag  0x023496D8
  GetMissionTargetEnemy         0x02349620

The first three read and write the two dungeon flags at 0x1 and 0x3;
GetMissionTargetEnemy returns enemy_species[0]. No new types.

The previous commit left thirteen functions unlanded because they failed four
checksums with no compile error, and recorded the elimination so far. Bisecting
found a one-function reproducer, GetMissionEnemyMinionGroup, and disassembling
the object the real build emits identifies the cause.

The scratch and the real build disagree, and the scratch was wrong. For
enemy_species[index + 1] the target computes the index first --
add r0, r0, #1, then add r0, r1, r0, lsl #1, then add #0x700 and ldrsh [r0,
#0x6e]. The real build folds the constant into the displacement instead, giving
add r0, r1, r0, lsl #1, add #0x700, ldrsh [r0, #0x70], one instruction shorter
and the same address. Same compiler, same flags, same C: the difference is the
context. The scratch used a cut-down struct dungeon carrying only the offsets
these functions touch, and against that struct the compiler emits the target's
form; against the real header it folds.

That invalidates the scratch verification for the whole cluster, not just this
function. Score 0 against an invented struct is not evidence about a build that
uses the real one, even when every offset and size matches -- and they do, which
was confirmed separately by compile-time assertions against the real headers.

So the thirteen are not near-matches to iterate on; they need re-verifying
against a faithful context before any C is judged. A preprocessed context is
obtainable -- mwccarm -E on a file including dungeon.h and mission.h, with
LM_LICENSE_FILE set, yields 9200 lines that reproduce the real build's view --
but that output does not yet compile as scratch context on its own, failing at a
typedef, so wiring it up is unfinished.

The four here were each verified by a matching build rather than by the scratch:
three of them alone, GetMissionTargetEnemy alone, and all four together.

No comments are added to any pmd-sky file.

Authored by Claude (Opus 5) under human direction. Confirmed by a matching
build: build/pmdsky.us/pmdsky.us.nds: OK.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 01:08:34 -07:00
2026-04-08 09:53:43 +02:00
2024-04-17 23:52:39 -04:00
2023-11-20 17:24:08 -06:00
2024-06-23 16:59:48 -05:00
2023-08-13 23:03:51 -04:00
2024-12-28 02:25:07 -06:00
2026-08-01 12:46:55 -04:00
2023-06-28 23:35:19 -04:00
2023-06-28 23:35:19 -04:00
2023-06-28 23:35:19 -04:00
2023-06-28 23:35:19 -04:00
2026-07-16 07:36:58 -07:00
2025-06-10 23:35:01 -04:00
2023-08-20 22:43:00 -04:00
2023-08-14 00:17:21 -04:00
2023-11-01 18:44:19 -04:00
2024-04-17 23:52:39 -04:00
2023-08-28 00:09:02 -04:00
2024-04-17 23:52:40 -04:00
2023-08-08 00:17:03 -04:00

Pokémon Mystery Dungeon: Explorers of Sky

This is a WIP disassembly of Pokémon Mystery Dungeon: Explorers of Sky. For instructions on how to set up the repository, please read INSTALL.md. For information on how to contribute changes, see CONTRIBUTING.md.

This repository builds the following ROMs:

For contacts and other pret projects, see pret.github.io.

Description
Decompilation of Pokémon Mystery Dungeon: Explorers of Sky
Readme 335 MiB
Languages
Assembly 66.3%
C 18%
C++ 7.1%
Boogie 4.3%
sed 1.5%
Other 2.8%