On a topic of adding "user data" to saves, that's not too hard technically, but there's a serious question of usability.
How may such "user data" be used, and what it may be useful for?
First of all, we have to keep in mind that engine, as it is now, cannot allow to run scripts while save is being saved or loaded. Because when writing nothing in the script or game may be accessed when saving (strictly speaking, it may be read but not written, but it's difficult to restrict that if a user script is run so long as a callback can access things), and when restoring a save - the script "executor" is stopped, and things like global script data and game objects may not be reinitialized properly yet.
As a consequence, we cannot let to have script callbacks run during the reading/writing of a save game. We may, optionally, have them run right before the saving and right after the loading of a save.
Technically that's not hard: we just use "memory files". User script can use File API, but it writes/reads a dedicated array in memory. On saving a game this array, if prepared, gets saved along, and when restoring a game, this array is read from a file, and then given to user script to be read.
But there's a question of use case. Since the "read user data" callback may only be run after whole game gets reinitialized, this means that it happens only after save has been restored first, this way or another.
Which in turn means that user script may still stop or restart the game when detecting "wrong" data, or force it to reload a different save, etc, but it cannot prevent the game state to be overwritten by a "wrong" save.
Which brings us to the "test save" idea from my previous post (see above).
If we have that, then, in theory, user could command to test the save first, which would extract only limited amount of data, including user data if one is present, and let user script to scan it and remember if this save is okay to load at all.
I am not sure how convenient that would be to script and use though.
I suppose we might have script callbacks for reading and writing user data, something like this:
Code: ags
And furthermore, the previously mentioned "validate" function can also have access to the "memory file" which contains read user data, by having "File* UserData;" inside "RestoredSaveInfo" struct. So when validation is run, either while testing a save, or right after it's been restored, user can check the custom data as well.
To elaborate, what is the advantage of separate "user data" in comparison with just script variables?
The advantage is that it may be stored separately from scripts, and then tested even if script data from the save was not applied to the current game.
How may such "user data" be used, and what it may be useful for?
First of all, we have to keep in mind that engine, as it is now, cannot allow to run scripts while save is being saved or loaded. Because when writing nothing in the script or game may be accessed when saving (strictly speaking, it may be read but not written, but it's difficult to restrict that if a user script is run so long as a callback can access things), and when restoring a save - the script "executor" is stopped, and things like global script data and game objects may not be reinitialized properly yet.
As a consequence, we cannot let to have script callbacks run during the reading/writing of a save game. We may, optionally, have them run right before the saving and right after the loading of a save.
Technically that's not hard: we just use "memory files". User script can use File API, but it writes/reads a dedicated array in memory. On saving a game this array, if prepared, gets saved along, and when restoring a game, this array is read from a file, and then given to user script to be read.
But there's a question of use case. Since the "read user data" callback may only be run after whole game gets reinitialized, this means that it happens only after save has been restored first, this way or another.
Which in turn means that user script may still stop or restart the game when detecting "wrong" data, or force it to reload a different save, etc, but it cannot prevent the game state to be overwritten by a "wrong" save.
Which brings us to the "test save" idea from my previous post (see above).
If we have that, then, in theory, user could command to test the save first, which would extract only limited amount of data, including user data if one is present, and let user script to scan it and remember if this save is okay to load at all.
I am not sure how convenient that would be to script and use though.
I suppose we might have script callbacks for reading and writing user data, something like this:
function read_save_user_data(File* f)
{
}
function write_save_user_data(File* f)
{
}
And furthermore, the previously mentioned "validate" function can also have access to the "memory file" which contains read user data, by having "File* UserData;" inside "RestoredSaveInfo" struct. So when validation is run, either while testing a save, or right after it's been restored, user can check the custom data as well.
To elaborate, what is the advantage of separate "user data" in comparison with just script variables?
The advantage is that it may be stored separately from scripts, and then tested even if script data from the save was not applied to the current game.
