Open Shadowblitz16 opened 1 year ago
Doing this by default would break compatibility with existing projects, as the number of arguments would change for all signal functions (and you can't have a mismatch).
It can be worked around but it requires awkwardly binding a additional argument when signals should already carry that info.
In Godot signals normally don't carry any information that you can get otherwise. Binding the node that you already have a reference to is the correct and expected way. Same goes for any other information that you can determine at connect or at emit time without extra arguments. So your suggestion goes against the design principle of the engine.
https://github.com/godotengine/godot/pull/60143 implements this as optional flag, which is much better solution.
Describe the project you are working on
A spaceship game
Describe the problem or limitation you are having in your project
I need a way to get the object the signal happened on without having to manually bind a nodepath each time
Describe the feature / enhancement and how it helps to overcome the problem or limitation
signals would just be redefined as
signal(args...)
tosignal(sender:<SelfObjectTypeHere>, args...)
they would be statically typed it the background but using the static typing in the callback signature would be optionalDescribe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
It can be worked around but it requires awkwardly binding a additional argument when signals should already carry that info.
Is there a reason why this should be core and not an add-on in the asset library?
It improves the godot messaging system