Destroying and splitting cars may make some untouched car parts disappearing.

[osuphobia]

Describe the bug

If you bash a car, destroying one tile of it and splitting some parts apart, the split parts ocassionally disappear.
I believe this is also the reason why vehicle splitting test is failing now.
There must be something wrong with the level_cache, like map::rebuild_vehicle_level_caches().

Attach save file

Kremmling-trimmed.tar.gz

Steps to reproduce

1.Load the save, debug spawn a 4x4 car.
2.Bash it until the top left corner is split, and it may disappear. If failed to reproduce, quit without saving and restart the game to test again.
3.Keep bashing until another part is split, see the top left corner returned. The newly split may also disappear.
4.Reload the save should also make the disappeared parts return.

Expected behavior

No bug while splitting cars .

Screenshots

Versions and configuration

• OS: Windows
  • OS Version: 10.0.19045.5247 (22H2)
• Game Version: 52e013b [64-bit]
• Graphics Version: Tiles
• Game Language: English [en]
• Mods loaded: [
  Dark Days Ahead [dda],
  Disable NPC Needs [no_npc_food],
  Portal Storms Ignore NPCs [personal_portal_storms],
  Slowdown Fungal Growth [no_fungal_growth]
  ]

Additional context

No response

[IdleSol]

Confirmed. For a simple test, take damaged cars and a hammer (+20 strength). After that smash the center of the car to split it into pieces.

Guided by memory. You can also pick up shards from where the missing piece should be.

[RenechCDDA]

Likely a type conversion error, though the behavior is erratic.

[Procyonae]

I'll try making the vehicle caches behave like the other level caches given that wants doing anyway bc it's not shiftable rn and see if that conveniently fixes it at the same time

[CLIDragon]

This unfortunately appears unrelated to vehicle_split_level test failures.

[Procyonae]

Based on what?

[CLIDragon]

Basically what the test does is it creates a test vehicle, destroys a part of it and then checks that the vehicle was split correctly. It does this for several vehicles, but it can be reduced down to the last one which is basically a 5x5 square with a few weird holes in it. It has a few pieces attached but removing them doesn't effect the test, so it boils down to a 5x5 square of frames.

In the test, it calls map::destroy on the centre piece, and then checks that there is only one vehicle. Where the test failures occur is that sometimes map::destroy not only destroys the centre tile, but also the tiles around it and in a diagonal, actually splitting the vehicle into two. A failed test might look like this:

While the undamaged vehicle looks like this:

Now, it could be that the root cause is the same. But given that the problem reported here is parts disappearing, and the problem with the test is that the vehicle is breaking further than expected, I'm inclined to say they are different problems.

[CLIDragon]

I've patched in a the ability to call map::destroy from the debug menu and manually destroyed the vehicles to see if I can use the debugger to find the cause. So far it appears to be completely random, but doesn't reproduce when setting the random seed in the tests.

The attached save file has a grid of vehicles which looks like this beforehand:

And this after:

Destroying two tiles seems more likely than three, and three more likely than four, but there otherwise appears to be no correlation. I have attached the patch for the debug menu, the save file and vehicle structure in case anyone wants to take a look. Help would be much appreciated.

EDIT: I've done a bit of work, and there's to be a strong correlation between number of collapse_at calls and chance of failure.

debug_menu.patch
Vehicle Split Test-trimmed.tar.gz
test_vehicles.json

[CLIDragon]

git bisect reveals that failures are introduced at 9d6f5ac7940f4ff6ac42fa4971a1f623c6b58a10 (#78679).

[mqrause]

git bisect reveals that failures are introduced at 9d6f5ac7940f4ff6ac42fa4971a1f623c6b58a10 (#78679).

Considering there's no call to clear_map in the test, the only way for that to make sense is a dependency for calls or missing calls to it in previous tests?

[CLIDragon]

git bisect reveals that failures are introduced at 9d6f5ac7940f4ff6ac42fa4971a1f623c6b58a10 (#78679).

Considering there's no call to clear_map in the test, the only way for that to make sense is a dependency for calls or missing calls to it in previous tests?

Re-testing shows that it fails sometimes but not most of the time. I now wonder if the failures were introduced earlier, they're just rarer?