Guard: Hide the detection light at minimum scale

[ricardolujan0501-glitch]

Guard: Hide the detection light at minimum scale

When detection_area_scale is set to its minimum value (0.1), the detection area is reduced to its minimum size. However, the Light2D used to visualize the detection area remains visible, causing a triangular light to appear over the guard instead of illuminating the ground correctly.

This change hides the detection Light2D when detection_area_scale is at its minimum value. The visibility is initialized in _ready(), after the guard's nodes are ready.

Resolves #2249

[manuq]

This works! But it needs an explanation, and I wonder if the change is needed in the two places.

Also, please change the title and description to match our contributing criteria. Is very important that you explain your changes.

[manuq]

Please explain why this is needed in the _ready function too. Isn't the one in the setter enough? And why inside the if patrol_path?

[ricardolujan0501-glitch]

Thanks for the feedback! I tested the change and removed the Light2D visibility update from the setter, since the setter only needs to update the detection area's scale.

I kept the Light2D visibility initialization in _ready(), where the detection area and its child nodes are ready. I also moved it outside the if patrol_path block because the visibility of the detection light is independent of whether the guard has a patrol path.

[manuq]

Almost there! Again, please change the title to match our contributing criteria. Current title "Fix issue number" is too generic.

[manuq]

Please don't use get_node("Light"). Instead, give a unique name to the Light node that's in the same guard.tscn and reference it by its unique name from the script.

Alternatively, consider just hidding the whole detection_area node.

[github-actions]

Play this branch at https://play.threadbare.game/branches/ricardolujan0501-glitch/main/.

(This launches the game from the start, not directly at the change(s) in this pull request.)

[manuq]

Thanks for the feedback! I tested the change and removed the Light2D visibility update from the setter, since the setter only needs to update the detection area's scale.

I kept the Light2D visibility initialization in _ready(), where the detection area and its child nodes are ready. I also moved it outside the if patrol_path block because the visibility of the detection light is independent of whether the guard has a patrol path.

Have you tested it in the editor? These assumptions look wrong, are these thoughts yours? In #2799 (comment) I suggested the opposite. The setter should be enough, unless you can let me know why is needed in the _ready too. Perhaps I'm missing something.

[ricardolujan0501-glitch]

Sorry for the confusion. I did not properly answer your question in my previous comment about why the line of code is not used only in the setter. I left it this way because it was not working as expected—the light cone was still appearing.

The light needs to be updated when the Guard is initialized, which is why it was also placed in _ready(). It was accidentally left inside the patrol_path check, and since it worked when tested, I did not modify the code further and did not notice it was still there.

In the latest update, it was removed from the patrol_path check and kept only in _ready(). The node reference was also updated to use the unique name of PointLight2D, and it was removed from the setter since the Detection Area Scale does not change during the scene.

[manuq]

Sorry for the confusion. I did not properly answer your question in my previous comment about why the line of code is not used only in the setter. I left it this way because it was not working as expected—the light cone was still appearing.

I understand why now: this is a tool script, so you need to call the setter from the _ready function as well, with the existing value. In the same way that the _set_sprite_frames() is currently called:

func _ready() -> void:
	# (...)
	_set_sprite_frames(sprite_frames)

This is because the setter is called too early when running in the editor, with detection_area and _light being null. I verified this by adding a print line to debug:

## Scale factor for the detection area.
@export_range(0.1, 5, 0.1, "or_greater", "or_less") var detection_area_scale: float = 1.0:
	set(new_value):
		prints("DETECTION AREA SETTER", detection_area, _light, detection_area_scale, new_value)
		detection_area_scale = new_value
		if detection_area:
			_light.visible = detection_area_scale > 0.1
			detection_area.scale = Vector2.ONE * detection_area_scale

This prints DETECTION AREA SETTER <null> <null> 1.0 0.1 for all the guards in res://scenes/quests/lore_quests/quest_001/3_stealth_level/stealth_level.tscn.

The light needs to be updated when the Guard is initialized, which is why it was also placed in _ready(). It was accidentally left inside the patrol_path check, and since it worked when tested, I did not modify the code further and did not notice it was still there.

In the latest update, it was removed from the patrol_path check and kept only in _ready(). The node reference was also updated to use the unique name of PointLight2D, and it was removed from the setter since the Detection Area Scale does not change during the scene.

Yes but we want this to be reflected in the editor as well. If you put it only in the _ready(), then the guards light looks fine when the scene is opened:

But when I change the scale from the Inspector, they are not updated:

Grabacion.de.pantalla.desde.2026-09-02.14-00-41.mp4

To avoid having the same line in 2 places (as in your first attempt):

• Change the setter to a named function.
• Make the light visible or not in the setter.
• And call the setter from the

[ricardolujan0501-glitch]

Hello, first I force-reset my local branch to return to the initial commit (6bc3880) before making the modifications, because I felt that I had already changed too much during the previous tests.

Regarding the issue, I created two functions to independently control the light and the detection area. The first one controls the light visibility when detection_area_scale reaches 0.1. The second one adjusts the detection area to keep the behavior consistent.

The problem I found during testing was that when reducing the detection area to 0.1, the light disappeared correctly. However, when starting the scene, the light remained hidden while the detection area returned to a value of 1.0. This caused the enemy to detect the player even when the light was visually disabled.

For this reason, I implemented both functions and call them from both the setter and _ready, so that the light and detection area states remain synchronized both when changing the value in the editor and when starting the scene.

[manuq]

It looks like I commented without part of my comment, sorry:

To avoid having the same line in 2 places (as in your first attempt):

• Change the setter to a named function.
• Make the light visible or not in the setter.
• And call the setter from the

• And call the setter from the _ready() function with the existing value, in the same way _set_sprite_frames(sprite_frames) is called.

[manuq]

Instead of this, add a named setter:

@export_range(0.1, 5, 0.1, "or_greater", "or_less") var detection_area_scale: float = 1.0:
	set = _set_detection_area_scale

Which would look like:

func _set_detection_area_scale(new_detection_area_scale: float) -> void:
	detection_area_scale = new_detection_area_scale
	if not is_node_ready():
		return
	if detection_area:
		detection_area.scale = Vector2.ONE * detection_area_scale
	_light.visible = detection_area_scale > 0.1

[manuq]

Instead, please call the named setter, like done with sprite_frames:

	_set_sprite_frames(sprite_frames)
	_set_detection_area_scale(detection_area_scale)

[manuq]

This should be removed, since now the setter takes care of it.

[manuq]

Please remove these in favor of the setter that I provided.