I'm playing with my old movement script, trying to find and fix bugs.
I've found out, that if I do not limit FPS at 60, then I get strange jumping behavior..
I've even found the line which caused that, here it is:
If I comment that line, jumping stuff disappears.. but without it I lose smooth movement down on slopes.
Any ideas? May be someone already faced something like this. Originally script is taken from A5 movement template.

What value does my_height have? If it's bigger than zero, then the marked line will quite obviously always return -my_height, which may or may not be something you want.

It probably isn't. Check the signs


Also, what framerate are we talking here? If we use vars, I wouldn't be too shocked if their inaccuracies add up fast here with small values (which time_step tends to have if your FPS goes beyond the insane)

Thank you for the response! "my_height" is distance to ground, which I get from "c_trace" and lowest point of the BBOX:
I mostly use variables (such as "my_heigh" etc). But I didn't understand your last question, sorry for my English man.
If you asked what framerate (fps_max) am I aiming for, then I'd say "60" If I don't limit, I get stable 512 fps and jumping behavior.

Edit: BTW, thank you! I guess you were right! When I changed "-10" into positive value in this line:
Jumping problem disappeared! But now, movement on slopes isn't smooth (it's almost smooth, jerking a little bit).
When I limit max fps by 60, it's very smooth (as it was before changes) on slopes! But still if I try it with 512, it isn't.


EDIT2: I've increased that positive value from 10 into 100, and it's smooth now But I need to test it. Maybe that will affect on something...
Math was always my weak point.. Thank you once again my friend! I appreciate it!

EDIT3: I've found what was causing those little jerking stuff on slopes! That wasn't gravity stuff (I fixed it completely with your help)!!
Problem was with camera Z smoothing script, but it works perfect now! Thanks once again!!!

Sorry for double post, but now I faced an other strange problem with camera.
I use the following script to make Z movement of camera smoother (on stairs etc):
If I set camera's position with "vec_set" instead of "vec_lerp", movement is perfectly smooth, other ways it jerks a little bit.
I tried to lerp without "time_step", but I get same results.. Used to make it smoother without "vec_lerp" with this:
But results are the same.. Camera jerks a little bit, what could cause that? It only happens if I don't limit fps as well.

Okay, let's talk about your camera code. That used to be my specialty, anyhow.

You set camera.x to the player's position (only not caring about z - probably NOT a wise idea). Then, you calculate another camera position that lies 30 quants above the player. Note that if your player's tilt (and roll) is 0 (as it is in most games), the vec_rotate line will have no effect (apart from making the game slower).
Then, you lerp between those position. The net effect is that you lerp between two coordinates, one taking care of x/y, and the other of z. That's an unusual behaviour.

If you want a first-person perspective, you probably want to go:



(at least for the simple case of tilt=roll=0).

If you want to smooth it, then simply smooth it!



I've assumed that your tilt and roll is always zero.

EDIT: I realized later with a creeping horror I didn't talk much about what caused the problem in the first place, and my disappointing take on it is "it's complicated". It's a bit hard to name the one detail that caused it in your game, but your way of handling camera movement still seems a bit strange to me, it's two different ways to do it put together. Since I don#t know the exact placement of the camera code, I'd rather guess that what you see is a relatively accurate "jerking" of the z-coordinate that can come about when you do several micro-adjustments, that tend to change in value, rather strongly so in relative terms. But that's a wild guess, and probably a bad one at that. What kind of "jerking" are we talkin' here?

~
Sidenote:

With the line


camera.z -= (camera.z - cam_pos.z) * time_step;

Remember that for very LOW framerates (<16), time_step is actually bigger than one, and you end up overshooting. So you'll want to correct that, for instance by using minv(1,time_step) - but that's just an aside.

I've found out that increasing "10" into "100" in gravity code affected on stairs movement. Now player can't walk up on slopes, but movement on slopes is extremely smooth. I'm thinking on how to fix that (player can't walk up on even very small stairs). But if I leave it as a negative value (-10) and limit FPS at 60, then everything works perfect (smooth movement on slopes and stairs). About the TILT and ROLL angles of camera. I change camera's TILT for aiming up and down, plus I change ROLL angle for making an explosion effects. I don't change player's TILT and ROLL angles (that's why I tried to use "my.pan" for "vec_rotate" instead of "camera.pan"). I rotate it with player's PAN angle only cause I use blobbing camera effect (see this line: "vec_set(cam_pos.x, vector(0, 0, cam_height));", I use variables for Y and Z additional to cam_height). If I won't use that blobbing effect, I would remove "vec_rotate" cause as you said it's not necessary

Edit: By jerking I mean that camera's Z position moves up and down a little bit while moving down on slopes (fast). If I use "vec_set" without lerping everything works good.

You probably don't want to change the player's tilt (as is impled with my.tilt) - you should only change the camera's tilt for bobbing. Same with roll and explosion-effects.

Anyway, I'm a bit lost as to what exactly is working and what isn't. My apologies, but could you summarize the situation once more?


Small note: I know you've used the yellow color to make things easier to read, and I think thats very nice of you - its just that I'm using the white colorscheme, and it actually makes it harder to read. You could use red color for that, then I suppose even I could read it just fine.

OK, I didn't know about white color scheme So, to summarize all problems which I've found out:

* gravity problem, I've found out the way to fix that jumping behaviour (when FPS isn't fixed and more than 60).
I've fixed it in this line, by changing negative "-10" into positive value "100":
After that gravitation worked smooth enough (no jumping) and movement on slopes was smooth too.
But after some little tests, I've found out that this fix affected on stairs movement, so now I can't walk up on them.
I can't walk up on any small stair or even a small object, which is even one quant higher than ground floor.
So, when I returned negative value in that line above ("-10"), and limited FPS at 60, everything worked smooth (slopes, stairs).
But everything works perfect, only if FPS is limited to 60, if it's higher player stars jumping (even if he doesn't move at all).


* camera problem. I don't change player's TILT and ROLL, only camera's TILT and ROLL changed for effects (blobbing, explosions, recoil).
I need to rotate "cam_pos" vector with player's PAN cause I use blobbing offset for camera's positions (Y and Z). See this line:
I tried to lerp camera's Z, but as I see it wasn't a good idea. BTW smoothing Z position works perfect when FPS is limited to 60.

SUMMARIZE:
- by fixing jumping behavior on hight FPS I've faced another problem (can't walk up on stairs), by fixing which I face first problem again (jumping behavior).
- I'm a little bit confused that it works on small FPS (60) and jerks off on high one (512).

BTW. I use physX (PH_CHAR) for movement, not "c_move" (I don't really like how it works for FPS).

Edit: Hm... With previous version of GS (8.30.5) after changing "-10" into "100" my character still can climb up the stairs and movement is really smooth.
But if I test the same script with the latest beta (8.40.1), player stucks (lowered "min_z", no results). And I've found really interesting thing:
Could this be somekind of bug (fast implementation or fix)? Or does my script really work wrong...

I had that problem too. I guess it's because time_step can has values between 0,1 and 10 (at least that's what the manual says). But at 512 fps time_step should have 0,031 as a var (16/512 = 0,03125) which is below 0,1. Limiting to 60 fps helped me there.

I've edited previous post mate, if you had any problem with PH_CHAR with latest beta, I guess that the problem.
I will use "minv(1, time_step);" as Error014 said, to prevent such problems. But that won't help on jumping stuff.