HyverNox
@hyvernox.bsky.social
Maybe I misunderstood something, but when trying the "Append Source" binding, wasn't the idea to send data from data_button to the _on_pressed() function?
Shouldn't it be 'song_data = data_button.song_data' then (instead of the inverse 'data_button.song_data = song_data')?
Shouldn't it be 'song_data = data_button.song_data' then (instead of the inverse 'data_button.song_data = song_data')?
December 3, 2025 at 7:37 PM
Maybe I misunderstood something, but when trying the "Append Source" binding, wasn't the idea to send data from data_button to the _on_pressed() function?
Shouldn't it be 'song_data = data_button.song_data' then (instead of the inverse 'data_button.song_data = song_data')?
Shouldn't it be 'song_data = data_button.song_data' then (instead of the inverse 'data_button.song_data = song_data')?
The procedure is the same for visual shaders. For adding to the diffuse, you take diffuse as an input into an vec3 addition with your calculated light and connect the result to the diffuse output. As long as the light calculation is correct, this should be enough.
September 10, 2025 at 8:18 PM
The procedure is the same for visual shaders. For adding to the diffuse, you take diffuse as an input into an vec3 addition with your calculated light and connect the result to the diffuse output. As long as the light calculation is correct, this should be enough.
Adding to DIFFUSE_LIGHT (or SPECULAR_LIGHT respectively) inside light() should be correct. If the result is too bright, maybe something's wrong with the calculation? Like, not multiplying by ATTENUATION or so?
September 10, 2025 at 6:12 PM
Adding to DIFFUSE_LIGHT (or SPECULAR_LIGHT respectively) inside light() should be correct. If the result is too bright, maybe something's wrong with the calculation? Like, not multiplying by ATTENUATION or so?
Oh, and the AnimationPlayer should probably be responsible for resetting the input storage to it's "didn't got a value yet" state at the beginning of the animation.
Hope that was comprehensible enough to help you!
Hope that was comprehensible enough to help you!
August 25, 2025 at 12:55 PM
Oh, and the AnimationPlayer should probably be responsible for resetting the input storage to it's "didn't got a value yet" state at the beginning of the animation.
Hope that was comprehensible enough to help you!
Hope that was comprehensible enough to help you!
didn't got a value yet -> set input storage to current timing state
6) At the end of the attack animation, the AnimationPlayer calls a function that acts depending on the stored input variable. (like dealing a different amount of damage or extending/interrupting the attack)
6) At the end of the attack animation, the AnimationPlayer calls a function that acts depending on the stored input variable. (like dealing a different amount of damage or extending/interrupting the attack)
August 25, 2025 at 12:54 PM
didn't got a value yet -> set input storage to current timing state
6) At the end of the attack animation, the AnimationPlayer calls a function that acts depending on the stored input variable. (like dealing a different amount of damage or extending/interrupting the attack)
6) At the end of the attack animation, the AnimationPlayer calls a function that acts depending on the stored input variable. (like dealing a different amount of damage or extending/interrupting the attack)
and if that storage variable already got a value. (It needs to have a distinctive "didn't got a value yet" state, because you don't want to override the value once it's set.)
So this should be like: when jump attack button pressed -> if current timing state isn't "inactive" -> if input storage ...
So this should be like: when jump attack button pressed -> if current timing state isn't "inactive" -> if input storage ...
August 25, 2025 at 12:53 PM
and if that storage variable already got a value. (It needs to have a distinctive "didn't got a value yet" state, because you don't want to override the value once it's set.)
So this should be like: when jump attack button pressed -> if current timing state isn't "inactive" -> if input storage ...
So this should be like: when jump attack button pressed -> if current timing state isn't "inactive" -> if input storage ...
via AnimationPlayer. (starting with "inactive", changing to "too early" and "perfect" over time, and resetting to "inactive" at the end)
4) Define a variable that will store the input timing. (maybe using the same enum?)
5) During the attack, handle inputs depending on the current timing state ...
4) Define a variable that will store the input timing. (maybe using the same enum?)
5) During the attack, handle inputs depending on the current timing state ...
August 25, 2025 at 12:51 PM
via AnimationPlayer. (starting with "inactive", changing to "too early" and "perfect" over time, and resetting to "inactive" at the end)
4) Define a variable that will store the input timing. (maybe using the same enum?)
5) During the attack, handle inputs depending on the current timing state ...
4) Define a variable that will store the input timing. (maybe using the same enum?)
5) During the attack, handle inputs depending on the current timing state ...
I've only ever used gdscript, but the logic I'd use would probably be like:
1) Define an enum for the different timing states. (like "inactive" (for ignoring inputs), "too early", "perfect" etc.)
2) Define a variable of that enum for the current state.
3) During the attack, change that variable ...
1) Define an enum for the different timing states. (like "inactive" (for ignoring inputs), "too early", "perfect" etc.)
2) Define a variable of that enum for the current state.
3) During the attack, change that variable ...
August 25, 2025 at 12:49 PM
I've only ever used gdscript, but the logic I'd use would probably be like:
1) Define an enum for the different timing states. (like "inactive" (for ignoring inputs), "too early", "perfect" etc.)
2) Define a variable of that enum for the current state.
3) During the attack, change that variable ...
1) Define an enum for the different timing states. (like "inactive" (for ignoring inputs), "too early", "perfect" etc.)
2) Define a variable of that enum for the current state.
3) During the attack, change that variable ...
So, it's about the timing based inputs during the attack? Or what exactly are you struggling with?
August 25, 2025 at 10:49 AM
So, it's about the timing based inputs during the attack? Or what exactly are you struggling with?
I looked up the pixel coordinates in Paint and the red spot seems to be correct. There's a clear offset between the circle and the 4 corners though. (So I guess the corners belong to your guess and the circle to the program's result?)
August 15, 2025 at 1:52 PM
I looked up the pixel coordinates in Paint and the red spot seems to be correct. There's a clear offset between the circle and the 4 corners though. (So I guess the corners belong to your guess and the circle to the program's result?)
Afaik the point of Dynamic Refresh Rate is to reduce the refresh rate if the image doesn't change, for the sake of saving power. So this seems to be the intended behavior? Unless there'd be stuff happening at >60fps (which doesn't seem to be the case for your video at least).
August 13, 2025 at 9:19 AM
Afaik the point of Dynamic Refresh Rate is to reduce the refresh rate if the image doesn't change, for the sake of saving power. So this seems to be the intended behavior? Unless there'd be stuff happening at >60fps (which doesn't seem to be the case for your video at least).
According to your error message, 'health.health' isn't found. So something isn't working in this logic chain, most likely 'hurtbox.health' not getting set correctly. (If 'health.health' wouldn't exist, Godot should realize before compiling.)
July 31, 2025 at 12:46 AM
According to your error message, 'health.health' isn't found. So something isn't working in this logic chain, most likely 'hurtbox.health' not getting set correctly. (If 'health.health' wouldn't exist, Godot should realize before compiling.)
But also to the exported var in the inspector on the right?
The logic should be:
- scene has a Health node
- hurtbox script has a var health
- this var health is set in the inspector to link to the Health node
- that Health node has a script which defines another var health
The logic should be:
- scene has a Health node
- hurtbox script has a var health
- this var health is set in the inspector to link to the Health node
- that Health node has a script which defines another var health
July 31, 2025 at 12:39 AM
But also to the exported var in the inspector on the right?
The logic should be:
- scene has a Health node
- hurtbox script has a var health
- this var health is set in the inspector to link to the Health node
- that Health node has a script which defines another var health
The logic should be:
- scene has a Health node
- hurtbox script has a var health
- this var health is set in the inspector to link to the Health node
- that Health node has a script which defines another var health
And it seems, health is an exported variable. So you have to make sure to assign an health object to that variable in the editor before running the scene.
July 30, 2025 at 11:06 PM
And it seems, health is an exported variable. So you have to make sure to assign an health object to that variable in the editor before running the scene.
From looking into the video, it should be 'health.health', without the capitalized H.
July 30, 2025 at 10:57 PM
From looking into the video, it should be 'health.health', without the capitalized H.
Melde mich hiermit für die Liste! o/
July 28, 2025 at 3:06 PM
Melde mich hiermit für die Liste! o/
If that function returns a boolean, it could be working as it is (even though it'd have a weird name for that). But yeah, without knowing the other script, this looks like an issue aswell.
July 26, 2025 at 2:39 AM
If that function returns a boolean, it could be working as it is (even though it'd have a weird name for that). But yeah, without knowing the other script, this looks like an issue aswell.
In line 12, replacing "is_action_pressed" with "is_action_just_pressed" should be enough to fix it.
Though I'd recommend moving it into another function: Change line 10 to
"func _unhandled_input(event: InputEvent) -> void:"
and replace "Input.is_action_pressed" with "event.is_action_pressed".
Though I'd recommend moving it into another function: Change line 10 to
"func _unhandled_input(event: InputEvent) -> void:"
and replace "Input.is_action_pressed" with "event.is_action_pressed".
July 26, 2025 at 2:10 AM
In line 12, replacing "is_action_pressed" with "is_action_just_pressed" should be enough to fix it.
Though I'd recommend moving it into another function: Change line 10 to
"func _unhandled_input(event: InputEvent) -> void:"
and replace "Input.is_action_pressed" with "event.is_action_pressed".
Though I'd recommend moving it into another function: Change line 10 to
"func _unhandled_input(event: InputEvent) -> void:"
and replace "Input.is_action_pressed" with "event.is_action_pressed".
Don't control nodes inherit z_index from CanvasItem?
July 25, 2025 at 8:28 PM
Don't control nodes inherit z_index from CanvasItem?
You can inherit from a script via the "extends" keyword, if that's what you're looking for: docs.godotengine.org/en/4.4/tutor...
GDScript reference
GDScript is a high-level, object-oriented, imperative, and gradually typed programming language built for Godot. It uses an indentation-based syntax similar to languages like Python. Its goal is to...
docs.godotengine.org
July 25, 2025 at 5:11 PM
You can inherit from a script via the "extends" keyword, if that's what you're looking for: docs.godotengine.org/en/4.4/tutor...
For the basics of 3D related stuff, fps sounds pretty good.
July 25, 2025 at 3:12 AM
For the basics of 3D related stuff, fps sounds pretty good.
A scene's root node can act as it's interface. In Godot it's best practice for nodes to only access their direct children and not their parents or siblings (except through signals). So all the root node's methods and properties will be exposed to it's parent node.
July 23, 2025 at 6:03 PM
A scene's root node can act as it's interface. In Godot it's best practice for nodes to only access their direct children and not their parents or siblings (except through signals). So all the root node's methods and properties will be exposed to it's parent node.
You can download them from the official godotengine.org website (make sure to get them for your exact version) or from inside your project (Editor -> Manage Export Templates; requires runing Godot in online mode).
Godot Engine - Free and open source 2D and 3D game engine
Godot provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.
godotengine.org
July 23, 2025 at 2:54 AM
You can download them from the official godotengine.org website (make sure to get them for your exact version) or from inside your project (Editor -> Manage Export Templates; requires runing Godot in online mode).
Okay, if that has already been done my next guesses would be some altered import or project settings. But if you wanted to upscale them anyways and higher resolution images aren't affected, I guess it doesn't matter anymore.
July 22, 2025 at 5:37 AM
Okay, if that has already been done my next guesses would be some altered import or project settings. But if you wanted to upscale them anyways and higher resolution images aren't affected, I guess it doesn't matter anymore.