Fake parts for filling vehicle gaps

[kevingranade]

Summary

Features "Fill gaps in vehicle walls when necessary to maintain vehicle integrity."

Purpose of change

Completes #53722, which is a continuation of #42462, which is an extension of #41277
Fixes #5684

As vehicles turn, they skew and open gaps in previously aligned lines of obstacles. This creates a weird situation where a vehicle that is driving in a cardinal direction fully protects its occupants, but a vehicle driving at any other angle can get hitchhikers.

Describe the solution

On vehicle refresh, the outline of the vehicle is scanned for eligible obstacles and protuberances that have skewed away from their neighbors, when found these obstacles have fake parts added to the vehicle to fill the gaps.
Vehicle damage code forwards all damage instances to the real part instead of the fake part until the real part is destroyed, at which point the fake part is marked for removal as well. Updates to the state of the real part are echoed to the fake parts on vehicle refresh as the fake parts are stripped off of the vehicle and recreated.

Describe alternatives you've considered

Too many to count, but this approach was selected because it mostly contains the change to the vehicle code instead of sprawling across all of the codebase that has to interact with the map.

Testing

Multiple layers of tests were added to exercise this feature, and the propensity for the overmap_terrain_coverage test to trigger several problematic use cases in mapgen has also been extremely valuable.

• have one lingering issue, which is that ramming other vehicles generates src/vehicle.cpp:7390 [int vehicle::get_non_fake_part(int)] Returning -1 for get_non_fake_part on part_num -1. errors.
  Turns out there was just a typo in the vehicle->vehicle collision code.

Additional context

When merging definitely do a merge even with the relatively messy history to preserve authorship.

[Inglonias]

That's a lot of changes. Best of luck

[kevingranade]

Ok two major changes:

1. There was a pre-existing issue that came up in testing because I was hammering on it, which is that when a vehicle is placed and then split in mapgen, the split code would call back into the global map instance to place the pieces instead of placing them on the tinymap being generated, the main things causing this were the wreckage generation code, which can cause vehicle splits now, and some map extras which would call map::destroy() and end up splitting vehicles that way. I fixed this by passing references to the current map being acted on into the vehicle damage functions so that they can target the right map.
2. There was a major problem with the fake parts code in that it would frequently strip the fake parts back out and then replace them, but this really can not happen because doing so invalidates part indexes and causes the state of the vehicle to go out of sync with the map cache. I addressed this by removing calls that would strip fake parts out with the exception of part cleanup code and unracking code, both of which are careful to invalidate and regenerate the vehicle cache afterwards.

I've hammered on the automated tests a ton (50 odd test suite invocations), and I'm pretty confident the errors I was seeing cropping up there periodically are resolved, but I haven't had a chance to do more than some light driving around and ramming stuff testing in-game for some more random testing.

I'll be pushing fixes tot he things clang-tidy is complaining about as soon as I can, but this PR really does need some fairly heavy testing before it goes in.

[esotericist]

did some quick in-game testing. made a cube van with a partly opaque cabin.

started running it at angles and immediately got some weirdness.

removed the mirrors, and i'm pretty sure proxy tiles are not correctly inheriting visibility:

i was able to determine they correctly function for passability and rigidity, and that damage correctly propagates to the right part when a proxy is hit.

the rendering needs a band-aid, and x look around shows that there's a vehicle there but not what the tile is supposed to be, which is awkward.

but right now the primary issue i can observe is the the proxies seem to be transparent, and it is in fact bidirectional:

[esotericist]

loaded up my actual save to do for-reals playtesting.

first thing i noticed:

my first surprise was that the fake parts are rendering for this flatbed truck when they didn't for the cube van above, but something more pressingly weird is happening with the door fake part:

i can only open/close the real door, not the fake one, which... could actually be problematic in some configurations. (note that opening the real door does correctly change the state of the fake door.)

back to rendering:
the first time i started up my rv this run, i got correctly rendering proxy parts when i started to turn:

then as soon as i turn off the engine:

whatever's happening here, it seems to work correctly the first time a vehicle is loaded in a game session, or the first time a vehicle rotates after a game session starts, then breaks once the player is no longer driving the vehicle until a new session. (turning off the engine is not necessary; i was able to reproduce the 'no tile' result above by simply letting go of the controls while the vehicle was otherwise stopped).

so far i have yet to discern any way of getting it back to the valid state other than save and quit, then restart.

bonus fun: a recurrence of an old map memory bug:

in some circumstances (i had trouble reproducing this on demand, but it happened a couple times when i wasn't trying to do it) the fake part can get remembered as it passes out of view, similar to some of the old problems we have historically had e.g. dragging a cart in darkness.

[kevingranade]

I need to flip to a tiles build to double check for the specific issues you're reporting, but I did find a critical error that is almost certainly related.
There's a cache of vehicle-relative coordinates to item index called relative_parts that is updated in vehicle::refresh(), when I overhauled fake part maintenance to avoid removing and re-adding fake parts on refresh (to prevent map cache desync), I failed to have refresh() rebuild relative_parts, so it would lose track of the fake parts on some kinds of refresh operation and then re-add them on other flavors of refresh.
I also need to clean up the code, what I have is working, but it's very messy.

[kevingranade]

I've finally had a chance to do a tiles build and test, and I'm working my way through the issues you reported.

• A diagonally oriented cube van's mirrors are rendered properly, This seems to be related to the relative_parts cache and is fixed.
• "the rendering needs a band-aid, and x look around shows that there's a vehicle there but not what the tile is supposed to be, which is awkward." This issue is still present, I'm pretty sure it needs a separate override in look_around.
• Fake parts are transparent, or rather are not participating in transparency.
• Inability to access doors via their fake parts is still occurring.

[andrei8l]

Collisions sometimes (temporarily) remove real parts

Another try from same angle

And it's not just a visual bug

But the missing parts do come back after moving a bit

Forgan.tar.gz