DynamicAnimControl with CharacterControl conflict of

What is IMO? Can you send a link or address?

1 Like

IMO = “In My Opinion”

3 Likes

ok :sweat:

@icyboxs I have learned that and many other abbreviations from this forum. Just stay here for a while and you will end up using them yourself :slightly_smiling_face:

I still do not understand some of them that people use in the Discord channel but Google has always helped me in finding the meanings :wink:

I suspect these types of abbreviations are harder for folks who are using a full text translator. I can’t even imagine how I’d realistically do it if I knew none of the other language.

Note: not picking on you using an abbreviation at all. Just pointing it out.

…icybox is using that translator so well we can’t notice it anymore.

2 Likes

After a period of reflection DynamicAnimControl with CharacterControl conflict of
I’m going to solve the problem in two ways.

  • Use 2 different physical worlds(The disadvantage is that it takes up resources)
  • Use DynamicAnimControl with CharacterControl switches.
    CharacterControl on while moving while standing CharacterControl off and DynamicAnimControl on.(The disadvantage is that they cannot be satisfied at the same time)

  • The Custom Character Controller does not use the minie Character controller (yaRnMcDonuts use this method I’m not sure what are the disadvantages of this method)

It works and it’s my fault that I initialized it in the wrong place and that caused the problem

 protected void onEnable() {
        bulletAppState.getPhysicsSpace().add(player);
        bulletAppState.getPhysicsSpace().add(dac);
    }

Initialize in onEnable and everything is fine.
The only problem is that in the video, we can see that the DAC is slightly backward when moving. I wonder if there will be any effect on it. I will try further

1 Like

The disadvantages of the method I use depend on what type of game your making. In my case, I actually find less realistic character physics advantageous because my game has hordes of enemies, and the ability for heavier or faster enemies to pass through other enemies and push each other in a unique (but slightly unrealistic) way prevents enemies from getting stuck on each other in tight corridors which can happen with CharacterControl. And to be honest, I think CharacterCotnrol actually ends up appearing equally unrealistic in its own way since humans are not actually rigid capsules and will rotate and squeeze past one another if they get funneled through a tight corridor in real life.

I also found it ridiculously hard to do clean client-side prediction with character control, as compared to using Collidables which is much easier since you’re not trying to fight and negate internal physics forces on the client-side every time you get a message from the server that contradicts what the client predicted. I never figured out a way to get CharacterControl networked without some type of annoying rubber banding happening one way or another, but as soon as I switched to a collidable based character control I immediately got client-side prediction working cleanly.

I would also caution against using 2 physics states at the same time unless your game is not multiplayer and is going to be a small scale. If players host a match on their own device, then that means they could potentially be running 4 physics spaces on a single machine (assuming you are doing client side prediction and thus need the physics state on the client side as well).

If I have time sometime in the near future and if there is enough interest, then maybe I will try to make a basic implementation of my light-weight character control that uses basic Collidables so others can try it out.

2 Likes

Thank you for your reply and supplement

1 Like