Client effects (e.g. shell impact/explosions) sometimes aren't spawned for a player in a vehicle

[Matt Hands]

Before clientside effects are spawned, EffectIsRelevant() is often checked. This function is very bugged for any 3rd party net players in any vehicle. It's another old bug, this time from UT2004. It often results in vehicle players missing effects that should clearly be relevant, e.g. 30m in front of the vehicle.

[Matt Hands]

EIR is really only relevant for a non-owning net player. It always returns false for a dedicated server and true in single player or a listen server. The owning net player, e.g. the one that fired a shell that has exploded and is spawning effects, gets true, so the effects are spawned.

The main checks for other net players are a calc to see whether the effects would be in broadly front of the player and so may be drawn on their screen, followed by a distance check. If the effect is in front of the player, the distance check will be a relatively long distance mostly based on level fog settings. But if it is to the side or rear, EIR only returns true if it's within 26m. Makes sense, but ......

The 1st check, to see whether the effect would be in front of the player, is a dot product calc using the PlayerController's rotation and the effect's SpawnLocation. The problem is that in any Vehicle (including VWPawns), the PC's rotation bay be relative to the vehicle (bPCRelativeFPRotation=true), and in our game it nearly always is. EIR doesn't factor in the vehicle's rotation, so the 'in front' check is effectively randomised.

The fix is to check whether the player's pawn is a Vehicle using relative PC rotation and, if so, to factor in the vehicle's rotation. Gets a bit more complicated, as a VWPawn needs to factor in the rotation of its Gun or VehicleBase (either works), not its own rotation. And a turret pawn needs to also factor in the yaw of the turret's CurrentAim. But it's still a fairly simple block of code.

After identifying the cause of the problem and writing a fix for it, I searched for other uses of EIR, to find where the function will need to be overridden. I found an override in ROArtilleryShell, with this comment: "Overrides Actor::EffectIsRelevant() because that function wasn't working correctly in vehicles. TODO: Add code to make this check work correctly when in a vehicle so we don't have to skip it - Ramm". TWI came across the same problem, but didn't have the time to find the cause and realise that it affected a lot more than just arty shells. Their fix was a hack fix to skip the 'in front' check for any player in a vehicle.

[Colin Basnett]

Regarding this:

The 1st check, to see whether the effect would be in front of the player, is a dot product calc using the PlayerController's rotation and the effect's SpawnLocation. The problem is that in any Vehicle (including VWPawns), the PC's rotation bay be relative to the vehicle (bPCRelativeFPRotation=true), and in our game it nearly always is. EIR doesn't factor in the vehicle's rotation, so the 'in front' check is effectively randomised.

This bug is likely related to issue 476.

[Matt Hands]

Should be fixed in various classes in commit 4ae3837.

Added fixed function to all 5 DH base projectile classes (bullet, shell mortar shell, throwable explosive & arty shell).

Removed all played sounds from under EIR checks. Sound should play regardless of which direction the effect is in relation to the way the player is facing. Sounds reduce their volume according to distance anyway. EIR must only affect visual effects.

Added EIR checks to wherever clientside visual only effects are being spawned, so they don't spawn if out of a player's view, unless quite close. Includes EIR check in class DHBulletHitEffect so it always plays the impact sound but does an EIR check before spawning the impact effect. Made bullet the owner of the spawning DHBulletHitEffect, so that actor can use the bullet to run an EIR check.

One rare example of an exception, where EIR can't be used: can't do it for mortar projectile's firing effect, as that gets played in the projectile's begin play initialisation, at which point is hasn't been drawn on player's screen yet, so it fails EIR checks.

Still have to add something to DH_WaterVolume class, but am doing some work on that. Will add later, but almost irrelevant to this problem, so am closing this issue.