Amazing! Thank you very much Dan, it’s great to not only see this being implemented but also to have this opportunity to give feedback.
I’m the sole bottleneck here. It can be months, as Dan said, but it usually isn’t. I have to update ChoiceScript manually (including testing that none of my modifications broke because ChoiceScript wasn’t designed to be used inside other apps as a “Library”), but it doesn’t usually take an inordinate amount of time. When it’s taken months that’s usually because I’ve not believed any of the updates are immediately valuable to CSIDE users. I might not always get this right, so feel free to tag me on the CSIDE thread if there are features you’re chomping at the bit to try. I otherwise aim to be reasonably quick where any new functionality/commands/features are concerned. So don’t fret, I’ll be pulling this one into CSIDE as soon as possible!
My understanding is that @dashingdon has had to “retire” from properly maintaining both dashingdon and its moody.ink successor… I don’t think we’ll be seeing many updates moving forwards, unless someone else from the community steps up.
Which brings me nicely to this point: I’d much rather see a shift towards official CoG/ChoiceScript solutions wherever possible. I love that the community can and does often fill in the gaps in the developer ecosystem with CoG’s blessing, and that’s one of the primary reasons I’ve stuck around so long. We’ve come up with some pretty cool stuff and developing with ChoiceScript has certainly come a long way. That said, community-made enhancements are supported and maintained by volunteers, often even just one volunteer, and there’s a real risk of those volunteers moving on/getting bored/not having time. So it’s always my hope and intent that unofficial solutions are just a stop-gap (CSIDE included) until CoG comes up with something official (however realistic/unrealistic that may sound).
tl;dr I’d rather see people migrate away from smPlugin if there’s an option for an official solution, though I’d encourage that solution to exhibit the characteristics people like about smPlugin.
The modern smPlugin is actually largely based on the save_gave functionality, it just adds some new commands (which are also a bad thing; as they’ll never be supported by tests) and access to an always available UI (which is what I believe most people use/want from the save_game function, in addition to local support).
As for the save_checkpoint feature itself, I think you’ve thought of pretty much everything I’d have wanted. I agree with throwing an error over “restarting” on a lack of checkpoint. I much prefer deterministic behaviour you can catch, and workaround, to potentially accidental behaviour you wouldn’t detect until runtime.
An author could always implement the other behaviour, deliberately:
*if (choice_saved_checkpoint)
*restore_checkpoint
*else
*restart
Actually, I don’t think *restart is a valid command atm, but I don’t imagine it would be too hard to add?
I think the only enhancement suggestion I have at the moment, and it could be tricky to do without losing checkpoint names, is if we could make checkpoints use ChoiceScript arrays/numerical IDs.
This would allow things like printing out the checkpoint list via a loop and dramatically simplified choice construction (for e.g. using CSLIB’s “build_array” menu).
You've unlocked the following checkpoints so far:
*temp n 1
*label checkpoint_print_loop
*if n <= choice_saved_checkpoint_count
--> ${choice_saved_checkpoint_name[n]}
*line_break
*set n + 1
*goto checkpoint_print_loop
or
*gosub_scene cslib_menu build_array "choice_saved_checkpoint_name"
*if cslib_ret <= 0
*return
*temp checkpoint_idx cslib_ret
Restoring '${choice_saved_checkpoint_name[checkpoint_idx]}'...
*restore_checkpoint checkpoint_idx
I’ll try to read in more detail in the next few days…
I stand corrected (if terrified)
it’s been so long since I did it that I forgot how easily it can be done…