You have to use the “Change Char Axis” node in your character to rotate the collision capsule and force-walk unwalkable surfaces; the “On Unwalkable Hit” event is triggered when the collision capsule bumps into an unwalkable blocking object, if the “Trigger Unwalkable Hits” checkbox is enabled.
Epic’s “Find Look at Rotation” node doesn’t work with non-standard capsule direction (Z up), you need to think about a more complex solution.
EDIT: using the “Make Rot from ZX” node might be a good idea.
New version is up, compatible with UE 4.27.
(THIS IS THE MULTIPLAYER SUPPORT UPDATE - Network Replicated: Yes)
1.36.27:
- Normalized vertical axis to avoid assert/crash with “Change Char Axis” Blueprint node.
- Disabled NetworkSmoothingMode of CharacterMovement by default.
– Linear and exponential modes have important issues if the collision capsule isn’t straight. - Added new FCharacterMoveResponseDataContainer to send the rotation of the collision capsule.
- Fixed network sync of vertical axis of the collision capsule.
– Network clients receive adjustments, movement modes shouldn’t desync anymore. - Converted LandOnAnySurface checkbox to pure boolean type to use it with TGuardValue.
- Added configurable ForceSimulateMovement checkbox to NinjaCharacterMovementComponent.
– Non-owning network clients skip simulating movement if base isn’t replicated.
– Modular corridor and stands of example map aren’t replicated properly (engine limitation?).
3 Likes
Thanks a lot that worked! I have another problem. The walk animation speed when walking up walls is slower than walking on general surface. How can i adjust that?
I never noticed that problem in my example map, did you test there? Or the difference is very subtle?
Hi community! Have an issue dealing with more complex capsule rotation with the Ninja Character Plugin. Would greatly appreciate any input, it’s an amazing plugin and would really like to make it work.
I’m running some smooth capsule rotation logic on tick in my character blueprint. This logic looks like this:
My problem is calculating directions and rotations on angles (especially at 90 degrees). If I print string the normalized cross product for the the NinjaPlayerCharacter_BPs forward/backward movement input, at 90 degrees, X = 1 has turned into X = 0 and Z = 1 . Which basically tells me that the world up does not rotate according to the gravity changes from the plugin. Now, as I’ve learned from @Xaklse , “There is no yaw rotation in a world with arbitrary gravity, unless you use (1,0,0) vector as reference, or another one derived from camera rotation, control rotation, anything rotation… Same problem with pitch rotation and (0,0,1) vector”. How would I go about solving this rotation logic based on that answer? The closest solution I’ve found is this:
But it does not work so well. At 90 degrees the capsule will start to freak out and have a hard time understanding its orientation in space.
Thank you for reading and any input is greatly appreciated! Let me know if more information is needed.
thanks u so much for the last update sir
Fixed it by changing character movement state from Blendspace to blendspace 1d
I’ve solved some of the problems but not all. If I remove the first interp node it seems the capsule will be consistent (no strange sliding downhill or uphill on 90 degrees for example). Perhaps the interpolation was too slow for fast and big changes in rotation when changing gravity. Below is a pic of the blueprint logic and I also added the rotation settings in the ninja movement component and class defaults that I use. However I would much rather use the old logic that uses control rotation to set actor rotation and have the same results as if gravity was “normal” (not arbitrary) regardless of rotation in world space of the capsule.
Here is the logic that works (but does not use control rotation unfortunately) and the class defaults and ninja movement component rotation settings below.
The rotation settings I use are:
Ninja Movement Component
Use Controller Desired Rotation = Checked
Orient Rotation to movement = Unchecked
Class Defaults
Capsule Rotates Control Rotation = Checked
Use Controller Rotation Pitch = Unckecked
Use Controller Rotation Yaw = Unckecked
Use Controller Rotation Roll = Unckecked
For the original logic that uses control rotation to set the actor rotation, which is the logic I want to use, these are my rotation class default and ninja movement component settings:
Ninja Movement Component
Use Controller Desired Rotation = Unchecked
Orient Rotation to movement = Unchecked
Class Defaults
Capsule Rotates Control Rotation = Checked
Use Controller Rotation Pitch = Unckecked
Use Controller Rotation Yaw = Unckecked
Use Controller Rotation Roll = Unckecked
And the logic for it again:
hi, does this only work in the 4.27 engine or can the new features be used in 4.25 ?
Last update with new features only apply to the most recent engine version (4.27).
Your greenish graph doesn’t make sense, it really interpolates ActorRotation with ActorRotation.
I tried to obtain a solution with blueprints, my first try didn’t work because RInterp node doesn’t keep the original capsule Z axis:
So the right way is to always keep the original capsule Z axis:
I hope the graph explains itself, let me know if you don’t understand it.
ah ok, Is there a way to keep the character from falling off? I want it to keep walking to the other side, as of now it just gets to the edge, does like a little hop, and it can fall off the edge, can it keep walking around like a spider?
I take my previous post back! This variation you created that projects the vector onto a plane works. As for the issue I had: I completely missed that I had set one of my states wrong and so the logic you proposed was never executed. It’s what can happen after many hours of working, haha, I’m sorry for the confusion. It totally works! Thank you very much.
Now, the rotation I get from the “Make Rotation ZX” at the end of the calculation, could I potentially use that as my control rotation variable to get “normal” values that work in arbitrary gravity for my animation blue prints? In other words, does it provide the same values as “Get Control Rotation” would in normal gravity so to speak?
Thank you and apologies again for this confusion. I will delete my previous post.
UPDATE
It seems Make Rot from ZX does not give me the full range of control rotationm, I assume because it does not take all rotation into account. If there was a way to set “Get Control Rotation” to a variable that gave me the control rotation as normal, i.e. treat new gravity direction as the new control rotation, that would solve a ton of my problems. Any input is greatly appreciated. I will keep trying things out.
I figured out how to make the camera smooth on low poly terrain Smooth Camera for Ninja Character Plugin - YouTube
1 Like
well thats awsome
SOLVED
I unrotated the forward vector and then made a rotation from x vector, skipped the delta and it works!
For example I’m trying to get this kind of logic to work in my animation blueprint. It drives my aim offset, so the head looks at the camera direction, it also runs the spine rotation. I tried to use the variation you made and project the control rotations forward vector onto a plane to build new yaw and pitch for the 2D vector you see in the code below. It doesn’t work when I’m close to 90 degree angles or on 90 degree angles. I also tried subtracting the capsules world rotation from the control rotation to get a local rotation, but it’s the same problem around and on 90 degree angles.
Glad you figured out how to fix the previous stuff. Obtaining pitch and yaw relative to capsule rotation is tricky, I wonder if I can make it easier for blueprint users.
There is a floating very long platform/stick placed in the green playground area (right side) where you move like a spider, it’s the only cumbersome solution I can offer you.
Really nice and smooth! Keep it up and thanks for showing it’s possible.
1 Like