Decompile two accessor clusters and the .col2 loader - #18
Open
Moss255 wants to merge 5 commits into
Open
Conversation
Seventeen getters, setters and tests on one struct. Their offsets establish BattleStruct out to 0x63e0, well past the part previously modelled. 0x02011644 and 0x02011650 are left alone - GrottoNameDataFile.cpp already names them, and its jpn offset shows the struct differs between versions, so the offsets in the header hold for usa only. func_02011584 becomes GetWorldData, after the name Zone3D and ZoneFeatures already give its result. Both now call it and drop their jpn defines, so the jpn symbol is renamed to match.
Seven status effects, each with a test, an apply and a clear. Their offsets name statusFlags and the two byte arrays behind it in CombatantStruct.
Fifteen more: three status triples, and two mutually exclusive states that each clear the other. Adds stateFlags at 0x18 to CombatantStruct.
Seventeen more, including four states that clear their opposite by tail calling it. statusDurations and statusCounters are two 0x23-byte arrays.
Resolves the file's offsets, scales the bounding box by the header's shift, and derives the cell count as gridX * gridZ + gridZ / 2.
Moss255
force-pushed
the
zone-struct-accessors
branch
from
September 8, 2026 05:24
c2f1025 to
c5822b6
Compare
Collaborator
|
The collision mesh identification is a good find, as is the mapping out of BattleStruct. Some notational things:
As for BattleStruct and CombatantStatus functions, there's generally not much use in decomping simple functions that handle individual variables until we know what they're for. Could I ask you to try and identify these? If you're using LLM tools for this, this part is best done by hand - set some breakpoints in DeSmuME / open the memory viewer to the relevant address, get into a battle and poison/confuse/sleep an enemy (or fight an enemy that can do this to you) and see what fires/which bits/bytes change |
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rebased onto
zone3d-experimental. Stacked on #17 — the first commit is that PR; review it there.dsd check modulesanddsd check symbolsboth pass on every commit.Commits
c7c702c49f4e29BattleStructaccessors at0x020115186dc87eb0x020888400b87bd10x02088bf031b18f40x02088dd8c5822b6.col2collision mesh loaderStructs
The accessor clusters are mostly one-liners; the work was the structs their offsets define.
BattleStructnow reaches0x63e0. It was modelled to0x3ACwith aTODO: validate— that TODO is untouched, and the new padding is expressed relative tocombatantList, so if that array's size is ever corrected the padding must move with it. There's a comment saying so.CombatantStructgainsstatusFlags(0x14),stateFlags(0x18), andstatusDurations/statusCounters— two0x23-byte arrays lying back to back at0x5fand0x82. All were previously insidechar unk[0x132]; the total size is unchanged.Both are shared headers, so I re-verified every existing file that uses them still matches.
Changes made for this branch
0x02011644/0x02011650are left alone —GrottoNameDataFile.cppalready names themGetTreasureMapLanguageData/SetTreasureMapLanguageDataPtr. Its jpn offset (0x6180against usa's0x63e0) shows the struct differs between versions, so the offset column inBattleList.his documented as usa-only.func_02011584becomesGetWorldData, after the nameZone3DandZoneFeaturesalready give its result. Both now call it by name and drop their jpn defines, so the jpn symbol is renamed to match (0x020112f4, size0xc).Notable findings
.col2, the header word at+0x04is a left shift applied to the bounding box, and the cell count isgridX * gridZ + gridZ / 2. The word at+0x00is tested, so it is a version rather than a constant.Caveats
GetWorldDataand the zone predicates are renamed in the jpn symbol table because files delinked for jpn now reference them; those addresses were matched by size sequence, but I have no JPN ROM to verify a build against. Happy to add full jpn entries if someone can check them.INFERREDwith the evidence.clang-formatpre-commit hook:.clang-formatisBasedOnStyle: LLVMwithIndentExternBlock: NoIndent, which produces unindentedextern "C" {andvoid *x, while every committed file uses indented blocks andvoid* x. Running it rewrote 139 lines of a file where my change is 8. New code follows the surrounding style instead. Probably worth a separate issue — the config and the codebase disagree.