vehicle collision unit test design

[mlangsdorf]

Vehicles need a set of collision unit tests

The vehicle collision code is fairly obscure. I don't think anyone really knows how it all works. It needs to get revised and refactored. First, though, it needs some unit tests so developers can tell what changed and make sure that things that aren't supposed to change didn't and things that are did.

Unfortunately, I'm not sure what the unit test case should involve.

Current plan

Take the following vehicles:
unicycle, shopping cart, beetle, electric scooter, motorcycle, car, solar car, SUV, electric SUV, security van, school bus, RV, apc.

Spawn each vehicle at 60,60 on a map of pavement (possibly other terrains?) facing north with a speed of 10, 20, 40, or 80 mph.

Spawn one of the following furnitures, terrains, or vehicles about 2 turn's of movement north of the vehicle:
long grass, wood wall, rock wall, tree, bench, fridge, flower, zombie, zombie brute, zombie hulk, dog, wolf, moose, and each of the vehicles.

Have the vehicle move 4 times, colliding with the object.

Report the final location and speed of both objects and the damage levels.

Vertical crashes

Also drop the vehicles from 2, 4, and 8 z-levels up.

Help

I would appreciate some help in getting useful data about vehicle crashes.

[Lorith]

May also want to test things like individual frames and shopping carts or office chairs/wheelchairs as collision targets - they may not be driving around but should be significantly different than hitting full vehicles.

As for collecting data, maybe % of tiles damaged plus % of total hp of all parts?

[LetterShapedGlyphs]

I think the main things that would be important to test for their effects on the collision would be:
Vehicle tile width and depth at impact point, mass, and velocity.
Obstacle width and depth at impact point, mass, and resistance to being moved.

As for the data being gathered, it seems to me that the things which would need to be checked are the distribution of the damage (Both to the vehicle and the obstacle), the end location/velocity of the vehicle, and the end location of the obstacle.

To expand upon the first: I think we would want to make sure that the damage isn't JUST to the tile being hit, but follows some kind of Gaussian distribution.

Also, I think we'd want to ensure that the momentum is treated sensibly? I'm imagining something like a quick and dirty inelastic collision calculation, and then damaging both based on the kinetic energy lost.
E.g. - A stationary 100 kg zombie and a moving 1000 kg vehicle produce a combined mass of 1100 kg (I'm going to pretend the friction between the zombie and the road is negligible). Approximately 9.09% of the kinetic energy of the vehicle is lost. A quick 1/2 * m * v_i^2 gives us the amount of energy which went to damaging both objects. Then just some quick math to convert that energy into damage based on material.

Edit: A thousand apologies if this is in any way how collisions are currently handled, or planning on being handled.

[mlangsdorf]

Collisions are very arcane, I don't blame anyone for not understanding how they currently work.

vehicle::part_collision() is the code that determines the amount of collision damage. Collision elasticity starts at 0.3, with 1 being a completely inelastic collision. Impassable furniture has elasticity 0.1; other terrain has varying values of e determined by terrain_collision_data(). vehicle on vehicle collisions are handled somewhat differently but not relevant.

post collision velocity is sum of initial momentum of both objects + elasticity * other object mass * difference in velocity / sum of object masses. damage is 1/400th the change in kinetic energy of the two objects. object materials factor in there somehow on the distribution of damage.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.