Let's expand a little bit upon this. I don't need the grinding stuff for a Tony Hawk or Skating Game in general but for a Sonic fanfic-game. The basics are the same, however, you also have rail loopings and stuff like that. Check this video to get a better idea of what I would like to do (especially watch closely to the rail looping at 1:12):
http://www.youtube.com/watch?v=uHB0y9r-haYSorry for the bad quality - I didn't produce this video, just found it on Youtube.
Oh, and about the question of placing paths to mark grinding possiblities: Tony Hawk definitly doesn't do that. Why? Two reasons:
A) Sometimes you may grind upon surfaces you really shouldn't be able to perform a grind/slide on
This would definitly not have happened if the programmers had placed paths on every grind-able object.
B) After all, you can create your own level (at least in THPS 2-4, don't know about the others), and the level may include rails to grind on. And you don't place paths there, definitly
Greets,
Alan
PS: Still can't figure out how in the world an automatic grind-possibility-detection-code could look like. Detecting the first spot to start the grind at is not that big of a problem, but as soon as the grind has started, how would you determine the coordinates for the next c_move command? You can't just say "Move ahead and check whether the rail is still beneath your feet, if not, move back" ^^'
Well... you basically COULD do that, at least when using a vector to "simulate" the player's position. But you can't just move that thing "up ahead", because you never know where this "ahead" really is! It could be forward and upwards, it could be forward and downwards or even forward and a step to the left/right when grinding in a curve. And last but not least, every rail ends at some point - we need to keep that in mind when creating the code...
