Add a shortcut to disable/deactivate a node in the editor #7715
Comments
|
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. |
|
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! |
@Calinou The |
Yes exactly, I agree with @RobProductions |
|
The functionality is there so we are talking just usability right? |
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.
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. |
A shortcut would also be nice. |
Calinou
changed the title
I agree with everything except 3. 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:
|
True, that's a very good point I didn't consider.
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? |
|
Nvm I was looking at the wrong node |
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 :) |
Ah, I was looking at the top. This idea makes sense, more than just varying the opacity of the entire icon <3 |
|
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? |
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.
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 |
|
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.
If strikethrough is getting in the way of reading, hmm maybe it can be slightly transparent? |
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.
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! |
|
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. ExampleAs 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:
Drag the static body out to a new parent, resulting in a structure like this instead:
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:
Now, you can also either toggle the whole visual component or the individual pieces. SuggestionSo, 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. AsideAs 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? |
|
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 |
|
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. |
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.
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).
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:
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. |
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 |
|
this seems bizarre, there is no simple disable node tree, should be fast, easy, 1 click |
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. |
|
I see what you mean by your example. Here's an alternate one that I can come up with off the top of my head. What if your described level is really big and complicated and you want to completely deactivate chunks of it depending on where the player is to save on any potential performance (let's say you have enough complex stuff in your game that it actually does matter). And the button that happens to open the door is way across the map and in a place where the player can't see (assume that, for whatever reason, you don't actually show the door opening to the player. Maybe you have an onscreen message telling them a door opened and they have to find it). So the door definitely needs to open when the player presses this button, but it also definitely won't be active when the player is standing by the button. In a case like that, I think you'd definitely want to be able to say "this signal should fire on this target thing, even if it's inactive". (Of course, you could just not have a signal and set up an actual function on the door for making it open, but that bypasses the whole point of signals.) Aside from that, I'll add here: I think it may be a good idea to have the default be "inactive nodes can't receive them", but provide a way for the coder to override that. Either a toggle on the signal itself, a toggle on the whole node that lets every signal through (I'd add an argument to |
|
yeah that's an interesting example. but it seems like the existing toggles (visibility and processing) already solve your case perfectly:
Hope it makes sense |
I don't necessarily agree we should be preventing the lifecycle calls like This is where the additional lifecycle function come in like If you previously did something in If we are to change it so |
I fully support adding those, yes. I don't even mind if enter/exit tree are executed if enable/disable are easily available because I can just never put any logic into those old lifecycle methods and only use _on_enabled _on_disabled. It's important though that _on_enabled is actually called at appropriate time when the node is first created (I know it's the case in Unity but I haven't checked in Godot yet) |
Yeah for sure the idea would be that if it enabled in the serialized scene, then during scene loading the Similarly both |
I like this idea, and
Though in hindsight it should be exposed by Node not Node3D, it was just necessary there at first to help propagate visibility stuff. Will fix that when I can. Is this "active state callback" approach the best option then? From what I'm seeing it should be possible to create these new lifecycle calls for GDScript and should be less disruptive to the existing calls, but I just wanted to double check that everyone's workflow is satisfied by that! One problem though is that in terms of naming enabled and disabled are already used internally:
These notifications were originally run by process_mode changes so that more specific nodes could run behaviors when processing is disabled, but the new active state stuff also runs them for this same purpose now. However, that means if I run the GDScript callbacks when these notifications are sent they also will be run when process_mode changes. I think we lose something with that approach because it removes the ability to get more granular with "disabled" vs "don't process" states if that makes sense, so I'm leaning towards keeping them separate from the existing notifications. So if we want these new lifecycle calls to only be triggered by active state changes, it would make sense to use a more unique name. I can go with something like As a reminder this feature I'm building is meant to do two things:
The first point definitely has a greater impact on my specific workflow so I appreciate opinions on the second point and hope to shape it to match expectations there. We've got some great ideas so far I think :) |
Yeah sounds like you get the idea, I think
Ooo I didn't know about that one, I'm just starting to dig into the engine side of things. So enable/disable are triggered when process is changed? Interesting.
Absolutely, I do like the granularity around process_mode enabled/disabled vs a node's active/inactive state. I think the active/inactive triggering visiblility and process_mode callbacks is good for sure. I'd be curious to see how people think about what happens if I change the visibility or process_mode on an inactive node. Does setting visibility/process_mode or anything like that would reactivate the node? Or we could throw an error like "Node is inactive, process_mode can't be changed while the node is inactive" like the active state overrides visibility, and process_mode. Consider this: @export var my_node : Node3D
func do_something():
my_node.visible = true;
my_node.node_active = false
print("Is Node Visible?:", my_node.visible) # false? Did we change visible to false?
my_node.visible = false;
my_node.node_active = true
print("Is Node Visible?:", my_node.visible) # what's the expectation here? is it forced visible?If it's actually changing the value of visible under the hood, then we may be losing the state of the node before it was disabled leading to unintended effects when re-enabling. I Personally think overriding the state makes the most sense to me as it preserves the state regardless of if it's active or inactive, but I want to see how other people feel. Here's an example of how that might look: # my_node stays true while active, checking it while inactive returns false because it overrides the visibility state.
@export var my_node : Node3D
func do_something():
my_node.visible = true
print("Is Node Visible?:", my_node.visible) # true
my_node.node_active = false
print("Is Node Visible?:", my_node.visible) # false it's overridden
my_node.node_active = true
print("Is Node Visible?:", my_node.visible) # true because it was true before becoming inactive
# my_other_node stays false, setting it back to active doesn't change the visibility back to true
@export var my_other_node : Node3D
func do_something_else():
my_other_node .visible = false
print("Is Node Visible?:", my_other_node.visible) # false
my_other_node.node_active = false
print("Is Node Visible?:", my_other_node.visible) # false it's overridden
my_other_node.node_active = true
print("Is Node Visible?:", my_other_node.visible) # still falseHopefully these examples help make what I'm getting at clear.
If I assume adding lifecycle callbacks for I do want to see if maybe someone else has any ideas besides active/inactive but I do think active/inactive makes sense here.
I definitely get the use cases for debugging by isolating stuff by deactivating other things in a scene, but I think there's other benefits to other uses, like object pools, and tools and stuff so I'm glad there's a good discussion around it and I think there's a lot of really good ideas between everyone. |
Yup but they are not exposed to GDScript, just "notifications" which help the nodes communicate in c++ world.
Neither, the way I implemented this is that active state is simply another property like visibility that can be toggled on or off, without either of them throwing an error. In the code that checks whether a node should render, it simply checks both visibility and node_active, hence it acting like an override.
Just tested this to be sure; so in this example Similarly, as I mentioned above I've got
Strictly speaking I don't think it's necessary (so long as something runs the GDVIRTUAL_CALL() macro) but definitely good to have from what I can tell! I like these names so I'll go with that for now as I try my hand at implementing it
Absolutely, really happy to hear your thoughts on this stuff and make workflow improvements that hopefully help everyone in the long run :) Will report back when I make some progress with this stuff! |
Interesting, I'm surprised it doesn't expose a signal for it like
Ohh that's interesting that makes sense to me, as long as having a node be in one state, setting it inactive, and then setting it active again keeps it the same way it was before setting it inactive I'm happy with that.
Perfect! I was literally just thinking maybe something like an
That sounds good to me! makes sense similarly
Yeah at least on the C++ side having those will probably enable someone to do something cool with them eventually right? haha |
|
If enable and disable are already taken naming-wise, would "awake" and "asleep" be a good compromise? I for one also expect a disabled node to still be reachable and "be there somewhere", just not using all that many resources. The sleeping analogy seems to work better in my head compared to "disable" anyways. For some reason I assume the later means the node is GONE gone. |
|
"sleeping" is already taken for physics bodies so it's not appropriate to use here |
|
D A R N I... |
|
Frozen is a different physics thing, but the node isn't really sleeping so I don't think any synonym for it is useful |
|
But it'd say the naming discussion and confusion here highlights an important thing: |
In that case I think "node active" is probably the clearest name I can put to it as an inactive node will not process and will not render, whereas an active node can do either/both of those things depending on how you set visibility/process_mode. So unless the existing To that end, I've reworked some names for clarity and fixed up a few things that we discussed above!
There are now two active-related signals which are implemented in Node instead of Node3D.
The node active getters are now named
I've now confirmed the Capture2024-06-24.15-13-30.movThe new lifecycle functions Note that are called each time the "active in tree" status changes, just not just the first time. Behind the scenes they are called just before the Lastly, I've implemented active state visibility changes for Node2D as well since it is handled independently of 3D nodes and it was much easier this time thanks to the signals being moved into Node:
Left to do: lifecycle calls on scene load, text fade feedback in the scene hierarchy, editor setting to disable checkmarks, testing/documentation. Signals currently still work like before (i.e. they always run regardless of active/process state on sender and receiver), and I might say that if we want signals to not be sent to inactive nodes it could be left for a future PR. There I would recommend we use two ways to call signals either via parameter or with 2 function calls, one that ignores inactive state and one that doesn't. That way we can keep the existing behavior and open up this ease of use feature for more complex stuff. Hope it's looking good for everyone that contributed ideas! |
Similarly anyone coming from Unity to Godot will already be very familiar with the idea of the "active toggle" as it more closely mimics how Unity's Most gripes I imagine will likely be with people who are already advanced Godot users who are familiar with Visibility and Process, and run into edge cases where they use
That's basically exactly what I expected, they'd be called every time the node becomes active/inactive and are good places to do initialization for tools and pooled objects and stuff! @RobProductions just to ask because I'm not sure if I've seen it mentioned, but for nodes with collision like StaticBody3D does this remove the body from the physics simulation? For example, if I have a StaticBody3D platform and a Rigidbody3D object on top, and I set it inactive, will the body on top of it fall? Just curious if that was something this covered or has been tested at all. I assume if not, I could probably use the |
Actually from what I can tell setting process to disabled in 4.3 does stop collision and forces, see below
Let's try it! First I run Rigidbody over Static Body with default state, then I set process mode on the static body to disabled, then I set process mode back to default and disable node_active for the static body: Capture2024-06-24.17-42-38.movSo it would appear that process mode disabled does in fact disable collisions and because the active state overrides the |
|
At the end of the day, this addition will work like a shortcut to do things quicker, a broader stroke, because I'm positive some Unity refugees currently go "Oh well, it's not a single call anymore" and have routinely made their own reusable code snippets that mess with several node properties in bulk. This would just make things official, so I can't wait for it to be accepted |
|
I noticed that since cameras aren't affected by process_mode or visibility, they needed extra logic to disable when inactive, so I'm currently working on that. However, it's made me think about the lifecycle calls because this is one case where utilizing them internally will make things a lot easier. Here's a quick question I wanted to ask about that: Currently, after a node has run
I'm also going to assume that we want |
Exactly you got it. I consider these functions like secondary constructors/deconstructors that are triggered when active/inactive state changes. So from my perspective yes only Then similarly to how So node initialization would be: Teardown would be: though I could also consider flipping these so inactive is before _exit_tree I could see both, but I think having it triggered by the exiting of the tree is probably easier to implement. That covers cases where if we set it inactive during runtime then it doesn't call |
|
In theory, the inactive function should be called before exit tree. On disable/inactive would often be used for cleanup of things set up during on enable/active. If possible, that cleanup should also work the same way even when exiting the tree (i.e., while the node is still in the tree). Also, as a rule, I believe that lifecycle function pairs should be nested so that their setup/cleanup scopes are preserved. Rough XML visualization of what I mean: <tree-scope>
<!-- On enter tree -->
<active-scope>
<!-- On active -->
<game-loop></game-loop>
<!-- On inactive -->
</active-scope>
<!-- On exit tree -->
</tree-scope> |
Yeah which is why I suggested that it possibly could be switched to before |
No worries, it was easily added before Currently facing a bug that when I switch scene tabs in the editor, the new node_active property is reset to false for the root node of the scene you switch to. I'm at a bit of a loss as to why that's happening, best idea is that I'm missing some serialization step or something in regards to root node properties during scene switching, but I don't see any special treatment on any of the other properties for this case so I'm not quite sure. Appreciate any ideas there if anyone knows why that may happen! Besides that I still have to generate the XML docs and test thoroughly, perhaps with new unit tests as well. Everything else is pretty much finished and cleaned up (should be done within a week or so if I'm lucky with fixing that bug), and it's gearing up to be a hefty PR so I imagine it will take some months to get it reviewed/merged. Will do the best I can though and appreciate your support when it's ready since community interest helps with getting it seen faster :) |
That is interesting, so it doesn't happen for visibility, I'd have to actually look into it but that's interesting, I wonder what happens when you switch tabs. Does it keep the whole scene loaded? Or does it like cache it to disk or something temporarily. I haven't looked too much at the engine code itself but I can check it out. Is there a fork/branch I could see the current changes you've made for this? Not that I think I'll have any luck haha |
|
@Snowdrama appreciate the ideas, I think I figured it out! What happens when you switch tabs is that the scene is removed from the special "editing nodes" list and the new contents are loaded into the tree, so since the new lifecycle call Feel free to check out my progress so far here, though it still has the issue I mentioned above and no tests/documentation yet. I was busy with another PR recently but I'm back on it this week to put the finishing touches on this! |
|
Ohh interesting, I was thinking about this and how this may be a desirable thing? I was curious of how Does At the very least it probably shouldn't do these things if it's not marked as Consider this script, if you close or open the tab @tool
extends Node
func _ready():
print("_ready")
func _enter_tree():
print("_enter_tree")
func _exit_tree():
print("_exit_tree")
#_process and _physics_process are also called, but I omitted them just for clarityNote that if marked as a So I'd imagine that the expectation would be that Godot_v4.3-beta2_mono_win64_AvoBGsZmPg.mp4 |
It should and does currently, same as the other lifecycle calls because it uses the same system to run them. Your demo actually helped a lot with getting me to think about when
Yes, yes, and yes imo. Here we have the same code you applied with the new lifecycle calls: And the script is marked as Capture2024-07-08.13-30-12.movAs you can see, _ready() is only called once on scene load (i.e. in the editor's case, when it loads) but all subsequent tab switching and enter/exit calls will run the lifecycle functions in the desired order :) As for this:
It turns out that |
|
Finally submitted the PR which will close this proposal :) Feel free to check it out, test it, or show your support here: godotengine/godot#94144 Since it's a big change and especially since we are in 4.3 feature freeze right now, it will probably take a while to iron out issues and get it merged but I will keep an eye on it and make any changes necessary. Let me know how it works for you if you'd like to play around with it! Thanks again to everyone that helped with ideas/feedback! |
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.
The text was updated successfully, but these errors were encountered: