Hi,

I just tried to do the following:

1) Created a rail in MED (a very simple one for testing purposes)
2) Saved it
3) Opened a new Level in WED
4) Added the rail and a PATH which follows the top side of the rail (like the player is supposed to do...)
5) Compiled it to a map entity
6) Added in that map entity (rail model + path) in my level.
7) When starting, EACH AND EVERY c_trace command causes the engine to crash! wtf...

Well, I think that paths are not the way to go if they can cause crashes like this so I thought about a new method:

The main problem is that it is difficult to detect the rail with line-traces, right? So why don't we use area-wide traces? In theory, this looks like this:
a) Place a cube model a few quants in front of the player (of course "in front of" takes into account the player's angle)
b) Do a c_trace right downwards, using USE_BOX enabled
c) The trace should hit the rail, no matter what. If it doesn't, the rail has a sharp bend (90° or more) somewhere which I don't want to include anyway.

And the "target" vector will automatically get us the position for our next c_move()-command. The faster we want to grind, the further away we have to place our block. Sounds good to me in theory, however, I see one major problem. If there is any obstacle between the block and the rail (one that would not end the grind normally but only causes the block-trace to hit a target to soon), the trace will hit an object which has it's FLAG 3 not set (therefore it has hit a non-grindable object) allthough the grind is supposed to continue normally. The big question is: how do we do this c_trace and ignore all other entities except for the one we are currently grinding on...?

Greets,


Alan

@Rei_Ayanami: If you can provide us with a tutorial for this topic, I would really like to read it ^^