Create onready variables when dropping nodes into script editor and holding Ctrl

[timothyqiu]

Describe the project you are working on

GUI tutorial

Describe the problem or limitation you are having in your project

Repeatedly typing onready var name := $Path/To/Node as NodeType for various nodes.

Dragging nodes into the script editor currently only inserts "Path/To/NodeA", "Path/To/NodeB".

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

When holding Ctrl, dropping nodes into the script editor creates and initializes onready variables for the dropped nodes.

It's similar to how file dropping works: when holding Ctrl, it drops a preload() function call instead of a path string.

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

Peek.2022-05-02.21-03.mp4

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

What to drop is in C++ code. It cannot be worked around, at least not a few lines.

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

Seems impossible.

[Mickeon]

What's the use case of the regular drop, in the first place? I assume it's for being inserted in get_node(), but I find weird it doesn't include it or $ automatically, although it's consistent with FileSystem file dropping.

Anyway, perhaps, going along with this proposal, dropping inside of a function while holding CTRL should not insert the @onready? Since, the annotation would pretty much be discarded on those occasions anyhow.

[h0lley]

any reason for as Type instead of : Type =?

[timothyqiu]

any reason for as Type instead of : Type =?

For these onready variables, normally, the type name can be deduced from the variable name:

# Looks quite busy and repetitive.
@onready var animation_player: AnimationPlayer = $Path/To/AnimationPlayer

# You can safely ignore the right side of assignment.
@onready var animation_player := $Path/To/AnimationPlayer as AnimationPlayer

[timothyqiu]

dropping inside of a function while holding CTRL should not insert the @onready?

To me, this could be a dedicated feature.

Dropping is not context aware currently. There are more things to handle in order to be "correct", e.g. :

• Dropping inside|identifier
• Dropping "inside| a string" or comment
• Dropping as a parameter of get_node(|). What if multiple nodes are dropped in this case?
• What to do if it's dropped inside a nested class?
• etc...

[YuriSizov]

any reason for as Type instead of : Type =?

For these onready variables, normally, the type name can be deduced from the variable name:

# Looks quite busy and repetitive.

@onready var animation_player: AnimationPlayer = $Path/To/AnimationPlayer



# You can safely ignore the right side of assignment.

@onready var animation_player := $Path/To/AnimationPlayer as AnimationPlayer

Those behave differently. Personally, I prefer having the type at the operator because it helps to catch errors earlier. Although, at least in some cases in 3.x, code support works better with the second option (but this feels like a bug).

[timothyqiu]

Those behave differently.

Ah, I thought they have the same behavior. What's the difference?

[YuriSizov]

Those behave differently.

Ah, I thought they have the same behavior. What's the difference?

When you have a type at the operator and try to assign an invalid node path, it will fail there. In the second option the type is deduced from the value, and the value is cast to the target type. In case of incompatibility it will just be turned into a null and happily assigned.

As a result, in the first case errors can be detected at assignment, and in the second case only when you try to do something with the variable (which can happen much later, depending on what you need a node reference for).

PS. Although, as I've said, in 3.x a deduced type provides better code support for some reason, which is counter intuitive, but is a reason why we chose it in some projects.

[Mickeon]

PS. Although, as I've said, in 3.x a deduced type provides better code support for some reason, which is counter intuitive, but is a reason why we chose it in some projects.

Oh yeah, I had noticed it too! For some reason letting the Node type be inferred with as [NameOfTheClass] gives better autocompletion when writing in a Script outside of the Scene the Script has been assigned into. If it isn't already, I hope it is reported as a bug.

[KoBeWi]

If it isn't already, I hope it is reported as a bug.

Yes: #39228

The : Type syntax is ok, but it generates unsafe lines. Although it doesn't really matter much.

[foxwellm]

For any MacOS users. You can drag from Scene to Script with left click. But before you drop, hold down control.

[djpeach]

For any MacOS users. You can drag from Scene to Script with left click. But before you drop, hold down control.

My goodness, thank you. Was very frustrated this did not work

[michaelgundlach]

For any MacOS users. You can drag from Scene to Script with left click. But before you drop, hold down control.

For me on an M1 Mac, it was 'Command', not 'control'. The problem is that Command-click deselects the node you had selected, or selects a second node if one is already selected, thus pasting either 0 or 2 variables. Pressing Command after the click works as intended in all cases.