Godot: Expose individual children as editable.

[OliPerraul]

Godot version:

Issue description:
Currently, in order to modify values of children, you must mark the scene as editable children which exposes all the children of the scene. It would be much better to be able to select which particular children of the scene I want to mark editable (alongside the old option). For example I want to be able to expose only the Data node of my Player without having to expose the other nodes. This cludders my workspace too much.

I believe this would be a great mechanism to make the interface of scenes more modular.

Thank you.

[ghost]

which exposes all the children of the scene

I think the editable children is just a visual representation of what you can edit. If you don't edit something, it won't really be changed or "exposed". You can see this because of the little circle icon appears next to the value in the inspector (only if it's modified). I recommend to just collapse your FSM node for now. The collapsed state will be saved upon re-opening the scene

[avencherus]

Would be a very nice option, I would add that it would probably be even better if certain children would be exposed in the editable tree list. This way you, when dropping in a new scene, it could have the child nodes using scripts with export var be immediately accessible for modifications.

It would make certainly make component nodes/sub-scenes a lot more friendlier to use.

[ghost]

Doesn't need an export(var) though, it's instanced so anything can still be changed :O

[OliPerraul]

@girng

which exposes all the children of the scene

I think the editable children is just a visual representation of what you can edit. If you don't edit something, it won't really be changed or "exposed". You can see this because of the little circle icon appears next to the value in the inspector (only if it's modified). I recommend to just collapse your FSM node for now. The collapsed state will be saved upon re-opening the scene

I know you can collapse a node, and this would only be a quality of life feature. But it seems this would not take too much work to implement and would make the experience a lot more enjoyable.

[ghost]

I know you can collapse a node, and this would only be a quality of life feature. But it seems this would not take too much work to implement and would make the experience a lot more enjoyable.

Yeah I hear you.

When you said

It would be much better to be able to select which particular children of the scene I want to mark editable

Maybe you meant visible, not editable? Because they all still editable, and I was thinking you were suggesting to only have certain nodes not editable, which confused me.

So basically, an "Edit Children Visibility" menu item underneath the "Editable Children", which will show a popup that will let you select (checkmark) which nodes you want to be visible for that instanced scene (in the actual item list).

[QbieShay]

Duplicate #21311

[QbieShay]

@avencherus I believe an automatic system would not resolve the problem. Also, in my experience, one of the nodes that I marked as editable more often was the collision shape which almost never has a script on it.

[OliPerraul]

@avencherus But suppose I want to expose some data to designers, I think it is wrong to force all of this data to be in one Node (i.e the root node of the scene). I would want more control over exposing the information without for that matter exposing the whole object's inner working with the current option Editable children.

[akien-mga]

Closing as duplicate of #21311.

[QbieShay]

@akien-mga maybe is more beneficial to keep this one, as it has more discussion on it. You can close #21311 instead

[akien-mga]

Good point.

[avencherus]

@QbieShay Wouldn't want anything automatic either. I believe we're on the same page, after reading https://github.com/godotengine/godot/issues/21311. I'd find it more useful to have an option the toolbar, much like the lock and prevent child node selection option. Something like "always expose as editable".

This is more of what i would imagine for it.

You'd elect which nodes you want automatically exposed, and when these scenes are instanced, you can quickly modify export vars of child nodes. In your example, be able to quickly adjust collision shapes, which does come up quite a bit too.

[QbieShay]

Yes. And I wouldnt make the exposing recursive: if you instance a scene that has subscene with some exposed nodes, you should mark them as exposed again if you want them to be editable when the current scene is instanced somewhere else.
This way you have the finest control over what is exposed and what not and at which levels.

[avencherus]

Nice idea, glad you brought it up, because I was fixated on a different use case. Now that you mention it, I can imagine a deep tree could lead back to a problem with clutter without the option to discontinue or forward what would get exposed as editable in the scene's parent.

In the case I was originally conceiving of, a non-recursive option might be tricky though. If you have maybe a hundred enemies placed in a scene that is a sub-section of a level. In this case you would only be using the sub-scene for organizational reasons, and would still want to see everything exactly as it appears in the "level section" scenes.

Node -> Enemy -> Section -> Level

I imagine you wouldn't want to enlist every enemy individually/manually to carry on exposing certain nodes up to the next scene from section to level.

It isn't a terribly likely setup for enemies, maybe more like environmental objects with some small scripts attached to them.

If I'm understanding it well enough, it seems there may be a double edge here. X)

Cases where you would want it to be enabled recursively and other times you don't, so perhaps two buttons or modes?

One that is "Expose node as editable to all inheriting scenes.", and mouthful number two, "Expose node as editable only to a parent scene." The second one you could keep reapplying as needed, like you described.

[rnoriega31]

Would be nothing more than a QoL change but I'm strongly in favor of it. It gets pretty annoying having to right click -> "editable children" every single time I instantiate a scene. Just voicing my support for the feature.

[samdze]

I'd really enjoy this feature. As @avencherus said, a toolbar button and an icon next to the child node (very much like the script icon or the not selectable icon ones) should do the trick.

This is my proposal, I'll call this feature node or instanced scene export from now on:

@QbieShay is right, the exporting should be non-recursive, only exported nodes (and not their children) are displayed, and instanced scenes with exported nodes will not display them by default inside other instanced scenes.

But, by default, exported nodes in exported instanced scenes are automatically displayed, unless the export flag is overridden, just like any property override in instanced scenes.

The exported nodes visualization works only displaying exported nodes, even if they are children of non-exported nodes, so, if only the grandchild C of the scene root A is marked as exported, it will be the only one displayed if the scene is instanced somewhere else, leaving the parent B behind as if it did not exist in the structure. If also the parent B is marked as exported, then the real local structure would be displayed.

The Editable Children option would always be available to view the complete scene structure if needed.

I think this could be a very powerful feature implemented this way.

[turbohz]

I'd also welcome the ability to define which nodes one wants to be editable for a given scene instance.

Some of my scenes have lots of generally configured nodes, with only a few needed to be configured for each particular instance.

[TheMisteryMan]

Just happened upon this issue, trying to find if there was any way I could set a scene to have editable children by default; the suggestion here of being able to choose which children would be nice to reduce clutter as well.

Other than the comment previous to mine, there hasn't been any discussion in close to a year, what are the core dev's thoughts on this?

[clayjohn]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!