| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
m_clrRender resolved to offset 0 in this build; writing it stomped entity
vtables instead of tinting anything. Remove that path.
The static-prop logging showed DrawModelStaticProp is never called for these
props, so hook the other studio draw entries as well: DrawModel (29) for
entity models and DrawModelArray (46, the instanced static-prop path). Both
read the model name from DrawModelInfo_t::m_pStudioHdr and force the prop
colour for models/props* draws.
|
| |
|
|
|
|
|
|
|
| |
Static props commonly use brush-style props/... materials
(props/woodcrate001a is LightmappedGeneric), so the models/props-only filter
missed them. Include the props/ prefix.
Also log the first static prop studio draws and a 500-draw summary so we can
see whether the engine draws props through DrawModelStaticProp at all.
|
|
|
Most of the crates are prop_static, which have no client entity, so writing
m_clrRender only reached the three dynamic ones. Hook the StudioRender
interface (VStudioRender025) on the interface object's vtable: substitute the
prop colour in SetColorModulation/SetAlphaModulation while
DrawModelStaticProp is drawing a models/props model, and set the modulation
explicitly before the original draw in case the engine sets it just before the
call.
Vtable indices verified by disassembling CStudioRenderContext: 27 = three
float stores from the argument pointer, 28 = one float, 30 = the
DrawModelInfo_t-drawing entry with three arguments (the 2013 SDK header lists
these slots five positions earlier in this build).
|
