|
|
|
|
Reply From: |
timothybrentwood |
In the second example the sprite is being added as a child to the node that the script is attached to. A child node inherits its parent’s position/rotation by default (as well as other properties). This is probably the cause of the behavior you’re experiencing.
Two ways to deal with this: attach the node to a node that doesn’t rotate, likely by changing add_child(that_sprite)
to:
get_parent().add_child(that_sprite)
Or by accounting for the parent’s rotation whenever changing the child’s rotation (using the formula: desired_starting_rotation - parent_rotation):
tween.interpolate_property(that_sprite,"rotation_degrees",
(0 - rotation_degrees), (0 - rotation_degrees) + rand_range(-180, 180), 2,
Tween.TRANS_QUINT,Tween.EASE_IN)
The node the script is attached to is a Timer
node in this case, which is a child of a Control
node. A Timer node can’t be rotated, right? The Control node’s rect_rotation
is 0.
But the behaviour won’t change using get_parent()
. It starts on a random rotation and ends at 0 degrees, so exactly the opposite of what it should do.
Your second suggestion throws that error again (The identifier „rotation_degrees“ isn't declared in the current scope.
)
I’m still at a loss here, sorry. Could this be a bug this time maybe…?
pferft | 2021-10-31 20:22
which is a child of a Control node
Ah okay that’s why. To my knowledge you’re not supposed to add Node2D
/Spatial
s (or anything inheriting from them) that are going to display on screen as a child of a control node. That would explain the undefined behavior you’re experiencing. (It’s probably not good practice to add them as children to a Timer
node either.) Try using:
get_tree().get_root().add_child(that_sprite)
tween.interpolate_property(that_sprite,"rotation_degrees",
0, rand_range(-180, 180), 2,
Tween.TRANS_QUINT,Tween.EASE_IN)
timothybrentwood | 2021-11-01 00:33
Well, another valuable hint, thank you. (Hitting me hard, because I guess I have quite some Control nodes set up like this…)
Unfortunately this doesn’t do the trick as well - interestingly enough there is no rotation going on at all now. But the debugger says _build_interpolation: Tween target object has no property named: rotation_degrees.
I believe the issue to be rootet in that “rotation” somehow, because interpolate_property(that_sprite,"position"
works fine. Could that be a hint?
pferft | 2021-11-01 12:15
My apologies, the Sprite
object inherits from CanvasItem
(generic 2D things that can be drawn to screen) not Node2D
so it doesn’t have the same properties as Node2D
. The solution here is change your Sprite
’s scene to mimic Node hierarchy:
-Node2D (or something that inherits from Node2D)
--Sprite
This will allow you to tween the rotation_degrees
property of the parent Node2D
and the child Sprite
object will inherit this rotation as a result of being a child.
timothybrentwood | 2021-11-01 13:48
No no no, my mistake! A typo in “tween”. In the end that “0” indeed makes the rotation start at 0 degrees:
tween.interpolate_property(that_sprite,“rotation_degrees”, 0, rand_range(-180, 180), …
Just as you had put into your example in the first place. You’ve been right all along, sorry for the unnecessary fuss.
I still don’t grasp why the sprite is being randomly rotated at start if that 0 is missing, but for now I’m very happy it works. Thank you very much for your help!
pferft | 2021-11-01 14:29
Glad you got it figured out.
I still don’t grasp why the sprite is being randomly rotated at start if that 0 is missing
If you look at the arguments for the interpolate_propert()
function it should become clear:
interpolate_property(Object object, NodePath property, Variant initial_val, Variant final_val, float duration, TransitionType trans_type=0, EaseType ease_type=2, float delay=0)
If you have the first two arguments correct, the remaining arguments are just numbers in the case of tweening rotation_degrees
. As long as you’re giving it at least 5 arguments, the last three arguments will default in.
In your case, by leaving out the 0
argument you shifted the rand_range(-180, 180)
argument one to the left to make IT the initial_val
, the final_value
was 2
- what you intended for the duration. Since Tween.TRANS_QUINT
is an enumeration, it’s really just an integer under the hood so you didn’t get a debugger message for putting it as the duration
. Then you used Tween.EASE_IN
- another enumeration so no debugger issues when setting it as the trans_type
. Then Godot just defaulted in 2
for the ease_type
because you didn’t give it enough arguments to specify an ease_type
in your function call.
When you follow the above logic you can see that it did exactly what you told it to. The reason it started at a random rotation was because you gave it an initial_value = rand_range(-180, 180)
. To be clear, I believe what I said about adding a Node2D
as a child of a Control
node should produce undefined behavior - it just so happens that in this case, doing so wasn’t the cause of the unexpected behavior.
timothybrentwood | 2021-11-01 15:10
Thanks for that detailed explanation, very much appreciated (and copy-pasted into my archives ; )
And I’ll certainly keep in mind to be more “careful” with Control nodes in the future.
Thanks again for taking your time and helping me out!
pferft | 2021-11-01 16:38