Another tool improvement porposition, but without opt in/out of functions

[Vitorgus]

Yes, tooling is great

...but it's also quite finicky. Sometimes have to implement a lot of safeguards just for simple usage. And there have been some suggestions on how to improve it, but most are based on adding annotations on functions to opt in/out of executing them in the editor.

My suggestion is to make tool run the same stuff it already does inside the editor, EXCEPT the node's _process and _physics_process functions. And for the cases where processing is needed, add two new built-in functions, _tool_process and _tool_physics_process.

Care to explain?

Alright, let's do this in parts. Disclaimer that my GDScript sintax will be of godot 3, since it's the one I use the most.

First one is to make tool not run both_process and _physics_process. The use case for this would be for simple things: a setter function that changes/adjusts the way the node is displayed according to an exported variable; a simple drawing that occurs inside the _ready function that shows a launchpad trajectory.

tool
extends Node

# onready variables would be set!
onready var x := 0 setget set_x

# setget functions would work!
func set_x(value):
    if value < 100:
        x = value

# ready function would run!
func _ready():
    ...

# process function would NOT run
func _process(delta):
    ...

# physics process function would NOT run
func _physics_process(delta):
    ...

If you need to separate some code to run only in game or in editor inside a setter or ready function, then you'd use the Engine.editor_hint we already have.

tool
extends Node

func _ready():
    if Engine.editor_hint:
        # Code to run in editor.
    else:
        # Code to run in game.

    # Code to run both in editor and in game.

But what if you need the process function to run inside the editor?

That's where the new built-ins _tool_process and _tool_physics_process comes in! The idea is that the editor would run these two functions, instead of the _process and _physics_process.

When you would need to run a script in editor and another in game, simply put the code in the appropriate function.

tool
extends Node

# logic to run in-game
func _process(delta):
    ...

# logic to run inside editor
func _tool_process(delta):
    ...

For the cases where you need to run a process function insinde both the game and the editor, you can simply call it inside the correspoding tool function.

tool
extends Node

func _physics_process(delta):
    ...

func _tool_physics_process(delta):
    # You can do things in the editor before the game logic runs
    _physics_process(delta)
    # Or after

If you need to add new behaviour in the middle of the code that run in the process function... yeah well in this case all I can think of is to copy/paste your process function logic inside the tool function, and change what you'd like.

tool
extends Node

func _physics_process(delta):
    # Game logic here

func _tool_physics_process(delta):
    # Same logic as above, but slightly modified

In this specific scenario code duplication would be needed, and if you modify the game logic you'd have to modify the tool logic to match it. But it can be migitaged depending on how you structure your code. If all your game logics are inside helper functions, and there are only function calls inside the process function, for instance.

tool
extends Node

func _physics_process(_delta):
    # Game logic
    do_first_stuff()
    do_second_stuff()
    do_third_stuff()

func _tool_physics_process(_delta):
    # Same logic as above, but slightly modified
    do_first_stuff()
    do_second_stuff()
    do_stuff_only_in_editor()
    do_third_stuff()

What do you guys think?

I think this proposition makes tooling use to follow the complexity of the code you need to run in the editor. Simple cases would need simple adjustments, and more complex ones would require a bit more thinking, depending on your needs. And also don't know how to adjust the proposed system to avoid code duplication in more complex editor processing scenarios, but I'm think those would not be the majority of tooling uses.

[theraot]

I think this would work. The idea had crossed my mind before, but I didn't attempt to write a proposal for it, see #6767 (comment)

I didn't think of _tool_physics_process at the time, I was thinking that there is no use of _physics_process running in the editor... But now I think that since it does currently run in the editor, perhaps some people out there would be using it, so it is good to give them an option to migrate to.

Something else: I believe there is value in _tool_ready (look, even in your example you have a check inside of _ready).

---

By the way, since this is a breaking change, I' guessing it would be for Godot 5.

[Vitorgus]

I assumed that for the most cases, the logic inside _ready would be desired to run both in editor and in game. So if there was a _tool_ready function, it would almost always call the _ready function inside.

func _tool_ready():
    _ready()

So having the _ready function run in both scenarios would remove the need to explicitly call it every time.

But then again, this was based on my assumptions. If most of the cases for tooling inside ready requires explicitly separation of editor and game logic, makes perfect sense having a separate _tool_ready.

---

One way I can think of this feature be implemented in Godot 4 would be to have both tool modes available for use, and have a projec setting that would toggle between the two. Existing projects would have the toggle off by default, so they would use the previous tool system and preserve compatibility, while newly created projects would have it on by default.

But I don't know how complex would it be to implement/mantain both systems at the same time.

[Calinou]

One way I can think of this feature be implemented in Godot 4 would be to have both tool modes available for use, and have a projec setting that would toggle between the two.

We should avoid adding project settings that affect scripting behavior, as it means that copy-pasting a script across projects may change its behavior. This is problematic for add-ons.

[Vitorgus]

Oooh I see. Makes sense.

[aXu-AP]

I agree that some solution is needed, using editor hint at the beginning of every function adds noise and potentially some overhead if the code is hot.
I think this would be great to handle with annotations. I think the logic is clear that by default in tool scripts everything runs in both editor and runtime. But you could annotate for exceptions eg. @only_tool and @no_tool. If you want function to partially run in editor and partially in runtime, separate the logic into 2 functions and annotate those:

func _ready():
    runtime_ready()
    editor_ready()

@no_tool
func runtime_ready():
    pass

@only_tool
func editor_ready():
    pass

This solution would also be non-breaking change.
Internally, could unnecessary bits be purged when compiling to bytecode? I'm not very familiar with scripting engine details so I don't know 😅

[theraot]

See also #729