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 #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 mode 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.