_ready(), _enter_tree() and _exit_tree() for tool scripts.

[aXu-AP]

The process of making tool scripts is often hindered by these objects getting into invalid state since resaving, attaching and deattaching scripts don't call _ready(), _enter_tree() and _exit_tree on node. I understand that this is valid behaviour, since host node itself doesn't get readded into tree, but nevertheless it causes headache and often need to reload editor in order to correctly see the results. I can see 2 different approaches to this problem:

• Free and readd the node whenever changes to script are made. This would provide a clean state and would result into similiar behaviour as reloading the project. For me, this is the expected behaviour.
• Add virtual functions for _script_attached() and _script_deattached(). Saving script would evoke both. This would be more explicit and potentially can skip some heavy initializing logic. However I feel this is a bit extraneous as they would most likely anyway only include calls to the same initializing/deinitializing logic which is located in existing functions.

[theraot]

Since you have _enter_tree and _exit_tree I'll assume we are talking of a tool script attached to a Node in the scene tree. Not an EditorScript.

By the way, if you are talking about an EditorPlugin, know that disabling it from project setting would result in _exit_tree running, So you probably don't have to reload the project, just disable and enable the EditorPlugin. Well, unless there is an error.

---

Before going any further, know that we can reload just the scene from the scene menu, and this will trigger _exit_tree on tool scripts. So reloading the project might be a little drastic.

---

We have a function that is called when the script is saved or attached to a Node. It is called _init.

Now, _enter_tree and _ready only run when you loaded the scene with the script already attached. If you saved the script or you attached it to an existing node, you get _init but no _enter_tree and _ready. So, we could check is_inside_tree(), for example:

func _init() -> void:
	if is_inside_tree():
		_exit_tree()
		_enter_tree()
		# initialize onready variables here
		_ready()

Or we could actually remove and re-add the node:

func _init() -> void:
	if is_inside_tree():
		var parent:Node = get_parent()
		var old_owner:Node = owner
		parent.remove_child(self)
		parent.add_child(self)
		owner = old_owner

By the way, yes, we need to handle owner like that. It is erased when we remove the Node, and add_child does not set it. If we don't set owner the Node would vanish from the Scene panel.

With this approach we can keep initialization on _enter_tree and _ready and it will also run when the script is saved or reattached. Similarly, cleanup can remain in _exit_tree. However, please notice that we are calling _exit_tree on the new script, not the old one. And of course, if the clean up is not appropriate you might still need a reload.

---

Thus, I understand the desire for a place for a custom clean up. Consider the situation when we added a tool script that creates some other nodes, connects signal and so on. These linger after we removed the tool script. The above approach would only help if we were adding a script again. For that situation a more convenient place for cleanup would be useful.

However, we don't have a solution for _script_deattached()… At least not if you want it to run before changing the script. I'd say it needs a better name.

Notice that something called when the script is detached is not possible, because that moment there would not be the method to call. And we already have something called when the new script is attached: _init. So something called before the script is removed is what is missing.

---

I had the idea of coming with some generic cleanup code. I have some notes on that approach:

• The editor will add some not persistent connections, so you cannot simply remove all not persistent outgoing connections. These are the connections I found while testing (On Godot 3.4.4):
  • tree_exiting is connected to _node_removed of EditorSelection
  • script_changed is connected to _node_script_changed of SceneTreeEditor
• About the incoming connections, since the results of get_incoming_connections do not include flags (which we need to check if a connection is persistent). So you have to use get_signal_connection_list on the source of the connection to check.
• If you only add children perhaps you can remove any direct child that does not have owner set. However if the tool script adds Nodes elsewhere, you need to keep track of them so you can remove them.

---

Things that do not work:

• Since it is a getter and setter method pair and not a property we cannot intercept when the script is set in _set.
• Also there seems to be no call to _notification about it.
• If the "changed" signal of the script worked, it would only work when the script is modified, and in that case we have _init. By the way, it does not work (On Godot 3.4.4). See Edit a script in the editor not emit signal "changed"  godot#47615
• There is an "script_changed" signal, but it does not solve anything. It will trigger after the script changed. Which is an error when the script is detached (and even if we connected it to something else instead, it is emitted too late). Plus we have _init for when the script is attached.

[aXu-AP]

Thank you for your elaborate answer. Yes, to clarify, I'm talking about your usual nodes in scene with added tool script.
I hadn't thought about checking is_inside_tree in _init, that does work! Cleaning up is still nuisance, but more often initialition logic is all we need.

As you mentioned, if tool script adds some helper nodes they will be left lingering. However since issue is marginal (and doesn't affect end product), I'd rather keep my script tidy and simple than add extra logic to do detective work for cleaning.

I also hadn't noticed reload scene option, I guess I already got used to reloading the whole editor when working with plugins (those tend up to be ever worse mess). Well, in the end reloading Godot takes like 2 seconds, so it isn't that bad.