Back to your original question: No, you won't gain much when I add gravity to the movement example. What you probably mean is not an example for the c_move function, but a real player movement script as it's used in a real game. That's not in the manual.

You can either program the movement code yourself - then you need to understand the basic collision functions and that's what the manual examples are for. Or you can use some pre-made movement scripts - that's probably what you mean with "simply push the ellipsoid around with gravity and everything". Then you can use the movement functions from the templates.

How much longer and more complicated would that example be with correct gravity? I don´t need a full movement script. Just a simple example with gravity instead of setting the entity to the ground every frame. Like my script but without the problem that you can run up every slope. I would like to limit it to 45° or so.

I understand what c_trace and c_move do but figuring out the reasons for problems like getting stuck isn´t always easy. This doesn´t only seem to be a beginner problem but if you look around on the forum a bit even Gamestudio experts often seem to have problems with this.


I mean this:

c_move(my, vector((key_w-key_s)*10, 0, -10), nullvector, IGNORE_PASSABLE | GLIDE);

Why can´t I just apply gravity at all times and have the ellipsoid correctly glide along the geometry? I think this would make it very easy to use. No need for extra traces. Some engines have a system which allows this.

Can you provide a link to this discussion?

sorry for that, it must be my english. i wanted to express that it doesn't matter how big your collision hull is because you're already letting it flow 2 quants from the ground, that's why i said:



if your model begins at zero in model space then you can indeed add some number to your bounding box min_z value.

nevertheless, try changing the following line:

I know how you feel amy. I have posted about this lots and there doesn't seem to be a solution. Basically, you end up with everyone saying "use blocks" or something seriously substandard like that. I know what is causing the sticking.

Your entity is standing straight up like normal when it moves up a slope. Look at your bounding box (hit f11 twice). Notice that when you stick on a slope, a bounding box corner dips below ground? That is causing the sticking.

Decreasing the size of the bounding box alone won't help, the entity will just be pulled down more.

What you have to do is find a way to keep it from touching the ground at all, as stupid as that sounds, I found relief to this problem by decreasing the size of the bounding box so that the bottom cut across the ankles then added the same number that I decreased the bounding box size by to the result of the trace. You will find some sticking on REAL steep slopes because the bounding box still dips below the ground slightly.

P.s: Amy. Notice how there are 2 pages and no real solution? Also, I would like for anyone to show me a game made with this software that successfully implements a good solid 3rd person movement script that works on blocks, terrains, and models without some sort of system that limits the diversity (no gravity, completely flat level surfaces, etc.). The reason why is that it is just too darned hard, and that is the dirty little secret of this software. It seems almost designed to allow you to not produce the game that you want.

coma_dose - the c_move example discussed here was just for avoiding "sticking" by faulty movement code. Just read this thread and look into the URL posted in the first post.

amy - gravity would double the example size. You need to add acceleration, store the speed, and reduce the speed on slopes. But you're probably right, this is often needed and I'll add a gravity example in the next time.

Movement code is very simple and straightforward with A7. I think the main problem is that player movement is the very first thing people try to program, when they have not yet understood collision detection and how to write good code. That's why so many bad movement examples and strange discussions are found on this forum.

Thanks! I am looking forward to your example.

I just tried the walkthrough template and there are problems with getting stuck too.

If I slowly move over one of the top corners of a ramp like that I get completely stuck and have to try hard to get free again.

If not even Doug can do it without flaws (where is Doug by the way?) how are the users supposed to? It doesn´t seem to be as easy and straightforward as you claim after all.

Yeah, that was my idea too and except for the slopes it works better than the templates. I will experiment with tricks like Joey has suggested but I fear that this will introduce other problems. For example with gliding.

Movement is one of the most important thing in games! If moving around isn´t flawless and fun then the game isn´t fun.

i guess it's beacuse c_trace uses a ray and collision uses the box, the ray says entity is not zero to ground but box says it is.

No, c_trace (with USE_BOX) and c_move both use an ellipsoid. Probably c_move internally just uses c_trace too.

I noticed the new manual example and tested it.

dist_ahead = sign(dist_ahead)*(abs(dist_ahead) + 0.5*dist_down); // adapt the speed on slopes

I don´t like the behaviour this line causes. It causes jerky jumps when going over stuff like stair edges.

And if I add move_min_z = 0.5; to prevent going up steep slopes I can move into the geometry of ramps and get stuck there if I glide along their sides. (I mean a ramp like on the screenshot above.)

The movement example is probably far from perfect - George, Doug and many users can write movement code far better than I can. Still, I would give it a try. If you have a level where my code does not work, or where you even have problems with the template script, can you send it to the support? I'll look into it and check where the problem might be.