Setting rotation to acos breaks everything

[delicate solstice]

Hey, I have a characterbody3d with AI, and this prints perfectly as the body moves around:
acos(velocity.x / velocity.z)
but if i try:
rotation.y = acos(velocity.x / velocity.z)
it somehow breaks the entire object's physics/AI, anyone know why that is?
Setting rotation.y to other things works fine by the way, the problem only comes up with inverse trig

[high gate]

I usually avoid trig if I can. What is this supposed to do? Look in the direction it's moving?

[craggy totem]

in my experience using the rotation and angle functions built into the Vector-Type are simpler and more performant than using the trigonometric functions directly. I'm guessing that you want to rotate the body into the direction it's moving on the xz-Plane. Putting the x and z components of the velocity into a Vector2 and then calling Vector2.angle() should do the same, while considering edge cases like one of the components being 0.

[delicate solstice]

Why avoid trig? I actually used a ton of trig for the directional knockback system :o
But yeah exactly, this is supposed to make it look in the direction it's moving

[delicate solstice]

I see. I didn't even know you could use Vector2s in a 3d scene, i don't know why i just didn't think of that. I also didnt know about the vector.angle function, that's really convenient here. You're exactly right on the intended function and that does sound a lot simpler, so ill give that a shot. That also opens up a lot of possiblities that i can use 2d vectors like this.

To be honest I'm still curious and confused about the trig attempt, i cant believe every part of the physics breaks from that simple line, especially since the trig works fine when not set to rotation

[craggy totem]

One thing i just remembered is the fact that acos like all invers trigonometric functions can only output in a range of 180°, not the full 360°. You have to check the quadrants your vector lies in and add to the result accordingly, which is what the angle() method of vectors does. So there definitely was a problem with your approach no matter if you set the rotation or not, you probably just noticed because of that.

[delicate solstice]

Interesting, i actually tried accounting for that not because i knew about that, but because i thought the negative values might be affecting it. So i originally made a long if statement tree checking which quadrant it's in and just doing the trig with absolute values and adding radians to put it in the right quadrant. But still had the same physics breaking output

[craggy totem]

I guess it's hard to tell what exactly the issue was. The question is if using Vector2.angle() fixed the issue.

[twin steppe]

if it broke the AI, that means the AI relied on the body not rotating. a simple fix would be only rotating the sprite and not the whole node, though i dont know if you tried that yet

[delicate solstice]

It works :D thanks a lot.
The thing is the question of what the issue was would be very educational and interesting I think

[delicate solstice]

Well actually the AI only breaks when setting the rotation to a trig function. I don't see how the AI could rely on the rotation anyway because it's totally unreferenced, I only did velocity things with it for it moving and getting hit etc. super odd right?