I know the stat screens operate a little differently from normal scene files, so I’d like to check something from those in the know.
I’m strategically placing reload/restore options across my game, mixed in with other choices. I would much prefer to take them all out and have a stats screen menu for checkpoints if I could.
Has anyone used the newish checkpoint system in a stats screen?
If so, what I really want to know is, did it work?
I have Load Chapter menus in most of my games on the stat page, I think it’s the most streamlined in The Earth Has Teeth WIP - the code is visible so feel free to have a look on the stat page code on there.
I’m not sure if you can use *save_checkpoint on the stat page though.
Loading a checkpoint from the stats screen:
It is officially supported by CoG, but someone did report a bug with it a while back, so it is probably not entirely stable. (As of this writing, I was still able to reproduce the bug on the omnibus.)
Saving a checkpoint from the stats screen:
I don’t think this feature is officially supported by CoG, and I’m not sure what would happen if you tried to code a checkpoint save in the stats screen. Another HG author did raise this question, but I don’t think anyone was able to answer.
Thanks, and double thanks for having the code available!!! I’ll take a look. I think I set up my checkpoints in a funny way. In a few early hubs, I have the option to save over certain checkpoints (it worked with Green), so perhaps I’ve created more problems. However, a stat menu would be far more elegant than periodically putting the option into choices.
Appreciated. I know most of the vagaries I need for the checkpoints to work, and my energy is floundering and hitting mental blocks. I’ll have a pop at sorting out a stats screen. If I can’t get my head around it, I’ll stick to what I know.
I shall venture forth armed with a little more wisdom.
EDIT: I’ll focus on my inelegant way first, just so I know I have something functional, then I’ll explore The Earth Has Teeth to see if I can streamline things.
Now that I’m at my computer, I’ll share the code directly here as it may be easier for you or others who are interested!
I have *save_checkpoint auto at the start of the game (after the game description, gender-selecting preamble etc).
At the end of each chapter, I call the following subroutine. Note that I have implicit_control_flow switched to true and if you have it set to false, you’ll need to add *goto commands where appropriate.
*label checkpoints
*page_break Next Chapter
*label checkpoints_init
Do you wish to save or load your game?
[b]You can also load a saved game from the Stats page at any time.[/b]
*label checkpoints_choice
*choice
*if (not(choice_randomtest)) #Save the game.
Which slot would you like to save your game to?
*fake_choice
#Save the game to @{choice_saved_checkpoint_save_1 Slot 1 (replace save at the end of Chapter ${save_1_chapter})|Slot 1}.
Save complete!
*set save_1_chapter {chapter}
*save_checkpoint save_1
#Save the game to @{choice_saved_checkpoint_save_2 Slot 2 (replace save at the end of Chapter ${save_2_chapter})|Slot 2}.
Save complete!
*set save_2_chapter {chapter}
*save_checkpoint save_2
#Save the game to @{choice_saved_checkpoint_save_3 Slot 3 (replace save at the end of Chapter ${save_3_chapter})|Slot 3}.
Save complete!
*set save_3_chapter {chapter}
*save_checkpoint save_3
#Save the game to @{choice_saved_checkpoint_save_4 Slot 4 (replace save at the end of Chapter ${save_4_chapter})|Slot 4}.
Save complete!
*set save_4_chapter {chapter}
*save_checkpoint save_4
#Save the game to @{choice_saved_checkpoint_save_4 Slot 5 (replace save at the end of Chapter ${save_5_chapter})|Slot 5}.
Save complete!
*set save_5_chapter {chapter}
*save_checkpoint save_5
#Go back.
*goto checkpoints_init
*if choice_just_restored_checkpoint
Loading game…
*return
Anything else?
*goto checkpoints_choice
*if (not(choice_randomtest)) #Load a game.
Which game would you like to load?
*choice
*if (choice_saved_checkpoint_auto) #Autosave at the start of Chapter 1.
*restore_checkpoint auto
*if (choice_saved_checkpoint_save_1) #Load Slot 1 (end of Chapter ${save_1_chapter}).
*restore_checkpoint save_1
*if (choice_saved_checkpoint_save_2) #Load Slot 2 (end of Chapter ${save_2_chapter}).
*restore_checkpoint save_2
*if (choice_saved_checkpoint_save_3) #Load Slot 3 (end of Chapter ${save_3_chapter}).
*restore_checkpoint save_3
*if (choice_saved_checkpoint_save_4) #Load Slot 4 (end of Chapter ${save_4_chapter}).
*restore_checkpoint save_4
*if (choice_saved_checkpoint_save_5) #Load Slot 5 (end of Chapter ${save_5_chapter}).
*restore_checkpoint save_5
#Go back.
*goto checkpoints_init
#Continue playing.
*return
In the stat page, I have the following code:
*label loadgame
Which game would you like to load?
*choice
*if (choice_saved_checkpoint_auto) #Autosave at the start of Chapter 1.
Loading game…
*page_break
*restore_checkpoint auto
*if (choice_saved_checkpoint_save_1) #Load Slot 1 (end of Chapter ${save_1_chapter}).
Loading game…
*page_break
*restore_checkpoint save_1
*if (choice_saved_checkpoint_save_2) #Load Slot 2 (end of Chapter ${save_2_chapter}).
Loading game…
*page_break
*restore_checkpoint save_2
*if (choice_saved_checkpoint_save_3) #Load Slot 3 (end of Chapter ${save_3_chapter}).
Loading game…
*page_break
*restore_checkpoint save_3
*if (choice_saved_checkpoint_save_4) #Load Slot 4 (end of Chapter ${save_4_chapter}).
Loading game…
*page_break
*restore_checkpoint save_4
*if (choice_saved_checkpoint_save_5) #Load Slot 5 (end of Chapter ${save_5_chapter}).
Loading game…
*page_break
*restore_checkpoint save_5
#Go back.
*goto statpage
I just tried testing the *restore_checkpoint bug that was mentioned on the other thread, and confirm the bug occurred on cogdemos. Annoying. Still, the above code should work fine outside of the stat page, if you wanted to have loading options at the ends of chapters as well.
This is excellent, thanks very much; this’ll help many of us. I think, when I start something new, I could build around such a system. Very elegantly done. I am in awe!
For my current WIP, just to keep it simpler for me, the loading screen on the stats page is very much what I am looking for. I could place ‘You can load past checkpoints from the stat screen at any time’ at the start and then proceed with my already placed *save_checkpoints.
Although I can’t test this on cogdemos, in your experience, if I test it using run-server, it should work fine?
Yes, it should be fine with the server - that’s how I normally playtest and it seemed fine on there (except for the bug that’s been mentioned 
)
Great. I’ll put the more cumbersome checkpoint version up for beta testing when the time comes, but set up a stats screen loading page that may otherwise work for my own testing. Worst comes to worst, I’ll still have a system in place if I am thwarted in my efforts.
You may have saved my day 
I believe this does work, I have had a “load checkpoint” menu in the stat screen in my current WIP for the past year. I’ve tested the feature myself and I have not received any reports about it not working from readers, though since COG Demos has a built-in save feature, I’m not certain whether enough do use it to find any potential problems that could arise.
I’ve tested mine and thought it was OK, but looking at this bug report made me realise that under some niche circumstances it doesn’t work. Weirdly I have it in my released games and hadn’t heard about any problems so maybe people just don’t end up triggering the buggy behaviour very much.
I might use both the in-text checkpoint system and the stats menu checkpoint system in my next CogDemos build. I’ll add a warning about the menu system and ask if folks can test it.
Yes, while it is great that the site has built-in saves, it can lead to certain issues becoming overlooked.
I can imagine you have clean and efficient code, which certainly helps.
EDIT: I am prone to spaghetti 
You are a hero and a gentleman! Thanks for sharing.
*save_checkpoint is explicitly disallowed in stats mode. If you try, it will automatically crash. There are ways around this, but without the use of the *script command, I’ve never been able to create a proper manual save system like the one available on CoG Demos.
What I’ve done instead is create a bunch of autosaves that occur after every few choices, then use *redirect_scene from the stats screen to make manual saves that use the latest autosave. This means you can save your progress manually every few choices or so, which isn’t terrible as a compromise.
I’m also happy to share more details or raw code if anyone needs it. I’ll probably end up posting a demo of the project soon in any case, so the code will be available from there as well regardless.
EDIT: FWIW, I also checked out the *load_checkpoint bug that was mentioned here, and I’m not experiencing it. Might have something to do with my particular code architecture, though I haven’t taken a proper look at the thread that was linked yet.
For me, there is an error when using the stat screen menu to restore, as reported in the bug thread. Pressing the ‘Show Stats’ button again flips back to the old scene, before the restore. Weirdly, pressing Show Stats a few times seemed to act like a ‘back button’ after I used the menu several times.
I don’t really understand the ins and outs. Having *save_checkpoint auto and implicit_control_flow true might be a factor in getting it to work. It may work if set up the way @HarrisPS has it.
Hi, I’m the person from the load_checkpoint bug thread. What did end up fixing the bug for me was using *redirect_scene inside the stats screen. This is probably also whats preventing the bug from appearing on your end since you mentioned using *redirect_scene.
So if your game is also working fine, then *redirect_scene might just be the best way to avoid this bug.
I spent a lot of time at the start of my project messing with the checkpoint system. The Stats Screen interferes with it because of the way “stats mode” works under the hood. It basically takes a snapshot of your position in the story, saves it temporarily, and then redirects you to the stats page (this is why you can’t change the name of choicescript_stats.txt–it’s directly referenced in the code). In “stats mode”, variable changes are not permanent, as explained in the tutorial on the CoG website.
Because checkpoints are saved in pretty much the same way as a normal variable, they can fail to be overwritten / changed when you’re in stats mode. When you load a saved game from the stats screen, the game pulls you back to wherever the checkpoint was saved from, using that variable.
The problem occurs because you’re sort of still in stats mode when you return to the game. Even if you return to the game the normal way (using the button at the top), without loading a save, it always takes one click before the game is “updated” and realises it’s not in stats mode anymore (refreshing the page should also work).
Therefore, if you use *load_checkpoint from the stats screen, you’re still in stats mode when you return to your checkpoint, until you refresh the page or make at least one choice. This means the game still has your previous position loaded as your “last known location”. If you click the stats screen button, it doesn’t save a new position, because it hasn’t seen you leave stats mode yet. Then, if you exit the second time, it reloads the original saved position, and voilà–you’re back where you started.
The way around this is to make sure you “leave” stats mode immediately when loading the checkpoint, without requiring the player to click through. I have two things to help with this (though, if I’m honest, I genuinely don’t remember which one it was that solved the issue originally).
First, I use *redirect_scene from the checkpoint menu to another .txt document (in this case, my global_functions.txt document that I use for all sorts of things), in which you find the actual *load_checkpoint command. Then, because my checkpoints are saved in a subroutine in the main chapter files, there is an immediate *return command, which sends the player back to a pre-saved position similar to stats mode. I’ve heard that *return refreshes the game in the same way as clicking through a choice, so it could be this–or it could be that *redirect_scene automatically kills stats mode immediately in a way that the “Return to the Game” button (and *load_checkpoint) doesn’t. Could be both, in fact.
It certainly feels like an oversight rather than an intentional quirk of the system, from what I can tell. Not sure if a fix is forthcoming, but you can still work around it, with a little creativity. 
EDIT: Well, that makes sense. As I said just above, it could be either (or both), of the things I mentioned, but I do know that my version works, at least, even if I don’t know exactly how. 
Thanks for the thorough explanation; you really thought and fought your way through this. I’m going to try a few things and see what happens…
Okay, so far, using *redirect_scene seems to work. One odd thing is that, after using it, the next time I press the Show Stats button, it reloads the current page I’m on. It doesn’t go back to a previous page; it just reloads the current one, though stats seem to be updated normally according to the current run. If this is the only issue, it won’t be a problem; you merely have to press Show Stats again, and everything functions correctly, as far as I am aware.
I haven’t used a go_sub. I am anxious about an unused return hanging over my head, since I will be entering other gosubs and hitting other returns. I had issues with this during Green, though it might just be me not understanding things. Perhaps restoring a previous scene mitigates this?
@WaveHarvest Appreciate that you were the one who first mentioned *redirect_scene in the bug thread.
EDIT: Regarding unused *returns, after a go_sub – this might sound ridiculous; it’s just a worry I have.
EDITEDIT: What I am currently doing is redirecting to a standard scene from the stats screen to where each restore point is stored under a *label.
Interesting. I did just manage to replicate this bug, but only when I run the game on a local server. Running the same files on CoGDemos works fine without any of that happening, very strange.
Thanks, but it was actually @LightningGarfunkel who first had the idea to use *redirect_scene, don’t wanna steal credit there 
If the bug is merely a reload of the current screen, with all the variables intact, the sheer convenience of a menu-checkpoint system might well be worth it. I will put both this and the in-text method in the next build and see what the feedback is. It will be in CoGdemos.
EDIT: For clarification, my own testing was with run-sever.
Cheers, mate.
My bad! @LightningGarfunkel Great stuff!