Happy so far w an ECM (sister company) Mechanika. Very similar looking build and materials.

You’ve got more knobs to twiddle it looks like. Enjoy!

To clarify - I think your proposed grammar is valid but the phrasing is uncommon. It’s not a phrase I would expect to hear. Though I would understand the gist of what you’re expressing.

Best sounding recommendation probably depends on context and ‘the thing’:

There’s a concept I don’t understand.

There is something in the box I don’t recognize.

There is a feature of the coffee machine I haven’t figured out yet.

There’s a Greek word in the original text that I don’t know.

My guess is it’s likely not a bug but an unexpected (by you) interaction of the tool script with whatever layout you’re doing.

If you can post example code demonstrating the problem someone will probably be able to pinpoint what’s happening.

What if I told you… every day is coffee day.

Sounds like you found a workaround.

There might be some tricks here that could help too:

https://docs.godotengine.org/en/stable/tutorials/audio/sync_with_audio.html

I think your supposition about using ik just to capture (key) animations is right. I wouldn’t delete the bones after because you might add or tweak the animations later.

Then you should be able to -X the scale for whatever the root node 2d of your character is.

Maybe helpful: https://ask.godotengine.org/110222/possible-animation-player-deals-animating-position-rotation

Here’s a nice tutorial vid - simpler arcade-like control than my example. Looks like this is for Godot 3.x but the concepts should translate to v4 pretty closely.

https://www.youtube.com/watch?v=RsrwmAme_WA

I think I have it working as you describe - in the latest version on GitHub. That is more complete now than the code snippet above. See if that helps.

Now for no good reason I added flaps that rotate with the controls. Definitely feature creepin. I’m out! Good luck op!

Not shown in the code here for simplicity, but in the project I added a little bit of yaw drift when banking.

I’m sure there’s a more accurate way to simulate all this. Just messin around.

True. Just showing roll and pitch. This is not op’s code… oh perhaps that’s the thing op really needs to see though? I’ll update the example to show it…

(Not op, just an example)

I don’t know an optimal answer here. I see various discussions online about flight control variants. However, here is a simple example I set up out of curiosity. Maybe useful? I’d like to hear about what you end up with.

Project code at: https://github.com/pipehat/godot41_flight_controller_example

————————————

plane controller script:

extends CharacterBody3D

var print_delay = 1
var next_print = 0
const SPEED_MPS = 500

func _physics_process(delta):
	var input_dir = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
	
	if next_print <= 0:
		print(input_dir)
		print("-z: ", -transform.basis.z)
		next_print = print_delay
	else:
		next_print -= delta
	
	var roll = -input_dir[0]
	var pitch = input_dir[1]
	
	rotate(transform.basis.z, roll * delta)
	rotate(transform.basis.x, pitch  * delta)

	velocity = -transform.basis.z * SPEED_MPS * delta
	move_and_slide()

Not tested but perhaps you should be using rotate_object_local - so the rotation is in the plane’s own axis, rather than that of its parent.

Looks like a decent ninja turtle!

Did you do the skull door sketch too? Looks awesome anyway.