Add ability to export Node pointers as NodePaths

[reduz]

This PR implements:

• A new hint: PROPERTY_HINT_NODE_TYPE for variant type OBJECT, which can take specific node types as hint string.
• The editor will show it as a node path, but will set it as a pointer to a node from the current scene if you select a path.
• When scene is saved, the node path is saved, then restored as a pointer.

This is the low level machinery required for doing something like:

@export var myvar : Button

And be able to edit this as a node path from the inspector, so you can assign another node. This functionality has been very requested, but it was not done due to how difficult it actually is to implement.

This is implemented by editing the property path in a hidden metadata property, then converted to an actual path in PackedScene and assigned on instantiation of it after the scene has been created.

Bugsquad edit: Implements godotengine/godot-proposals#1048

[reduz]

Another way we may be able to implement this in a more clean way is to make this a regular NodePath property that somehow points to another, hidden property. Example:

PropertyInfo(Variant::NODE_PATH,"which_node_path",PROPERTY_HINT_NODE_PATH_TO_NODE_PROPERTY,"which_node:Button");

This means that, during inspector editing, only the node path will be set via the which_node_path property (pointer could be set too, I don't know) but upon saving the scene, the extra special property will be saved (as the current code does) that will result in setting this value to which_node after the scene is loaded.

This script languages would need to expose this as an extra property and, if you want to use this in GDExtension, you have to also use it manually by exposing another property.

[rburing]

For completeness let me point out an existing workaround/hack in 3.x:

export(NodePath) onready var button = get_node(button)

One would "just" have to add a better syntax and static typing to this solution. Maybe it can serve as inspiration.

[jasonwinterpixel]

Another way we may be able to implement this in a more clean way is to make this a regular NodePath property that somehow points to another, hidden property. Example:

Yes I think this is the way.

I've always imageind this feature just as syntax sugar that would back the exported Nodes with a hidden NodePath variable.

eg) User writes:

@export(Button) var myvar

But Godot actually creates this:

@export(NodePath) var __nodepath_myvar
@onready var myvar:Button = get_node(__nodepath_myvar)

[reduz]

@jasonwinterpixel My most recent commit does this transparently now by using the newly implemented metadata system. It will probably need a good amount of testing once @vnen implements it in GDScript 2.0 but I am confident this is probably the simplest way for users (even if it required a bit of hack in the inspector and PackedScene).

[YuriSizov]

Can the syntax be made in such a way so that we preserve actual type hints, not introduce export hints back? We just unified the mess we have in 3.x with both export hinted types and proper types.

[reduz]

@YuriSizov I think that is the case, I am just not used to writing modern GDScript so my example is likely wrong.

[neikeq]

It has the downside that it requires a pointer to be node to be kept during editor.

I didn't quite understand this. Can you explain it a bit more?

[neikeq]

If I understand this correctly, this implementation assigns the node properties when instantiating a packed scene rather than on _ready, right?

[reduz]

@neikeq It no longer needs a pointer. It now edits a hidden metadata and stores the nodepath there instead of modifying the actual property. It sets this on PackedScene instantiation, not ready.

[dpalais]

Ever since we got unique nodes the need for this with C# has been reduced drastically. It's still a nice feature to have but I just wanted to let you know about the unique nodes perspective of this.

[neikeq]

 It sets this on PackedScene instantiation, not ready.

Then I think this is much better than the "export NodePath & onready get_node" syntax sugar proposed above. It behaves just like any other exported property.

[reduz]

@neikeq Yes, it aims to be as transparent as possible to the user code, so it can be used from C# or C++ directly without language hacks. Just export a property to a node pointer and give the editor hint, then the editor will manage the nodepath internally and set the pointer on scene instantiation, all transparently.

Doing it from within GDScript would have been much easier, but this I something you want in the other languages too, which is why it took so long to figure out how to do it the best possible way.

[vnen]

Looks good to me. I've been testing this a bit and it works well. We can probably merge this and do further improvement later.

[akien-mga]

Should be good to merge once it passes CI.

[AaronRecord]

I might be missing something, but I just tested this with GDScript in a new project and it's not working:

It looks like these lines in the GDScript parser need to be changed to accept Nodes as a valid export type:

godot/modules/gdscript/gdscript_parser.cpp

Lines 3603 to 3612 in 68bf4eb

	case GDScriptParser::DataType::NATIVE:
	if (ClassDB::is_parent_class(export_type.native_type, SNAME("Resource"))) {
	variable->export_info.type = Variant::OBJECT;
	variable->export_info.hint = PROPERTY_HINT_RESOURCE_TYPE;
	variable->export_info.hint_string = export_type.native_type;
	} else {
	push_error(R"(Export type can only be built-in, a resource, or an enum.)", variable);
	return false;
	}
	break;

Also the body of the commit message should maybe be updated

[KoBeWi]

@AaronRecord The GDScript part is going to be implemented in a follow-up PR.

[akien-mga]

Thanks!