[TF2] Fix attachments on dropped weapons having broken textures for certain war paints / skins

[Piogre]

Dropped weapons that have attachments on them can have broken textures on the attachments if the weapons are Decorated/War Painted with skins that use "material_override" -- including War Paints using the Macaw Masked materials (colloquially referred to as "albedo tint" skins). The override gets applied to the attachments when the weapon is dropped on death, causing the textures to break.

This fixes that issue for dropped weapons.

This issue appears most prominently for festivizers on weapons with these skins, but also breaks the pilot lights on flamethrowers, and the screens on rescue rangers.

Tangentially, this fix removes the only obstacle to adding festivizer support to the Golden Wrench (which also uses material_override to apply its unique skin) -- this bug is the only reason the Golden Wrench wasn't in the "easy adds" pile for festivizers so with this fix it can be implemented in its items_game definition ("169") with the standard "can_be_festivized" tag and "attached_models_festive" block in the visuals section (models/weapons/c_models/c_wrench/c_wrench_festivizer.mdl can be reused for this with no changes)

(re-make of pull 1845, requested merge of wrong source branch, no functional change)

[Voids29]

Hi @Piogre,
I wanted to ask if you (or anyone else) think a similar override-prevention / proxy-respect fix could help with/look into this somewhat related material proxy inconsistency in TF2 warpaint handling:
Issue 6961

In short: when the WeaponSkin material proxy is deliberately not present in a .vmt (to prevent warpaint texture replacement on certain model parts), some war paints (e.g. Yeti Coated, Dragon Slayer, Coffin Nail, etc.) still override the $basetexture anyway — while others (like Autumn Mk.II) respect the absence correctly.
This breaks custom models / item viewmodels where modders want control over which sub-parts accept warpaint tint/albedo overrides.
Your dropped-weapon fix is specifically about attachments + material_override war paints, so it's not exactly the same code path — but both issues involve inconsistent application of warpaint material overrides when the engine should be respecting certain flags/settings.
Do you know if:

• the same kind of override suppression (or an equivalent check) could be applied earlier in the WeaponSkin proxy / warpaint material resolution logic?
• this PR's change already helps part of the #6961 behavior as a side-effect (e.g. on dropped weapons)?
• or if the root cause is completely separate?

[Piogre]

Hi @Piogre, I wanted to ask if you (or anyone else) think a similar override-prevention / proxy-respect fix could help with/look into this somewhat related material proxy inconsistency in TF2 warpaint handling: Issue 6961

snip

This PR will not fix this issue. Addressing this issue would require a significant overhaul of a major element of the War Paint system (and the material system in general.

The reason those war paints do not respect the absence of WeaponSkin material proxy in VMTs is because those VMTs are entirely ignored for those war paints; the "material_override" tag causes the renderer to NOT load the usual material, but instead load a different material. Unlike the war paints that respect the proxy (which use the normal VMT and just swap out the base texture using the proxy), war paints like Macaw Masked et al replace the loaded material with a different loaded material, which has the weaponskin proxy on it already.

This PR and several bit already existing in the code can suspend material override on a model-by-model basis, but suspending material override for different materials within the same model (as you'd need for the issue you cited, as well as the "bazaar bargain" problem that was fixed with a bandaid solution instead, and the still-extant problems with the Loose Cannon / Iron Bomber / Detonator reloadable projectiles) isn't something I'm sure I can do with what's available. I believe I may need access to code deeper in the material system which I suspect isn't in the publically-available code. We do have a comment visible in a public header file we CAN see calling out this exact issue

TLDR I'm aware of that issue and it irks me for several reasons including some you don't mention in that issue description (including issues present in in-game vanilla weapons, not just custom models). This PR won't fix it, I don't think I can fix it in publically available code but if someone does know how to fix it it would be most welcome.