I need to figure out a good way to find 360 degrees

v4.1.3.stable.official [f06b6836a]

This is terrible. I keep searching for this every day. Every day I only find hope. I try to convert to simple 1 degree turns. Every time the code simplifies it but records the results in Radians. Every time I try to convert the radians to degrees it does just that, but in the ongoing simulation the results are still calculated in Radians. Then I try to convert my simulations to Vector3 it asks for an angle which is in radians. How do i properly do this. Because the simulations don’t add up my positions properly. After several left and right turns they end up as float numbers outside of the normal Single Digits I need. You can see it in the field notes. It starts as single digit numbers. Then it gets lost! What gives?

Could you show the code for what you are trying to do? I understand that Godot uses radians under the hood, but what are you having trouble doing in degrees that can’t be done in radians?

You mention you do convert from radian to degrees, you can convert back with deg_to_rad or set the rotation_degrees property

It the same code. I’m not moving anywhere without cleaning this up. It’s just one object on the ground. With a camera watching. It is a sphere. I can use information printed to compare to the label. But, like I said it keeps jamming in the delta. After jerking it around it starts to get stuck on floats.

extends RigidBody3D

var direct = 0.0
var punctual = 0.0
var cage = 0.0
var dol = 0
var doll = 0

func _ready():
	print("erest")

func _physics_process(_delta):

	directed()
	roll_cage_l()
	roll_cage_r()
	$Label.text = str(cage)

	if Input.is_action_pressed("ui_right"):
		cage_r()
		dol = 1
	else:
		dol = 0
	if Input.is_action_pressed("ui_left"):
		cage_l()
		doll = 1
	else:
		doll = 0
	if Input.is_action_pressed("ui_down"):
		pass
	if Input.is_action_pressed("ui_up"):
		pass
	if Input.is_action_just_pressed("ui_accept"):
		print(cage)
		print(self.rotation_degrees)

func directed():
	pass

func cage_r(): # This is negative value
	if cage > -30:
		self.rotate(Vector3(0,0,-1), deg_to_rad(1))
		cage -= 1

func cage_l(): # This is positive value
	if cage < 30:
		self.rotate(Vector3(0,0,1), deg_to_rad(1))
		cage += 1

func roll_cage_r():
	if doll == 0:
		if dol == 0:
			if cage > 0.0:
				cage_r()

func roll_cage_l():
	if dol == 0:
		if doll == 0:
			if cage < -0.0:
				cage_l()

Oh well the RigidBody3D can’t be controlled directly, you need to apply forces. Try using apply_torque_impulse or changing the node’s type.

Here’s an example using apply_torque_impulse but keep in mind you need to use different values when dealing with forces. We’re talking Kilograms per radians.

func cage_r(): # This is negative value
	if cage > -30:
		apply_torque_impulse(Vector3(0, 0, -1))
		cage -= 1

func cage_l(): # This is positive value
	if cage < 30:
		apply_torque_impulse(Vector3(0, 0, 1))
		cage += 1

I didn’t ask you to direct my project. All I want is to find out how to permanently change operations to degrees. 1 degree is preferred.

It’s actually very strange with.

var tack = Vector3(0,0,1)

func cage_r(): # This is negative value
	if cage > -30:
		$RigidBody3D.apply_torque_impulse(tack * deg_to_rad(-1))
		cage -= float(1)
		
func cage_l(): # This is positive value
	if cage < 30:
		$RigidBody3D.apply_torque_impulse(tack * deg_to_rad(1))
		cage += float(1)

It behaves even worse. It will turn about 779.8 degrees in any direction and stop.
But, worse of all. It’s the opposite of what I’m trying to do. Because I need it to spring back into position. And, that’s still a problem. Because I don’t know how to Capture Vector.Zero and Freeze.

Do you understand what 30 degrees is?

It like this many notches from there to here;

Note sure exactly what you want, but I watched a video yesterday where this guy made a collectable coin. He rotates the coin with speed value, but also shows how to convert that to degrees.

YouTube : BornCG : Collectable Coin

I don’t mean to interrupt anything. But, I strictly got one thing going on here. I don’t think it’s that desolate;

How many degrees per frame does the character turn?
How many tics per frame would equal 30 degrees?

That doesn’t make sense. It’s supposed to be 30 tocks in any direction. Every time by 1 degree. Does that make sense?

It actually looks pretty sweet in Godot.

Have you looked up any car tutorials?

But it is turning, again the rigid body speaks in terms of kilograms per radian, so putting deg_to_rad(1) is 0.017 kilograms of angular force, and it won’t stop spinning until it sleeps.

I think you do want to change this node’s type to something visual instead of a physics object.

All the other suggestion are worse. A CharacterNode3D is an empty shell, weightless and motionless. The documentation only describes consuming a CharacterNode3D with striped lines of code. For compromising the motion, weight, behaviour, gravity and art. That’s messed up!

Oh I just realised I made a small mistake. I was supposed to ask Why does the animation rotation 3d need to be normalised? It was supposed to be easier. I could have just used the animation player.

Normalised? I never mentioned normalized rotations, nor did StormWHM. Are you using quaternions? Those need to be normalized or else a 4D sort of scale could also be applied, the engine will try to make this not happen.

I have to say. After some time with the program again. While doing problem samples from the forum. I have to agree that you are right. I just have to use physical processes. While using the transform features is not recommended in this case. There’s a million reasons to use transforms. Like in real world game application that uses parts and take aways in the menus and 'normal simulations during gameplay. It’s not recommended because it’s manipulating the editor transform values. That’s why it’s so bad for the FPS. So the physics interactions are much better made for this application.

I went to the tutorial again. I found it. The rest of the code should not be a problem. I found how to add the animation keys. And, the whole normalised property.