[Investigating - Don't merge] Bullet visuals, better pen, shotgun debuff

[AdamTadeusz]

Description

A toggle to draw the path bullets take

cl_neo_bullet_trace 1 to see where bullets are going
cl_neo_bullet_trace_max_pen controls the colour of the bullet trace. The closer a bullet's pen is to this value the more red it will be. The further away it is, the more yellow it will be

Fixes a problem with bullet penetration where if multiple thin materials were stacked closely together, some could be missed completely by the bullet as it would continue along its trajectory further ahead. Also now when a player entity is hit by a bullet, it is added to an ignore filter, so that bullet can never hit that player entity again.

Also changes how shotguns pellets work, so all pellets are now tracelines that effectively have no width and can only hit whatever is directly in front of them, as opposed to the previous behaviour where half of the pellets behaved like a cube 6hu6hu6hu large, which are much more likely to hit something.

Toolchain

• Windows MSVC VS2022
• Linux GCC Distro Native [Specify distro + GCC version]
• Linux GCC 10 Sniper 3.0

Linked Issues

[brysondev]

idk if we care enough about #endif's // NEO that are only a few lines but I nit marked a few that were more spaced out.

[Rainyan]

This might be somewhat unrelated, but it appears the FireBullets is sometimes called multiple times for a single gunshot:

All 3 bullet holes in this screenshot were from 3 different mouse clicks, but for some reason the middle one has 4 traces on it (but expected to see only 1). This multiple-lines-rendering behaviour seems to also happen quite often if you shoot in the far distance with the SRS.

[AdamTadeusz]

This might be somewhat unrelated, but it appears the FireBullets is sometimes called multiple times for a single gunshot:

All 3 bullet holes in this screenshot were from 3 different mouse clicks, but for some reason the middle one has 4 traces on it. This multiple lines rendering seems to also happen quite often if you shoot in the far distance with the SRS.

I did make a change so that the firing of penetrating bullets is done on both client AND server. This is different to the original functionality of bullets penetrating glass for example (which is the only material that has penetration in the base sdk) where the initial bullet is fired by both client and server, but the bullet fired behind glass is only done on the server, which meant no bullet impacts were being drawn on the second wall that the penetrating bullet hit. I did some testing firing a bullet only client side and not server side and observer no actual damage being done to the player, but I will look into it again.

Also if this is only with the srs then it probably is something unrelated.

[Rainyan]

Also if this is only with the srs then it probably is something unrelated.

This particular screenshot above is from 3 bullets from with the Tachi in semi-auto mode, to produce the 3 different bullet visible holes in the wall. I saw this happening with both the SRS and the Tachi, but I don't think it's specific to a particular gun (I didn't test all the guns). For whatever reason, shooting the SRS down the long end of the dimensions test map seemed to reproduce it the most often, but could be inconsequential.

[AdamTadeusz]

Also if this is only with the srs then it probably is something unrelated.

This particular screenshot above is from 3 bullets from with the Tachi in semi-auto mode, to produce the 3 different bullet visible holes in the wall. I saw this happening with both the SRS and the Tachi, but I don't think it's specific to a particular gun (I didn't test all the guns). For whatever reason, shooting the SRS down the long end of the dimensions test map seemed to reproduce it the most often, but could be inconsequential.

seems that the value of m_flNextPrimaryAttack is being reset, so itemPostFrame triggers PrimaryAttack() again. Removing the piece of code right above PrimaryAttack() in neobasecombatweapon::ItemPostFrame that does exactly that somehow only seems to make the problem worse. I don't think this PR is to blame, probably we're missing some m_flNextPrimaryAttack = max(m_flNextPrimaryAttack, calculated_m_flNextPrimaryAttack)