Spline cleanup

One of the more difficult and involved tasks I have happening in the background right now is being able to correctly lay-out locomotives and carriages onto the track given an arbitrary track tile. 

This is trickier than it sounds, because train elements exist mostly in 1-dimensional 'spline space' that is mapped back to world space for display. It's easy to reverse engineer a u value from a world position: but I had a more fundamental problem:

Overlapping numbers = overlapping splines

To make tracks travel in both directions, I had inadvertently been generating two overlapping sets of splines with opposite starts and ends. 

This makes the task of 'lay out my train on this section of track' a lot harder:which spline do you choose? You would need to know something about the intended direction and a bunch of other mess: basically, a non-starter (as well as bloating the memory use of tracks by 2x).

So today, what I did was remove this hack: Trains can now travel bidirectionally on a spline regardless of where it starts and ends, and the splines don't ever overlap.

In principle this isn't that big a deal - but, transitions from spline-to-spline did make assumptions about always traveling from a 0 to a maximum u value (because they used negative u values to communicate a carriage 'floating' in transition from a previous spline to the next).

To make this work, I added a very simple mapping function between the train and the spline - so that the train always believes it is traveling 'forwards' even if a spline is actually set up in reverse. This actually worked out really cleanly, and even the things that required some pause turned out decently too (e.g: when traveling in reverse, the current logic works out the target angles of carriages by looking at the current point and the next point. But the 'next' point is headed in the wrong direction if we're going backwards. Solution? Flip the resulting angle by 180' when traveling in reverse. Easy).

Hopefully the next step is to locate a spline based on a tile position, and then reverse engineer the necessary u positions for each carriage. I'm not quite sure how this will work when the carriages span onto an adjacent spline though - I may have to cleanup the train logic some more for that. (Right now the train statefully builds a list of previous splines as it travels, to permit negative u values. Maybe I need to eradicate this concept and have something that can dynamically work out what the previous splines would have been from just a static position)