It is extremely difficult to kill some vehicle and gun occupants

[Colin Basnett]

Not sure what the cause of this is, would like to see it fixed, since many players have reported this bug to us. Pretty sure it exists in 5.1 as well.

[Matt Hands]

Possible/probable fix in commit 10cdbbe.

Have tried it with bots and with the LeaveBody() debugging function & hit detection seems to work perfectly - but of course needs true MP check. I am very excited - if this works it has far reaching consequences for player hit detection in vehicles !!

HT MG has no collision boxes. The pawn sets bKeepDriverAuxCollision=true in def props, meaning the player keeps their bullet whip attachment that will try to do an accurate HitPointTrace on different player body parts. That's great - if it works - because player pawn hit detection is far more sophisticated & accurate than the crude system used on most vehicles (collision box plus head & body HitPoint spheres traced in code). Player pawn hit detection has lots of different hit points for body parts and it automatically moves with the player's pose. But .... it produces very inconsistent results.

I knew that a VehicleWeapon with collision boxes then to screw it up, e.g. AT guns. While vehicle riders, with no collision box or weapon mesh, seem to work ok. The HT MG & similar MGs are in between, with a mesh but no col box, so I wondered if the mesh somehow screwed it up. Btw, the HitPoints for the head & torso on the HT MG are a mile off - easily fixed - but I was thinking they don't even matter, 'cos the MG has no col boxes & so a bullet isn't even going to register a hit on it & run a HitDriver() check. Instead the bullet should hit the whip attachment & then run an accurate HitPointTrace on the player pawn.

But having observed & logged it, the bullet was hitting the damned MG actor ! How? Answer (light bulb moment): in the absence of any col box in the VehWep's anim mesh, it appears to fall back to using the collision cylinder (height & radius) for collision detection. Where if the mesh has any col box, even I guess a single, tiny one a mile away, it appears to ditch the col cylinder & use the mesh's col box(es). "Show collision" in SP console only shows col boxes etc. But lesser known "Rend collision" shows col cylinders. And ANY VehWep collision appears to get in the way of the hit detection & tracing on the player pawn.

Problem with HT MG was combination of very small col cylinder being 'in play' & nowhere near the gunner (centred on the MG itself), so collision detected only around the MG and not usually anyway near the player, plus way off vehicle HitPoints for player's head & torso.

SOLUTION (I hope !): As MG has no gunshield or any other need for collision, simply disable all collision for the VehWep actor & remove VehHitPoints for head & torso. Then simply let bullets hit the whip attachment & trace hits on the player's body parts, exactly as if he were out of the vehicle. With no VehWep collision getting in the way, it seems to work. Have added bPlayerCollisionBoxMoves=true in def props, so server always plays animations, to put serverside gunner (collision) in correct place.

IMPLICATIONS: Higgins boat follows this automatically, can be applied to mortars I think, Bren carrier (although player generally inside hull colllision) & Marder MG. Not for StuG, StuH & German HT as have collision boxes for gunshields - similar with AT guns, although understanding the problem, it may be possible to work around it. But I think EVERY tank cannon can use this, with the annoying commander's col boxes removed from the top of turrets. I have done a demo on the Firefly & will upload. In general, think should also make server player any DriverTransitonAnims too, wherever detection is on pawn's body parts, e.g, collision follows movement when leaning, etc.

[Matt Hands]

Added Firefly turret demo in commit 25b9061. Needs SVN update for temp demo FIrefly turret mesh.

Demo turret mesh has had commander's collision box (above the turret) removed. VehHitPoints for com's head & torso are removed (all changes temporary & marked as TEST). No collision will be detected for the commander on the cannon actor, only hits on turret itself. So all normal commander hit detection functionality is bypassed. Instead retains player's bullet whip attachment and the same accurate body part hit detection as an infantry player pawn. No VehWep collision gets in the way.

Parts of the body inside the vehicle are theoretically vulnerable to small arms fire, but in practice the turret or hull collision intercepts bullets before they can reach the player pawn. Have tested only using the LeaveBody() debug function & that worked fine, i.e.; I could accurately shoot myself after leaving my body & re-spawning. But not tested with bots as they never unbutton.

[Matt Hands]

Further developed in commit a1ec1c8.

Previous demo worked in SP but not in MP. HT gunner could be shot by firing 2 feet above his head. And I think that if the HT was moved from original position, the gunner could no longer be shot - but he could be killed by shooting his original parked position(blood splats in mid air) !

That told me the problem was the server had the collision in a different position to the seemingly perfect collision points that were visible on the client's screen. I've encountered the same before, when figuring out how to attach a 50 cal VehWep onto another VehWep (M36 turret). There are 2 issues here and I think I have resolved both:

1. AttachDriver() function applied 2 positional offsets to the player's attachment position. But when it 1st sets the player's location, before making the bone attachment, it doesn't include those offsets. It only includes them later as a relative location, which only seems to operate on the client and not the server. Result is server collision has different offset to client, so the authoritative server hit collision differs from your screen. Simple 1 line override fixes this.

2. Vehicles and player pawns have bForceSkelUpdate=true in def props, but VehWeps do not. This bool makes the server update bone positions, which otherwise it doesn't appear to do as it isn't rendering the mesh.

Thinking about it, I wonder if the fix for (2) makes the fix for (1) unnecessary. As in, maybe the skeletal update will make the relative location effective serverside. Will try that later.

But .... I think this works now.

[Colin Basnett]

@AndrewTheel and I checked this out and, though it's not perfect, it is certainly much better than it was. I would be happy to call this bug resolved once it is applied to all the other relevant vehicles and guns (mortars, FlaK guns etc.)

[Matt Hands]

Great ! And I think it probably will be perfect - or at least as perfect as normal infantry pawn hit detection - when I make the server play the DriverTransitionAnim & possibly the initial DriveAnim, both of which move the player into the exact pose seen on screen.

Will need to modify anim files to remove/alter some collision. Very quick, simply job though.

Looks like it doesn't need both the mod to AttachDriver() AND bForceSkelUpdate. bForceSkelUpdate makes the unmodified AttachDriver() work fine, in terms of the server's positioning being aligned to the client. Although for static 'vehicles' like mortars & AT guns, just modifying AttachDriver)() is probably effective & a more efficient method (no need for serve to bForceSkelUpdate).

Been thinking about implications/uses and actually I think there are less restrictions than I originally imagined. Should be fine for all MGs & AT guns. 'Enveloping' Marder hull collision will prevent hit detection on commander & MGer body parts that are inside the hull collision box, but no more so than currently. Some AT gun shield collision will probably block hit detection on parts of the gunner, but I can see how the gun collision can easily be adjusted to remove that problem (gun shields will actually automatically work to block bullets too).

Freakin' awesome ! :)

[Matt Hands]

When I modify anim files to adjust collision boxes as necessary, I STRONGLY recommend that we remove the extra LOD meshes.

If you aren't familiar with LODs, the editor auto-generates 3 extra LOD meshes every time you import a mesh, with each mesh being less detailed, smaller in file size and designed to save rendering by using less detailed meshes at longer ranges. Logical but several overwhelming reasons to remove them:

1. In nearly every case they aren't even being used. Nearly all DH models override the normal LOD settings so the main mesh is the only one ever used (LODLevels[0].DistanceFactor set to 0, instead of default 1. This is reason enough, on its own !
2. They are utterly pointless for internal models, as those meshes are only ever viewed by the player in the vehicle at close range.
3. The auto-generated LOD meshes are utter garbage and you would never, ever want one to appear in game. There is a facility to import proper, reduced detail LOD meshes that have been made by a modeller, but we don't have any. Again, this is reason enough on its own.
4. Removing the meshes reduces file size by around 40%. And I'm pretty sure that when a specific mesh is loaded into memory (server as well as each client), it must load the whole mesh content, including LODs. So pretty sure we reduce the memory usage for every anim mesh in the level, helping to keep overall memory use down.

It's about an hours work for me, even if I do it very slowly & carefully. Will keep a backup copy of modified col mesh anim files, prior to removing LODs, but really that is paranoid backing up, nothing more. There really is no potential downside here. This is not what you could describe as a system change. I've talked through this with Theel before, but not I think with Basnett.

OK to proceed?

[Andrew Theel]

I concur. Only reason why I didn't do that so far is I forgot about it. I wouldn't really consider that a bug so I'll make a new task card on trello for you.

[Colin Basnett]

Sounds good to me.

[Matt Hands]

I'm on it today. I am on leave (from work) this week, but it's meant to be a sort of holiday, so I am juggling DH with real life stuff. Still, I have a more time than I normally would during the week.

[Colin Basnett]

Issue #169 was marked as a duplicate of this issue.

[Matt Hands]

Nearly done. Will finish tomorrow morning & upload.

[Matt Hands]

Every vehicle mesh edited & committed. No player collision boxes left.

Bulk of code changes made in commit 9996a77.

Those are the critical code changes - mostly removing stuff - but still needs further code changes to make the server play every vehicle weapon mesh & driver transition anim that the client plays, so their positions match. That's only a pretty small change and can do it tomorrow morning. For now I have temporarily added bPlayerCollisionBoxMoves=true to cannon & MG pawns, which is a simple workaround to make the server play VehWep mesh transition anims. But for now the server isn't player driver (player) trans anims, that affect the player's pose - and therefore his hit points - so hit detection will sometimes be a little out.

When done & confirmed I will remove all VehHitPoints from def props of every vehicle, as well as now unnecessary variables MinCommanderHitHeight, bHasGunShield and MaxPlayerHitX.

[Andrew Theel]

Stupid question: Aren't some VehHitPoints for the Engine and Ammo storage? Or is that something else or have you changed that also?

[Matt Hands]

No, a fair question ! In the Vehicle class they do include engine and ammo storage, as well as one for the driver. That remains unchanged.

I will remove VehHitPoints from only the VehicleWeapon classes, where they only represent the head & torso of the player.

Not sure if the new hit detection system (well, old system really, just use the existing infantry pawn system & make it work the same in vehicles) will need to be applied to vehicle drivers, but I'm not doing anything in the Vehicle classes for now.

I've added a refinement to my system, where the collision on the bullet whip attachment actor is only enabled if the vehicle occupant is in an exposed position. Avoids any risk of hitting unexposed occupant (e.g. feet sticking out bottom of tank, which happens !) or of buttoned up player hearing bullet snap sounds (although tbh not sure if exposed occupant will either).

[Matt Hands]

Should be fully fixed/implemented in commit 78872e5 .

Will remove obsolete variables & def props later.

Will also look at mortars as they don't currently extend DH classes.

Also plan to change collision on open turreted vehicles so commander can be shot from above while lowered (currently classed as not exposed, probably only to make the 'shoot_closed' cannon firing anim play, instead of the shoot_open anim). Not a big change to make that work properly.

[Colin Basnett]

Players mentioned in the public test on June 20th, 2015 that the mortar operators were virtually impossible to kill; so this issue still affects the mortars. (I know you didn't touch the mortars yet, just wanting to reaffirm that this is still an issue).

[Matt Hands]

Redundant variables & def props removed from cannons & vehicle MGs in commit 15b15be.

Open turreted vehicle meshes modified in commit 32b347a, so crouching commander can bow be shot from above.

Added important fix for remaining mortar operator hit detection bugs in multi-player in commit 921d943. A server doesn't normally update skeletal mesh positioning for VehicleWeapons, as it doesn't draw the mesh. Without position updates, the server has the player in the wrong position/pose for hit detection. Need to set bForceSkelUpdate so server matches clientside positioning. Without this, the player didn't adopt the forward leaning, crouched pose on the server, so shooting him from the side often resulted in a miss, while shooting 2 feet behind his head scored a hit.

I call this issue closed. Any remaining problems are due to:

• Armoured vehicle drivers with bad VehHitPoints positions for their exposed heads (easy to see & fix; I have some adjusted ones to commit, separate issue).
• Armoured vehicle drivers with no collision mesh or box where their head is, so hits don't register (probably better to remove this and keep the bullet whip attachment hit detection method, same as all other types of vehicle & gun occupant).
• Non-armoured vehicles with some unwanted collision in the way of the bullet route to the player (I'm removing some of these now, separate issue).
• Current, flaw in bullet HitPointTrace() that ignores vehicle's collision static mesh & allows bullet to be blocked by blocky col box (will commit fix soon; separate issue)
• Blocky collision boxes on turrets stopping bullet path to player, especially from a steep firing angle (longer term fix is add collision static mesh system to turrets).

[Colin Basnett]

Marking as resolved. Good work.