Hi everyone! I’ve recently been playing around with making some test games and ran into some issues with the checkpoint system.
If you use restore_checkpoint from the stats screen everything works as it should at first, you rewind to an earlier part of the game. But if you check your stats immediately after restoring the checkpoint and then close the stats screen you will be brought “back to the future” to wherever you were before loading the checkpoint.
As a player the first thing I’d want to do after loading an old save would be to check out my stats. Having to reload the checkpoint again after that seems kind of annoying.
I’ve noticed the same thing happening with other people’s games that allow you to restore checkpoints from the stats screen, so this seems to be a general issue and (hopefully) not because of my own coding.
sounds like an interesting bug! I can’t really code this out properly but for a rough fix I guess you could do…
*save_checkpoint whatever
*if choice_just_restored_checkpoint
Loading checkpoint Please do not check stats. Please continue.
*page_break Continue
And then your normal text here
this should display the text in the *if should you reload the save
It probably wont be supported but maybe you could use either *page_break or *delay_break? as long as there is no text displayed before it then those two commands force a page_break immediately
*save_checkpoint whatever
*if choice_just_restored_checkpoint
*delay_break 0 // OR // *page_break
And then your normal text here
again, zero idea if that’ll work. You’d have to check yourself. and I’m not sure CoG supports using the *delay_break command anymore
It does seem like this bug no longer happens if the player either makes a choice or goes through a pagebreak. So the first code snippet that @LightningGarfunkel posted should work as a rough fix as long as the player actually reads the warning and doesn’t open the stats screen. Thanks!
For testing this I just made another really barebones ““game”” and accidentally stumbled upon another strange bug.
You basically just count to three and can restore to all previous numbers through the stats screen.
But now after restoring you are kicked out of the stats screen back into the game the first time you try to open it.
This happens whether or not the page_break stuff is there.
This is the startup file:
*title checkpoint test
*author yes
*scene_list
startup
*create implicit_control_flow true
*create value 0
*label counting
*if value = 0
*save_checkpoint zero
*if value = 1
*save_checkpoint one
*if value = 2
*save_checkpoint two
*if choice_just_restored_checkpoint
Loading checkpoint. Please do not check stats.
*page_break continue
Your number is ${value}
*choice
#keep counting
*set value +1
*if value < 3
*goto counting
You have counted to 3. Well done!
*ending
Stat screen:
This is the stat screen
*choice
*selectable_if (choice_saved_checkpoint_zero) #Restore to 0
*restore_checkpoint zero
*selectable_if (choice_saved_checkpoint_one) #Restore to 1
*restore_checkpoint one
*selectable_if (choice_saved_checkpoint_two) #Restore to 2
*restore_checkpoint two
I’m guessing it has something to do with the weird loop there.
Any idea why that happens?
I tell the player to click to the *page_break when the checkpoint reloads to prevent this. Looking back on my earlier response, I hoped I made sense.
There are many bugs from the stats screen that result from not advancing the page in the main game (like how *rand variables will re-randomize if you go to the stats and return to the game). I think the *restore_checkpoint bug is one of them. I’m not quite sure how to fix the issue without telling the player to click the *page_break unfortunately.
The stats screen always introduces bugs like this because it kind of runs a separate instance of the game that is totally independent of the “real” game, so once you close out of it, it returns to where you used to be. This means you can’t meaningfully change variables while within the stats screen. You can still play with variables but it’ll only be for display and it’ll only last until you close it.
It also means that if you’ve run any *rand commands on the main screen, they’ll be re-randomised if you go into and out of the stats screen. Careless coders open up the opportunity for readers to cheat the system and keep refreshing the randomisation until they get the result they want.
And of course it means that if you restore checkpoints from the stats screen, it hasn’t actually restored a checkpoint. It might “calcify” if you keep playing but if you go back in and out it’ll completely reset as if you hadn’t restored a checkpoint at all. Not quite sure the exact flow of the backend here but yeah none of that is surprising.
The best option here is to simply never give the reader the option to restore a checkpoint from the stats screen.
Interesting. This appears to be a bug and may be something we need to report to @dfabulich . At least one published HG (Saturnine) allows you to restore checkpoints from the stats screen. I just tried to reproduce this bug on Saturnine on the omnibus, and it seems that the bug is present there as well.
People do this because CoG/HG explicitly told us that the system supports it.
Check whether *save_checkpoint has happened yet
Run some code after restoring from a checkpoint
Exclude some stats/temps from being restored
Multiple checkpoint “slots”
Restore to the last checkpoint at any time from the stats screen
Player-named save slots
Restore to the last checkpoint at any time from the stats screen: You can write code to restore from the stats screen like this:
[choicescript_stats.txt]
*stat_chart
...
*choice
#Done.
*finish
*if (choice_saved_checkpoint) #Restore from the last checkpoint.
*restore_checkpoint
Note that you’ll need *if (choice_saved_checkpoint) to make sure the player doesn’t try to restore before the first checkpoint has been set.
I used to do that in Choice of the Vampire. It’s not cheating if the game lets me do it.
Do you think *redirect_scene might fix it. From what I can tell it acts like a *goto_scene function for choicescript_stats.txt and forces the game out of the stat instance and back into the main game.
Something like;
this_scene_name.txt
choicescript_stats
checkpoint_manager
*set save_name “this_scene_name” *gosub_scene checkpoint_manager new_save . . . continue scene like normal
*label redirected_scene *checkpoint_restore {save_name} *bug restoring save. should not reach this line *label new_save *checkpoint_save {save_name} *return
I tested that yesterday. The moment restore is called, it’s not possible to use redirect (and you’d need to have a label name to redirect towards). I’d love to keep testing ideas with you, however.
Yes! Using redirect seems to prevent restore checkpoint from being used at all as it stops any other commands added afterwards. I want to keep tinkering with it to see other solutions.
I would say this is a bug and requires modification of the engine itself. The engine records where it was before it loads the page, so when you click the button to exit the stats it renders that page from scratch (which is why rand variables get reloaded). However, if you exit the stats page via another method, such as restoring a checkpoint, it doesn’t seem to go through the same process of loading a page and updating the pointer. So the last place it remembers is where you last were before you entered the stats page to click restore_checkpoint.
Edit:
Just tested @LightningGarfunkel ‘s code, and it worked really well (although there are issues with setting save slots, as it returns to the last one, but for a single checkpoint it works fine). It looks like the return in the checkpoint_manager forces the pointer to update.
I just tried using *redirect_scene into another file that handled all the restoring and it actually seemed to work! I’m gonna have a closer look at this in a few hours when I have more time, but this might just be the solution I was looking for.
Edit: Yeah so this seems to work as far as I can tell. I don’t know if and where the bug in general should be reported, but this method is a great workaround.
I tried adding something like this to Werewolves 3 and ran into the same issues, talked directly with CoG about it, and was basically told it couldn’t be done.
Glad we seem to have a workaround for a single save. The system I was trying to do was multiple saves from the stats menu, but I beat my head against the wall on that code for days and nothing ever worked.
That’s why I only have chapter restores in Werewolves 3. I wanted multiple slots you could use at any time.
As far as I can tell it is really just *redirect_scene that causes the pointer update.
In my testing I’ve avoided the “return to the future” bug when I redirected to manager files that do not even have a *return, while doing something like a *gosub_scene into a manager with a return still leads to the issue happening.
You should be able to extend this to multiple saves!
So for this I’m assuming I have a series of checkpoints that I save at some point during the main story, maybe at the end of each chapter or something like that.
Then having something like this somewhere in your stats:
*label other_stats_stuff
This is the stat screen test123
*choice
*selectable_if (choice_saved_checkpoint_zero) #Restore to 0
*redirect_scene save_manager loading0
*selectable_if (choice_saved_checkpoint_one) #Restore to 1
*redirect_scene save_manager loading1
*selectable_if (choice_saved_checkpoint_two) #Restore to 2
*redirect_scene save_manager loading2
# Cancel
*goto other_stats_stuff
And a save_manager.txt that just looks like this:
*label loading0
*restore_checkpoint zero
*label loading1
*restore_checkpoint one
*label loading2
*restore_checkpoint two
This should hopefully prevent the return to the future bug from appearing.
It’s not cheating if the game lets me do it. 
