Save.browser.export() should include the game release version in the default file name/output file

[BawdyInkSlinger]

Is your feature request related to a problem? According to the documentation of Save.browser.export():

filename: (string) The base filename of the browser save export, which gets slugified to remove most symbols. Appended to this is a datestamp (format: YYYMMDD-hhmmss) and the file extension .savesexport—e.g., "The Scooby Chronicles" would result in the full filename: the-scooby-chronicles-{datestamp}.savesexport.

Here's a scenario, though it may be far-fetched: imagine a player is unable to load their save because of a bug that you thought you already fixed. They send you their export file so you can troubleshoot. Without knowing what version of the game they exported from, how can you answer these questions:

1. Are they playing a version of the game before you fixed the bug?
2. Are they playing a version >= where you thought you fixed the bug?

Knowing the answers to these questions provides valuable information.

Describe the solution you'd like. Include Config.saves.version in the output file or filename.

Describe alternatives you've considered. I'm assuming the default save dialog will use this new function. Unless I'm misunderstanding, modifying the default filename produced by clicking this button would require relatively advanced JavaScript trickery: e.g., monkey patching the export button's ariaClick()

Additional context. This relates to https://github.com/tmedwards/sugarcube-2/issues/190 You can find documentation for this here https://github.com/tmedwards/sugarcube-2/issues/248#issuecomment-1613881828 The conversation starts here: https://discord.com/channels/389867840406159362/389868418855075840/1124107029452181646

[tmedwards]

After thinking about it a bit. I'm unsure how useful adding a game version to the suggested filename of a browser saves export would be. The issues being that a) the export could potentially contain saves from not only different game and save versions, but b) potentially not even the game version that's on the filename. In this scenario, adding the current game version to the suggested filename probably won't tell you much useful.

Adding a game version to the suggested filename of a disk save would be somewhat better, as you're guaranteed that the game version the save was created under matches what's in the filename.

All in all, I think it's probably better to add extra details like this to the metadata of each save, so you have access to it no matter when or where a save is created, or in what fashion you receive it.

To that end, while you can add metadata by manually calling the APIs, there's no convenient way to do so when using the Saves dialog. Thus, I'm thinking what would be best is to add a new Config.saves API to allow default save metadata to be provided.

For example, something like simply using its value:

Config.saves.metadata = {
    gameVersion : 'Release 12: "Horny Toads Need Love Too" edition'
};

Or perhaps make it a callback that returns the value, so dynamic metadata would be possible:

Config.saves.metadata = function () {
    var metadata = {
        gameVersion : 'Release 12: "Horny Toads Need Love Too" edition'
    };

    if (/* some logic */) {
        metadata.something = 'a value';
    }

    return metadata;
};

All of the various save "load" APIs give you access to the save info chunk, which includes the metadata. Thus, you'd easily be able to check the game version under which any save was created—either manually from the console or by using a Save.onLoad handler to report it in some way.

Cc: @ChapelR @greyelf

[ChapelR]

My understanding of the hypothetical (?) the issue is that the save file doesn't work, so no one can (easily) load it to see the data, and therefore what the version of the save is? I'm not sure I quite get it. I guess the idea is that the user could hand over the malfunctioning save, and you can just see right from the filename that it's an old version or not. But people can change file names anyway, and if it's the only copy of their saved game and they don't remember when they made it, you're screwed anyway. It could be even worse if the player starts guessing.

I think what would make more sense (if this is a concern warranting a fix) would be like a "header" or something in the save file that isn't base64'd, just plain text. Maybe game title, save id, save version, date. Only for save to disk saves, obviously. I'm not sure it's that big of a concern, and also you can open a SugarCube save on Save Edit Online even if you aren't a power user and check the game version in like a second, so I don't think a header would really bring a ton of value. But if I were inclined to somehow have the game version in "plain text" in the save file, I'd do something like a header, not anything with the file name.

To that end, while you can add metadata by manually calling the APIs, there's no convenient way to do so when using the Saves dialog. Thus, I'm thinking what would be best is to add a new Config.saves API to allow default save metadata to be provided.

I don't see any reason not to do this. I think it's a good idea, esp the callback idea. Yeah, users can do it themselves, but making it super easy to set up as a config might encourage people to do this sort of versioning through the proper channels (meaning not through a story var instead).

One thing is maybe users should have more control over the filename of save files? That's one angle I think maybe hasn't been discussed. Like a config we can provide a string or a callback to.

[tmedwards]

Hmm. I must have glossed over the bit about it being completely broken. I thought the save that started this was broken in the sense that it simply fails to load. Mea culpa.

One thing is maybe users should have more control over the filename of save files? That's one angle I think maybe hasn't been discussed. Like a config we can provide a string or a callback to.

The Save API adds a datestamp and file extension to the provided filename suggestion in addition to doing some sanitation. The basic filenames are provided by the API consumers, which are:

• End users using the API manually. They have complete control over the filename they provide themselves.
• The Saves dialog. The filenames it provides are based on the story's own name.

It wouldn't be a huge thing to add a setting to override the use of the story's name by the dialog, I'm just not sure it really adds much. /shrug

[ChapelR]

I'm not sure it adds much either. I think needing control over file name is a very niche desire, but I also don't see any rationale for not letting users have an easy config for it. I think this would technically give @BawdyInkSlinger exactly what he wants, and its not a crazy thing to do. But I also think it's of questionable overall value to most users.