So, let's say we have our rail done in MED as a .mdl model file. We added it to our level and set its FLAG 2 to ON (let's just assume that we want every object with FLAG 2 set to be grind-able).
In the movement code, we trace down at every frame until a object is hit which has its flag 2 set - there we start the grind.

So far - so good. But now what? We can trace 45° downwards in front of the player. That would let us detect straight rail situations. If the trace hits the same object as the one the grind started on, we move our player there, no problem.
If the rail is going downwards, the 45°-check won't do the trick because if the fall-off of the rail is more than 45°, the trace won't hit anything and the grind would end with no reason visible to the player. In this situation we can add a certain amount of quants to the player position in its current movement direction and trace straight downwards from this new position. This would do the trick for straight rails which go upwards and downwards and would even work for loopings.

But what about rails which describe curves? Checking for a point "straight ahead" is useless. We could use the trick we did with straight rails and do three traces: the original one, one at a position left of the original one and a third one to the right of the original trace. However, if our rail is thin enough, it might go right through these three traces which would be unable to detect it as a result. The problem I see here is that the curve angle may be different at any rail so the sideways-distance of our three traces would have to be able to change accordingly as well.
The alternative would be not to do three traces, but 5, 7, 9 or even more - but doing that many traces every frame might slow down the overall performance and cause the FPS to drop...


Greets,



Alan