Passengers can be shot through the sides of some infantry vehicles

[Matt Hands]

Bullets can pass through the sides of some vehicles and injure or kill passengers.

This is NOT a new bug. Apparent in DH 5.1 and presumably every earlier version.

Probably would have appeared in RO, except that RO makes vehicle passengers invulnerable to all damage (damage modifier of zero).

[Matt Hands]

Suspect culprit on the M3 halftrack is the collision static mesh, which has no 'thickness' in most of the side panels. It's 2D flat panels.

Have made a new collision mesh, properly 3D. Took the opportunity to simplify a little as well, without spending too long on it. Testing.

[Matt Hands]

Culprit is not the collision static mesh, or at least it may be a factor, not not the main problem. Problem affects other vehicles too, although M3 HT is the most obvious example.

Will post fuller explanation later, but the culprit is mostly the native RO function HitPointTrace(), which gives unreliable results that can have serious consequences. As a complicating factor, calling Trace functions on another actor (e.g. Instigator.HitPointTrace in bullet classes) can also give incorrect results, as any Trace uses the collision properties of the other actor and not the projectile collision.

Have just about figured it all out and can work around this. Can't fix failings of the function directly as it's native, but have found ways to solve the problem. Should get it committed tomorrow (Sat) morning.

[Matt Hands]

Have tested fix. Sorry for delay in getting ti checked out & committed. Before the weekend.

[Colin Basnett]

Fixed in revision 645.

[Matt Hands]

This is still an problem & needs code fixes in both bullet's ProcessTouch() and in its pre-launch trace system. Finished; about to commit.

[Matt Hands]

An explanation of this problem:

First, it occurs in single player & isn't a net issue.

It's mostly about HitPointTrace (HPT), which is an RO native function that seems to have some significant flaws, although we can't see what's going on. It's useful for tracing hits on a player pawn. Compared to a normal trace, it detects hits on player pawns that have no collision, such as vehicle occupants, and it returns the body part location of any hit. So it has a place, but we have to understand its limitations & failings and I've spent time investigating this.

HPT *may* return another 'intervening' actor if the trace would otherwise reach a player or maybe a player's bullet whip attachment. But sometimes it ignores an intervening, blocking actor, including the side or rear of a half-track (especially the M3), hitting players who should have been protected. Seems worse when there are multiple players in the vehicle (maybe being confused by overlapping whip attachments).

So some kind of 2nd trace verification is needed.

Problem can occur in both the bullet's ProcessTouch (PT) function, or in it's pre-launch trace (PLT) for close actors, both of which use HPT. Both need a similar 2nd, verification trace to see if another blocking actor was in the way of an apparent hit on a player pawn.

Another problem is that both PT the PLT use the bullet's Instigator pawn (the firing player) to do the trace. PT does this because the HPT works better that way, as it seems to ignore the actor it is called on, as well as that player's bullet whip attachment, which is good - we don't want to check for hits on ourselves. And PLTdoes that because PLT is in the WeaponFire class, which isn't an actor and so can't use Actor trace functions.

So sound reasons to use the Instigator to trace, but the problem is that any trace uses the collision settings of the actor it's called on. And while projectiles bUseCollisionStaticMesh, player pawns like the Instigator do not. So a trace from the Instigator ignores vehicle's detailed collision static meshes and instead trace hits against crude collision boxes.

[Matt Hands]

Commit 8df9553 fixes the DH bullet half of the problem. Does not fix the similar problems caused by pre-launch trace, which will be committed separately.

A spawned bullet's ProcessTouch() function, which is called when the bullet collides with a player's surrounding bullet whip attachment, now runs a 2nd verification trace to make sure there isn't a blocking actor in the way, including a part of the vehicle. This 2nd trace is a TraceActors iteration, allowing it to ignore any invalid traced actors (any that ProcessTouch would normally ignore) and continue tracing. Although it's a foreach iteration, it's very fast as TraceActors is a fast iteration, like any trace, and it's a one-off, on demand usage, with a trace over a very short distance, which exits if it hits any blocker.

Also fixes problem where trace was ignoring vehicle's collision static mesh, by temporarily changing the Instigator's collision settings to bUseCollisionStaticMesh. Again, this is only for the DHBullet half of the problem. Instigator is reset to its default bUseCollisionStaticMesh setting as soon as the traces are done, so it's only for a split second. And that is harmless anyway, because if we set a player pawn to bUseCollisionStaticMesh, all that means is it has more complex collision detection with vehicles, i.e. the player's feet would follow the hull's shape more closely when standing on the vehicle, rather than simply standing on the crude collision box.

[Matt Hands]

Commit c438a0b fixes the remaining pre-launch trace (PLT) part of the problem.

Essentially the same fixes for DHProjectileFire's PLT system as for DHBullet's ProcessTouch() function. PLT now does 2nd verification trace if HitPointTrace says we hit a player pawn. PLT now also temporarily makes the Instigator pawn use vehicle collision static meshes in its traces. PLT functionality is moved into new PreLaunchTrace() function, so SpawnProjectile() is shorter & easier to read.