- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 754
- Reaction score
- 457
Anyone still grinding on legacy CoD knows that FastFile (.ff) replacements are a bloated way to handle custom assets. Real development happens in memory. If you're hooking BO1 on the 360 (specifically TU11), you've likely realized that applying shaders to the lobby background is easy, but weapon camos require a bit more finesse within the player and weapon structs.
TU11 Engine Offsets & Functions
Based on current research, here are the verified entry points for TU11 memory writes:
The Data Structure
For those digging into the g_entities array, the current consensus for the weapon material/camo offset is 0x1C8. The struct size for TU11 entities appears to be 0x2E0. If you are calculating the offset from the base of the playerState_s (0x82F00000), keep in mind that entity indices can shift depending on the slot you're occupying.
Weapon Camo Injection Logic
If you're building a .xex plugin to handle this, your application loop needs to iterate through the entities to ensure the material index is held. If IDA is closing on you during the search, the problem is likely your debugger setup—ensure you're not hitting a heartbeat or memory protection check.
If you're still hitting VRAM crashes or looking at white textures, check if you're attempting to register the material after the game has already peaked its asset count for the current map.
Anyone verified the 0x1C8 offset on a clean TU11 dump recently?
TU11 Engine Offsets & Functions
Based on current research, here are the verified entry points for TU11 memory writes:
- GEntity Base: 0x82C32558
- G_MaterialIndex: 0x822BD9E0
- G_GetWeaponIndexForName: 0x822C3E60
- Cbuf_AddText: 0x8230FD58
- Material_RegisterHandle: 0x82585308 (Alternative seen at 0x823E1D48)
The Data Structure
For those digging into the g_entities array, the current consensus for the weapon material/camo offset is 0x1C8. The struct size for TU11 entities appears to be 0x2E0. If you are calculating the offset from the base of the playerState_s (0x82F00000), keep in mind that entity indices can shift depending on the slot you're occupying.
Applying a shader ID to the offset via WPM or a direct pointer write will often crash the renderer if that material hasn't been precached into the active asset pool. Simply calling Material_RegisterHandle on track 7 (World) isn't a silver bullet. You may need to force a precache via the command buffer before the weapon model is initialized.
Weapon Camo Injection Logic
If you're building a .xex plugin to handle this, your application loop needs to iterate through the entities to ensure the material index is held. If IDA is closing on you during the search, the problem is likely your debugger setup—ensure you're not hitting a heartbeat or memory protection check.
Code:
void(*Cbuf_AddText)(int localClientNum, const char *text) = (void(*)(int, const char *))0x8230FD58;
void*(*Material_RegisterHandle)(const char *name, int imageTrack) = (void*(*)(const char *, int))0x82585308;
int(*G_MaterialIndex)(const char* name) = (int(*)(const char*))0x822BD9E0;
void ApplyCamo(const char* shader) {
int shaderID = G_MaterialIndex(shader);
// Iterating through entities to apply the material index
if (shaderID > 0) {
for (int i = 0; i < 18; i++) {
*(int*)((0x82C32558 + (i * 0x2E0)) + 0x1C8) = shaderID;
}
}
}
If you're still hitting VRAM crashes or looking at white textures, check if you're attempting to register the material after the game has already peaked its asset count for the current map.
Anyone verified the 0x1C8 offset on a clean TU11 dump recently?