Hello @britzl , @Ken
Is there any progress about this behavior or workaround if anyone experienced same.
EDIT : When i try to rotate Z with editor handles 0 to 135 , it rotates to (180,180,45) so somehow engine treats my 0,0,135 to 180 180 45 internally.
EDIT : Finally found the solution :
Arrow 1 euler (0,0,45)
Arrow 2 euler (0,0,135) (this is the buggy euler prints (180,180,45) )
Quaternion rotations of this two objects is :
DEBUG:SCRIPT: vmath.quat(0, 0, 0.38268342614174, 0.9238795042038) hash: [/g_food_garden/trap_arrow1]
DEBUG:SCRIPT: vmath.quat(0, 0, 0.9238795042038, 0.38268342614174) hash: [/g_food_garden/trap_arrow2]
What does it mean :
arrow1 rotated go.get_rotation().w = 0.9238795042038 with in (0, 0, 0.38268342614174) axis
arrow2 rotated go.get_rotation().w = 0.38268342614174 with in (0, 0, 0.9238795042038) axis
Arrow 1
w = cos( angle / 2 ) = 0.9238795042038
angle / 2 =math.acos ( 0.9238795042038 )
angle = 0.78539831133951 (45 degrees )
Arrow 2
w = cos( angle / 2 ) = 0.38268342614174
angle / 2 =math.acos ( 0.38268342614174 )
>angle = 0.38268342614174 (135 degrees )
So, now i have the right rotation of this 2 objects. We can now use the angle to vector functions to move this object kinematicaly.
angle_to_vector = function (angle, magnitude) --angle in radians, i use magnitude to apply speed.
magnitude = magnitude or 1 -- if no magnitude supplied make it a unit vector
local x = math.cos ( angle ) * magnitude
local y = math.sin ( angle ) * magnitude
return x, y
end
EDİT : angle_to_vector (angle) gives normalized direction. I don’t know if this solution may optimized.
Best Regards,