New ship/track collision system. - #208
Conversation
|
You said “Not bulletproof” - is there any regression with this? Or is it "no worse" than what we currently have? I don't like having functions that are not called just in case we might need them later. So |
…e_with_track was the only thing setting SHIP_DIRECTION_FORWARD.
|
I've fixed a bug: for some reason
I had a carefully-trimmed-down 260 words here, but in the interest of brevity I'll say: this is somewhat subjective, and a rigorous comparison seems impossible. The data structures I have to work with are typical for the era and awful. I am trying to think of a flawless, performant solution, but it is not easy. More words available upon request.
I've added a menu to switch between "authentic" and "experimental" collision resolution. |
The old ship-track collision system has been thrown out. We now have these:
ship_point_find_collision: Collision detection between points and tracks. Not bulletproof, (in junctions especially) but the original was not either, and it's easier to reason about.ship_resolve_collision: Collision response derived from the original code. Should behave identically.ship_resolve_collision_scrape: Basic "track scraping" collision response. Not written to match any particular entry, but could be elaborated upon.point_face_collision_t: Produced by collision detection and consumed by collision response.Right now,
ship_point_find_collisionis passed a point and a section, checking the point against the section and all its neighbors, and selecting the shallowest collision.track_nearest_sectionmight simplify that, but I haven't yet investigated whether that would be more robust or less.