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)
motionTypeFromText isn't part of physDefines: its "Keyframed" string (only used there) sits between the StaticCompound and PlayReport strings in .rodata, far from physDefines' enum text, and the function is linked right after the contact listener's inline virtuals, so it most likely starts a new TU at 0x7100fd069c. Nothing separates it from getMaterialMaskFromShape and the other helpers in physUtil, so it goes in the same file and its declaration moves to physUtil.h. That part is a guess: neither function has data that would show a boundary. (AI assisted using Claude Opus 5.5)
Most of these helpers have nothing to do with StaticCompound: they look up material masks and collision filter info from shapes and collidables. physUtil also fits the link order, between physUserTag and physWorld, and it's what the function groups already call this block. (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)
calc_ goes before leave_ in ForceSetCameraPos and InWaterSelForkASPlay, and RailRoute's dtor goes after getCheckPointName (an unnamed row there is likely its D0). BaseProcJobHandler's ctor is linked right before BaseProc's ctor, so it moves into actBaseProc.cpp, and the class moves into actBaseProc.h so that its declaration stays with its definition. (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)
These objects are linked in case-insensitive file name order, but the lists kept renamed files at their old positions, so the decomp linked them out of order. (AI assisted using 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)