Yea the method does introduce more problems.

JCL: Look at the original post? I did, it is the same problem that I had and spent a year trying to fix to no avail. Sure it did work if you used only geometry blocks, or only a completely flat surface. The sticking is a result of gravity only in the face that the gravity pulls the bounding box to the ground.

AMY: I'll prove it, decrease the x/y size of the bounding box so that it is small and looks like a pole, then try your movement code. The sticking will decrease but will not disappear.

BTW: Still waiting for that example of a game that doesn't use some crazy-tail system like a completely flat world, or one that doesn't use lol ent_move.

i also can reproduce the problem with ramps.
test.zip
you just have to move forwards with w and see what happens.
additionally you can get stuck at the top right corner of the ramp.

Ventilator - just read the comments in the manual: if your entity is too small, as is the case with your egg in your level, its default bounding box goes down all the way to its feet and you have to fix that.

vec_scale(my.min_x,0.7);
vec_scale(my.max_x,0.7);

Otherwise the code example permanently presses the BBOX on the ground and gets your entity stuck on any edge on the floor. The c_move code example was for players in the standard size, as our actor models, not for eggs!

Still, if anyone has a level with a normal player where my movement example does not work, please upload it and I'll fix it.

You can easily see bounding boxes by pressing [F11] twice.

it's supposed to be an ellipsoid not an egg! and it isn't very small but has about the same size as the gamestudio character models.

making the ellipsoid smaller seems to fix the getting stuck problems but how could i solve the slope problem then? move_min_z doesn't have any effect anymore with this method since the ascending happens because of the c_trace calculations and not because of c_move gliding. it's possible to move up almost vertical walls. can this be fixed in a simple way? without breaking nice gliding behaviour?

Yes, the code example does not use move_min_z. For preventing entering slopes, another piece of code had to be added. And so on....

All this is in the template scripts, my example was just a small code for illustrating c_move. Of course it has to work flawlessly, but the more features I add and the more complicated I make it, the harder it becomes to understand for beginners.

I will suggest that George publishes a lite-C movement action with all bells and whistles in one on the next AUM issues.

in which template scripts? i tried the template walkthrough project and it has sticking problems too. i can get stuck at the top of the ramp. from a quick look at the code it doesn't seem to use your feet.z method.

a robust yet simple movement example by george would be nice.

...but i still don't understand why it was possible to completely move into the geometry with the original ellipsoid?

You could not move fully into the geometry, but you could move into it until the bounding boxes touch. The code example then would not move you out of it.

I may be wrong, but as far as I know all sticking problems are caused by wrong bounding boxes and can easily be avoided when following the suggestions under "Remarks" in the manual. All our examples and templates use basically the same simple algorithm. When the bounding box is so big that it touches the floor, the height adjustment permanently attempts to push it further downwards. Because the entity can not glide downwards deeper than its bounding box, it will become stuck as soon as it encounters two planes that intersect in an acute angle with the floor. That's not a bug, it's just mathematics.

Therefore, either make sure that the bounding box is ok, or use a different movement algorithm. As to my knowledge, Doug's new T7 movement template also works with a fully extended bounding box.

So how is all this different from what I said? LOL! My bounding box goes to the ankles. It fixed the problem with the bounding box.