That's missing the point. It has nothing to do with type of curve and the mathematics behind them, but with the complexity of throwing out all the code that operates on discrete tiles. (I was perhaps misusing the word *spline*, but *cycloid* is probably not the word I was after either, because I don't think you can represent a straight line with a cycloid.)

It was very clear from your post, that it is not meant for simutrans. I was referring to a hypothetical game that would use free-form curves as its paths. By the way, wouldn't even have to be as complicated as the mentioned games have it. One can simply parametrize the curve and do all the calculations with no regard for the actual shape of the track/curve. In particular when one gives up a graphical representation, as it were.

You can either have a piecewise function with straight line segments, or consider a line as limit of a cycloid with

*r*->0.

These are all "straight" tracks at different angles, forced to be skewed by the simulation. Computationally, they have differing radii if the curves are taken literally.

May I take this as another incentive to emphatically recommend to make a threshold, such that S-bends are not penalized at all, but rather treated as straight curves?

The argument is: They are almost exclusively a consequence of the square-tiled nature of simutrans, and as such ought not to have an adverse effect on gameplay.

Trying to make an order of frequency of such S-bends, based on my own games and countless screenshots:

(a) Double-to-single track, here they simply represent part of a point.

(b) At railway stations

(c) Diagonal tracks at angles different from multiples of pi/4.

(d) grade crossings of diagonal tracks

(e) navigating obstacles in cities, mountains.

Of the few cases where such curves have a different purpose, there is a speed limiting feature in place already anyway (b), (e). For all other cases (a, c, d, e) they are a workaround for game limitations, the player oughtn't have to suffer twice.