A matcher had put library, Super Mario Odyssey and Splatoon symbols on
functions whose bodies only looked similar, often on game code. Those
names were just wrong.
Rows with other evidence (vtable slots, enum tables, TU placement or
what the function actually does) now get the IDB's name, with a Maybe
suffix where part of it is still a guess; two of them now match.
The rest are blanked.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
The 8-byte function only masks the bool argument and branches to the
body right after it, so the body is tryCreateDualHeap and the wrapper is
createDualHeap (name from the IDB). GameData calls the wrapper, so it
now calls createDualHeap.
(AI assisted using Claude Opus 5.5)
Some names sat on the wrong body, e.g. increaseFlag_* functions that
differ only by a string literal (which tools/check can't see) and
FixedSafeString operator= rows with the wrong size. These rows now take
the IDB's name, which comes from flag strings, vtable slots,
FixedSafeString sizes and Super Mario Odyssey, Labo and Splatoon 2
symbols; a few are blanked.
O/M/W statuses that belonged to another function are dropped, and some
rows that now have the right name are marked O.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
These rows had no name, a placeholder or a misspelt class name (e.g.
forceSetCameraPos) even though the decomp already had the function, so
nothing counted or checked them. They now carry the source's name and
are marked O or M.
Also adds the missing row for sead's decodeSZSNxAsm64_.
(AI assisted using Claude Opus 5.5)
They're linked before gameStageInfo.cpp's sinit with no other sinit
in between, so they belong to gameStageInfo, not gameScene, and become
StageInfo statics declared in gameStageInfo.h. Their GameScene owner
was a guess.
(AI assisted using Claude Opus 5.5)
calcHash is linked between AwarenessInstance's sinit and the next one,
together with two AwarenessSourcePool helpers and the job queue
functions of Awareness::Unk1, so it's a shared helper rather than an
Awareness member, declared in the new file's own header.
actAwareness.cpp calls this 4-byte function out of line, so it's likely
not defined there. The file name sorts between actAwarenessInstance and
the sensor files, which is where it is linked.
(AI assisted using Claude Opus 5.5)
Each base class virtual is named after what its overrides do and how
callers use it, e.g. AttCheck::calcMtx (0x710108a614) is the virtual
that AttClient calls before testing its checks.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
Each file moves to where its code is linked, and namespaces follow the
new paths. ASSettingMgr is an unofficial name.
| Old | New |
|---|---|
| act::ASSetting (ActorSystem/actASSetting) | res::ASSettingMgr (Resource/Actor/resResourceASSettingMgr) |
| Resource/resResourceASSetting, Resource/Actor/resResourceASResourceExtension | Resource/Actor/resResourceASSetting |
| ksys::DebugFinder (System/DebugFinder) | ksys::act::DebugFinder (ActorSystem/actDebugFinder) |
| ActorSystem/LOD/actLodState | ActorSystem/actLodState |
| ActorSystem/actAiRoot | ActorSystem/aiRootAi |
| Map/mapStagePreActorCache | System/StagePreActorCache (ksys) |
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
A folder's files are linked before its subfolders, and the rigid body
files are linked as one flat sequence. ListShape is the one file that
does not fit this order.
| Old | New |
|---|---|
| RigidBody/Shape/<Kind>/phys<Kind>Shape.cpp | RigidBody/Shape/phys<Kind>Shape.cpp |
| RigidBody/Shape/<Kind>/phys<Kind>RigidBody.cpp | RigidBody/physRigidBody<Kind>.cpp |
| RigidBody/Shape/List/physListShapeRigidBody.cpp | RigidBody/physRigidBodyListShape.cpp |
| physHavokMemoryAllocator.cpp | System/physHavokMemoryAllocator.cpp |
| StaticCompound/physStaticCompound{,Mgr,RigidBodyGroup,Util}.cpp | System/ |
| StaticCompound/physStaticCompound{Info,Autogen}.cpp | System/physStaticCompoundInfo.cpp |
The original has the type infos' cleanup functions just before
StaticCompoundInfo's functions, so the merged file defines the
reflection data first, with plain static cleanup functions as in
Havok's generated reflection code. Template instantiations would be
emitted after the rest of the file.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
Rename classes and files so that they sort where their code is linked,
and move code that is linked inside another TU into that TU's file.
| Old | New | TU start |
|---|---|---|
| ActorAreaInOutSendMessage | AreaInOutSendMessage | 0x710009fa64 |
| AreaTagAction | AreaActionBase | 0x7100e21e64 |
| sndResource.{h,cpp} | sndSound.{h,cpp} | |
| Code | From | To |
|---|---|---|
| SoundMgr | sndMgr.h | sndSound.h |
| PlayReport | PlayReportMgr.cpp | PlayReport.cpp |
| PlayReport::addPlayTimes, addPosition | PlayReportMgr.cpp | ProductReporter.cpp |
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
DamageManagerBase's root base class (previously
DamageManagerBase_UnknownBase1) holds the damage callback list, and its
code is linked among the ActorSystem objects rather than with the
Game/Actor/Damage files. It appears to be an engine-side abstract base,
so let's move it to KingSystem/ActorSystem as ksys::act::IDamageManager
(unofficial name, following the ksys IManager/Manager pattern and
Actor::getDamageMgr), together with DamageCallback and Struct20Base, and
have Actor::getDamageMgr return it. DamageManagerBase now overrides its
getters and inherits addDamageCallback/removeDamageCallback from it.
The rest of the damage code stays in Game/Actor/Damage but is regrouped
to match link order: Struct20::combineMaybe moves into
actDamageManagerBase.cpp, Struct20::reset becomes inline and
dmgStruct20.cpp becomes actDamageMgr.cpp. The uking::dmg namespace is
merged into uking::act, so the files there take the act prefix too, and
dmgInfoManager becomes actDamageInfoMgr after the class it holds.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
The 0x18-sized accessor appears to be named ActorLinkConstDataAccess
based on a source path string in the Wii U build. The 0x10-sized
base class (which we had given the name to) only holds a BaseProc and
its dtor/acquire functions live in a separate TU so let's rename it
BaseProcAccessor (unofficial name).
acquireActor is a header inline whose one copy landed in the BeamBase
object. Nothing in BeamBase calls it, so the BeamBase function that used
it was probably dead-stripped by the linker.
(AI assisted using Claude Opus 5.5)
ActorFactory's static initialiser fills its table with uking actor
ctors. CurrentResNameMgr (0x71010b770c) links in KingSystem/System right
before GameConfig.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
They link in the same block as the plain-ksys:: Message family.
getItemValue and applyScreenFade sit in engine UI TUs, hence ksys::ui.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
They form one run in the ActorSystem block (DemoRootAI at 0x7100d61e68,
right after VillagerMgr).
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
Both link in the game archive, and NXArgs uses game classes such as
GameScene. The engine only calls SystemPauseMgr's virtuals, so it now
goes through ksys::ISystemPauseMgr and no longer includes Game/.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
aoc::Manager is created during engine start-up and called by gdt, map
and StarterPackMgr; only game code uses HardModeManager and
ChampionBalladManager.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
It is created only from game code, no engine code calls it, and it
hardcodes game actor names.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
setCamera's only caller passes the camera actor, a ksys::act::Actor;
ksys::act::Camera is only forward-declared.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
Every decomp user of PlayerInfo is game code, and PlayerBase sits right
above Player. GameConfig.h models the engine base that
links at GameConfig's slot in KingSystem/System.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
The action factory uses the single ksys ctor for both entries and
DummyDropTable's ctor calls it too; deriving from it makes
DummyDropTable's five functions match.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
They link with KingSystem/Sound (0x7100fe8b54-0x7101060ed4) as sorted
Action/AI passes of their own. The three area tag actions keep their
game base AreaTagAction, which links in the Game/Actor/Area block.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
Keeps source and CSV from drifting from the IDB. Names are read from the
bodies, e.g. ActionBase::applyParams is what all 13 non-stub overrides
of that slot do.
(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)
* world: implement Manager::isRaining
Implement the position-based rain check for Rain, HeavyRain, ThunderRain,
and BlueskyRain. Declare the climate weather lookup dependency and name
both functions in the function table.
The rain check matches the original function at 0x71010f33a4.
* world: keep rainfall queries const
Restore const on Manager::isRaining and make its climate weather helper
const. Both queries only read Manager state. Update their function-table
symbols; the rain check still matches the original.
It logs nothing: it queues flag increments per core and
GameDataMgr::calc0 applies them once per frame. The IDB already uses
this name.
(AI assisted using Claude Opus 5.5)
Each pair differs only in the vtable it installs or slot it fills, which
tools/check ignores. E.g. 0x7100b15bf4 installs FileDeviceReadStream's
vtable, and the ASAssetResource/ASAssetExResource D0 rows were swapped.
(AI assisted using Claude Opus 5.5)
The flag is "AoC_HardMode_Enabled", as 0x71008e3dbc returns; tools/check
ignores string literals, so the misspelling still matched.
(AI assisted using Claude Opus 5.5)
Léo Lam