I think this may be something that was affecting earlier moody. I’ve checked it again just now – logged in, launched a game, read a few pages then left it idling for a few hours, but everything appears to be ok when i got back to it, and the login seems to persist when accessing the site again.
I mean, I’m obviously aware of that. I have published a game under Hosted Games after all.
I’m trying to discuss the possibility of making changes to a standard feature in choicescript since I’m planning to publish a game with a character profile and saving system.
But after reading through some of the earlier comments, my plan now is to include a clear warning in the save menu, and leave it to players if they do decide to hit the restart button, since they were already warned about it in the menu.
Maybe. There are times when I come back after a few hours and it appears fine, but attempting to save and load fails because I have been logged out, despite the page not being refreshed
That’s an impressive level of dedication. I cannot imagine having the patience to wrangle ten (10!) copies of each startup variable.
But more to the point, I don’t think any of us here can tell you if Hosted Games would allow you to publish a game with a modified version of ChoiceScript. Some games are slightly non-standard – Choice of Robots’ params before params and Choice of Magics’/Fallen Hero’s custom CSS come to mind – so there is some precedent, but only HG staff would be able to speak to your specific situation.
I think a prominent warning in the save menu is a good solution. Or maybe a warning right after starting the game, so no one can say they weren’t informed.
I think this is less of a concern now that there is no more Restart button. Someone needs to hit the Menu button, choose “Restart the game”, and then confirm they want to “Restart the game” before the game restarts.
For some reason, this escaped my attention until today.
1: you can create “custom” checkpoint slots using the checkpoint system in the latest CS, so I do not know why you would do such a system
and
2: As a person that has implemented such a working save system as you mention here, I highly discourage you from doing so. @Cataphrak as well as @AllenGies both deployed such systems in published games, both using 100’s of “save variables” to make it work and both of whom, when I talk to them about this system talk about it in nothing but horror.
I think Cataphrak mentioned using 500+ save variables and that is in addition to the normal variables he used. My system used 300ish, I believe which was basically a copy of Allen’s from Tin Star.
3: Bugs are a nightmare to track and fix within the system. Trust me on this.
Is there an easy way to print variables from a saved checkpoint without loading the saved checkpoint? This is the main reason I’m holding off on using the checkpoint system. If yes, I’m jumping ship in a heartbeat.
I mean, I have a save system in my first game, so I’m not exactly using an unproven method. Did anyone encounter any bugs when using that save system?
To my knowledge, the Choice Script engine requires the loading of a game-state to record the variables before you’d be able to display or print them.
You could try to just store the variables that you need to print with the checkpoint list? That would lessen your extra work significantly. Although I don’t know what happens to your later checkpoint saves if you load an earlier one. 
Fun fact - the manual save system in Dragon of Steelthorne was only implemented at a very late point in development. The game has elements of a linear narrative, but it is centered around a Hub scene, which I realized was actually a good place to build a save system.
I pretty much copied the Hub system for Scarlet Sorceress, so it was (as I saw it), copying the save system over from my first game.
Confession: The whole reason I had this idea was because I was wondering if I could mine a save system with wait timers. (Don’t kill me please 
)
I am looking into this option, but I’m curious about this too.
Anyways, I’m planning to just include a clear warning for my game regarding the restart button, so I suppose the original question has been sort of answered. (Thanks all!) I’m also taking a look at having multiple checkpoint saves, and trying to see if I can apply the workaround to store certain variables. Anyways, the game won’t be done for a while, so this is a decision to make down the line.
Meanwhile, I’ll upload a full beta on cogdemos a few months down the line, when everything is done. 
Which is 100% the way to do it, if you’re going to. My checkpoint system in Rebels would have taken me a lot less time and headache if I’d waited to implement it until I knew all the variables I was going to *create and could just go through once to make all the save-state variables in a single swoop. The real pain for me was adding extra save variables every time I added a single new variable to startup.
I’d still recommend using the checkpoint system now, but if you’ve got some reason to make comprehensive sets of near-duplicate variables, for your sanity’s sake make it the last thing you do. 
This is what I did when I introduced checkpoints into my games (most of them temporarily). I had a few bugs I had to squash and it took forever, though, so I like the checkpoint code much more.
hello all,
sorry to chime in someone’s thread, but I think my question has relation to the restart button
assume that I purchased a full version of a game, or even better, bought an in-game DLCs, then I restarted, would those purchases lost?
thank you
No.
The reset button will take you to the start of the game, and allow you to begin from page one again.
It is not used to reset your library or delete a purchase.
The Advanced Choicescript tutorial goes into more detail, but you can exclude variables from the save system so they persist when loading/unloading saves. One thing you could do is make a couple arrays to hold the preview values and exclude those variables from the save system. For example:
*create_array save_slot_name 10 "nil"
*create_array save_slot_difficulty 10 "nil"
*create_array save_slot_day 10 1
*create checkpoint_exclusions save_slot_name_1 save_slot_name_2 [...] save_slot_day_10
Then, when you’d save a checkpoint, you’d update those variables as well:
*save_checkpoint save_slot_1
*set save_slot_name_1 name
*set save_slot_difficulty_1 difficulty
*set save_slot_day_1 day
Allowing you to have:
Choose a save slot:
*fake_choice
*selectable_if(choice_saved_checkpoint_save_slot_1) #${save_slot_name_1}, ${save_slot_day_1} days, ${save_slot_difficulty_1} mode
*restore_checkpoint save_slot_1
This is an oversimplified example, but you get the idea.
If you didn’t have too many stats you wanted the player to preview, to save on variables I’d personally only have one persistent variable per save slot and use concatenation to generate an indicative save slot name.
You can also let players name all of part of the save slot name, so it’d be on them if they chose to name it something unhelpful. This may be useful to allow players to disambiguate two saves with the same character, difficulty, and day.
Now we’re talking. 
Coming up with a system and interface for this will be something I need to work out, but this is a good place to start.
Thanks!
Don’t quite understand what you’re saying about the checkpoint save system but, as Eiwynn indicated, the alternatives are excessively confusing and convoluted. Will/must look into this more.
I wanted to be able to display variables from a save without loading the save. The above is an example of that in the latest version of Dragon of Steelthorne. This was coded manually, and the system is centralized in a single scene file, the city management scene. To the best of my knowledge, it is bug free, but people are welcome to report any bugs to me.
@lan was telling me a way to use the new checkpoint system while being able to display variables from the save without loading it. I do appreciate the help, and am looking into it once my next game is complete.
Also note that what I have is more of a save system and less of a checkpoint system. There is a central location in my game where you can save/load your progress at will. It is very difficult to ‘die’ in my game, so I didn’t really need a checkpoint system.