?
Do note: for a physics object it is very important to give it accurate size and mass. I see so many people post test cases with short fat characters (1 meter tall, 1 meter radius = extremely fat midget)
I always had a capsule of 1.2f radius, 3f height. Is that considered to be an extremely fat midget? It used to work just fine with CharacterControl. Here’s an example that doesn’t work with BetterCharacterControl. See top right corner I output player_physics.isOnGround() function that comes with it:
I tried with mass = 10f, 100f and 1000f and it doesn’t change anything. I also tried with height = 4f just in case it was too fat of a midget to work with 3f height but it’s the same: As you can see even tough it’s on the ground, on slopes it says it’s not on the ground when polling isOnGround()… so YEAH… back to square one I guess. This is turning to be a nightmare… 3 hours just to migrate from CharacterControl to BetterCharacterControl and all of this to finally realize that the problem is still exactly the same as before…
Well, if this is supposed to be a person… then 1.8 meters in height, and about 0.3 meters radius… and maybe 75 mass? (not sure what units mass are in).
Someone 2.4 meters wide wouldn’t fit through doors… barely fitting through some garage doors I guess.
OK thanks for replying. I tried what you mentionned altough I’m asking myself… isn’t everything supposed to be relative? I mean… OK, if 1wu = 1meter, but who knows better? This is a virtual world, so it does not necessarily mean it’s the case right? It depends on the models size, the terrain scale, pretty much everything might be off in scale IF 1wu has to be 1meter. But what does it effectively matter in this scenario? If all things are in a scale that relatively makes sense to each other, I don’t see how it would matter?
So… back to your suggestion: at BetterCharacterControl(0.3f, 1.8f, 75f); (0.3f = radius, 1.8f = height and 75f = mass) it sits on the ground and doesn’t move at all when I press W (or any other movement keys). If I make the player start in mid air, it falls on the ground correctly, so there is definitely gravity attached to the control. Anyways, on idle on the ground, it tilts back and forth very rapidly, like it was unstable on the ground or something but as stated it does not walk at all. I tried also with mass 1f and also with mass 200f and it didn’t change anything. I also tried to change the walkDirection.addLocal(camDir.mult(3)); to walkDirection.addLocal(camDir.mult(10)); and to walkDirection.addLocal(camDir.mult(100)); but it only made the player go through the floor probably because it was too much speed in between frames for the collision detection to pick up and restrain the player from going through the floor.
This situation is not getting better at all by making the player shape taller and thinnier it seems… Any other suggestions before I just roll back nearly a day of changes and go back to the good old CharacterControl that was working nearly perfect (especially after seeing the impressive number of things I’ll have to hack my way around to fix)?
Basically, here is the list of NEW problems arising when trying to migrate from CharacterControl to BetterCharacterControl (besides fixing almost 40 other lines of code that were causing the compiler to not be happy, deprecated functions, incompatible types, etc…):
-
Player is not always picked up as “on the ground” especially in slopes, even very subtle slopes (as seen using the isOnGround() function)
-
Player can climb slopes, haven’t found any threshold function to make steep slopes unwalkable.
-
Player flies in the air when running too fast on slopes (and also by looking up… before I subtracted the Y factor from the direction vector).
-
Player bounces like a rubber ball when hitting the floor and the higher it falls, the higher it will bounce off the floor when landing.
-
Can’t seem to remove gravity, not that it’s that important, but I do want to immobilize the player in air on certain occasions.
BASICALLY… all of these problems to fix just to be able to use isOnGround()… that does not even work half of the time for some reason… I mean… the CharacterControl+collisio+PhysicsTick hack was working almost perfectly in all situations, so I don’t want to sound like a forever disatisfied guy, but… at this point, unless somebody figures out how to strip all those “features” out AND make the isOnGround() function always work perfectly even in slopes, I don’t see the point of pulling my hair out for ANOTHER DAY of work lost AND using more RAM/CPU (OK not much more but still) for a more complicated control while my previous hack was working 99% of the time.
You know what I mean?
Thx for reading BTW, I’m very happy that you try to help.
Fun fact:
BetterCharacterControl(0.3f, 1.8f, 75f);
BetterCharacterControl(0.3f, 1.7f, 75f);
BetterCharacterControl(0.3f, 1.6f, 75f);
BetterCharacterControl(0.3f, 1.5f, 75f);
BetterCharacterControl(0.3f, 1f, 75f);
They all go straight through the floor… pretty weird huh?
EDIT: Wow, BetterCharacterControl(0.4f, 1.7f, 75f); picks up slopes like 90% correctly. It’s almost accurate except for steeper slopes, but it’s still WAY WAY better than BetterCharacterControl(0.3f, 1.8f, 75f);
Is this normal that a small capsule shape change can make so much difference?
EDIT 2: I think actually, the problem is the capsule shape itself that is bound to the BetterCharacterControl. It looks as if the BetterCharacterControl only collides on its 10% bottom of the capsule shape, meaning that on slopes, since the SIDE of the capsule might be first/only to collide, it ignores it and thinks it’s not on ground at all. I’m pretty sure about this assumption as slightly changing the capsule shape changes the results DRASTICALLY… so to me, this is still hacking and may not be working any better than the old hack I had for CharacterControl (which collided on all its surface rather than only on the bottom end of it).