Guide [Crash] Day of Defeat — DrawModelExecute DME Hook Stability Issues

[byte_corvus]

Anyone still messing with the Source engine knows that DrawModelExecute (DME) is a fickle beast. One wrong check and you're staring at a desktop instead of a capture point. Recently ran into a specific crash where the game would dump to desktop during the loading screen if the cheat was already injected, but worked fine if injected mid-game.

The debugger flagged a recursive nightmare — basically memory calling itself until the stack gave up. This usually points to a hook logic error or accessing entity data before it's fully initialized by the engine's object system.

Spoiler: Technical Breakdown of the Hook Logic

Checking out the implementation of the detour. The hook follows a standard VTable detour pattern for IVModelRender:

void __fastcall ModelRender::DrawModelExecute::Detour(void* __this, void* ecx, const DrawModelState_t& state, const ModelRenderInfo_t& pInfo, matrix3x4_t* pCustomBoneToWorld)
{
 FN o = VTable.Original<FN>(index);
 if (!o)
  return;

 bool didDraw = false;
 C_DODPlayer* plr = I::EntityList->GetClientEntity(I::EngineClient->GetLocalPlayer())->Cast<C_DODPlayer*>();
 C_DODPlayer* otherPlr = I::EntityList->GetClientEntity(pInfo.entity_index)->Cast<C_DODPlayer*>();

 if (I::EngineClient->IsInGame() && I::EngineClient->IsConnected() && pInfo.pRenderable && pInfo.pModel && pInfo.entity_index)
 {
  IClientEntity* ent = I::EntityList->GetClientEntity(pInfo.entity_index);
  if (ent)
  {
   ClientClass* pCC = ent->GetClientClass();
   if (pCC)
   {
    ChamItem* cham = 0;
    // Class ID Switching Logic
    switch (pCC->m_ClassID)
    {
      case EClientClass::CDODPlayer: 
        cham = &Hacks::Visuals::Chams.Enemies; 
        break;
      case EClientClass::CDODRagdoll: 
        didDraw = true; 
        cham = &Hacks::Visuals::Chams.Ragdoll; 
        break;
      // ... additional cases ...
    }
   }
  }
 }
 if(!didDraw)
  o(__this, ecx, state, pInfo, pCustomBoneToWorld);
}

The Culprit

The instability was narrowed down to this specific check within the default case of the switch:

if (U::Game.IsClassWeapon(pCC->m_ClassID))
{
    didDraw = true;
    cham = &Hacks::Visuals::Chams.Weapons;
}

It seems that calling IsClassWeapon or performing class ID comparisons on certain entities while the engine is still populating the entity list (joining a server with active players) causes a pointer violation or an infinite loop when the renderer tries to draw those models. Removing this check or making it more robust against null ClientClass pointers seems to stop the load-time BSOD/crash.

Stability Checklist for Source DME Hooks

1. Always verify pInfo.entity_index is within valid ranges before casting.
2. Check if pInfo.pModel or pInfo.pRenderable are null before accessing members.
3. Ensure your material overrides (ForcedMaterialOverride) are properly cleared with nullptr to prevent engine state corruption.
4. Avoid heavy logic inside DME detours; the renderer calls this thousands of times per frame.

If you're seeing memory "calling itself" in the debugger, double-check your recursion. If you call the original function inside your detour without clearing your material state or if your logic triggers another render call, you're going to have a bad time.

Anyone else found a cleaner way to filter weapon class IDs in DoD Source without hitting these edge-case crashes?