Right. I'm using custom gui for quitting game, which has quit confirmation button.
Under the button, there's code:
if (button == 0)
{
SaveGameSlot(21,"quick");
QuitGame(0);
}
Correct? It's supposed to save whatever is happening to slot 21 and quit game without prompt.
Now, at the game first room I have object "continue" to let player continue game from point he left.
Under object is even simpler code:
RestoreGameSlot(21);
Problem is... AGS says it cannot find savegame. What am I doing wrong?
There's file agssave.001 in compiled folder, it's not read/write-protected, and I'm not recompiling game before trying to quit and restore. The system is as simple as I explained, no additional bug chances anywhere else.
Yet, AGS fails to save the game. It doesn't report any errors when save-quiting neither. Why?
I think the problem was savegame actions are queued up to be executed as the last action just before a script ends, this can cause problem when there's a quitgame, that the game quits before the savegame action was taken out.
I think one possible (not tested) solution is to set a variable to say,1 after that savegame event, and check if the variable equals 1 in repeatedly_execute(_always) and quits if it's 1.
so, something like:
if (button == 0)
{
SaveGameSlot(21,"quick");
savequit=1;
}
repeatedly_execute:
if (savequit==1) QuitGame(0);
and for on_event():
if (event==eEventRestoreGame) savequit=0; //reset it so your game won't quit immediately when it's loaded again.
Loads of thanks, Gilbot!
I would NEVER figure this out by myself.
Neither I knew what on_event stuff is in AGS for.
Got it working now.
(Though, your simple variable assigning does not work in AGS. I used predefined GlobalInt for this.)
Quote from: InCreator on Sun 10/12/2006 08:56:16
(Though, your simple variable assigning does not work in AGS. I used predefined GlobalInt for this.)
Hmmm where did you define that variable? If all the stuff were in global script just define it on top of Global script (if you need to use it sometimes in room scripts you need to ex/import the variable. But anyway GlobalInt would work just fine, so if you feel compatible to use it it's perfectly okay.
Well, AGS variable usage (and making em' global) is still quite a mystery for me, so my whole game relies on Globalints only. Why couldn't be it as easy as in Game maker/BASIC/etc?
Then again, if it works, it's not broken.
Quote from: Gilbot V7000a on Sun 10/12/2006 08:45:40
I think the problem was savegame actions are queued up to be executed as the last action just before a script ends, this can cause problem when there's a quitgame, that the game quits before the savegame action was taken out.
I think that's something that shouldn't be too hard to fix. Could a moderator please move this to the main Tech Forum so CJ can take a look?
Edit:
And InCreator, check the Wiki on how to use custom variables (http://americangirlscouts.org/agswiki/Scripting%2C_Code_%26_Interaction#Working_with_variables:_the_basics).
I think there's nothing wrong with it, just how stuff was implemented.
QuitGame() will always be executed immediately while savegame action would only be executed while a script ends.
So there's nothignto fix in my opinion.
Okay, but I think QuitGame should run all queued save operations first before quitting.
I really think that all functions should run queued to avoid problems like this one (AFAIK SaveGameSlot(); is the only one which doesn't run queued)
So I'd really support a suggestion talking about fixing this script problem. Actually if someone supports this, I'd open it myself.
Hope an answer.
Perhaps it should be looked in to (although I don't quite understand the way you phrased that, Joe).
However since this is a 'Solved' issue, I think that should have it's own suggestion thread - provided one doesn't already exist, in which case post there.
Quote from: Joe Carl on Tue 12/12/2006 20:11:33
(AFAIK SaveGameSlot(); is the only one which doesn't run queued)
No, there're others, like starting a dialog topic say for example.
It's just by design like that, nothing wrong.
For example with the save game part, if it's able to be executed in the middle of a script, the engine need to be able to resume the half-finished script when you restore the game later, which might need some patience for CJ to implement. Moreover, take this exact thread for example (read the original codes in the first post),
if CJ
"fixed" this
"problem", then the engine would continue to execute the next line after the savegame line when the game is restored, which is just quitting the game immediately, this even render that saved game useless.
Oh I see.
But It would be useful that SaveGameSlot(); was executed in the middle of the script, and then when you restore that slot the script is not run anymore.
I mean this:
--------------
//Some stuff
SaveGameSlot(1,"savegame");
//The rest of the script
--------------
//Press button continue
RestoreGameSlot(1);
//And the rest of the other script won't run
--------------
Doesn't this make sense?
I think it would be more confusing to people, asking why the script won't continue to run after restoring a game.
You're right but, look at what you said:
"asking why the script won't continue to run after restoring a game."
Then is more confusing currenly due to currently when you restore a game the script doesn't continue.
You understan what I mean?
Saved games currently do not store things like local variables, dynamic sprites, etc. Making it save immediately would mean all this had to be added as well, apart form the issue Gilbert mentioned. strazer's suggestion is the most workable. NB I think that control actually has to return to the player before games are saved. This also guarantees that any screenshots that are saved of the game do not have modal dialogs across them ;)