| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
The forced SetColorModulation/SetAlphaModulation calls before DrawModel are
what turned matched props into the error material and destabilised the
material system. Mirror Amalgam instead: set a "drawing a prop" flag around
the original draw and only substitute the colour when the engine itself calls
SetColorModulation during that draw. Log those calls for the first few draws
to see whether the engine applies modulation inside DrawModel at all.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Hooking IStudioRender's draw/setter slots made matched props render the error
material and then crashed the material system ("debug/modelstats has bad
reference count 0 when being bound"). Keep the hook code for reference but do
not install it.
Fix the m_clrRender netvar resolution: the walk picked an embedded table entry
at offset 0, so the earlier entity writes stomped entity vtables. Only accept
offsets inside C_BaseEntity (0x20..0x2000), then write the prop colour there
for models/props entities. Restore white when disabled.
|
| |
|
|
|
|
|
|
| |
studiohdr_t::name is not "models/props/...". In this build it is the short
model name with Windows separators, e.g. "props_junk\wood_crate002a.mdl"
(the models/ prefix is stripped). Normalise the prefix/separators and match
props/, props\ and props_ (excluding the distant props_skybox set), so the
studio hooks actually recognise prop draws.
|
| |
|
|
|
|
|
| |
Log the first crate materials the tint pass modifies and the first DrawModel/
DrawModelArray calls with their model names, to see whether the crates are
brush materials that were never reached, materials loaded after the tint was
applied, or a studio draw path that is still missed.
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
|
