Allow binding dynamic call arguments when connecting a signal through the editor

[NickMakesGames]

Describe the project you are working on

strategy game with many signals connecting back to UI elements

Describe the problem or limitation you are having in your project

I have a node that emits a custom signal with a resource as a parameter. The resource contains a string value as well as some additional data. When the signal is emitted, I would like a label to update its text value to reflect the string value in the resource. Currently, I have to add a script to the label whose only purpose is to read the string from that resource and assign it to Label.text.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

when connecting a signal to a callback through the UI, there is already an option to bind extra arguments to the callback (as well as ignore preexisting args). It would be convenient to set these additional args dynamically (using the original values the signal was emitted with). This makes it easier to connect signals to callbacks with slightly mismatched signatures without needing additional niche scripts that are just designed to convert data types

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

a special character ($ in this mockup) could be used to indicate that the extra argument is a dynamic value (instead of hard-coded), and an ARGS keyword could be made available for reading the existing arguments that the signal was emitted with

If this enhancement will not be used often, can it be worked around with a few lines of script?

It is possible to write add scripts to nodes that handles this data conversion, but it leads to scripts with overly specific use-cases, or pollutes existing scripts with functionality they potentially shouldn't be handling.

Is there a reason why this should be core and not an add-on in the asset library?

This would be a valuable tool for minimizing code bloat in scripts

[KoBeWi]

I think godotengine/godot#60143 would solve this. If you receive the object, you can access any variable from it.

[NickMakesGames]

Maybe I'm misunderstanding the PR you linked, but it doesn't seem like it covers this use-case. If the callback receives a copy of the node that emitted the signal, I still need a dedicated script that can parse the fields I need off of that node and hand them off to set_text