Weird glitch during crouching

Hello everyone, I have recently started using BGE and I’m experiencing some difficulties, in this case, with crouching.
I’ve managed to make a simple fps movement setup but when is time to make the character crouch the cylinder I’m using for the player glitches

Is there any way to solve this?

So far I am managing the crouching by scaling the cylinder, it’s using “character” physics.

how exactly is it glitching, i dont see it, but i might suggest that why not, instead of crouching the whole player, just crouch with the camera, just move the camera up and down, then you shouldnt get glitches

Every time it crouches it moves randomly in the x and/or y axis. Also, if you look closely, once it’s crouched it shakes. The camera solution won’t change the collision of the player collider, hence, the character won’t be able to go under any obstacle (tunnel, boxes, etc.). Like this:

I would check collisions, but even better is to not scale the cylinder at all. The best method is to replace the physical representation of the mesh with a smaller cylinder. However this can only be done with Triangle mesh on both cylinders and also will NOT work with character physics (the engine will crash). To fix this use dynamic movement instead.

I checked and tried every collision combination possible but nothing seems to work. Other than the shaking and random x/y movement, scaling the collider works like a charm, responding even to different heights of obstacles, as shown in the next video (notice that one of the blue boxes is higher than the other two and the collider “stands” just enough to fit in the hole (00:25):

I tried using replace mesh and triangle mesh collision, but the dynamic physics has and unexpected behavior even when standing still (it shakes):

Edit: it also manages to provide a wrong collision detection on the cylinder over the player collider (used to determine whether the character has enough room to stand up or not)

I think I have had something similar happen, does your terrain have collision bounds? if so try removing or changing them.

Couldn’t you perhaps leave the cylinder as it is and just move the camera? For example by parenting it to an armature bone and then animate that bone to lower the camera?

I could but if I did the character wouldn’t be able to go through any obstacle below his own height (2 units).

The floor doesn’t have “collision bounds” activated

Try activating collision bounds, or try changing the collision bounds on the player. Its just a matter of changing the settings until it works. Otherwise you could try another Blender version and see if that works.

I tried activating it, deactivating it and changing the collision bounds but the problem persists. Also I tried using blender 2.70 and 2.66, not only does the problem persists, the previous versions don’t have the ‘character’ physics type that is supposed to make the character go up stairs (which doesn’t seem to be working properly either)

select the cone, press CTRL A on your keyboard and click apply rotation. also, i recommend avoiding the character physics preset for now. Its a bit glitchy and has limited features, just set it to dynamic and give it a capsule physics boundary so you can climb stairs.

Thanks for the tip about the character physics. Apply rotation to the cone? How is that going to help?

oops, I saw the cone being squeezed when you crouch and thought that was one of the problems you were dealing with. :stuck_out_tongue: the squeezing is caused by the fact that the parent cylinder is being scaled along the z axis and (because its the parent) has to do the same to the cone.

Anyway, I haven’t been able to fully figure out what is wrong with using character physics. All I do know is that with it enabled, the player is constantly trying to clip through the ground and Bullet is trying to correct that by teleporting you up a tiny amount (thus causing the random up / down motion).

I now about the cylinder scaling, it is just there to know which way the character is facing (I’ve dealt with that by unparenting the camera from the cylinder which will be scaled and using some python to copy the cylinder world position to the camera position plus some offset).

How about that, maybe it’ll be fully functional on 2.80? So far I’ve found incredibly annoying to achieve the simplest things in BGE. Up until recently I was using Unity 4.5 and every aspect of FPS (locomotion, crouching, jump, climb, swim, fly, etc) is extremely easy. I haven’t found yet any sphere casting, capsule casting or anything similar (except raycasting but for some situations it is worse than useless). Is there such a feature?

I believe the feature you are asking about would be the radar sensor, however I could have misunderstood. Also yes, unity does have those features built-in but when you implement those into your game you are essentially just using templates that you are copy-pasting into your game’s code. We have those too, you just need to search for them here on blenderartists (check the stickies on the top of the game engine support forum and the game engine resources forum).

What? Template? Nonono, you’ve got me wrong. Coding a condition to check if a character is grounded or if it can stand (from a crouching position for instance) can be easily done by sphere casting downwards or upwards respectively. Input reading is also simpler. You can serialize entire objects, etc. I’m not talking about some “generic fps prefab” (of which there are plenty both in unity and blender), I’m talking about scaling a capsule without it glitching or the lack of “switch… case:” in python (among other things).

The radar sensor works in a similar fashion, but, since it has a conic shape, the farther you cast the bigger the detection radius, hence it becomes useless for certain situations when you need to cast a constant radius to check for collision

i dont know if this suits your game, but here is a solution i made which might fix your problem, or at least give you an idea of how to solve it, basically when you crouch the camera drops and a boolean property becomes true, which moves a barrier in front of the obstacle up, when the property is false, the barrier is moved back in front

HERE IS THE .BLEND: https://drive.google.com/file/d/0B9SMh1EBaTribl84Q1FlSnVQWHM/view?usp=sharing