custodian
commented
1 year ago If I may add some feedback on this one:
It might be more beneficial for map creators and LTS itself to omit rail types completely at this point. It is not map/content creator job to understand all math behind the route generations, understanding rail types, and select if rail should be an arc, line or clothoid. Right now any minor change to a rail yields errors in snapping and so on.
I would rather implement node-based design, where you draw a way using nodes, and LTS Editor/Engine decides based on those nodes if rail should be a lines, arc, spline, or clothoid.
Such approach will completely eliminate snapping tolerance issues, switches generation (that is just a node which happens to be on multiple ways):
- If you even need to adjust your railway - move a single node, nearby rails would be adjusted automatically.
- If need to continue your track further, add extra node, depending on the position and maximum allowed curvature this will update adjacent rails (Image 1)
- If you need to adjust curvature, you split your rail in 2 parts by adding new node on the existing rail, and dragging this rail.
All current playable LTS tracks, which already have been properly snapped, can be automatically converted into new format.
This will also drastically simplify geospatial data import.
I'm trying such approach with my map generator based on osm data and modified LTS version.
Some real train tracks that are neither straight nor a circular arc can be described using "clothoids".
These are arcs where the curvature changes proportionally to the length of the track.
Not only was this mentioned in #480, but I have also found that ZuSi 3 uses clothoids. So it seems to me that implementing this kind of shape is necessary to properly simulate railsways.
This might also help to make automatically calculate rail connections easier. As right now, only a few special cases are implemented.