Just wanted to let you know I’m looking into it and working on possible solution/workaround that keeps your setup the same. The object setup helped greatly as there is more going on to consider such as animations, multiple save points trying to rectify each other, etc. I’ll respond here when I find something that works. My goal is to present a system where you can have 1 object for all save points and they can all ‘clean up’ themselves when a save point is triggered. Of course I will stay true to your current logic (though it may be arranged a little different).
1 Like
Regarding the save expiration issue, I’d like to ask Mr. Baz: has the development team taken any action to investigate the cause? This is one of several major bugs currently causing trouble 
Hello S.C!
I’ve been working on this and I have a module for you to try. This is the system I mentioned before, where one object handles all of your save points and cleans itself up when a save point is triggered.
First, I want to mention I was not sure why you had a separate save point A and save point B. I did some tweaking and got it working with just one save point, and I hope that is okay. I took save point A, added a ChangeAction to it, and rearranged a few things. You can see it all in the module.
Here is how to install and use the module:
- Download the module. revamped_save_a.tres (9.8 KB)
- Open the Module List window. It is down near the Output Debugger window.
- Click the folder icon, then click “Open My Module Location in File Manager.”
- Put the downloaded module into that folder.
- Back in AGMaker, click “Reload Module List” (right next to the folder icon) to refresh.
- You’ll now see the revamped Save A. Drag it into the Visual Script of save point A.
- Delete the old states you had in there.
- Set the initial state to the correct one. It sometimes gets mixed up, so please double check this.
Next, go to Game Scene 2 and space the candles out a little more. If they are too close together, they will save at the same time and cause logic issues. This is just a caveat of the object distance being set to 25. I’m guessing you’ll never place them that close anyway, so just separate them a little.
Getting both A and B working is more technical. With ChangeAction and all of them set to A, it works really well. But with a B and an A, the A will activate before the B can switch to that state. So if you can manage with just one save point, I think you are better off. It is just how these actions and conditions work.
Please test this and let us know how it goes for you. If you really do need both save point A and save point B, let me know why you needed two and I’ll rethink the approach.
Thanks for the reply, Baz. The main reason for using two save points, A and B, is to keep the animation of turning back into a candle seamless.
As you can see, my level scenes may feature two save points within the same frame. If saving at the first one caused the other to also change its animation simultaneously, it would look very strange. So I ultimately decided to use A and B, allowing each to play its own animation independently, even when they’re under the same camera view.
Would something like this be more acceptable?
It seems the video has expired and cannot be viewed~ Switching to English mode makes it visible.
All animation frames in the game were drawn by me, with the hope of making the game’s animated sequences smoother. If there are any stutters or dropped frames, I, as the creator, would find it unacceptable 
I have put a lot of effort into the smoothness of the animation, hoping to understand
I will keep trying to refine the visuals and get back to you.
Thank you so much!
Is the save failure caused by the simultaneous presence of A and B an issue that the development team has confirmed cannot be fixed in the engine?
Do we need to find another way to overcome this challenge?
Correct this isn’t a bug, it’s a Visual Script or design setup matter. For context, getting save/load to feel smooth and polished is one of the trickier things to nail, and it was the same in PGM. The save/load system is deliberately simple and reliable. The real work is dressing it up with coordinated visuals (for example only one point lit at a time, retract animations that don’t repeat, that kind of thing).
One design solution is to layout the level in a way to not have multiple save points be able to be seen within the same viewport. That would be the easiest quickest way.
What about this?
The animations fight too much with the logic so I separated them out a bit. There is a script that takes care of the animations and the VS is purely the logic.
What do you think?
This looks pretty good. Thanks a lot, Mr. Baz, for the optimization. Although I haven’t fully grasped the logic yet, it seems I need to send it over to the engineering team for further research!
After being told yesterday that this wasn’t a bug, I came up with a simpler way to resolve the save failure issue. Instead of saving A and B separately, we can replace them with variable switches. We can also create an empty object in the scene that triggers a save whenever the switch is turned on. This way, we can ensure there’s only one save object for the entire game
Oh ok you already solved it. Let me know if you want this version, otherwise I’ll move on to next things.
Please send me a copy of this version. I’m not sure how to implement the effect where a single object animates out of sync. It looks amazing, and I’d love to learn how it’s done!
Setup (in order in 存档点A)
-
Add the script. On Save A, add a child Node and attach
save_point_driver.gd.
save_point_driver.gd (16.5 KB) -
Add the switches. In Switch Settings, add the three below. Names must match the script — rename in both places if you want different ones.
-
Drop in the module. Open the Visual Script and drag in the save point module. AGMaker groups it and renumbers the node ids — that’s normal. It should build all the states and connections for you. custom_save_method.tres (5.9 KB)
-
If the module is broken or missing, build the state machine by hand using the Logic section below.
-
Place your Save A objects wherever the player should be able to save.
-
Delete every Save B and swap in a Save A. Done.
The switches
| Name | Savable | Why |
|---|---|---|
request_save |
OFF | One-shot “save now” signal. If savable, the file stores true and re-fires on every load → loop. |
request_load |
OFF | Same deal for loading. |
current_save_point |
ON | The game has to remember which point was active after a load. |
VS Logic
How the two sides talk:
- Script flips
request_saveON when the player saves → Visual Script runs Save, flips it back OFF. - Script flips
request_loadON after a load (only at the active point) → Visual Script runs Load, flips it back OFF. current_save_pointis the script’s business only. The Visual Script ignores it.
4 states plus an Any State. Start state: wait. wait does nothing on its own — it just listens for the two switches.
Save: wait → on save setup → save → wait
- wait → on save setup — when
request_saveturns ON (Switch Variable Changed, watchingrequest_save). - on save setup runs: Play Audio (save sound) · set
request_save = false· restore player HP (target = P1). - on save setup → save — automatic, no condition.
- save runs: Save Game Data.
- save → wait — automatic.
Load: wait → on load → wait
- wait → on load — when
request_loadturns ON (Switch Variable Changed, watchingrequest_load). - on load runs: Change Action (reset player, P1) · set
request_load = false· restore player HP (P1). - on load → wait — automatic.
Both branches restore HP — that’s why every save and every load also heals the player.
Quick VS Flow:
- Start state is
wait wait → on save setupfires onrequest_save- on save setup: plays sound, sets
request_save = false, restores HP - save: runs Save Game Data
- save → wait is automatic
wait → on loadfires onrequest_load- on load: resets action, sets
request_load = false, restores HP - on load → wait is automatic
request_saveandrequest_loadare NOT savablecurrent_save_pointis savable
1 Like
This is really cool! So you can add GD as a child node under a VS node. I’ve learned a lot—thank you very much to baz for the kind guidance!
1 Like
Thank you for your patience.
We have fixed the object loading leak issue in version 1.3.0, which occurs when the camera gets close. Please check it out.
Thanks, but you replied to the wrong thread. It should be this one:
I also have a question regarding the respawn position of child GameObjects depending on the parent node’s position.
Even in the latest version, there are still many mysterious issues. For example, after selecting a camera for respawn, moving to it sometimes results in a respawn and sometimes doesn’t.
Moreover, after a child node respawns, it doesn’t remain attached under the parent node; instead, it detaches and becomes an independent node.
Is this currently being fixed?
I can confirm there is a ticket open for it. No ETA at this point.