Skip to content

New ship/track collision system. - #208

Open
unofficial-fish wants to merge 4 commits into
phoboslab:masterfrom
unofficial-fish:track_ship_collision_rewrite
Open

New ship/track collision system.#208
unofficial-fish wants to merge 4 commits into
phoboslab:masterfrom
unofficial-fish:track_ship_collision_rewrite

Conversation

@unofficial-fish

Copy link
Copy Markdown

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_collision is passed a point and a section, checking the point against the section and all its neighbors, and selecting the shallowest collision. track_nearest_section might simplify that, but I haven't yet investigated whether that would be more robust or less.

@phoboslab

Copy link
Copy Markdown
Owner

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 ship_resolve_collision_scrape() should be used (with a menu setting to turn it off?) or not be in this PR.

unofficial-fish added 2 commits August 9, 2026 17:28
@unofficial-fish

Copy link
Copy Markdown
Author

I've fixed a bug: for some reason ship_collide_with_track was responsible for setting SHIP_DIRECTION_FORWARD, so rewriting it broke a few things.

You said “Not bulletproof” - is there any regression with this? Or is it "no worse" than what we currently have?

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 don't like having functions that are not called just in case we might need them later. So ship_resolve_collision_scrape() should be used (with a menu setting to turn it off?) or not be in this PR.

I've added a menu to switch between "authentic" and "experimental" collision resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants