Why is my character is sliding (when it's not supposed to) and the gravity not working right?

[NEYSE_O001]

As you see in the video, in some surface/inclines character is sliding, as if it is falling down and just sliding on a buldings surfaces, instead just walking.

The character is rotating here not map, and, everytime the player presses Space key, gravity must be modified via line trace, it simply takes impact normal and that’s it.

So if I understand correctly whatever surface the line trace hit, no matter it’s incline, the character must be able to move along it perfectly normally, but it’s not the case yet.

Thanks for you guys for your helps in advance

@Mind-Brain @gardian206

[Mind-Brain]

Hey @NEYSE_O001!

The gravity “not working right” is because your capsule component is still there with collision on. You need to select it, go to “collision” in the details and set it to “No Collision”.

Then, select your NEW collision (the little box) and set it to collide with what you need (you could just use the “Pawn” preset).

The sliding is in your Character Movement component under acceleration, max speed, and braking.

[gardian206]

if the AboveArrow is attacked to the root component, why are you setting its rotation in addition to setting the gravity, ALL SceneComponents that are attached to the RootComponent will be rotated based on the Gravity.

you are also setting the Relative Rotation of the SceneComponent to be based on a World PoV Normal vector (look at what these changes are actually doing: for the AboveArrow in Rendering→HiddenInGame = false)

• if the actor currently has its gravity set to the default of -Z, then the AboveArrow will have an orientation pointing exactly Up
• if the actor then has its gravity set to a <1/sqrt(2),1/sqrt(2),0> ( ~.707) gravity the Up Vector SHOULD be <-1/sqrt(2), -1/sqrt(2), 0>, which is what the world ForwardVector of the AboveArrow would be just before you set its RelativeRotation
• the new world ForwardVector of the AboveArrow would close to (floating point approximation not withstanding) < -sqrt(2),-sqrt(2),0> (~1.414 ) which would be pointing to the left (because a zero-rotator would be pointing forward, and the windings of a unit circle in trig goes counter clockwise)

the current UpVector of an actor for the purpose of your line trace can be obtained in a couple ways not requiring you to hold an ArrowComponent (keep it for editor visualization but don’t rotate it, and you don’t need to actually reference it, and probably mark it as EditorOnly)

• Negate(GetGravityDirection()) from MovementComponent
• GetCapsuleComponent→GetUpVector() // in most cases the CapsuleComponent is the RootComponent, so therefore its transform is the Actor's Transform

keep in mind that the UpVector is defined in World space that is why you don’t need to convert it into world space to do your line trace.

try drawing your vectors using DebugDrawLine. I have a strong feeling that your gravity is pointing in a different direction then you believe

// these do not need to be actual variables, labels are for text.
// this is directly doable in Blueprints
Tick()
{
    VectorA = GetActorLocation() + <100,100,100>
    VectorB = VectorA + (100.0f * GetGravityDirection())
    DrawDebugLine ( VectorA, VectorB, Yellow) 

    VectorC = VectorA + (100.0f * GetCapsuleComponent()→GetUpVector())
    DrawDebugLine ( VectorA, VectorC, Pink)

    //and for sanity sake add this too see actual gravity
    VectorD = VectorA + (100.0f * FVector::DownVector) // <0,0,-1>
    DrawDebugLine(VectorA, VectorD, Green)
}

I have a strong feeling that it looks like it is sliding to the side because your GravityVector is not oriented properly.

are you using the Box2D physics, or are you using the 3D physics system? the Box2D physics system might be overriding your character’s orientation to be alternative to the Gravity based UpVector, and therefore it looks like you are sliding to the side.

[gardian206]

capsules components in a gravity frame will only slide if the angle of incline relative to gravity is greater then “inclineMax” which is the behavior of all colliders set to Collide with WorldStatic and WorldDynamic, so even a BoxCollider would slide as well if the angle of the surface relative to Gravity frame is greater then “InclineMax”

[Mind-Brain]

Ah, I didn’t catch the first part of the video being “Normal” gravity behavior. Yes, it’s almost like it’s sliding against a wall during a jump.

[NEYSE_O001]

Yes, I am using that Arrow Component to set a forvard vector in the name of all components practically.

I am certainly not good at bp math as you are but theoretically does not the current system makes sense? It already, at least as seems works in mostt situations? I am pretty sure there is much better ways to achieve that but in regards of math I don’t see anything wrong. Enlighten me please.

you - the current UpVector of an actor for the purpose of your line trace can be obtained in a couple ways not requiring you to hold an ArrowComponent (keep it for editor visualization but don’t rotate it, and you don’t need to actually reference it, and probably mark it as EditorOnly)

me - I didn’t understand this part. So the resoult in final export project and editor could be different you mean?

The physics it’s not Box2D, it’s standart 3d physics I didn’t use any physics assets, plugins or anything. But also this means your theory (which I am apprechiated for) can’t be completely right.

(edit) the main problem (because there are many problems) could be simplly because the cylinder collision is above the arrow component and not rotating with it, so in some inclines surface hits the beveled area and make the character slide. I certainly have to fix at least this one.

[NEYSE_O001]

(post deleted by author)

[NEYSE_O001]

Yes I didn’t calibrate the collisionn properly, so you mean it’s simply, the character is sliding because the surface is hiting the beveled area? Yeah it could be really that simple at least partially.

[gardian206]

please… your math doesn’t work, and it is the smaller set when it does. This isn’t “Blueprint Math” this is Trigonometry. Blueprints are meant to make these systems easier to work with, so in order to get your game idea to existence isn’t locked behind multivariate calculus based physics, and 2 years of Programming.

the tick function to validate directions (for the most part if we are on the axis angles I expect to see maybe 2 or 3 lines)

the assignment, and your proposed ArrowComponent→SetRelativeRotation()

for the rotations of the cubes pay attention to the Rotations about Y (the green accented box)

during the play session pay attention to the arrows direction, and the behavior of the sliding.