nosoop / SM-TFCustomWeaponsX

SourceMod plugin that allows players to use custom TF2 items.
GNU General Public License v3.0
22 stars 11 forks source link

Add the ability to replace the attributes of a weapon when you're using it as a CW base #63

Open yumm-dev opened 1 month ago

yumm-dev commented 1 month ago

There doesn't seem to currently be a way to remove or replace the attributes of a weapon when you're using it as a base for a custom weapon. For instance, if I wanted to use the Postal Pummeler as a base for a weapon, I would have to work with the attributes that base comes with instead of the base stats of said weapon, such as the Fire Axe. The current 'solution' is to use a CAF plugin that allows replacing the model of the Fire Axe to the Postal Pummeler, however that has its own issues (such as weird inspect animations, or mismatching kill icons). It would be quite nice if there was something that allowed you to choose whether to keep the attributes from the base item or not, say it being something like "maintain base attributes" as an option.

nosoop commented 1 month ago

There is. It's all compromises.

The built-in option is to set keep_static_attrs to 0. By default it's set to 1, which determines if the inherited item definition also uses the attributes from the schema (the static attributes is what you're describing). Unfortunately, because Valve decided to make minmode viewmodel positioning an attribute, setting it to 0 also disables minmode. There is no way around this since string attributes are not properly networked.

An alternative is to enumerate all the static attributes and override the runtime value to an identity value ("1" for value_is_percentage, "0" for value_is_additive, etc.). This does mean that you will see the attribute in the display panel, but functionally will not be applied. If I recall correctly, this is what #40 does automatically, but you can look over the attributes that are applied and manually replicate those in your configuration.

A third option (that would need to be developed) would be to do what keep_static_attrs = 0 does internally (set m_bOnlyIterateItemViewAttributes to 1), but via per-client sendproxy. This does require a third-party extension that was historically a pain to find the correct build for (as there's half a dozen different releases of varying age and APIs). It also has a performance impact due to the API design (is it significant? unsure).

Fourth option. I believe this has a bigger performance impact than option 3 since it runs on every attribute query (though I don't recall off the top of my head whether or not this happens before memoization).