Add the ability to expose nodes for direct access in instantiated scenes

[yahkr]

Description

This pull request implements a feature I believe really improves Godot's scene editing capabilities. It adds functionality to expose specific nodes of a scene so that, when this scene is instantiated elsewhere, it allows those nodes to be visible and editable. I feel that "Editable Children" clutters the scene tree far too much if you wanted to use it to create re-usable scenes. It is also pretty inflexible to change when assigning children to an instanced scene's nodes then making changes to that subscene.

This current implementation uses Unique Names to reference where nodes will be saved, as much as I would prefer not. Something like #86960 would be much more preferable where nodes are referenced by unique id. This allows property overrides and child node placement to remain when the underlying instanced scene changes. Please see the Example section for a hopefully better explanation of this.

This pr also adds the ability to expose nodes on import. (or use -exp within blender)

Example

For a simple scene like the following:

[node name="Scene0" type="Node3D"]

[node name="Mesh" type="MeshInstance3D" parent="."]
unique_name_in_owner = true
exposed_in_owner = true
mesh = SubResource("BoxMesh_vuc28")

This main scene where we add a child node to Mesh and override the Mesh to a prism instead of a box:

[node name="MainScene" type="Node3D"]

[node name="Scene0" parent="." instance=ExtResource("1_mbyq7")]

[node name="Mesh" parent="Scene0" index="0"]
mesh = SubResource("PrismMesh_g1soo")

[node name="Child1" type="Node3D" parent="Scene0/Mesh" index="0"]

[editable path="Scene0"]

Becomes

[node name="MainScene" type="Node3D"]

[node name="Scene0" parent="." instance=ExtResource("1_mbyq7")]

[node name="Child1" type="Node3D" parent="Scene0/%Mesh" index="0"]

[override path="./Scene0/%Mesh"]
mesh = SubResource("PrismMesh_g1soo")

Where we only save the information relevant to this scene, no need to save the Mesh node from the instantiated scene just to override the mesh.

Since we reference the parent of Child1 and the override via the unique name of the exposed node we gain the following benefits if the Mesh is moved within the subscene:

1. Child1 will not be orphaned and will remain a child of Mesh
2. Mesh will retain the prism mesh override

---

TODO

• Continue to test

---

I think that this pr addresses the following proposals:

• Closes Improve usability of Editable Children godot-proposals#3248
• Closes Make the "internal node" feature more accessible godot-proposals#4265
• Closes Allow saving scenes as a prefab (aka property bag) godot-proposals#9660
• Closes Add ability to flag a "Node Slot" for instanced scenes godot-proposals#5475
• Closes Allow user to expose nodes within an instantiated scene godot-proposals#8266
• Closes (?) Make child nodes export variables be editable in the scene root inspector godot-proposals#7803
• Closes (?) Allow for exposing properties on parent nodes from child nodes (multiple alternative suggestions how it could be implemented) godot-proposals#9536

[jcostello]

This will work with imported gltf scenes?

[yahkr]

This will work with imported gltf scenes?

I havn't looked into that aspect, but would be a nice feature to add to this as well

[AThousandShips]

Also please update your branch by rebasing instead of merging, important skill to get used to with contributing, see the pr workflow for details

[AThousandShips]

You have reset your branch and this closes the PR, if you update your branch this can be reopened

[yahkr]

Sorry, still trying to get a grip on correct way of updating my repo from main while keeping my changes. I've pushed my new changes up. This includes a somewhat functional version of this pr.

[KoBeWi]

Here's some minimal project:

editablebugren.zip

The setup is convoluted, not sure what exactly is the cause. Might be related to editable children.
Try assigning Node to Inst sprite in Main scene.

[yahkr]

The setup is convoluted, not sure what exactly is the cause. Might be related to editable children. Try assigning Node to Inst sprite in Main scene.

Believe this is fixed now, had to be more specific when to parse owned exposed nodes. is Root instead of just a part of an editable instance:

	if (nd.type == TYPE_INSTANTIATED && !is_editable_instance) {

	if (nd.type == TYPE_INSTANTIATED && !root_editable_instance) {

[KoBeWi]

The feature looks good and addresses a great deal of proposals. I unliked 2 that I think are not directly related. Once this is merged we can ask in these proposals if this feature satisfies them.

The code looks alright. There are some core changes, so it needs a review from a maintainer of this area.

[AThousandShips]

Otherwise code and docs look good

[yahkr]

• updated to commit [db24ed4]
• cleaned up commit changes
• fixed an issue with has_exposed_nodes not correctly searching past first child node

[timothyqiu]

I found something unexpected. In this project: test-4.zip,

1. Open a.tscn and demo.tscn. Scene A exposed a node named Slot. Scene is instantiated in scene Demo.
2. In demo.tscn, add a new Node as child of Slot.
3. In a.tscn, unexpose Slot and save. Switch to demo.tscn.
   • Expected: Like renaming the Slot node, the new Node is made the root node's child and renamed to something like A__Slot#Node.
   • Actual: the new Node disappears.
4. If you expose Slot in again, switching back to demo.tscn prints an error:

   Node not found: "A/%Slot/Node" (relative to "Demo").

[yahkr]

I found something unexpected. In this project: test-4.zip,

Thanks! Appears to simply be an issue of not registering that the previous parent was exposed and now inst. it still technically exists as a child of the slot node, however it no longer belongs to the demo scene. Will see if I can work this kink out.

[yahkr]

I found something unexpected. In this project: test-4.zip,

• updated to [40b378e]
• fixed issue of nodes not being orphaned if node is unexposed in instantiated scene

[tetrapod00]

Testing this out and I noticed that the tooltip is technically incorrect, since you can't actually click to disable. This happens when the scene with the exposed node is instantiated in another scene. I don't know if we have the tools to selectively display tooltip text depending on the context to make this technically correct.

For what it's worth, it's the same for scene unique nodes, so this is probably a separate feature proposal rather than something this PR should solve?

[yahkr]

@tetrapod00
I at least fixed this pr's implementation. I agree it should be different. If you're not interested in making that separate PR for other buttons like this, I'm happy to. Thanks!

[tetrapod00]

@yahkr That was fast! Actually I would like to try to fix other instances of this behavior. I'll make an issue collecting the ones that I can find.

[yahkr]

• updated to [b6223c0] to resolve conflicts
• updated to [db66bd3]