Allow for exposing properties on parent nodes from child nodes (multiple alternative suggestions how it could be implemented)

[zachHixson]

Describe the project you are working on

An RPG game with various bits of functionality ("interactive," "flammable," etc.), where each functional component has settings that need to be tweaked, often on a per-instance basis.

Describe the problem or limitation you are having in your project

It's currently impossible to expose child-node settings on the parent node without expanding the node in the node tree and losing the

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

Different ways to solve this problem

• "Component," node flag. In the same way we currently tag things as a "tool," script, tagging something as a "component," will automatically add any exported variables to the parent node, instead of the current node.
  • Pros: easy, borderline drop in replacement, and allows for the editor to automatically flag these nodes as components if used without a valid parent.
  • Cons: Using just the "component," flag would limit components to exporting only on the parent, and a child of a child wouldn't be able to expose properties on the parent object.
• "Component-root," node flag. This could be similar to the "tool," flag in code, or a UI checkbox, and would cause all properties from all children (recursively, but only to the nearest child component-root) which are exported with "@root-export," (or similar) to show on the selected node.
  • Pros: Flexible, and strikes a good balance between functionality and ease-of-use
  • Cons: Probably a decent amount of work to implement, and still requires the user to be very specific about how their properties are exported.
• An "expose," UI system that doesn't use code whatsoever. The user right clicks a child-property they want to expose, selects "link to parent," and then right clicks the parent node and selects "expose child property."
  • Pros: The most flexible and easy to use of all three suggestions
  • Cons: Not code based, which will be a pro to some, but will probably be a con to others.

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

//Option 1 "Component," flag
[component]

@export var propertyToShowOnParent: int = 7

func _someCode():
pass

//Option 2 "Component-root," flag
//parent node
[component-root]

func _process():
pass

//child-component
@export-root var propertyToShowOnParent: int = 7

func _onReady():
pass

//Option 3 "UI system."
//this one doesn't use code and would be done entirely in the UI.

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

There is currently no way to do anything like this without tying the parent nodes to the child-component nodes through exports, as well as requiring the export chain to be set up manually through scripts every time, and updated if one of the child-components is changed.

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

It deals with how nodes relate and communicate with each-other, and depending on which of the above options was picked would require integration with all of Godot's scripting/programming systems, or with inter-node communication in the UI.

[dalexeev]

Related:

• Automate delegation of exported properties to internal nodes to improve GDScript abstractions #361
• Add synchronized variables / pointers without functions #2817
• Add cascading Node properties to auto-populate values and statically check ancestral dependencies #3147
• Add ability to set exported NodePaths or Nodes to children of scenes without making the children editable #6726
• Make child nodes export variables be editable in the scene root inspector #7803
• Add support for providers (dependency injection) in GDScript #8322

[Shadowblitz16]

Number 3 but the root should be a completely type independent object that has absolutely no properties exposed by default.
Else we get too much inspector clutter and thing's we don't want editable

[zachHixson]

What do you mean? I agree the root should be type independent, but I feel like having a "child properties," heading in the inspector where all the child properties are exposed would work just fine.

Considering it would be up to the user which properties they want to "link," to the parent, it would only be as cluttered as the user makes it.

EX: I have a "wood box," object, and a "flammable," component as a child. "Flammable," has a "fire damage," property I'd like to expose on the parent. In the "wood box," scene, I select the "flammable," child node, right click the exported "fire damage," property, select "select for linking," and then right click the "wood box," node and select "link selected property," which would only expose that one property on the parent.

[jasonwinterpixel]

It deals with how nodes relate and communicate with each-other, and depending on which of the above options was picked would require integration with all of Godot's scripting/programming systems, or with inter-node communication in the UI.

This could be done with a S-Tier implementation in get_property_list()

I've seen some absolute mad-lad get_property_list()'s before and I promise, it can be done.

I too have wanted this, because using Editable Children is a liability.

I usually just expose and forward the properties manually.

[pineapplemachine]

Not having a feature for this, and having to write and maintain a new gdscript for every instanced scene so that instances can assign properties on child nodes, feels very cumbersome. This is one of my most wanted features for Godot at the moment, to make it easier to reuse instanced scenes rather than copy-pasting.

[jasonwinterpixel]

You can use Editable Children when you want to do this. I prefer not to use Editable Children because it's hard to tell what is all overridden, but it's important when discussing this proposal for everyone to be aware that the intended Godot workflow for this is to use Editable Children, or I guess creating a new Inherited Scene and editing the properties there.

…

On Fri, Jun 14, 2024, 4:51 a.m. Sophie Kirschner ***@***.***> wrote: Not having a feature for this, and having to write and maintain a new gdscript for every instanced scene so that instances can assign properties on child nodes, feels very cumbersome. This is one of my most wanted features for Godot at the moment, to make it easier to reuse instanced scenes rather than copy-pasting. — Reply to this email directly, view it on GitHub <#9536 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS2HDAMVJAGW5SDZACFEIJTZHLDMTAVCNFSM6AAAAABGKDRLSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRXG43DQNBSGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[pineapplemachine]

I really dislike editable children for most purposes. The scene using the instance should not have to "know" about the internal structure of an instanced scene. Being able to edit the original instanced scene without losing changes in the scenes instancing it, e,g, losing properties because a node was renamed or moved around, is crucial for a sane development workflow. The instanced scene should expose an interface, a list of properties that matter, and then that scene should be what contains the logic and knowledge of how to express those properties in its children and internal structure.

[jasonwinterpixel]

Yes. And this comment is far more valuable than your previous comment as for moving the discussion forward.

…

On Fri, Jun 14, 2024, 7:47 a.m. Sophie Kirschner ***@***.***> wrote: I really dislike editable children for most purposes. The scene using the instance should not have to "know" about the internal structure of an instanced scene. Being able to edit the original instanced scene without losing changes in the scenes instancing it, e,g, losing properties because a node was renamed or moved around, is crucial for a sane development workflow. The instanced scene should expose an interface, a list of properties that matter, and then that scene should be what contains the logic and knowledge of how to express those properties in its children and internal structure. — Reply to this email directly, view it on GitHub <#9536 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS2HDAIQ6NFQJCCSN3M2Q7DZHLX55AVCNFSM6AAAAABGKDRLSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGA4TCNBSHE> . You are receiving this because you commented.Message ID: ***@***.***>

[EAinsley]

There's another possible solution in this proposal: #3248, that exposing the entire child node to parent. I personally adore this method since it will only expose the nodes that the outer scene should know. Compared to export property, exporting child node could also preserve the ability to edit some special nodes in the 2D/3D editor (such as CSGbox and collision shape).