GERMAN: hei i have this problem here

ENGLISH: hey ich habe dieses problem hier

https://www.youtube.com/watch?v=2sCFtbuN-Mk

GERMAN: wie kann ich steuern, ab welcher höhe der bounding box er diesen "jump" ausführt?

ENGLISH: How can I control from which height of the bounding box, he executes this "jump"?

maybe you need this move_min_z = 0.4; add it to your main

Hi.

As I see, you are using the code from Superku's TipOfTheWeek series. As far as I remember, small box like BBOX was part of the 'setup', so making it as big as your player's model will mess things up. You probably edited this lines in your code:
And I think, you shouldn't do that. I'm pretty sure Superku will give a better reply about his code.
Anyway, this is how it should look like to work correctly (as in his example and as in your first part of the video):




Best regards!

i have set the bbox..

by the first part of the video is the bbox zu small by the second part ist the bbox on this size tath i want but if i move on a block he bzg/jump upside and i need to controll this

look on 0:39
https://youtu.be/2sCFtbuN-Mk?t=39s

if the BBOX to high, he jump upside.
i want the BBOX on this size and i want control the bug/jump high with a variable...

I struggle with this problem for a long time period
but it could never solve

That's the thing I'm trying to tell you. This code won't (probably) work with rectangular BBOX! You have to use square BBOX (as on the picture from original source I've posted above and as in the first part of your video!). To make sure, you have to wait for Superku's reply, cause he is the one who made that gravity code, and I'm pretty sure he made square BBOX for a reason.

This caused by ellipsoid shape of collusion bbox ( READ MANUAL ), and we all suffering from this :< You can try and change 'move_min_z' parameter as Dico suggested, but I'm sure it won't help (it may reduce the stepping height, but will cause to other issues that you'll need to fix), cause there is no ONE variable that will solve that problem, it's pretty tricky to get working collusions properly. It may sound really frustrating I know this on my own, cause I'm been suffering from Acknex's OBB collision engine for years. You may want to check physX engine too, but it's also undone and tricky (and out-dated as hell). Take a look at the contribution I've made here:
PhysX Movement (RIGID BODY)


Best regards.

slowly I understand it ...
with an ellipsoid and move_min_z I can choose, at what level he skips the stairs?
you mean this?



A = skip the stair. while the normal contact is okey
B = no skip . while the normal kontakt is to big?
and i can set it with move_min_z ?

Quote from manual:
It means that 'move_min_z' determines the angle of the slope entity can step on. You have to know, that those 'black' obstacles in your picture, will affect normal.z too, as you try to step on them they will return 0 (probably). So playing around with 'move_min_z' may help, but as the manual says it's not a thing to rely on. It will cause other problems anyway at the end, probably cause to get that 'normal.z' value, you have to collide with those 'obstacles' at first, and after that they are too steep entity won't step on them.. I tried to find german manual, to make quote from it (instead of english version), but I couldn't find it. Read more about collision engine, you'll find out that it's really tricky to get properly working movement code :<

I tried to explain how it works via this picture:

The red silhouette that goes down from the entity is the 'c_trace' with USE_BOX flag set on, you have to know that it's using ellipsoid as well. Also, to understand what 'move_min_z' sets you have to imagine a slope going more and more steeper from flat ground (pointing straight up) which has angle 0 to a vertical wall, that has angle 90 (let's say), in this situation setting 'move_min_z' to 0.5 will prevent entity from GLIDING (this is very important) up on the slope, which's angle is steeper than 60 degrees (as the manual says, you can convert those 'move_min_z' values (1-0) into the angle of the slope by 'acosv' function, f.e. acosv(0.5) will equal to 60). Prevent from GLIDING means, that it will get stuck on moving up on the slope, and that is something that will result to unwanted results at the end. I tried my best to explain Keep it up!


My best regards!

"This code won't (probably) work with rectangular BBOX! You have to use square BBOX"
The code theoretically works with all kinds of bboxes, square or not.

The problem is, as already identified, the OBB collision system. Because of that you can move the player's hull at least to some degree over a corner, and the USE_BOX trace, starting from let's say the middle of the player position, will then hit the ground on the downward trace.
As 3run already said this is a tricky one to solve - or at least to find workarounds -, especially in three dimensions. Maybe a separate small collision hull (entity) near the feet with a separate c_move could do the trick (then limit the player's movement/ c_move call accordingly).

Well, maybe I used few wrong words to explain myself there. It will be MORE tricky to make it work with rectangular BBOX

Yeah that's true.

If the level geometry is mostly grid aligned (meaning few diagonals and such) you can for example put min_x/max_x to something small (0.01) temporarily, do a trace in x-direction, reset min/max, same for y, and use "target" positions to limit player movement. I do something like that in my sidescroller as it emulates a box (or in 3D cylindrical) trace more or less easily.