Hi,

well, your first three suggestions are "just" shorter versions of mine. Would be better to use the short ones, for sure, but during the development process I like to have a few more (but therefore more readable) lines with fewer content each ^^

vec_normalize(grindtrace, 100);

If I'm not mistaken, there's no question about what vector is "changed" here - the "grindtrace" vector is changed, however, only in length, not in direction or orientation. This is to make sure that the target of the trace really IS 100 quants beneath the trace origin point, nothing else ^^
Same goes for "vec_normalize(grindheight, -47)". My model is 94 quants high in total (at least MED told me that ^^), so if I have calculated the position the player's feet are supposed to be, I have to go upwards 47 quants in order to get the point where the model origin has to be then.


I just re-wrote the whole code from scratch, SAME PROBLEM as previously: The grind suddenly (with no visible reason whatsoever) STOPS halfway accross the rail, and ALWAYS at the SAME point!! I tried two independent rail models, both with the same result! Something's definitly wrong in here...

Thanks for your tips Ottawa!


Alan

Hi Alan!

Thanks for the feedback.

Just an idea. Can it turn around and come back to the starting point?

... what exactly do you mean by that? When the player is grinding a vertical rail upwards, his speed gradually decreases due to gravity until it reaches zero and then becomes negative, therefore the player turns around and grinds back downwards - but that's a detail I don't rally care about yet, I want to get the grind process to work for a straight horizontal rail first ^^ (I hope that this was what you meant...)

Greets,

Alan

Hi!

I was thinking along these lines :


2nd line : why not?
If your block is at the end of the line he should be able to turn back. If he's
really stuck he wont be able to move back.

Do you have a debug panel that follows the vectors (they are global)
and the other path nodes? (PANEL* and digits)

@Ottawa: Oh that was what you meant. Well, the player is not actually moving before the final movement vector is determined. It is done "virtually" by placing a block above the new position and doing a trace downwards from there. If the trace misses / does not hit the rail, it is quite sure that the rail has ended there. And if not - then the player moves there. No reason to "try" to go anywhere ^_-

I really need to do more detailled de-bugging. Just didn't have the time within the last few days. I still need to set up a propper debug-panel and I *hate* the debugging process in general because it's just annoying, but unfortunately sometimes it can't be avoided ^^'


Greets


Alan

Hi!

Well, you will eventually enjoy your game.

Good debugging...panels are great for that.


Ottawa