Add a shortcut to disable/deactivate a node in the editor

[JaimieVos]

Describe the project you are working on

When developing a game sometimes I want to set a node and it's children to an inactive state so I can test better without having to delete the entire node and losing track of what I removed.

Describe the problem or limitation you are having in your project

I cannot disable/deactivate nodes in the editor right now. This causes me to lose track of which nodes I deleted when I am testing something and I want a node to be gone for testing.

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

If I can disable/deactivate a node I can visually still see the node in the scene view. Then I have a clear view of which nodes are active and which are not.

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

In the inspector view there will be a disable/deactivate checkbox. If this is checked the node becomes faded or another color in the scene view.

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

I think it will be used quite often.

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

I think it is quite an essential part of being able to test.

[Calinou]

This should be possible already by setting the node's process mode to Disabled in the inspector.

If you wish to hide a node in the editor or running project only, see https://github.com/godotengine/godot-proposals/issues/3433.

[RobProductions]

Thanks for the info @Calinou ! I tried it out and it works like you explained, but a really minor gripe would just be that they are 2 separate processes when OP's suggestion would unify it under a single click which would be faster/more intuitive for testing. I think it's something a lot of us from Unity will miss so I'm wondering if something like this would work:

Or even replacing the eye icon or switching it when you use a modifier key could be another option. And then basically when this new "enabled" state is on, it would override process to be disabled and visible to off. Or a potentially less destructive/easier approach would be to have this state inherit from Node and show up in the inspector like this:

But without the "metadata" label and maybe pushed to the top above "process". That's just an idea though so feel free to suggest any better options!

[markdibarry]

This should be possible already by setting the node's process mode to Disabled in the inspector.

If you wish to hide a node in the editor or running project only, see #3433.

@Calinou The Disabled process_mode option currently breaks Area2D/Area3D nodes, but Rindbee just opened a PR to fix half of the problem. That being said, once it's fixed, it should cover this request.

[JaimieVos]

Thanks for the info @Calinou ! I tried it out and it works like you explained, but a really minor gripe would just be that they are 2 separate processes when OP's suggestion would unify it under a single click which would be faster/more intuitive for testing. I think it's something a lot of us from Unity will miss so I'm wondering if something like this would work:

Or even replacing the eye icon or switching it when you use a modifier key could be another option. And then basically when this new "enabled" state is on, it would override process to be disabled and visible to off. Or a potentially less destructive/easier approach would be to have this state inherit from Node and show up in the inspector like this:

But without the "metadata" label and maybe pushed to the top above "process". That's just an idea though so feel free to suggest any better options!

Yes exactly, I agree with @RobProductions

[falquinho]

The functionality is there so we are talking just usability right? I dont agree with adding a checkbox on the Scene panel, too much clutter. Neither adding the "Enable" in the Inspector panel, that's duplication of concerns. My suggestions: 1 - Add a project setting to not totally hide the Node when you click the Eye, but make it transparent or just an outline (con: you'd have to know this option exists); 2 - Add a "shortcut" to disable/enable process of a node in the right-click menu; 3 - Make the "Eye" a 3-state toggle: enabled, disabled and invisible, disabled but partially visible;

[RobProductions]

I dont agree with adding a checkbox on the Scene panel, too much clutter. Neither adding the "Enable" in the Inspector panel, that's duplication of concerns.

True, it's a bit of a repetition and maybe cluttering up the scene panel isn't the best. I'm just spitballing ideas, but also the fact that "hidden" is a concept only for "renderable nodes" (like 2D, 3D, etc.) makes it strange to prioritize it over "Node disabled" which every object inherits from.

Getting rid of the eye in favor of a "Node disable" button sounds drastic but to me makes more sense since now everything in the Scene hierarchy can use it and would also accomplish the same as the visible button, just with the added functionality of also disabling scripts. Then you could still edit "visibility" on the renderable nodes independently via the inspector panel. Again, just ideas though.

My suggestions: 1 - Add a project setting to not totally hide the Node when you click the Eye, but make it transparent or just an outline (con: you'd have to know this option exists); 2 - Add a "shortcut" to disable/enable process of a node in the right-click menu; 3 - Make the "Eye" a 3-state toggle: enabled, disabled and invisible, disabled but partially visible;

I like the third option as a good middle ground but I'm a little confused on what you mean by "partially visible". If you mean the setting toggles between 1. disabled (no script process and no visibility), 2. invisible (still processes) and 3. active (all on) then I'm definitely on board for that idea. There's still one other state though which is visible with no process, but at that point you could just use the process_mode to accomplish it.

This is getting complicated fast lol so I'll just say even though a new "disabled" property would repeat the functionality of process_mode, I'm still in favor of that because of its versatility and ease of use. Since it would exist at the highest level possible, it could be used as a universal parameter that affects rendering, scripts, and more; in my opinion, this is a pretty useful concept to speed up development without having to go through each descendant node disabling stuff.

[JaimieVos]

The functionality is there so we are talking just usability right? I dont agree with adding a checkbox on the Scene panel, too much clutter. Neither adding the "Enable" in the Inspector panel, that's duplication of concerns. My suggestions: 1 - Add a project setting to not totally hide the Node when you click the Eye, but make it transparent or just an outline (con: you'd have to know this option exists); 2 - Add a "shortcut" to disable/enable process of a node in the right-click menu; 3 - Make the "Eye" a 3-state toggle: enabled, disabled and invisible, disabled but partially visible;

A shortcut would also be nice.

[inhalt120g]

I dont agree with adding a checkbox on the Scene panel, too much clutter. Neither adding the "Enable" in the Inspector panel, that's duplication of concerns. 1 - Add a project setting to not totally hide the Node when you click the Eye, but make it transparent or just an outline (con: you'd have to know this option exists); 2 - Add a "shortcut" to disable/enable process of a node in the right-click menu; 3 - Make the "Eye" a 3-state toggle: enabled, disabled and invisible, disabled but partially visible;

I agree with everything except 3. Right now, clicking on the eye can be used for quickly turning a, say, reference node on / off in order to confirm everything in the target node is as it should be. This is very useful when, for example, implementing interface where I often compare "reference" and "target" layers (first prepare a layout sketch in a graphic editing program to serve as a reference layer, export it as jpg/png and import it in Godot, make the menus… at this point there's lot of switching of node visibility on/ off, and later remove the reference). If the 3-stage eye icon were implemented, a simple turning visibility on / off would be very tedious.

An option I'd like to see is a simple MMB click on the eye to toggle it on/off. Or maybe Shift+LMB click or even just RMB click(whatever is the simplest). Reaction to RMB click is even already implemented (the interface reacts to it) but it just doesn't do anything.

I like how this is handled in Illustrator, where a layer can be visible / hidden / outline ("outline" is basically the equivalent of "disabled" here) and the eye icon has three states:

[RobProductions]

If the 3-stage eye icon were implemented, a simple turning visibility on / off would be very tedious.

True, that's a very good point I didn't consider.

An option I'd like to see is a simple MMB click on the eye to toggle it on/off. Or maybe Shift+LMB click or even just RMB click(whatever is the simplest). Reaction to RMB click is even already implemented (the interface reacts to it) but it just doesn't do anything.

I like how this is handled in Illustrator, where a layer can be visible / hidden / outline

I like this idea too! To clarify it, you mean that the eye can simply show the "process disabled" status by utilizing transparency, right? If so, here's a potential mockup of the 4 possible states:

Where "Enabled" and "Disabled" reflect process_mode, and visible and invisible reflect what currently happens when you press the eye icon.

I think that definitely works as a quick way to show feedback from a shortcut button like you suggested. Unfortunately this would eliminate a current "feature" of the Godot UI which uses this "semi-transparent" style to show when a child of a node is invisible due to the parent visibility:

But imo it's worth it to be able to get more feedback about the state of the Node, and with the text changing transparency too it could work even for non-rendering nodes.

I'm still in the process of developing a game and learning about the Godot source so in about a month I'd like to start looking into the actual implementation of something that can address this. I do have a question to pose to the community though and that is: how people would feel about the proposed additional "Node disabled" property which would exist in the base Node class? The obvious downside is memory overhead but I still believe this would solve all the above concerns because it provides one quick action that lets you turn off everything related to the Node. To me that's a useful concept especially for things like level culling and debugging. The actual presentation of that button (whether it's a regular property, checkbox in the Inspector, or nested in a right click context menu) can definitely go any direction, but I'm wondering if other people find the tradeoff to be worth it? And would it be possible to prototype/mirror this behavior with a plugin?

[Zireael07]

Can't tell the difference between the four above?

Nvm I was looking at the wrong node

[RobProductions]

Can't tell the difference between the four above?

Check the items at the bottom: CanvasLayer and RichTextLabel. Also I realized I misunderstood the idea from inhalt120g so I may do a second mockup to address it, sorry about that haha.

EDIT: Nevermind, I can't seem to make the idea make sense. I believe inhalt120g wanted to have "no eye" as an alternative look for the icon but sadly I don't think it'll mesh well because not all Nodes have the eye in the first place, only renderable ones. So you'd never be able to tell when that area is clickable or not. Instead I thought maybe the current "closed eye" could take its place but then the 4th state (disabled and invisible) has no distinguishable shape as you can see here:

And not to mention as a user I'd be confused on the functional difference between outlined eye and closed eye, and having 4 different shapes would definitely be overwhelming. Considering that, I'll stick by my original mockup from the other comment and propose that as my best user feedback idea for "disabled node". And of course my question from above about a new property still stands :)

[Zireael07]

Check the items at the bottom: CanvasLayer and RichTextLabel.

Ah, I was looking at the top. This idea makes sense, more than just varying the opacity of the entire icon <3

[inhalt120g]

Thinking about it, simply crossing out the disabled node (strikethrough) would probably be the best indicator of the status. Here is what it could look like:

Alternatively, how about a "pause" sign added to the icon?

[RobProductions]

Thinking about it, simply crossing out the disabled node (strikethrough) would probably be the best indicator of the status.

Great ideas! But I think strikethrough is a bit too distracting when you need to clearly read the name of disabled objects. Remember that disabled nodes could exist anywhere and could be used for culling/game mechanics, and not just temporarily for debugging.

Alternatively, how about a "pause" sign added to the icon?

This is a lot more clear. I like this (especially if there's no extra "disabled" property implemented) since it can clearly show the process_mode status independently and would work well with the shortcuts mentioned above!

EDIT: One caveat though is that the eye is only shown for a subset of nodes, not all nodes, even though process_mode exists for all nodes. Definitely still nice to have but doesn't cover all bases. However, combined with the "transparency" idea I made above, it can still work since the text can fade without needing an icon. Just a thought haha

[inhalt120g]

Without taking the functional aspect into account I also prefer the pause sign, but in context I actually prefer the strikethrough because it's very obvious (deactivated node is quite a big deal). Also strikethrough is more newbie friendly (in the case of "pause" you really have to know where to look) so it'd help avoid situations where someone might forget to activate something back after deactivating it.

And in case nodes ever have to have something more added to them in the future (visually, like some indcators or whatever), strikethrough is so flexible that it'd allow it no problem. For example let's say in the future a small "warning" sign has to appear next to nodes where "pause" was shown in the previous sketch, there wouldn't be enough space for both markings.

strikethrough is a bit too distracting when you need to clearly read the name of disabled objects

If strikethrough is getting in the way of reading, hmm maybe it can be slightly transparent?

[RobProductions]

Also strikethrough is more newbie friendly (in the case of "pause" you really have to know where to look) so it'd help avoid situations where someone might forget to activate something back after deactivating it.

And in case nodes ever have to have something more added to them in the future (visually, like some indcators or whatever), strikethrough is so flexible that it'd allow it no problem. For example let's say in the future a small "warning" sign has to appear next to nodes where "pause" was shown in the previous sketch, there wouldn't be enough space for both markings.

True, but the same could be said about the "transparent" approach I tried above; if the text color simply fades out when disabled you would also get to see at a glance which nodes are disabled, but without visually punishing you as much for utilizing it since strikethrough to me feels like something you have get rid of or mark as complete. And it allows the same room for more icons in the future too.

Thinking about it, the fade out tactic is actually what Unity does for disabled GameObjects, and for good reason it seems lol.

If strikethrough is getting in the way of reading, hmm maybe it can be slightly transparent?

Okay! Let's try it out then:

Definitely better on readability but imo this is still too much visual clutter within the scene panel. Any less opaque than this and you start to miss the fact that the line exists at all. I'm also trying to consider the fact that for whatever reason someone's project could have every node disabled since it's meant to reflect script processing only. At that point we might as well just make another icon to show it but I don't think that was a popular idea either.

Sorry for having strong opinions on it haha but I still believe transparency can solve all of these issues because it is: clear at a glance, doesn't eat up space from other icons, preserves the eye icon functionality, and doesn't introduce more clutter because the "fade out" style is already used for the icons themselves. But definitely let me know if there are any other ideas or ways to address this stuff!

[OhiraKyou]

Is actual, practical usage being considered here? Who is this theoretical person who needs to specifically toggle visibility without toggling processing? You generally have separate visual nodes (like mesh instances) to toggle anyway. Even for UI, there should be separate layout and rendering component nodes.

Even coming from Unity, where a single game object could have an arbitrary number of visual and functional scripts crammed in, I have never once felt the need for a visual toggle on the object level. Why? Because of composition; if I wanted to hide a mesh, I would toggle the mesh renderer component instead of the whole object. And, in Godot, composition is done through nodes. So, I would just toggle the mesh node.

If your visual and functional nodes are so tightly coupled that they require a separate node-level toggle specifically for visibility, you should probably just separate them. Then, you'll have your separate node-level toggle automatically, because they will be separate nodes.

Example

As an example, assume you have a mesh with collision and you want to be able to toggle visibility and collision separately. Instead of organizing your node like this:

• MeshInstance3D
  • StaticBody3D
    • CollisionShape3D

Drag the static body out to a new parent, resulting in a structure like this instead:

• Node3D
  • MeshInstance3D
  • StaticBody3D
    • CollisionShape3D

With that done, you now have separate visual and physical components and can toggle each one separately. And, you can still toggle the entire object by toggling the parent.

If you have multiple visual components, simply group them, like this:

• Node3D
  • VisualComponent (Node or Node3D, depending on if you need the extra transform)
    • MainBodyMesh (MeshInstance3D)
    • AccessoryMesh (MeshInstance3D)
    • Particles
  • StaticBody3D
    • CollisionShape3D

Now, you can also either toggle the whole visual component or the individual pieces.

Suggestion

So, I would expect the toggle to both affect visibility and processing. And, I would expect the recommendation to be this: if you want the toggle to just hide an object, compose your object such that the visible components are separate in the first place. Your visible nodes shouldn't be "processing" anything other than visuals anyway.

Also, the existing behavior (toggling visibility only) can be left as a user setting. If separate buttons are used for toggling visibility, processing, and both at the same time, just one of those buttons can be included by default (ideally, the dual-purpose button). And, users could simply enable and disable any of those three in the settings.

Aside

As an aside, for intuition, consider the following: what's so special about visuals? Why not an object-level toggle for audio components? Or physics? Or lights? Or any other arbitrary category? How many states does the toggle icon need to support then?

[Zireael07]

Godot is not Unity - there are no component scripts. There are a lot of cases where you might want to make something invisible (especially in remote tree, so that something doesn't cover what you want to see at the moment), but keep it processing/active

[OhiraKyou]

There are component scripts, because nodes are components, and they can have scripts; I'm using the term in the general sense (component as in "composition"). And, in the case you're describing, your "something" should be split into a visual component (node) and functional component (node). Then, a single, dual-purpose toggle would affect them both equally while enabling toggling visual and functional aspects of the composite object at will.

[RobProductions]

If your visual and functional nodes are so tightly coupled that they require a separate node-level toggle specifically for visibility, you should probably just separate them. Then, you'll have your separate node-level toggle automatically, because they will be separate nodes.

So this is actually similar to the first idea I proposed which would add "disabled" as a property to the base node class, allowing every descendant Node and child node to benefit from it. I would actually favor the approach you described to how Godot currently works, but I also didn't want to propose drastic changes to the way users interact with the nodes currently. That's why I believe that simply adding this property first is a good step towards that goal because it opens up the use case and in the future when people have had a chance to adjust, we could consider removing the visibility toggle if the same is achievable through the node activation.

But speaking from personal opinion, I'm of the belief that more options are better and I would prefer both in the long run; a universal disabling property and a visibility property that only affects rendering. While you could technically achieve any combination with just the one through composition, having granular control over each part of the node seems useful too.

So, I would expect the toggle to both affect visibility and processing. And, I would expect the recommendation to be this: if you want the toggle to just hide an object, compose your object such that the visible components are separate in the first place. Your visible nodes shouldn't be "processing" anything other than visuals anyway.

The discussion veered into shortcuts because I wasn't sure if people wanted to eliminate the old behavior or rely on some new property. But there is one other complication that would make this shift more challenging: process_mode.

There are multiple states in process_mode, not just an on or off toggle. It can be running when paused or unpaused, disabled, inherited, etc. So if we add a universal "disabled" property, what happens to process_mode? Does it sit on top of process_mode? Or does process_mode become this new feature, and "disabled" also means "don't render"?

Again I will be in favor of granular control and propose that a new property could sit in the base node (separate to process_mode) which overrides process_mode when the property is set to "disabled". Then, much like visibility, in the future process_mode could maybe be reworked or removed if the same becomes achievable through some other method (like, say, a "paused" field you can read through code? I'm sure something like that already exists).

As an aside, for intuition, consider the following: what's so special about visuals? Why not an object-level toggle for audio components? Or physics? Or lights? Or any other arbitrary category? How many states does the toggle icon need to support then?

I'll again mention another suggestion I had above which is to remove the eye icon entirely and just have it be this new "disabled" property:

Getting rid of the eye in favor of a "Node disable" button sounds drastic but to me makes more sense since now everything in the Scene hierarchy can use it and would also accomplish the same as the visible button, just with the added functionality of also disabling scripts. Then you could still edit "visibility" on the renderable nodes independently via the inspector panel.

In this way I believe it should address your concern since the button becomes more universal and the individual component toggles can still exist within the node inspector panel if people need them. I didn't want to presume any specific direction though which is why I'd also settle for a shortcut/feedback UI for process_mode.

So to summarize: there seems to be 2 separate but related ideas in this thread. One is a shortcut/feedback UI for toggling the existing process_mode, and another is the addition of a new property that may or may not replace the existing state toggles. Then, if a new property was added, a further step could be taken to replace the eye icon/feedback UI to use it. Hopefully I got that right, and I'd appreciate any other suggestions or ideas to define the best direction here. In about a month or so after my current game is complete I'll probably start learning the Godot source and this is definitely something I'd like to look into.

[hsandt]

So to summarize: there seems to be 2 separate but related ideas in this thread. One is a shortcut/feedback UI for toggling the existing process_mode, and another is the addition of a new property that may or may not replace the existing state toggles. Then, if a new property was added, a further step could be taken to replace the eye icon/feedback UI to use it. Hopefully I got that right, and I'd appreciate any other suggestions or ideas to define the best direction here. In about a month or so after my current game is complete I'll probably start learning the Godot source and this is definitely something I'd like to look into.

Yes, I think that's it. However, note that the UI feedback will also be useful for the first idea: we need some feedback that we actually disabled a node, because currently we can only check this by scrolling the inspector to the bottom and check the Process Mode. Feedback could be checkbox, grey out, etc. as we've already researched above (with the subtlety that with the first idea, only one enum value DISABLED would have the feedback so there wouldn't be a 1:1 relationship between property and visual feedback, unlike with the second idea).

I think it'd be faster to start with the first idea: implementing a keyboard shortcut to toggle process mode between INHERIT and DISABLED + a visual feedback (e.g. gray out) + toggle visibility, which would work with 90% of the nodes. But I admit that the fact that the operation would be destructive for nodes in different process modes may disturb some users (e.g. if you two toggle twice an ALWAYS node, it will switch to DISABLED then INHERIT so you end up in a different mode).

For a concrete use case: if you wanted to temporarily disable a Pause Menu in ALWAYS process mode, you'd have to make sure to disable some parent node of it that originally had an INHERIT process mode to avoid losing information.

If the implementer feels like they can skip the first idea and implement the second idea with the new metadata enabled on the go, though, they can just go ahead!

[ratzycon]

this seems bizarre, there is no simple disable node tree, should be fast, easy, 1 click why does nodes not have a disabled state? the top function in nodegraphs should be 'if active:' atm disabled nodes still run ready functions a scenegraph based system is exactly supposed to have easy ways to disable subgraphs, and each base node should have a basic on/off switch to completely ignore the node, until it's state changes similar to how Awake() will not be called on a deactivated object in unity

[Calinou]

this seems bizarre, there is no simple disable node tree, should be fast, easy, 1 click

This exists since Godot 4.0:

[zargy]

This exists since Godot 4.0:

Sorry to be pedantic, but that's three clicks: Click on node to select it, scroll down to bottom of inspector if it's too long, click on dropdown menu, click on bottom item. And as far as I remember, there's no easy way to tell if the node has processing disabled by just looking at it in the hierarchy.

[Macklehatton]

And as far as I remember, there's no easy way to tell if the node has processing disabled by just looking at it in the hierarchy.

Disabled nodes will have their name text grayed out. It's easy to miss because this grayed out state is controlled somewhere else, you won't be looking near the text when you change it.

In my case some of my nodes look like this.

Each of the four white icons allow actions that I consider less important than disabling/enabling the node, so I'm not getting the impression that reducing clutter is that big of a priority.

[RobProductions]

Disabled nodes will have their name text grayed out. It's easy to miss because this grayed out state is controlled somewhere else, you won't be looking near the text when you change it.

Had to double check this but you're right! I can't believe I missed that recently :'D

I would still be in favor of some sort of new "enabled/disabled" state to all nodes that uses this grey-out visual which overrides both process and visibility accessible via a simple toggle as was discussed when this proposal was first created. I think it would make editing a bit easier and you'd get to keep the granular control that's already there; reduces clicks and simplifies moments when you want to turn off both process and visibility

[zargy]

I think what would work best for me is: Checkbox on the hierarchy row. Clicking it toggles between Inherit and Disabled, but you can also right click it to get the dropdown with the full 5 process mode options. The checkbox would of course style itself differently depending on which of these are selected so you can tell which one it was set to at a glance. And changing the process mode of multiple selected nodes at a time would also work as it does currently for visibility. (I personally haven't used anything other than Inherit and Disabled yet, but I can see how they're useful.)

And I think both that and the visibility icon should both be displayed by default. They're separate variables that do different things. I can understand the issue of having a bunch of icons in the hierarchy, but this software is a tool to make video games, and video games are often very complicated. (I also think the amount of empty space in Godot's UI makes this issue more difficult to figure out.)

I would still be in favor of some sort of new "enabled/disabled" state to all nodes that uses this grey-out visual which overrides both process and visibility accessible via a simple toggle as was discussed when this proposal was first created

I'm not as sure about this but this would also probably be a valid solution.

Each of the four white icons allow actions that I consider less important than disabling/enabling the node, so I'm not getting the impression that reducing clutter is that big of a priority.

I can't find a list of all the potential icons that can display next to each node so it's difficult to say which ones I'd suggest dropping.

[adamscott]

The creator of Beat Saber had today a similar opinion on this.

One thing I really miss in @godotengine is some kind of Unity's SetActive variation on Nodes. I can disable many things, but it's a huge pita when you work in editor and want to test just part of the whole scene. You have to delete nodes which you don't want to use right now :(

— Jan “Split” Ilavsky

[adamscott]

This should be possible already by setting the node's process mode to Disabled in the inspector.

If you wish to hide a node in the editor or running project only, see #3433.

This doesn't work for visual nodes. A Sprite2D will show the sprite even if the process is set to disabled. I don't think it's a bug, I think it works as expected. But a "disabled" node would remove the sprite, in my mind.

[Macklehatton]

I can't find a list of all the potential icons that can display next to each node so it's difficult to say which ones I'd suggest dropping.

Bumping out another icon may be a false dichotomy. I just want to point out that if this proposal isn't meeting a standard for clutter it would be good to define that standard and see it applied generally. Some of the discussion on #4565 and #8264 touch on the need for something like that eventually.

[torcado194]

Moving discussion from the above PR here, as per @AThousandShips's request

@passivestar:

I think having this function in the context menu and exposed to editor's shortcuts to be able to bind some hotkey to it (can be empty by default) is the best compromise here. Then you don't need to make an addon

I think this is a perfectly fine solution!

so - a context menu toggle (including optional shortcut), and also the property exposed in the inspector panel? I think that sounds fine.

[AThousandShips]

(Please don't just tag people without actually wanting their attention 😄 )

[passivestar]

I think torcado's PR is awesome, it will finally allow me to disable different parts of the game for testing

I just want to point out the obvious bigger problem with Godot - UI for disabling stuff is very incoherent and will be confusing to newcomers

Lets say you're a 2d graphics designer using primarily photoshop and you want to learn gamedev. In the medium of raster graphics hiding an object (layer) is equivalent to completely disabling it

In Godot you have:

• Visibility in the scene tree
• Process mode dropdown buried deep in the Inspector
• One-off toggles to disable nodes of specific types, like CollisionShape3D. Or Light3D for example has an "editor_only" property. The only way you'll ever find those is if you know that you need to be looking for them
• Now with the new PR we're also adding a new option to disable stuff at runtime

A user-friendly UI would allow you to easily discover all of those and control them from the same location in editor. Gamedev is already hard enough as it is, you don't want object deactivation to have a learning curve

[ratzycon]

this seems bizarre, there is no simple disable node tree, should be fast, easy, 1 click

This exists since Godot 4.0:

I'm aware of that feature - it does not quite do what we are looking for however

in a scenegraph, if you disable a root node, you'd have the following expectations:

1) no code being run anywhere in the node or node subgraph (at all) 2) no node or subnode is visible or rendering 3) no updates, physics or anything else

basically the node is entirely bypassed

atm, setting the topnode to disabled still causes init (_ready) code to run on scripts and also does not remove visual rendering of for example sprite2d subnodes

The UI shows the node as greyed out which should normally indicate that this nodetree is disabled, but it's really not, creating an erroneous understanding of the graph

It is great to have various processing state options, but it is not the first thing any beginner would go look for when they just want to 'disable' a node and not have it be active in the scene

[Calinou]

• Now with the new PR we're also adding a new option to disable stuff at runtime

The CollisionShape/Light3D/ReferenceRect properties that disable/hide them in certain conditions can be deprecated and hidden from the inspector (if they equal the default value) once this proposal is implemented. This proposal is essentially about implementing a more generalized variant of these properties after all.

[RobProductions]

UI for disabling stuff is very incoherent and will be confusing to newcomers

• Now with the new PR we're also adding a new option to disable stuff at runtime A user-friendly UI would allow you to easily discover all of those and control them from the same location in editor. Gamedev is already hard enough as it is, you don't want object deactivation to have a learning curve

I definitely agree and considering all these points I think a suggestion from @grgp in https://github.com/godotengine/godot/pull/92377 can remedy this--relegating the "enabled/disabled" concept to a single checkbox like so:

I think disabling/enabling an entire node for both Editor and Runtime flat out supersedes the idea of toggling "node existence" for runtime only because you get the features of both and can easily write a script/extension that achieves the same effect by turning off nodes immediately at runtime. This would also alleviate concerns over missing references as you're not really "excluding" it from the build but merely adding an extra state that drives anything that the node could impact, i.e. visibility and processing. One downside though is having to include those nodes in the build in the first place which removes some benefits like making a smaller build, but to me it's worth it for being able to use it at runtime too instead of just having the editor ignore nodes.

Then for hierarchy feedback as mentioned above in this proposal, the "active state" could take over the faded text look used for process_mode so that you know whether it's on or off:

Thoughts?

[zargy]

I think what you're showing is generally the right path and satisfies the majority of the uses that I want for the proposed feature.

I still think having a checkbox in the hierarchy as well would be ideal if space could be found for it. I just remembered that Unity doesn't provide this feature, it's a feature of a Unity extension I use called Smart Hierarchy, that adds a checkbox next to any items your mouse is over. This is pretty useful to have, so maybe we could an optional toggle on the hierarchy panel that adds a column for checkboxes if the user wants it enough to take up the space?

[Snowdrama]

Macklehatton:

Each of the four white icons allow actions that I consider less important than disabling/enabling the node, so I'm not getting the impression that reducing clutter is that big of a priority.

zargy:

I still think having a checkbox in the hierarchy as well would be ideal if space could be found for it.

Yeah I don't mind having more icons(for example personally I'd like to see the script icon turn into a toggle for the process in the scene tree but that's a different proposal) so I'd definitely prefer to have the icon in the scene tree, something like this makes sense to me. Putting it on the left separates it from other specific feature buttons on the right like visibility and it's partially similar to how icons are on the left in code editors for things like breakpoints.

RobProductions:

I think disabling/enabling an entire node for both Editor and Runtime flat out supersedes the idea of toggling "node existence" for runtime only because you get the features of both and can easily write a script/extension that achieves the same effect by turning off nodes immediately at runtime.

I think the one benefit to having an editor-only toggle is that we can use that to strip it from the build meaning it isn't loaded during scene loading so it improving scene load performance at runtime.

[passivestar]

because you get the features of both and can easily write a script/extension that achieves the same effect by turning off nodes immediately at runtime

I'd strongly prefer to have an option for proper editor-only nodes, there's more utility to them than reducing the build size

Overall it seems like a dropdown in the scene dock header that lets you choose which icons to show (just like in Blender) is the best solution that should make everyone happy because after reading comments you can tell that different people have different workflows and care about different things. With customizable view we should be able to have all of the relevant activation icons (visibility, processing, editor-only and/or any other) easily accessible through the scene dock

[zargy]

Snowdrama's mockup is great.

I'd strongly prefer to have an option for proper editor-only nodes, there's more utility to them than reducing the build size

Yeah, I think having "Editor Only" be a separate thing you can enable is a good idea. It doesn't need to be an icon in the hierarchy because, I think that's probably something you'll be using a lot less than normal disabling. (I don't remember if Unity has editor-only gameobjects built-in as something you can just set or not, I don't think I've ever seen it)

[passivestar]

I think that's probably something you'll be using a lot less than normal disabling

There's no such thing as normal disabling currently. Processing mode doesn't disable everything. If you want to quickly disable some enemies for testing you'd use Editor-Only for that. So you'd need a way to quickly toggle that

[torcado194]

clarifying a few things:

Now with the new PR we're also adding a new option to disable stuff at runtime

My PR does not add the ability to disable anything at runtime. It solely affects the build process. It adds an editor-only toggle that dictates whether a node is included in the built game or not. There may have been a better proposal to link my PR to, but as far as I can tell it resolves the original request.

Disabling Visibility+Processing is not the same as excluding the node entirely, as some have already mentioned. For my use case I want the ability to prevent a node from being included in the built game so that I can quickly A/B test features. Disabling a node has its own benefits, but I prefer a feature that as closely mimics deleting a node as possible.

In my PR's implementation, disabled nodes are replaced with an empty Node instance. This keeps references from failing (unless they're typed references). Removing the node entirely is closer to a "deleted node", either way is fine for my case.

Understandably, everyone has slightly different problems and slightly different ideas of how they think it should be solved. It may have been better for me to open a proposal for exactly what I implemented, but I suspect it would be marked as duplicate because it's similar to existing open and closed proposals.

I think Snowdrama's idea is totally fine. An additional button makes sense to me, it's what I did for my PR originally after all. Some people prefer not to add another icon to the scene tree nodes, that's also valid. I more so care about a quick way to toggle the node than the existence of a button, so a way to add a shortcut is sufficient for me. For the purpose of moving the PR forward i think there's less friction in not adding a new button. If people use the feature often enough something like that can easily be added later, the inverse isn't as likely.

What I would like to do is update my PR in the following ways:

• Remove the icon from the scene tree
• Add a button to the context menu of tree items to toggle editor-only (which also allows for an optional shortcut for the toggle)
• Mark editor-only nodes as blue (and descendants faded)
• (and also probably rename the PR to "Add Editor-Only Toggle" since that's really what I implemented)

Here's a demo of my original implementation:

And a demo of the changes I described: (The shortcut is empty by default, I added one just for the demo)

[RobProductions]

There's no such thing as normal disabling currently.

Just to clear this up, you're right but that's exactly why some discussion in this proposal was aimed at adding it.

There may have been a better proposal to link my PR to, but as far as I can tell it resolves the original request.

Technically yeah, but some of the ideas in here wanted to expand on it and make it work in the editor too. Thinking back on it I do believe this is a great option to have, my only concern was it essentially blocking out possibilities for the "active state" idea/shortcuts but there is definitely room for both to exist

What I would like to do is update my PR in the following ways

That looks perfect! I think that solves my concerns at least. I'm all for it because it allows us to keep the exclusion options while leaving room in the scene hierarchy for future buttons that could work with that feature or for the buttons/shortcuts we proposed above. Appreciate your work on this stuff :)

[Snowdrama]

my only concern was it essentially blocking out possibilities for the "active state" idea/shortcuts but there is definitely room for both to exist

Yeah I can definitely see Editor-Only and the ability to enable/disable the "active state" being 2 different things. Disabled nodes would still be added to the build, unlike Editor-Only nodes, and could be enabled at runtime. Disabled nodes would just behave like nodes that have had visibility set to false and process set to disabled for the node and all children, it's essentially a shortcut to "fully disable" a node and all it's children at once.

I think we would probably want the active state enable/disable feature to come with additional callbacks like _OnEnable, _OnDisable, and _OnActiveChanged or something like that. We could then leave things like _EnterTree and _Ready alone so they'd behave as they currently do. Disabling a node I assume would also change visibility to false so disabling a node would also trigger the Visibility Changed callback of CanvasItem.

[Kalto-Mate]

Regarding Icon clutter over at torcado's implementation: https://github.com/godotengine/godot/pull/92377#issuecomment-2132415956 In short, node disabling functionality could very much reside in an expanded visibility toggle eye button, while the nuance of editor only or game only could be set in the node's inspector column and displayed with a subtle change on the "disabled" symbol.

[OhiraKyou]

I'm against a 3-stage toggle. It makes quickly toggling things on and off unwieldy, and it assumes that "visual nodes" is some special node category simply because it is the only one with a toggle currently available.

From my previous comment:

consider the following: what's so special about visuals? Why not an object-level toggle for audio components? Or physics? Or lights? Or any other arbitrary category? How many states does the toggle icon need to support then?

Today, there is only a toggle for visibility. But, imagine there were (or will ever be) similar branch-wide toggles for audio, physics, lights, etc. that could be made available through editor interface settings. All of those are "disabled" states for their respective node purpose categories, effectively toggling just that category across a tree branch—just like visibility.

If this discussion were happening in that hypothetical future, would people be arguing about which toggle to merge the enabled toggle into? Or, would it simply be far more intuitive, then, to simply add an overall enabled toggle and also allow that to be added or removed from the interface through editor settings? I would imagine the separate toggle would be more likely. And, at the very least, I would prefer it that way.

[Kalto-Mate]

I would honestly never allow for that much granularity and nuance to be displayed and used from the tree, way too much clutter. Clutter is the only reason I thought about having the functionality accesible via the visibility button. It makes marginal amounts of sense, as I'm loosely going by "how does this node exist?".

I do concede that visibility enjoys some privileges over other things like audio or physics, but hey, the main purpose of hiding stuff is for quick visual debugging. When you debug things like sound or the like one tends to just disable the node responsible for that. Of course, the same could be said about nodes whose sole purpose is to display visuals: just disable it if you need to see past it. I think the actual issue here is the visibility toggle should've never existed at the tree view. An enable/disable button should've always taken it's place.

[OhiraKyou]

I would honestly never allow for that much granularity and nuance to be displayed and used from the tree, way too much clutter.

Having used Unity extensions that add extra functional icons to the scene hierarchy, it's fine as long as the defaults are clean and the extras are optional.

Clutter is the only reason I thought about having the functionality accesible via the visibility button.

This assumes that clutter can only grow "wide", in a sense. However, clutter can also grow "deep". Making a Boolean checkbox into a 3-stage button adds "clutter" to the othewise clean toggle itself. For example, there are 3-stage buttons to toggle visibility of gizmos in the viewport. I have no idea what the middle mode does, but I do know that it's annoying.

I think the actual issue here is the visibility toggle should've never existed at the tree view. An enable/disable button should've always taken it's place.

Although I agree that the default should be just an enabled toggle, I disagree that the visibility toggle shouldn't have existed. It should exist, as an optional feature that can be enabled from settings.

[Kalto-Mate]

Although I agree that the default should be just an enabled toggle, I disagree that the visibility toggle shouldn't have existed. It should exist, as an optional feature that can be enabled from settings.

I wouldn't mind the tree view being this table with function columns you can show or hide based on preference or even profiles. Hmm

[Snowdrama]

I'm not super opposed to more scene view clutter, in fact to some extent, I'd rather embrace it and have it be more cluttered BUT have more info. However I do recognize that this adds friction to complete beginners, so I think the compromise is definitely to have these things be able to be enabled.

I do love the idea of doing something like Blender where you can hide/show the icons. For example for me personally, the visibility icon isn't as useful to my workflow as something like the Unity style "full disable" with visibility but also process and collision disabled. So I would probably personally hide the visibility icon, and in it's place have a "Set Active" toggle.

Quick examples of the icon toggles in Blender:

Related to my suggestion before but it might also make sense if we're adding a way to toggle the columns on or off to also allow you to move the icons to the left OR right of the text as well. But this is probably best left for a new proposal, just mentioning it to add some other ideas I was having