I ran recently into the nightmare of creating a custom container, so I can say that the `setup.call_deferred()` trick is not enough if your GUI is not completely static, because children sorting can occur afterward (adding a sibling, changing game language, resizing the window, etc.). The solution is to connect `setup()` to the `target.resized` signal.
Im having the same problem, but for the viewport size. I can't find a way of updating the animation correctly when the viewport size changes so the UI element is at an incorrect position
I think typically the "on" in "on_hover" isn't used in the sense of "activation," but as a preposition like "on Friday." So instead of "off_hover" you might call it "on_hover_end" or something. Love your videos! I like this animation component idea, I'll have to try it out.
Great video as always! I have an idea on how you could maybe improve understandability / engagement on your videos: Take the completed (in this case) animation and show it in the beginning of the video. That way the viewer can look forward to what they'll create in this tutorial.
To borrow from JavaScript terminology (hi, web dev by day ;)), you could go with on_hover() for when the mouse enters the button, and on_leave() or on_exit() for when the mouse leaves the button. (I went with on_leave(), since that's a bit clearer as to what the purpose is than on_exit())
Instead of call_deferred("setup"), could you instead wait on the ready signal from the parent node? Or, even the root node? await target.ready or (await get_tree().root.ready)? New to Godot so not such I have the syntax correct. Some sources say yield(target, "ready"), but I think the await target.signal is more contemporary. BTW: Really enjoyed this tutorial. Composability is awesome.
I understand the reasoning behind attaching a node like this, but an inherited button class should allow you to hook into the theme system and not have to duplicate the settings on each node. Maintaining the UI could be a nightmare if you want to change any values since you'd need to update each individual button. Tweaks to the approach could include: 1) save the settings as a Resource, then you can just share the Resource between all of the similar controls. 2) Make your animator a Control and see if you can hook *that* into the Theme system. Different animation settings would be Theme subtypes. Personally I use custom subclasses just because there are only a few types Controls I ever care to animate so the advantage of being able to attach it to anything is a small one for me. YMMV.
1) What happens when both Tweens run at the same time? If you hover off before the first animation is over? 2) Do Tweens self-remove from the tree when they're done? 3) According to the color, the hovered button is losing keyboard focus during the animation.
1) It will override the previous tween.. The hover off will run fully. 2) I believe so BUT Godot 4 might be different. You could manually remove them or bind them to a node. 3) I'll have to check that
@@stayathomedev 1) Technically both will run at the same time. With really short tweens it's less likely to cause any visible issue though. 2) You can end up with weird issues if the button is deleted while the tween is running. use self.create_tween instead and it's lifespan is automatically tied to the button. I would have a reference to the Tween at the class level and when switching Tweens, call kill() on the existing one and then recreate it with self.create_tween.
Honestly how I have to do these things is I have to have a shared tween var, then before you start one, you need to check if the tween var is_valid or is_running, cant remember, if it is then you need to need to kill() it, then you start the next tween
Thank you, quite interesting, has much potential. I get a crash in add_tween when clicking on the button (4.2.2). It seems get_tree is null at that point. Checking for that solves the problem.
Great tutorial!!! But I have a small problem. If I add a pressed() signal that loads another scene it fails. I got around it by hiding the button before loading another scene but it seems like a suboptimal solution....
🔥 GET THE SOURCE FILES ►► www.patreon.com/StayAtHomeDev_
👉🏼 CHECK OUT MY GODOT 4 FPS TUTORIAL SERIES ►► ua-cam.com/video/N-jh8qc8tJs/v-deo.html
I ran recently into the nightmare of creating a custom container, so I can say that the `setup.call_deferred()` trick is not enough if your GUI is not completely static, because children sorting can occur afterward (adding a sibling, changing game language, resizing the window, etc.).
The solution is to connect `setup()` to the `target.resized` signal.
Im having the same problem, but for the viewport size. I can't find a way of updating the animation correctly when the viewport size changes so the UI element is at an incorrect position
Depending on how this series evolves I can imaging that rebuilding iconic menues could be a very nice tutorial
Definitely going to start there shortly!
Like Halo 3
i watched 4 different videos, asked chat gpt, seen some reddit posts and i almost gave up, but you just made it so simple.. thank you dude
for real
I think typically the "on" in "on_hover" isn't used in the sense of "activation," but as a preposition like "on Friday." So instead of "off_hover" you might call it "on_hover_end" or something. Love your videos! I like this animation component idea, I'll have to try it out.
Every time I run across one of your videos I learn so much, thank you for keeping things clear and simple but also engaging!
Great video as always! I have an idea on how you could maybe improve understandability / engagement on your videos: Take the completed (in this case) animation and show it in the beginning of the video. That way the viewer can look forward to what they'll create in this tutorial.
This is great. I was not aware of "call deferred", thanks for passing that along.
Cant wait for GUI tutorial, I struggle so much wondering whats the best/good way of going about it
Thanks for the tutorial! 🙌
what i use is custom stylebox draw with lerp between the styleboxes.
To borrow from JavaScript terminology (hi, web dev by day ;)), you could go with on_hover() for when the mouse enters the button, and on_leave() or on_exit() for when the mouse leaves the button. (I went with on_leave(), since that's a bit clearer as to what the purpose is than on_exit())
nice, so much information.. thanks for sharing!
This is gold, I learned a lot, thank you!
Glad to hear it!
you saved my day
as always a great tutorial
Instead of call_deferred("setup"), could you instead wait on the ready signal from the parent node? Or, even the root node? await target.ready or (await get_tree().root.ready)? New to Godot so not such I have the syntax correct. Some sources say yield(target, "ready"), but I think the await target.signal is more contemporary.
BTW: Really enjoyed this tutorial. Composability is awesome.
I understand the reasoning behind attaching a node like this, but an inherited button class should allow you to hook into the theme system and not have to duplicate the settings on each node. Maintaining the UI could be a nightmare if you want to change any values since you'd need to update each individual button.
Tweaks to the approach could include:
1) save the settings as a Resource, then you can just share the Resource between all of the similar controls.
2) Make your animator a Control and see if you can hook *that* into the Theme system. Different animation settings would be Theme subtypes.
Personally I use custom subclasses just because there are only a few types Controls I ever care to animate so the advantage of being able to attach it to anything is a small one for me. YMMV.
Thank you!
How is the game's user interface created in the Godot game engine?
Exactly what i need
Awesome!
the good stuff!
1) What happens when both Tweens run at the same time? If you hover off before the first animation is over?
2) Do Tweens self-remove from the tree when they're done?
3) According to the color, the hovered button is losing keyboard focus during the animation.
1) It will override the previous tween.. The hover off will run fully.
2) I believe so BUT Godot 4 might be different. You could manually remove them or bind them to a node.
3) I'll have to check that
@@stayathomedev
1) Technically both will run at the same time. With really short tweens it's less likely to cause any visible issue though.
2) You can end up with weird issues if the button is deleted while the tween is running. use self.create_tween instead and it's lifespan is automatically tied to the button.
I would have a reference to the Tween at the class level and when switching Tweens, call kill() on the existing one and then recreate it with self.create_tween.
Honestly how I have to do these things is I have to have a shared tween var, then before you start one, you need to check if the tween var is_valid or is_running, cant remember, if it is then you need to need to kill() it, then you start the next tween
Why not use it like a resource that you just slot into the control node?
Thank you, quite interesting, has much potential.
I get a crash in add_tween when clicking on the button (4.2.2). It seems get_tree is null at that point. Checking for that solves the problem.
Did you find the solution? The same thing happens to me.
Great tutorial!!! But I have a small problem. If I add a pressed() signal that loads another scene it fails. I got around it by hiding the button before loading another scene but it seems like a suboptimal solution....
Hey, kinda late here but i got the fix, don't use get_tree().create_tween() | Instead just use create_tween()
The same thing happens to me, how did you solve it?
Nice video! But why does the button change its color if the only property modified in the tween is the scale? You didn't say anything about that.
Might be a default color behavior of the theme?
@@stayathomedev Ah, yes. Makes sense. Thanks for the video and your response! :D
Pls make a video full fps game in one video (big fan)
What is that Godot theme ?
That's my question as well.. it looks really cool!
github.com/passivestar/godot-minimal-theme
I am surprised to learn that it is possible to mess with the properties of a node that is the child of a Vbox-type of container.
tkns
👍
Why not:
@onready var target: Control = get_parent()