I’ve been out of the country, but am back now and should get around to updating CSIDE soon.
7 Likes
Can anyone tell me if this works with the exisiting plug in or on dashingdons? Or does it need to be compiled to work? Just wondering whether to put savepoints in while working on docs or at the very end. Thanks 
My understanding is that checkpoints don’t work on Dashingdon / Moody, because they’ve never updated to the latest version of ChoiceScript, and they probably never will.
My goal for HTML exports was to eliminate the need for Dashingdon / Moody. You’d just upload HTML anywhere (e.g. here on the forum) and then never need to use the other sites.
Is there still a reason you’d want to use Dashingdon? (Force of habit?)
2 Likes
Thanks for letting me know
Yeah, force of habit is one reason definitely. But also ease of updating. Its so easy to just update a text file here and there rather than having to compile it each time for upload like I need to do when I host stuff on itch. It’s not a deal breaker, just easier
I also really like how easy it is for testers to access the code as needed which (my understanding is unless I’m doing it wrong) much harder in a compiled game and at least involves downloading it. I already have so few people willing to test most of the stuff I write, making it harder for readers to check code where needed doesn’t seem like a good move. (I know if I’m on my phone in particular, I probably wouldn’t be downloading files to check.)
I also do really like the save plug in for betas when I read others my and work as it allows me to easily run back and forth over individual sections and check out all choices as needed rather than relying on periodic chapter saves (although that is my preference for finished games.)
2 Likes
I think some players check the Dashingdon front page before elsewhere to see if there are games with any updates. Another thing is that it’s easier for players to check the code when making bug reports (which could be a con rather than a pro, I suppose if the writer doesn’t want people seeing it).
Heh, I just saw @Jacic’s post which says a lot of the same things. Great minds!
By the way @Jacic, this plugin works with the compile/itch upload method, if you’re not using dashingdon, although I don’t yet know if it works with the new checkpoints (I’ll try and remember to test it sometime soon).
3 Likes
Yeah, I would have to be very invested in a wip to consider downloading it (even worse if I had to download it to play! That would mean I’d just pass it. If I can’t play it on my phone, I won’t bother, unless I’m super invested already.)
Sorry for the confusion LiliArch. Compiled games are playable online (To the point it would actually make them easier to pirate and share those files released for final betas as they’re set up to play as is without extra bit and pieces unless you have images in which case you probably need something like itch for hosting to zip the files, then set up to run in the browser.)
I think to actually look at the code though you’d need to download it though rather than just use the “scenes” function on dashingdons
Wouldn’t that depend on where it’s uploaded? If you add it as an attachment to your wip thread, would it really be playable without downloading? (I mean, I’ve always assumed forum attachments download by default.)
If you’re just using a compiled file, you can upload it anywhere (I think including the forums as long as the site allows it?) It should just open as another html window and play in the browser.
Worst case, hosting the html file on itch definitely does allow plays in the browser without download. (I have a mix of html files and the zipped folders for CSGs on my itch account depending on if they have separate images and they don’t require downloading to play.)
If you want images in the game, it gets trickier (unless you can get CSIDE’s image scene maker to work) as you have to put the compiled file in a folder with the images together. Those will play on download fine, and you can set them up to play in the browser via a hosting service like itch, but they wont play properly if you just put the file in a thread here.
So yep, avoiding images in WIPs would probably make your life easier if running updates outside of moody or dashingdons as it avoids the need for hosting and zipping files each time. But if you’re only doing the occasional update, it’s not that much extra to get it to work either.
1 Like
I as a reader enjoy dashingdon/moody because it also allows me to scroll through all the games with playable demo’s. It’s really hard to keep track of which games are available to play and/or updated through the forum. And that is without including all the games that don’t have a forum post, and only a tumblr page. It sounds daunting to keep track of all the games I want to keep an eye on only by actively checking the forum updates and tumblr posts. I love that their finally is an easy way for author to include saves/checkpoints (it’s something I was desperately missing in these games). But I’ll find it bothersome if that comes with the discontinuation of a site where all the demo’s are easily accessible and kept track of. I’m also not really a fan of needing to download all the demo’s I want to try. I’ll probably become more picky with the demo’s I’ll try out. Is this also easily done on mobile? I don’t use my pc for these games and use mobile for everything. So if it’s not easily supported on mobile that will most definitely make me annoyed 
. It’s why I definitely preferre CS games over twine ones. Those are very often not mobile friendly.
3 Likes
I have a question about "Player-named save slots It only lets the player name the save slot, right? We as the author still have to decide where we implement *save_checkpoint?
It doesn’t let the player save wherever they want, it’s still us that decides the location of the save points. They just get to name it, instead of us saying do you want to restore save point chapter 1 or chapter two?
Noted. Thanks.
Indeed, checkpoints don’t allow the player to save wherever they want, but only at author-defined checkpoints, e.g. at the start of Chapter 3, at the start of Chapter 5, etc.
Letting players name their save slots can be useful if you want to support players exploring the full tree of your game.
For example, with author-named checkpoints, if you put a *save_checkpoint chapter7 at the start of Chapter 7, then if the player restores back to Chapter 2 and plays ahead to Chapter 7, the chapter7 checkpoint will be completely rewritten.
With player-named saved slots, players could have multiple saved checkpoints at the start of Chapter 7, based on different choices made in earlier chapters.
14 Likes
Ah, I am just now seeing this thread after incorporating my own checkpoint system. Wish I had known about this. I am considering moving to this, I just have a couple questions / comments:
Can you please confirm or answer the following:
- The restore checkpoint goes back to any place in time, and that includes saving the value of not only global variables, but temp variables as well? For example, let’s say I use the command *save_checkpoint, on each scene, for example: *save_checkpoint chapter 1, *save_checkpoint chapter 2, does that mean the player can go back to any chapter in that place of time?
Alternatively, if I do something like *save_checkpoint_ chapter 1 mid (does that mean I can save checkpoints in the middle of a long chapter and keep all the temp variables that may have been set there?)
-
Is there anyway to check if the checkpoint exists before I try to load it? For example, let’s say I have 10 chapters in my game, but chapter 8 is optional, and you only see chapter 9 if you took a particular route. Is there a way to check what checkpoints exist and display them as a choice if it does exist? (like selectable_if or just a *if statement within a (*choice) (I know there is choice_saved_checkpoint, but can we check status of other checkpoints?)
-
Is there anyway for users to save a checkpoint while looking at the choicescript_stats screen? This would be really useful, but I understand it may be difficult or not work. I just saw you can restore, I just wanted to know if save works as well.
-
Does the restore_checkpoint go exactly to the line where you did the save_checkpoint?
-
Are achievements still met if the user restores a checkpoint. For example, let’s say they wanted to get a really hard or silly achievement, and then they load back. Is the achievement still marked as complete in the game (maybe not in the session, but is it listed as achieved in the game’s achievements?)
-
Anyway to check the date/time of when the *save_checkpoint was made? Or perhaps an easy way to add this to a variable, so maybe users can see Chapter 2 (7/5/2024 11:0 AM) for example.
-
The excluded variables, I am assuming this works with negatives too. For example, if someone restores a checkpoint, I can make it that they can only do this so many times, so each time they do I subtract 1 from let’s say a variable called checkpoint_token, if checkpoint_token <= 0, I can make it that they cannot select to restore, is that correct?
-
*If they do use a checkpoint_token, is there anyway I can run a *gosub command right after, for example, let's say I want to use the checkpoint system as a way for them to essentially have lives, could I restore the checkpoint but then run *gosub restore_health (where it replenishes their health for example?*Just saw there is a variable called choice_just_restored_checkpoint, so you can. Thank you. -
Oh, finally and most important. Is this feature in the latest choicescript code in github? I just downloaded the main branch, and wanted to make sure it wasn’t on an alternate or older branch. Thank you!
Just trying to understand. This is a really cool addition. I wonder if I will use it for my current game, or try using it for the next and these questions will help me figure out which one is best.
Thank you!
2 Likes
For what it’s worth…
I suppose you could use excluded variables to keep track of checkpoint usage. Assign one excluded permanent variable to each checkpoint, and change its value when the checkpoint is utilized. But I haven’t tried this.
This would definitely be useful. It would essentially be a save anywhere system, and would only be require writers to code one set of menus for saves to be carried out anywhere.
I don’t think it’s possible to do this without the *script command. Closest I can think of is asking the player to input the date and time when saving.
1 Like
I suppose you could use excluded variables to keep track of checkpoint usage. Assign one excluded permanent variable to each checkpoint, and change its value when the checkpoint is utilized. But I haven’t tried this.
See, now this is interesting. I wonder if I saved on each chapter, such as Chapter 1, Chapter 2, etc., but I called it something different like *save_checkpoint chapter1. Does that mean the user can load each Chapter in the past or the future?
For example if they were on Chapter 5 would they see something like this:
*choice
#Load Chapter 1
#Load Chapter 2
#Load Chapter 3
#Load Chapter 4
#Load Chapter 5
If they loaded Chapter 3, and they decided to Load again would they see the same menu?
*choice
#Load Chapter 1
#Load Chapter 2
#Load Chapter 3
#Load Chapter 4
#Load Chapter 5
Essentially, they could bounce around saves?
Is there any issue with having these many checkpoint saves, does the checkpoint data save somewhere externally? Does it clear when you reach the ending screen?
1 Like
I noticed this note:
Each checkpoint slot gets its own variable. In this example, choice_saved_checkpoint_major would be set to true when you *save_checkpoint major .
So maybe you can check if it is true or not.
1 Like
If they are on Chapter 5 they see the above.
If they restart Chapter 3, they will see the below, all previous chapters they’ve unlocked are now locked.
*choice
#Load Chapter 1
#Load Chapter 2
#Load Chapter 3
I set up mine in the stats screen.
I think once the game ends, it resets all the saves.
3 Likes