RunAGSGame Issues (A Couple Script Language Suggestions

[RickJ]

I am in the process of updating the MiniGame module and hope to make an official release soon.   There are a couple of quirks in the script language that require a bit of a  convoluted work around that I would like to eliminate.

Queue After Script
Some script commands don't execute until after the curent script is finished.   SaveGameSlot() is the one I am particularly interested in.   In the Example below the SaveGameSlot() function is never executed because the  RunAGSGame() function immediately after closes the current game and starts the new one before the SaveGameSlot ever has a chance to execute.   I am not certain if there are other built-in functions that have the same or similar behavior. 

Code: ags

	MiniName = String.Format("%s Return",mininame);
	SaveGameSlot(MiniGame_SAVSLOT,MiniName);
	Wait(1);
	RunAGSGame(mininame,0,game.previous_game_data+1); 

I was thinking it would be handy if there were a way of synchronizing these type of functions with other code.    I suppose there are any number of implementations that would be acceptable.  One possibility is  the introduction of a new keyword as shown in this example:

Code: ags

	// Script code executes normally
	MiniName = String.Format("%s Return",mininame);

	// The new keyword quesup instructions to be executed 			// after script completes.
	QueueAfterScript {   
		SaveGameSlot(MiniGame_SAVSLOT,MiniName);
		RunAGSGame(mininame,0,game.previous_game_data+1); 
	}

The other idea that comes to mind is to have another version of Wait() that would accomplish the dsame thing.  Perhaps the latter (i.e. Wait()) would be more intuitive for most people.

RestoreGameSlot()
When returning from a minigame it is desireable to seamlessly return to the previous game in it's previous state.   Currently this isn't possible because RestoreGameSlot() can't be executed until aafter the first room is displayed.  The workaround is to have the game's first room be a dummy black room with a some code to determine if returning from a minigame or starting from the OS.   

Since it's now possible to do a NewRoom command in game_start() I was wondering it could also be made possible to allow RestoreGameSlot() to be run from within game start?   

Alternative Suggestion
If the above two items are deemed to be relevant only to RunAGSGame() the perhaps a better solution would be to integrate the save/restore functionality within RunAGSGame() itself as follows:

Code: ags

RunAGSGame (string filename, int mode, int data, optional int saveslot, optional int restoreslot)

saveslot - if this parameter is specified and greater than -1 then the current game is saved to this saveslot before starting the new game.

restoreslot - if this parameter is specified and greater than -1 then the new game is restored from restoreslot before displaying the first room.

Summary
The above two requests would allow the removal of convoluted logic and awakward requirments from the module before release. 

1.  Ability to execute commands after builti-ins such as SaveGameSlot() complete.

2.  Ability to execute RestoreGameSlot() from within game_start().

3. Alternatively integrate save and restore functionality into RunAGSGame() itself.

I believe these changes, if possible and practical, would be of benefit to all.  Thanks for your consideration.

[monkey0506]

1.  I think the better suggestion might be an optional parameter being added to the delayed functions.  So it might be like:

SaveGameSlot(MiniGame_SAVESLOT, MiniName, eNoDelay);

Or some such.  I'm not to picky as to the exact naming convention, I just think this way would just fit in better with the way things currently work.

[RickJ]

Yeah, that would work just fine but I think there were reasons why the delay was originally required.  I don't know if those reasons are still valid but presumably they are.    I'm open to any implementation that cleanly provides the desired functionality though.   

[monkey0506]

Well, yes, presumably so.  RunDialog also is delayed, not that I use that .  It would also be nice if users could create delayed functions...but...my computer is screwing up so I'm going to restart it now.

[RickJ]

monkey,

After having taking some time to think about it,  I really like your idea.   I think the options would be more appropriately named eBlock/eNoBlock as this is consisten with many other built-in functions.  So we would have something like the following.

SaveGameSlot(MiniGame_SAVESLOT, MiniName, eBlock);

There is a similar discussion regarding the Restart function in the thread below.

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24818.0

[Pumaman]

Ok, let's keep discussion of why the delay is required to this other thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24818.0

In this thread, let us just consider the RunAGSGame implications.

While it could be considered a bit "hacky", your suggestion of adding Save and Restore parameters to RunAGSGame might be the best solution for this, I'll need to think about it further.