Non-stock weapons (such as TFA weapons) do not render their base viewmodels

[nike4613]

Your version of TTT2 (mandatory)

v0.13.0b (both workshop and git)

Describe the bug (mandatory)

Non-stock weapons do not render their base viewmodels by default. This appears to be due to #1342 being opt-in to rendering the base viewmodel rather than opt-out. Any weapons which are not aware of this property will not render correctly.

This can be fairly simply fixed by setting that property to true on any weapon which does not have it set.

To reproduce

Steps to reproduce the behaviour:

1. Install some custom weaponry
2. Enable it in TTT (through whatever means)
3. Pick up that weapon

Expected behaviour

The viewmodels render.

Context (please provide as much as you can)

Mostly the same as #1411.

Screenshots

[TimGoll]

It is not opt-in though. If the weapon is based on the TTT2 base, the value is automatically set to true:

https://github.com/TTT-2/TTT2/blob/master/gamemodes/terrortown/entities/weapons/weapon_tttbase.lua#L94

So I guess TFA doesn't use the TTT2 weapon base?

[nike4613]

Yes, that is correct. TFA does implement a number of methods that are required for TTT weapons though. I would expect that this property either default-true if type(tbl.ShowDefaultViewModel) == "nil", or that the render prevention be disabled for non TTT-derived weapons.

[Histalek]

IMO we should definitely prevent this unexpected breakage; unexpected because TFA weapons don't do hacky render stuff with the Viewmodel.

I would be fine with default-true in the nil case. Given that the idea was to give weapons an easy way to prevent the rendering of the default viewmodel.

I don't think we should cripple weapons that go out of their way to have TTT compatibility while not using the weapon_tttbase for whatever reason.

WDYT @TimGoll ?

[TimGoll]

I can prevent this issue by explictily checking for false instead of if not xyz. I think that is the best solution here

[nike4613]

Can confirm, 0e8e177 fixes this issue.

[TimGoll]

Can confirm, 0e8e177 fixes this issue.

Awesome, thanks for testing