Make Character the same as Pawn? (Planet Physics)

Development Programming & Scripting Blueprint
, ,
1

For context, I’m working on a game with planet physics in a first-person template. Yes, I already know about the post which explains how to do this with the third-person template, and I haven’t gotten anywhere with making that work for first-person, so I’m doing it from scratch!

Recently I came across an awesome tutorial vid which really helped me to get it working. It still does it in third-person but the method works just as well for first-person. The catch is… it only works when you use a Pawn blueprint.

I’ll link the vid here for those curious: https://youtu.be/l2J45z6aoJQ?si=4M_1J9MbuQD_xner

In the video and in a reply to one of the comments, he talks about how he tried to get this method working for a Character blueprint, but really weird rotation issues were happening that he had no idea how to fix. Unfortunately I am running into those same problems when I try to use his method in my FPC blueprint.

The only difference between the two is the CharacterMovement component, which begs the question: what could the CharacterMovement component be doing to the blueprint to cause such a weird difference in behavior like this? And if we can figure out what that difference is, what can be disabled to make it function like the pawn?

Thanks for reading!

2

Hey @Piquit!

Not that, it’s due to the capsule component’s behavior of always staying upright.

Nope, capsule component cannot be removed. And I believe you’d actually want the capsule component to exist since your character utilizes the character movement component. So I’d recommend not switching to a pawn class since the character class fits your use case. Instead, you can try to implement your own planetary gravity logic that works for characters. It’s totally possible! Because I remember helping someone on the exact same topic a couple of months ago. But I also wanna add that I do remember encountering issues back then, so it may not be too straightforward. Lemme just mention one thing btw, you can rotate the capsule component by constantly setting it’s rotation, perhaps this can help as a guidance. Of course, you can still consider using a pawn class. We don’t have much of a context here, maybe it’s already sufficient in your case! While it doesn’t show us the full picture, if your planets are really small and the movement mechanics will be unusual, meaning the game’s more about jumping between planets and not exploring them, (which all come down to not utilizing the char mov comp) it’s safe to say you’d be better off using a pawn for this purpose. Keep in mind that something that also fits my description above may not be what I imagine, so if you’re unsure, get back to us with more context! :blush:

Hope these can help :innocent:

3

Thanks for the advice! I kept fiddling with my blueprints, and it did actually come down to something that you mentioned: “it’s due to the capsule component’s behavior of always staying upright”

For whatever reason, the Pawn blueprint’s capsule doesn’t really mind being rotated around however you want it to. However, in the case of the Character blueprint, it turns out that the more you rotate the Character’s capsule away from world-up, the more its built-in movement code and velocity projection fight you. As the character moves around the planet and rotates away from world-up, the CharacterMovement keeps calculating velocity based on the ground plane… because this wasn’t built to handle planet physics.

I could just be talking nonsense, but that’s my best guess for why the following fix worked.

For future people trying to do what I’m doing, here’s the fix!

Before taking my advice, make sure to do what the tutorial video from the original post does, except for making custom code for movement; that’s already provided inside the FPC blueprint, and we can still use that code no problem!

My issue was caused by rotating the main capsule component, with the method pictured here: Imgur: The magic of the Internet (the Z input is the same as the tutorial)

We need to keep the main capsule component’s rotation exactly the same and never change it so that the CharacterMovement’s code doesn’t break. Instead, we can make duplicate capsule components that are attached to the main one, and use those in our nodes instead! I made a child capsule called “Capsule of Pain” and changed my code to this: Imgur: The magic of the Internet

This next step is optional, but I made another child capsule called “Capsule of Pain 2”, which is a child of the first Capsule of Pain, but I have extra code that changes its Z rotation based on IA look, and it has the camera attached to it. Basically it determines what direction you’re facing, but if you use something else to do that that’s fine too! All you gotta do is plug in said component into the default movement code, like this: Imgur: The magic of the Internet

And just like that, the tutorial method works in a Character blueprint. Hopefully my imgur links never break!

4

Character Movement Component does allow for custom movement modes. In fact you could possibly get this working by simply changing the movement to Flying which allows for rotation of the capsule component. Movement Mode (None) disables CMC for the most part.

You will have to write your own movement logic if you go this route though. There’s also walkable slope angle that you can adjust as needed in real-time.

Regardless the approach you will be disabling and enabling CMC depending on the capsules orientation in world space.

5

There’s also this

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.