Flak38 has questionable exit positions or lack of multiple ones

[cmbasnett]

Originally reported by: Andrew Theel (Bitbucket: AndrewTheel, GitHub: AndrewTheel)

---

In the location of the new Flak38 gun on Carentan Causeway, there are no exit positions. Even if collision is ON on the net above the gun, it should not be enough to block all exits.

---

• Bitbucket: https://bitbucket.org/darklightgames/darkesthour/issue/436

[cmbasnett]

Original comment by Colin Basnett (Bitbucket: cmbasnett, GitHub: cmbasnett):

---

The problem is likely that the exit positions are not high enough.

[cmbasnett]

Original comment by Colin Basnett (Bitbucket: cmbasnett, GitHub: cmbasnett):

---

I looked into this, and I'm flummoxed. The exit positions seem valid, but I'm getting completely stuck on the Flak 38. See the screenshot clearly showing a variety of valid exit positions. Assigning to @Matt_UK.

[cmbasnett]

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

---

It's nothing to do with the camo nets, or I think to do with the gun's exit positions. The blocker is the gun pit static mesh (DH_Misc_002.Defences.PAK40_gunpit).

All 16 exit positions are blocked by this static, based on a trace from the gun to the exit position, which stops players exiting a vehicle/gun through an adjacent wall or other blocking thing (UT2004/RO stuff, nothing new). Logging shows that the player could be successfully moved to most of the exit locations; it's only this 'line check' that blocks it.

I think the trace is 'seeing' the static mesh as a sort of box collision shape, and the gun and player and inside/enveloped by that box. If the trace is made zero-extent the player can exit without a problem. But the trace uses an extent based on the collision size of the player, which is logical, i.e. it's checking whether something player sized could get to that position).

[cmbasnett]

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

---

I think this static mesh's collision needs some work, but I have an idea for tracing exit positions which seems to work and is more logical anyway.

Currently the trace start is based on the vehicle base's location. That's a little random, because it depends where the vehicle mesh's origin has been located. Older models tend to have a roughly central origin, including the Z axis (think centre of gravity, roughly). But at some point DH vehicle mesh's switched to having their origin set on the ground, i.e. zero Z. Some logic in that, e.g. consistency and less arbitrary selection of Z positioning in the skeleton. The Flak38 is modelled that way.

The effect on vehicle location in the world is that the earlier method places it higher up and the later method places it on the ground. The vehicle always 'settles' into a world location based on how its collision interacts with world geomoetry, but that's more of less where it ends up.

Remember that the trace is meant to check whether the driver can reach the exit position without passing through blocking world geometry. It doesn't trace actors, only world geometry - otherwise the vehicle or turret would often block the trace, I expect. So my modification is to trace from the player's current location, i.e. where the vehicle's or vehicle weapon's attached 'Driver' is located, instead of from where the vehicle is located. That is more logical, because we are meant to be checking whether the player can get from where he is to where the exit is. Using the vehicle's location isn't really very relevant and, as I mentioned above, it introduces a somewhat randomising element, given that vehicle location isn't consistent. But the player's location should be entirely consistent - what you see is what you get.

The change in code is very simple and minimal. I'll check it a little more when I get back from work. It would apply to all vehicle and vehicle weapon pawn classes, not just the Flak38.

Re the gun pit mesh, I think the problem is that the collision model is extremely convex. As a cross section through a vertical plane, it is a U shape and everything within the 'hole' in the U (the pit itself) probably gets some scrambled collision. Effectively everything inside the pit gets enveloped in the collision. All the UT2004 collision references say avoid anything concave, although I've not found anything that says why. I think that collision detection is really a series of mathematical calcs, slicing the collision mesh up into box segments and checking each one in turn. But that relies on a rule that there must be no concave angles, i.e. with concavity the model sort of turns back in on itself and that ruins the calcs.

The solution to modelling collision on concave models is to break the collision mesh up into physically separate convex shapes, with a very slight separation between them. So the gun pit collision could be broken up into a base section, plus separate 'ramped' sections for all 4 sides. The collision is probably too detailed/complicated and the polys could be reduced I think, smoothing out any slight concavity in the ground undulations. That is beyond by limited modelling ability.

[cmbasnett]

Original comment by Bitbucket: Matt_UK, GitHub: Matt_UK:

---

Modified exit position functionality implemented in commit 14cb90f. This resolves the problem with the FlaK 38 on Carentan Causeway & should generally make exiting more reliable, predictable & trouble free.