Checkpoint: Add tile change persistence by NataliaOspinal · Pull Request #2877 · endlessm/threadbare

NataliaOspinal · 2026-09-10T23:11:18Z

Whenever an enemy changes part of the tilemap as the VoidSpreadingEnemy does, if the player reaches a checkpoint and dies, the scene resets to its original state instead of keeping the changes that we'd like to keep in previous traveled zones for storytelling or possible gameplay mechanics.

To fix this, I created a new Checkpoint child class (I wasn't sure I could edit the original, but if that's the idea I could just add a checkbox for persistent enemies and the respective exports to incorporate the code to the original) that effectively tracks with both _process and _physics_process for accuracy of tile changes, checking the respective paths and its enemy states.

Note: I've included (as part of the code) a way to track the changes of a possible void-spreading guard, since that was the idea shown in the screenshots of the issue!

Resolves: #1208

github-actions · 2026-09-11T13:37:08Z

Test build no longer available.

wjt · 2026-09-14T11:54:09Z

+
+# Store everything including position, paths, and consumed tiles in a single dictionary 
+# bound strictly to each enemy to prevent synchronization issues.
+static var saved_enemy_states: Dictionary = {}


As commented on #1208 (comment) I don't think static variables are an appropriate approach.

Gotta fuse the new code with the og checkpoint in a way that doesn't affect (?) existing ones

manuq · 2026-09-16T17:16:57Z

@NataliaOspinal I see you have added new changes. Let us know when it's ready for review again.

NataliaOspinal · 2026-09-22T22:49:49Z

Hello! The code is ready for review, I gave notice on the Issue itself a few days ago, but just in case I'm giving notice here too! @manuq

manuq

This is looking good, but I wasn't able to test it! Please provide a working example. You could add one in scenes/dev/level_design/. Check for instance, the scenes/dev/level_design/doors_and_levers/.

manuq · 2026-09-23T15:15:40Z

The comment in the ticket "Imagine that the template enemies are void-spreading enemies which chase you, but can't cross the bridges" was hypothetical. Sorry for the confusion. Please revert any changes to guard.gd.

Okay got it! I created a testing scene inside scenes/dev/level_design/void_persistence and reverted the changes in the guard.gd script! Let me know if more changes are needed!

manuq · 2026-09-28T18:05:33Z

Nice, if I abandon the demo and continue it, I can see it persists:

void-persisted.webm

And it resets properly if I restart the demo quest.

manuq · 2026-09-28T18:06:36Z

+	if path_walk_behavior:
+		data["path_progress"] = path_walk_behavior.get("progress_ratio")


PathWalkBehavior doesn't have any progress_ratio property. Am I missing something or is this a leftover?

manuq · 2026-09-28T18:07:01Z

+		if path_walk_behavior and data.has("path_progress"):
+			path_walk_behavior.set("progress_ratio", data["path_progress"])


Same, no "progress_ratio" in PathWalkBehavior.

manuq · 2026-09-28T18:35:03Z

+	for listener: Node in get_tree().get_nodes_in_group("persistence_listeners"):
+		if listener.has_method("_on_checkpoint_activated") and not activated.is_connected(listener._on_checkpoint_activated):
+			activated.connect(listener._on_checkpoint_activated)
+	activated.emit(self)


Using the nodes in a group for connecting and then immediately calling the signal, makes the signal irrelevant. This could be done by calling the method directly:

get_tree().call_group("persistence_listeners", "_on_checkpoint_activated")

Now, there is a better way of doing this, with a signal and without the grouping. For that, please check how the signal lights_changed in per_scene_state.gd is used to turn on/off lights in the game. Then add a similar signal checkpoint_activated one.

manuq · 2026-09-28T19:05:02Z

+## Dictionary to store arbitrary persistent scene facts, such as enemy states and consumed tiles.
+@export var facts: Dictionary = {}


Interesting! We already have 2 other generic facts, one global GameState.global.facts, and one per-quest GameState.quest.facts.

For collected buttons, we use those because we don't want the buttons to re-appear when replaying the scene. Now I think for the Void enemy position and consumed tiles, it makes sense to add a new per-scene generic facts. Adding this here will make them reset when the scene changes. Seems to be what we want.

manuq · 2026-09-28T19:15:39Z

@NataliaOspinal this is looking nice! If you can, in addition to the request above, please:

Fix the formatting errors. If you install pre-commit like described here, it will be done automatically https://github.com/endlessm/threadbare/wiki/Contributing#coding-style
Make the demo level more similar to the one in the ticket description Support checkpoints in expanding void levels #1208. That is, a sequence of 2 runners with a checkpoint in the middle. That will make this more easy to test.

manuq · 2026-10-05T21:28:55Z

@NataliaOspinal do you know if you will continue working on this?

manuq · 2026-10-06T18:27:37Z

I'm going to close this for now. @NataliaOspinal feel free to reopen!

NataliaOspinal · 2026-10-06T19:17:05Z

I think I got it now! I edited the dev level and implemented the variables in PathWalkBehavior, plus changed the get_tree().call_group("persistence_listeners", "_on_checkpoint_activated") to a signal in per_scene_state! I did change the scripts a couple of days ago but I was struggling to make the void enemies chase the player in the dev level so it can be easier to check the changes. I'll push the changes now, let me know if it needs more editing!

NataliaOspinal · 2026-10-06T19:23:38Z

I'm going to close this for now. @NataliaOspinal feel free to reopen!

Should I create a new PR with a reference to this one? It doesn't let me re-open

manuq · 2026-10-07T14:47:16Z

Should I create a new PR with a reference to this one? It doesn't let me re-open

Interesting. I just reopened it for you.

NataliaOspinal · 2026-10-10T06:39:52Z

Hi! @manuq Just in case I'm letting you know I pushed the new changes last time, the day the issue was re-opened. Let me know if there's more editing to be done! Thank you for the helpful reviews! 😄

manuq

If I get cought by the second Void enemy and then go back to the checkpoint, the game crashes and the game state is not recoverable. If I stop the game and try to continue, I get the same error again:

E 0:02:32:860   NavigationFollowWalkBehavior._physics_process: Invalid access to property or key 'global_position' on a base object of type 'Nil'.
  <GDScript Fuente>navigation_follow_walk_behavior.gd:144 @ NavigationFollowWalkBehavior._physics_process()
  <Rastreo de Pila>navigation_follow_walk_behavior.gd:144 @ _physics_process()

Grabacion.de.pantalla.desde.2026-10-13.10-15-38.mp4

NataliaOspinal · 2026-10-28T17:05:33Z

I've tested it from the dev archipelago now, it works! I'm not sure if I should have updated my main branch with the original main branch before pushing the fixes, but I have a "bringing-back-changes" branch that exists before that merge just in case.

manuq · 2026-10-28T21:20:08Z

@NataliaOspinal thanks! I will check this soon!

NataliaOspinal · 2026-11-11T23:31:18Z

Thank you for helping me restore the main branch! Is it ready for merge? I tested it again a couple of times to make sure and I think it seems to work fine on my end?

manuq · 2026-11-13T18:22:27Z

+		if parent == null:
+			continue


I can see that you added this to avoid the problem of unassigned elements in the inspector, which the void_persistence_test.tscn has:

I think it's fine, but I will add a comment about it in the code.

manuq · 2026-11-13T18:25:24Z

+	if (
+		GameState.scene != null
+		and not GameState.scene.checkpoint_activated.is_connected(_on_checkpoint_activated)
+	):
+		GameState.scene.checkpoint_activated.connect(_on_checkpoint_activated)
+	_load_state()


This is in a _ready function of a @tool script that already returns early if running in the editor. So I don't think the conditional is needed. Because a TileMapCover will always be part of a scene. I tried it without the conditional and the example works fine. I'm going to drop it.

manuq · 2026-11-13T18:27:08Z

-	if animate_modulate:
-		self.modulate.a = 1.0
+	self.modulate.a = 1.0


This reverts the change in 48565eb. So I'll bring it back.

manuq · 2026-11-13T18:30:42Z

+	if not checkpoint.save_void_and_enemies:
+		return


I don't think that the checkpoint should have the knowledge about this node wanting to be saved. Instead, the setting for saving should be in each TileMapCover and void_spreading_enemy.gd

manuq · 2026-11-13T18:35:48Z

+	if GameState.scene == null or not "facts" in GameState.scene:
+		return


Same here, this extra safety isn't needed. This node will be part of a scene, and a PerSceneState always has a facts property.

manuq · 2026-11-13T18:48:14Z

+	if (
+		GameState.scene != null
+		and not GameState.scene.checkpoint_activated.is_connected(_on_checkpoint_activated)
+	):
+		GameState.scene.checkpoint_activated.connect(_on_checkpoint_activated)
+	_load_state()


Same as with the tilemap cover. Instead of adding the extra safety, do an early return in the _ready when running in the editor. And connect later.

manuq · 2026-11-13T18:49:05Z


 ## Makes this the active checkpoint.
 func activate() -> void:
+	if GameState.scene != null:


You can see that scene here can't be null, because the next line uses it (GameState.scene.spawn_point).

manuq · 2026-11-13T20:19:50Z

+	if GameState.scene.facts.has(save_key):
+		var data: Dictionary = GameState.scene.facts[save_key]
+
+		global_position = data["position"]


For consistency this should be:

Suggested change

global_position = data["position"]

global_position = data["global_position"]

And the same when loading the save.

manuq · 2026-11-13T20:31:17Z

 signal lights_changed(lights_on: bool, immediate: bool)

+## Emitted when the player activates a checkpoint.
+@warning_ignore("unused_signal")


To avoid this warning the checkpoint script can call a method in PerSceneState, rather than using the signal directly:

func activate_spawnpoint() -> void: checkpoint_activated.emit()

manuq · 2026-11-13T20:49:12Z

Thank you for helping me restore the main branch! Is it ready for merge? I tested it again a couple of times to make sure and I think it seems to work fine on my end?

I did some changes for merging it. Congratulations!

NataliaOspinal added 5 commits September 10, 2026 11:00

Checkpoint_void first ver

cc395a4

Update checkpoint_void.tscn

b50de8c

Update checkpoint_void.gd

a20d780

fix path tracking

ce24aef

Final checkpoint_void after testing

b7ad2ca

NataliaOspinal requested a review from a team as a code owner September 10, 2026 23:11

wjt requested changes Sep 14, 2026

View reviewed changes

NataliaOspinal added 2 commits September 14, 2026 12:41

Delete separate prop

6ac56c7

Gotta fuse the new code with the og checkpoint in a way that doesn't affect (?) existing ones

Update with game_state

e4acba8

NataliaOspinal and others added 2 commits September 17, 2026 17:11

Shift overall responsability to checkpoint

80b6aad

Merge branch 'main' into main

ee1ce69

NataliaOspinal requested a review from wjt September 17, 2026 22:57

manuq requested changes Sep 23, 2026

View reviewed changes

testing scene + deleting changes in guard

a3517bf

NataliaOspinal requested a review from a team as a code owner September 24, 2026 00:38

NataliaOspinal requested a review from manuq September 24, 2026 00:43

manuq requested changes Sep 28, 2026

View reviewed changes

manuq closed this Oct 6, 2026

Fix: Script and Dev Level

983abaa

manuq reopened this Oct 7, 2026

NataliaOspinal requested a review from manuq October 7, 2026 17:13

manuq assigned NataliaOspinal Oct 8, 2026

manuq modified the milestone: UTP CGM 4.0 Oct 8, 2026

manuq unassigned NataliaOspinal Oct 8, 2026

manuq requested changes Oct 13, 2026

View reviewed changes

NataliaOspinal and others added 2 commits October 28, 2026 13:23

Merge branch 'endlessm:main' into main

9cc9597

Fix: Bug Crash

63b0b15

NataliaOspinal requested a review from manuq October 28, 2026 17:07

manuq added 2 commits October 29, 2026 08:41

Fix format errors

822e1b5

Restore unwanted change from main

b6de07c

Fixups

ff68fc1

manuq approved these changes Nov 13, 2026

View reviewed changes

manuq merged commit 8f72093 into endlessm:main Nov 13, 2026
4 checks passed

		if path_walk_behavior:
		data["path_progress"] = path_walk_behavior.get("progress_ratio")

		if path_walk_behavior and data.has("path_progress"):
		path_walk_behavior.set("progress_ratio", data["path_progress"])

		## Dictionary to store arbitrary persistent scene facts, such as enemy states and consumed tiles.
		@export var facts: Dictionary = {}

		if GameState.scene == null or not "facts" in GameState.scene:
		return

	global_position = data["position"]
	global_position = data["global_position"]

Conversation

NataliaOspinal commented Sep 10, 2026 • edited by wjt Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

manuq commented Sep 16, 2026

Uh oh!

NataliaOspinal commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

manuq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

manuq commented Sep 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

manuq commented Sep 28, 2026

Uh oh!

manuq commented Oct 5, 2026

Uh oh!

manuq commented Oct 6, 2026

Uh oh!

NataliaOspinal commented Oct 6, 2026

Uh oh!

NataliaOspinal commented Oct 6, 2026

Uh oh!

manuq commented Oct 7, 2026

Uh oh!

NataliaOspinal commented Oct 10, 2026

Uh oh!

manuq left a comment

Choose a reason for hiding this comment

Uh oh!

NataliaOspinal commented Oct 28, 2026

Uh oh!

manuq commented Oct 28, 2026

Uh oh!

NataliaOspinal commented Nov 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

manuq commented Nov 13, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

NataliaOspinal commented Sep 10, 2026 •

edited by wjt

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

NataliaOspinal commented Sep 22, 2026 •

edited

Loading