Yeah, I think that is way better value-for-effort than mythic’s probability spreadsheet. KiSS
MUNE shares similar concepts as Mythic but simplified. Free PDF:
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
Personally, I’d drop all the macro template syntax, applys, intersects, etc. And simplify the function arg to be just: (sequences)
let item-map make-hash-table
dolist seq sequences
dolist item seq
;; gethash / return / or setf & continue
If you don’t care about the intersection values:
init empty hashmap w best guess on size
Iterate sequences
Iterate elements
If elt in hashmap return t
Add elt to hashmap
return nil
If you have maybe million+ elements, a db like sqlite might help. Unique index, insert each item til you get a unique constraint failure.
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.
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!
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!