Through further experimentation, I have found that removing the script from the node and adding it back gets it to work

I was just about to post this for setters.
while work around for the int setter above does work, it doesn't seem to even try, for anything that's in the tree like a Node3D.

@tool
extends MeshInstance3D

@export var vint:int:
	set(v):	print("int ", v)

@export var vVector3:Vector3:
	set(v): print('Vector3 ',v)

@export var vNode3D:Node3D:
	set(v): print('Node3D ',v) ; vNode3D = v

@export var vResource:Resource:
	set(v): print('Resource ',v) ; vResource = v

everything but the Node3D prints whether you just open the scene or change the setting. this is of course only after closing and reopening the scene after adding the setter.

on run it does.
though the Node3D setter fires later in order after other scripts have initialized. which I would assume is exactly right. ex:

CORE API HASH: 2378449490
EDITOR API HASH: 200905626
Loaded builtin certs
int 0
Vector3 (0, 0, 0)
Resource <Texture2D#-9223372010933976765>
set:::: Target:<MeshInstance3D#26088571289>  <-- setter in other script
Node3D Node3d:<Node3D#26105348500>

• Related to Exported resource property with custom setter in tool script cannot be cleared by resource picker in editor #65916 and Exporting Node variable can't trigger setget in tool mode. #69283.

Through further experimentation, I have found that removing the script from the node and adding it back gets it to work

On my side, with a reference (Marker2D) field, reopening the scene or re-adding the script doesn't fix the issue. The setter simply seems ignored. Even assert(false) will show nothing.

This prevents me from calling update_configuration_warnings when assigning a field, so my warning stays longer than necessary (I wanted to see how built-in classes like AnimatedSprite2D do it, but I figured they are written in C++).

Since the issue only happens with get/set and assigning field in the inspector, should we rename the issue to something like "Inspector not running property get/set when reading/assigning field"?

EDIT: actually I just read about parse_begin / parse_end also failing in the original post, and I've just tested _process and couldn't make it work it works, but after some reload. I'm surprised most editor plugins are not broken by now. Maybe checking which ones still work or don't work and why could help us.

I tested again with a numeric property, and it worked this time. Warning was removed / appears in one second.
So, this only seems to happen with reference assignment now.

@export var waypoint: Marker2D:
	set(value):
		waypoint = value
		update_configuration_warnings()

@export var arrival_margin: float = 5.0:
	set(value):
		arrival_margin = value
		update_configuration_warnings()

func _get_configuration_warnings() -> PackedStringArray:
	var warnings:PackedStringArray = []
	warnings.append_array(super._get_configuration_warnings())
	if waypoint == null:
		# this is always entered, as if waypoint node was not ready
		warnings.append("Waypoint must be set")
	if arrival_margin < 0:
		# this is only called when actually the case
		warnings.append("arrival_margin %s is negative" % arrival_margin)
	return warnings

One explanation could be that this is executed while iterating over the tree in a certain order, and referenced nodes are not ready yet (debugging showed that it was the case in _ready indeed, but I don't see why it would be when assigning a field in the middle of working in the editor).

In my case the set action does work while the game itself is running and that it does not work when the game is not running

@tool
extends Node2D

@export var seed : int = 0:
	set(new_seed):
		seed = new_seed
		print("the seed is ", seed)

Also seeing this issue: I'm unable to run scripts in the editor via @tool.

Following the official docs' tutorial on @tool verbatim doesn't work.

IMO, I think this is a high priority feature to get working. Without editor scripting working, procedural generation is a total "guess and check" operation.

@Mietzsche81 what specifically is not working, is it different from what's already mentioned here? Because running scripts in the editor does work in general

@AThousandShips

is it different from what's already mentioned here?

Yes, to clarify: I am not able to run scripts in the editor in general. v4.0.2.stable.official.7a0977ce2 on Windows 10.

I have tried closing/reopening the scene and still can't even get the tutorial's rotation behavior to work.

Have you restarted the editor?

This is unfortunately a current limitation which I'm not sure why it is, nor is it documented, can't find an issue tracking it either

@AThousandShips huge thanks, that did the trick.

In case it's helpful to anyone:

When adding/removing @tool from a script or attaching/detaching a @tooled script to a scene, you must restart the editor to add/remove interactivity in the editor

After restarting, I'm now able to edit the script and see the behavior change immediately without having to restart the editor. But if I create a new scene and attach the same script to it, I have to restart the editor again to get the behavior into the process loop.

@AThousandShips lots of people been running into this, really ought to be documented !!!

Agreed, if an issue over it can't be find someone please open one (I'm preoccupied at the moment)

See also:

• Setter function is not called for newly created export variables #81972

  Tested on 3.5.2
  The behavior was instantaneous and worked fine. It didn't require reload of scene or Project

• "@tool“ signal connect is not working when you first create scripts #82443

  Reopening the scene also works, not just restarting godot entirely.

When adding/removing @tool from a script or attaching/detaching a @tooled script to a scene, you must restart the editor to add/remove interactivity in the editor

This shouldn't be a requirement. Attaching a script should just work, at most you need to reload the scene (especially for previously attached scripts). If this is not the case right now and you need to restart the whole editor, it's not something to document but rather something to fix.

Importantly, though, does this still happen in 4.1.3 or 4.2 betas?

does this still happen in 4.1.3 or 4.2 betas

@YuriSizov I believe I can confirm this is still happening in 4.2-rc.2, though the behavior I'm seeing might not quite be the same. Also I'm using C#.

1. Create main scene.
2. Add another scene ("secondary scene") as a child of the main scene.
3. To a child of the secondary scene, add a script with the [Tool] annotation.

This Tool script will only run when the main scene is opened, and not the secondary scene. Restarting Godot enables it to run in both scenes.

Can confirm the bug still exists on 4.2 also with GDScript.

Bump happening to me as well on v4.3.dev5.official [89f70e9]