choppy movement was caused by line 3967
// Abort if angle between new and old capsule 'up' axis almost equals to 0 degrees.
if ((DesiredCapsuleUp | CurrentCapsuleUp) >= THRESH_NORMALS_ARE_PARALLEL)
{
return;
}
When I disable that check, the character (capsule) rotation looks smooth. I’m not sure if I can simply disable that check though, might impacts performance? (see no hit in my current test level, but not sure about replication and multiple active characters)
Interesting finding. It would impact performance yeah, I will look into lowering the 1 degree change requirement and/or make it configurable.
I assume you still experience gimbal lock, right?
Yeah gimbal lock remains. Did a quick debug, but need to investigate a bit further. I also read about the native yaw/pitch funcions causing locks for people making 360dof controls. I think they just do a rotation.x+=, and dont use quaternions to add rotation. Which is destined to cause gimbal locks. Was planning on looking into that first, and maybe override the add control yaw/pitch functions to add rotation according to the component rotation.
thanks
Frank
I tried adding override functions for the addinput yaw and pitch (from pawn.cpp). I used the forward vector of the movement component to make those relative, however that didn’t seem to fix it.
After some debugging I noticed the controller Z axis gets mirrored when approaching the opposite pole (I think according to the gravity Z value).
I changed OnCharMovementAxisChanged function in NinjaCharacter.css to
void ANinjaCharacter::OnCharMovementAxisChanged(const FVector& OldAxisZ, const FVector& CurrentAxisZ)
{
// Rotate the control rotation of the Controller if needed.
if (bCapsuleRotatesControlRotation && Controller != nullptr)
{
FTransform trans = GetTransform();
const FQuat QuatRotation = FQuat::FindBetweenNormals(OldAxisZ, CurrentAxisZ);
trans.ConcatenateRotation(QuatRotation * ControllerRotation.Quaternion());
trans.GetRotation().Normalize();
Controller->SetControlRotation(trans.GetRotation().Rotator());
}
}
Added to NinjaCharacter.h:
#include "GameFramework/Pawn.h"
public:
FRotator ControllerRotation;
public:
virtual void AddControllerPitchInput(float Val) override;
virtual void AddControllerYawInput(float Val) override;
and added to NinjaCharacter.css:
void ANinjaCharacter::AddControllerPitchInput(float Val)
{
if (Val != 0.f && Controller && Controller->IsLocalPlayerController())
{
ControllerRotation.Pitch += Val;
}
}
void ANinjaCharacter::AddControllerYawInput(float Val)
{
if (Val != 0.f && Controller && Controller->IsLocalPlayerController())
{
ControllerRotation.Yaw += Val;
}
}
makes the controller rotation match the gravity (movement component), and stops the gimbal lock. However, because of using the transform to make the rotations relative, enabling the option Orient Rotation to Movement doesn’t work correct anymore. So unfortunately it still might not be the correct approach… Any ideas to get those rotations relative using something else than the transform?
cheers
Frank
Hey , thanks for awesome work! Have been playing around with the plugin for a few days now, and noticed one strange thing: character’s velocity gets smaller for some little amount each time he steps on sloped surface. Felt it myself with walk speed cranked up to huge amounts, then tested with blueprint which compared current and previous velocity values, and current<previous happened exactly the moment character changed angle he stands on. Is intended behaviour? If it is, can effect be somehow cancelled out, so character remains constantly accelerating? Hope I explained the problem clearly 
Edit: Did more testing with bare NinjaCharacter_BP by just tweaking CharacterMovement parametres, found out that oddity is especially noticable with high MaxWalkSpeed and low MaxAcceleration. For example I set those two to 3000 and 512 respectively, ran into the loop on NinjaTestMap at max (ie 3000) velocity, after that quickly slowed down to something around 1770 and stayed like that as long as character continued making circles. I use vectorlength of GetVelocity to measure current speed.
Edit2: After more researching I came to conclusion that the reason may be some component of velocity being lost during angle change, same as you land after jumping/falling (for example if you landed on flat 0deg surface then Z part of fall velocity will be ignored). Tried forcing the character to maintain same speed when stepping on slope, but no luck.
Edit3: Nevermind the previous blueprint, here’s one that works. VHorizonAngle is an impact normal vector from CurrentFloor component. product (ie cos) between its current and previous values pretty much determines amount of speed being lost during angle change, which can be cancelled out very easily.
I updated the NinjaCharacterMovementComponent.cpp to work with 4.20 (Epic did some changes causing errors in current code).
I can post it here if that’s okay with , just let me know!
cheers
-Frank
Hi,
I have everything working great, but I was just wondering if anyone has any suggestions on matching up gravity for other physics actors? I am fairly new to the engine so it might be a basic thing I am missing. Most of the solutions I have found have been pretty cheesy.
Hi,
Any downloads available for 4.20?
It’s ok Frank, feel free to post your version of the updated code; I just downloaded 4.20 and will update the code one of these coming days.
Unfortunately for you Xenomatic, last time I checked, having custom gravity for physics actors requires changes in the engine, which were already posted on GitHub for old versions of the engine.
Thanks for the feedback STourist, will review that example in detail.
please update to 4.20!
For other actors you could set gravity to 0, and add a constant linear force in the same direction your gravity points. It’s not the cheapest way, but if you tweak it so it’ll only trigger in a close range around the player i think you’ll be fine.
I’ll try upload my 4.20 changes tomorrow
I uploaded the files for 4.20 here:
http://www.mediafire.com/file/e6qh93…acter.rar/file
just overwrite the existing files and you should be good to go (only 4 are updated, so keep the rest of the previous files in place)
Please note that there’s currently a bug in 4.20 which causes intellisense to fail to include your header files. Resulting in a ton of compiling errors!
see post on how to fix that:
https://forums.unrealengine.com/deve…02#post1504102
=vODHoUT5URs
in addition, don’t forget to add these paths also for the plugin to get properly build:
..\..\Plugins\NinjaCharacter\Source\NinjaCharacter\Private;..\..\Plugins\NinjaCharacter\Source;..\..\Plugins\NinjaCharacter\Source\NinjaCharacter\Public;..\..\Plugins\NinjaCharacter\Intermediate\Build\Win64\UE4Editor\Inc\NinjaCharacter;..\..\Plugins\NinjaCharacter\Source\NinjaCharacter
they say it will be fixed in the next hotfix (4.20.3)
cheers!
What a surprise present from Epic… broken Intellisense. Thanks for the info Frank!
Ninja Character plugin for Unreal Engine 4.20.2 is up! Go to >> UnrealEngine · GitHub << and grab the ZIP file (not the green button) from the link posted at the top part (if error 404: log in to Github, link your UE4 account to Github).
is for C+±based game projects.
://forums.unrealengine.com/unreal-engine/announcements-and-releases/1529704-4-20-3-hotfix-released
I just uploaded a new version with very minor code changes and an important change to fix non-Editor compilations.
I also added explanations about the input settings you need to test the sample content.
Thanks for the update !
a couple posts back you mentioned a replication bug. I was wondering what bug exactly, since I’m planning to add multiplayer to my project soon. Doesn’t it work at all, or just some minor things?
thanks
Frank
Thanks for the update !
Replication generally works, I noticed only one thing… if the character is on a moving surface - he shivers at clients
Sorry for the big delay Frank.
A problem with ControlRotation happens to me with the “Run Dedicated Server” checkbox enabled:
…com/=O-wNtOn_X7c
(RGB is XYZ of ControlRotation)
The rotation is not right after changing between floor angles with big or very small differences.
behaviour has changed for the better after upgrading to 4.20, the camera was also borked.
.
Could you please elaborate a little more or show us a video?
…com/=6ink4WGgbT4