Messages

I'm in the process updating the demo to be V2.7 compliant.  I am about to begin work on the LEC GUI room and I wonder if it would be better to abandon the previous LEC gui example in favor of a template?  Rui has recommended any of Proskritos templates for this purpose.   What do you guy over here think?

How / where are you turning the GUI off?

I vaguley remember something about the character speech but thought that the display mechanism would just use the speech fonts but otherwise work as it does when using a text box.   Fair enough. though.   

Monkey,

Conrats on doing your first module.  Several of us had an extnsive discussion on what conventions we should use so as to make script modules as useful as possible.  You can find that discussion here:

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

The following documents resulted from this discussion which you may also find useful.  They are not finalized yet as I have been hard at work updating the dem o game to be compliant with the new V2.7 lauguage.

http://www.gaia-spa.com/project/ags/doc/ModuleProgrammingGuidlines.txt
http://www.gaia-spa.com/project/ags/doc/ModuleScriptTemplate.txt
http://www.gaia-spa.com/project/ags/doc/ModuleHeaderTemplate.txt

Cheers

I created a custom inventory window but I noticed that speech is displayed behind the GUI; fair enough.   However if the "Display Text As Speech" option in the "General Settings" tab is checked then when one examines items in the inventory gui the resulting text descriptions are displayed behind the GUI.   

Has it always been this way or is this a bug or something introduced by V2.7, or have I done something wrong?

If it's supposed to work this way then I wonder how useful the "Display Text as Speech" option is;  in fact it would seem to me to cause more harm than good.   

One of my favourite films from my childhood is The 7 Faces of Dr Lao. My parents introduced it to me when I was a kid, and I think you'll like it a lot. It's on oldie, made in 1964...

Hehe,  my parents took me to see it when it first came out. 

Really neat.    A number of people have been asking about making car driving type applications lately and I have recently upgraded the DQ Motorcycle Race to V2.7 script language.  So I am wondering if this could be applied to such things. 

Problem Using RestoreGameSlot() from Script Modules -

Calling RestoreGameSlot() from a Module Scirpt's game_start() event is now disallowed; fair enough, as was previously explained the game isn't fully initialized at that point and so ... 

So in my MiniGame module I moved the RestoreGameSlot() from the game_start() event to the repeatedly_execute() event.  Currently game_start() sets a flag and repeatedly_execute() tests the flag, counts to 10 (i.e. 10 actual game cycles, not "while") , and then calls RestoreGameSlot(). 

When RestoreGameSlot() is called the following fatal exception occurs :

"... exception 0xC0000005 occured in ACWIN>EXE at EIP 0x0045C050; program pointer is +6, ACI version 2.70.861, gtags 492,4"

Is this something that can be fixed or am I doing something wrong?

How long is a long session? Is this problem particular to this version, or has it always happened?

• A long session would be perhaps 1 or 2 days without closing the editor. 
  
  
• This seems to happen with the latest version, however, I have noticed on previous versions that ocassionally (perhaps during a long edit session) that file manager windows won't open until AGSEDIT is closed.   When AGSEDIT is closed all of my attempts at opening the file manager seemed to be queued up and so all these file manager windows start poping up. 
  
  

  
  Sounds like some sort of resource leak, but it's hard to say.
  

  That would seem consistent with what I observed.   My AGS computer is a couple years old and only has something like 192 Mb of RAM.   
  
  

  
  When this problem happens, could you open Task Manager, enable the GDI Objects column and see what it says for agsedit?
  

  I'm running WinME (Arrrrgh!!) on the AGS machine.  I don't think WinME task manager has that?  Unless you are talking about something other than than what comes up in responsde to the 3 finger salute??

I have noticed some odd behaviour.  Near the end of long AGSEDIT sessions button and other graphics fail to be drawn.  This includes the view of the room's background images in Room->Settings tab.    AFter closing the editor and re-opening the problem disappears.   

Hmm, changing room within Player Enters Screen Before Fadein is a bit of a dodgy thing to do; I guess perhaps the best solution would be for it to error out if you attempt this, unless it is a scenario that's useful?

Displaying a descriptive error message would be fine.  It's easy enough to work around once you realize what's happening.   Getting a black screen like that is a bit unsettling.  :'(   

Bug: ChangeRoom()

When the player character is set to start in room 1 and in the room 1 "Player Enters Before Fadein"  you attempt to do  a player.ChangeRoom(1,77,198) the background image is not displayed.  (Music is played however).    Seems to happen only with player character. 

This is an acrade type game and the apparent redundancy (i.e. CHangeRoom()) is there to establish a generic pattern for additional levels.   So although it doesn't serve a useful purpose in the first level, it would in subsequent levels.   

It seems that the easy fix on my part is to just start in room 0  as a blank screen and immediately go to room 1.  However, CJ, I thought this would be somthing you would want to be made aware of.

Hehe, you probably won't believe this but I once cut down a tree, striped it's leaves off, and  bolted it to the wall of my basement so my kittens would have something to play on.    There is a 4x4 wooden post wedged between the wall and the tree they can scratch.   

The scratching thingy in your link, I think, is just  a bunch of cardboard strips clued together, so that the cat can scratch the edges of the cardboard.  I think that's a good surface and plan on making something like that for my cats.   The one thing I didn't like about the one pictured is that it lays fairly flat.  My cats like to reach up and stretch out as part of their "claw sharpening" routine.  I would look for one that's taller or just make one yourself with wood and cardboard.  If you do the latte you could put a platform on top so she can climb up and play or sleep. 


 

[Abstract]

Abstract
AGS  allows one game to activate another game via the RunAGSGame() script function.  This  is useful in implementing arcade sequences and other game-within-a-game type things. These can be called Mini Games  and  designed  to be run stand-alone or from within another game. 

This module provides an easy method of calling and returning from mini games and an easy method of passing data back and forth. Examples illustrating the use of these  functions  are presented in subsequent sections of this document.

Download:
MiniGame-M0100 (module only)
MiniGame-T0100 (template example)
or  DemoQuest GiP Thread

Description
What does  this  module do that RunAGSGame doesn't do? If you were just going to activate the games from the very beginning each time then this module wouldn't be necessary.  However,  the usual scenario is that the player wants to return to the previous game and game state from where he left.  For example if the player plays an arcade game in a pub,  when he quits playing he ought to find himself in the same spot in the same pub where he was standing just before activating the arcade game.  The MiniGame module makes this as easy as pie.

Game Requirements
The main game and each mini game it calls must have been created with the same AGS version, color depth, and resolution.   All game files must be kept in the same folder.  The main game and all the mini games must use the same version of MiniGame and have Room0.crm be a black/blank room.

Passing Data
When a mini game is called it is often desired to pass data to it.   For example, in some situations it would be desireable to use the player's  money  to  make wagers in the mini game and then return the resulting winings or losses.  The MiniGame module uses a data dictionary to  pass  data to and from mini games. Each data point is associated with a unique name.  Data can be either a string or  an integer and is accessed through the following functions.

   MiniGame.sSet(String name, string value)
   MiniGame.iSet(String name, int value)
   MiniGame.sGet(String name)
   MiniGame.iGet(String name)

Calling a Mini Game
Mini games are called using the MiniGame.Call() function below.  The parameter 
FILENAME specifies the  name of the game file to be called.  It may or may not include file extensions of ".exe" or ".ags".

   // Call a mini game (from a room script or the global script)
   miniGame.iSet("Money",player.InventoryQuanity[iMone.ID]);
   MiniGame.Call("DemoCycle");

In this example, the amount of money in the player's inventory is passed to the mini game. The amount of money is stored in the data dictionary with a key of "Money". Next  "minigame.exe" is  called,  when it  terminates  it  will  return to "mainagame.exe".

Starting the Mini Game
The  mini  game will be loaded and then started as a result of the above MiniGame.Call(). The next thing to do is to determine if the game has been started from the operating  system or if it has been called. The function MiniGame.IsCalled() provids for this.  A value of  true is returned if called from another game and returns false otherwise.  This function is normally used in Global Script's game start event handler, game_start().

   // Mini Game Global Script
   function game_start() {

      // Mini Game startup script
      if (MiniGame.IsCalled()) {         // Read data dictionary
         Money = MiniGame.iGet("Money"); Passed from caller
      }
      else {                             // Run from OS
         Money = 10;                     // Give default amount
      }
   }

In the example above a global variable, Money, is set to the value stored in the data dictionary  under a key "Money" if the game has been called.  It is  set  to a value of 10 if the game was started from the OS.

Quitting a Mini Game
If  the  mini  game has been called then data must be saved in the data dictionary and the calling game re-activated. If the game has been run directly from the OS it can simply quit in the normal way using the QuitGame() function.  The preferred method of doing this  is to create a global function in the global script similar to the example below.  This  function is then called from any interaction functions designated as game exit or quit.

   // Mini Game Global Script
   function ExitGame(int ask_first) {
      MiniGame.iSet("Money",Money);      // Save data and ...
      MiniGame.Return(ask_first);        // return to caller
   }

In  the  example above  the global variable Money is  saved in the data  dictionary  via  MiniGame.iSet(). Next the MiniGame.Return() function  determines  if the  game  was  called  or  run  from the operating system. If the game was called then the  calling game is re-activated  and  the data in the data  dictionary is passed back.  If the game was run from the operating system then it's terminated normally using the AGS QuitGame() function.
 
Saving a Mini Game
The  MiniGame  module makes a call to the Game.SetSaveDirectory(). The specified directory name is formed by extracting the extension from the Game.  FileName string.If this extraction does not result in a useable  string then "SaveGames" is used instead. The success or  failure of  the Game.SetSaveDirectory() call should be checked before executing SaveGameSlot(), RestoreGameSlot(), DeleteSavSlot(), as follows..

   // Save the Game
   if (MiniGame.SaveAllowed()) {
      SaveGameSlot(slot);
   }
   else {
      Display("Error saving game, save directory not found");
   }

Perhaps a better  approach is to simply  remove the Save functions from the Gui at start up using Gui control prperties. 

   // Remove save functions if not allowed
   if (!MiniGame.SaveAllowed()) {
      gOptionsSave.Visible = false;    // Disable the Save button
      gOptionsRestore.Visible = false; // Disable the Load button
   }

Returning from a Mini Game
When  returning  from a mini game, any data it passes back must be read from  the data dictionary. This is done with a series of "if, else-if" statements  in  the  Global Script's repeatedly_execute() event handler function. The MiniGame.IsReturningFrom() function is used in the  conditional expression to determine which if any mini game has returned.
   
   // Main Game Global or Room Script
   function repeatedly_execute() {

      // Script to return from mini game
      if (MiniGame.IsReturningFrom("minigame.exe")) {
         Read data dictionary returned by mini game
         player.InventoryQuantity[iMone.Id] = MiniGame.iGet("Money");
      }
      else if (MiniGame.IsReturningFrom("anotherminigame.exe")) {
         Read data dictionary returned by another mini game
      }
   }

Any  data returned by the mini game can be retrieved and copied to the appropiate  game variables  using  the MiniGame.iGet() and the MiniGame.sGet() functions as shown above.

Note:  THIS MUST BE DONE IN THE REPEATEDLY EXECUTE HANDLER and not in the start game event handler because when returning from a mini game a  RestoreGameSlot()  operation is  performed to return to the point in the game from where the mini game was launched. This will overwrite  all game variables, so the data dictionary must be read after this occurs.  The  MiniGame.IsReturningFrom()  function will return true only after the restore opertion is complete. 

Known Issues
The following issues are known to the author, who can be contacted by posting on the AGS tech forum or by sending PM correspondance.

• Double Screen Transitions - As of this writing it is not possible to execute RestoreGameSlot() before the first screen is displayed.  This  was briefly mentioned above.  So instead of returning to the  screen from which the mini
  game was launched directly, it returns to  ROOM0 whoose background is  momentarily  displayed  before  the  desired screen is finally displayed  as a result of RestoreGameSlot()'s  execution.  To make this less noticable, ROOM0's background image is a single color of black and contains no script or interactions.  So when running directly from the OS ROOM0 is skipped and the game starts in another room as designated by the player character. When the game starts after returning from a call the GUI and mouse  are turned off and the player is left waiting in a black room.When the RestoreGameSlot() executes  the palyer is transported  to the room from where he called the mini game.
  
  Nested Calls
  Nested MiniGame.Call()s are  supported but have not been thourghly tested as of this release.  Should  someone try to do nested calls it is likely that it would work and that some issues would come to light.
  
  API Documentation
  A summary of this module's functions an Properties is given below.  There are three categories of functions as follows:
  
  
• Functions used in the calling game
       - MiniGame.Call()
       - MiniGame.IsReturningFrom()
  
  
• Functions used in the called game
       - MiniGame.Return()
       - MiniGame.IsCalled()
       - MiniGame.SaveSlot()
  
  
• Functions that are used in both
       - MiniGame.iGet()
       - MiniGame.iSet()
       - MiniGame.sGet()
       - MiniGame.sSet()
  
  static function MiniGame::Call(String filename)
  This function calls a mini game. The file containing the mini game must be in the same directory as the main game.  It must also have the same resolution and color depth as the calling game.  The file name of the mini game is  given by  the FILENAME parameter.
  
  Save slots  are numbered  from 0 to 999. The game restart function uses slot 999 so it is reserved. The call stack uses utilizes save slots 998 to 998 - MiniGame_STACKSIZE.
  
  In  debug  mode error messages are displayed if the specified game  files do not exist or if  the call  operation  cannot be completed.  When debug is  disabled these  messages are surpressed. In  either case the following error status is returned as follows.
  
     Return:
     eMiniGame_Ok                      - call complete successfully
     eMiniGame_MiniFilenameErr  - game file doesn't exist
     eMiniGame_MiniGameDatErr   - can't write to minigame.dat file
  
  static function MiniGame::IsReturningFrom(String filename)
  This function returns true if the game is starting up as result or returning from a previously called mini game. This fuinction is to be  called  from  the repeatedly_execute() function of the calling game to know when  to  copy  data  from  the memory buffer to game variables.
  
     Return:
     true                       - just returned from specified game
     false                      - did not return from specified game
  
  static function MiniGame::Return(int ask_first)
  This function is called from any interaction or custom function to return to the calling game or to quit if the game was started from the operating system.
  
  static function MiniGame::IsCalled()
  This function returns true if the game was started from the OS and returns false if it was called by another game or is returning from a called game.
  
     Return:
     false                      - game was started directly from OS
     true                       - game was called from another game
  
  static function MiniGame::SaveAllowed()
  This function returns true if a save directory was setup correctly.  It  returns  false  otherwise, in which case the main game and the mini games share the same save game space and would interfere with each other.  In  this  case the mini game should be prevented from executing SaveGameSlot() operations. 
  
     Return:
     false                      - prevent mini games from being saved
     true                       - allow mini games to be saved
  
  static function MiniGame::iGet(String name)
  This function returns the integer value corresponding to NAME.  If NAME doesn't exist an error mesage is generated.
  
  static function MiniGame::iSet(String name, int value)
  This function modifies value corresponding to NAME as specified by the VALUE integer parameter.  If NAME  doesn't exist the name-vale pair is appended to the end of the memory  buffer.  If there is no more room and error message is generated.
  
  static String MiniGame::sGet(String name)
  This function returns the string value corresponding to NAME.  If NAME doesn't exist an error mesage is generated and a null string is returned.
  
  static function MiniGame::sSet(String name, String value)
  This function modifies value corresponding to NAME as specified by the VALUE string  parameter.  If NAME  doesn't exist the name-vale pair is appended to the end of the memory  buffer.  If there is no more room and error message is generated.
  

When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error  "stack corrupted after function call".  If I put the identical statement in the room script it works just fine.   Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()? 

Thanks for the report, I'll look into it.

Here is some additional information about this that may be helpful.  After further experimentation I have found that it seems to work just fine when called from a Script Module's repeatedly_execute() handler.    It was a pleasant surprise  8).

That seems to work just fine.     

Just for reference I was wanting to do this in the game_start() function of a script module.  This seemed to me to be the most straight forward and intuitive way of doing things.   Since there needs to be some script in the main game to consume data returned by the mini game I can embed the restore operation in there and move it to the first room.   If you ever have ocassion to work on game initialization etc, perhaps you could keep this in mind and see if anything could be done. 

Thanks for your input.

The RestoreGameSlot() function seems to have no affect when executed from the game_start() event.  Is this by design or an oversight or am I missing something?  Is  it something that can be changed?   

*** Edit ***
Further investigation shows that this also happens when executing from repeatedly_execute() on the first execution.   

I have also noticed that there is a momentary blink of the screen when RestoreGameSlot() begins executing and before it transitions to the target room.

======
Why is this necessary?  I wish to use the RunAGSGame() featue to callup a mini-arcade game and then return to the original game.   So to return  to the same state in the original game from where I launched the mini-game I am using SaveGameSlot() just prior to launching the mini-game and RestoreGameSlot() after returning.   

In this case it is not desireable for intermediate screens/rooms to be displayed before returning to the original room in the main game. 

I am also having a problem calling the RunAGSGame() function from within a script module.   I have previously asked about this in the Beta thread and mention it here for completeness of the above explanation.

Thanks in advance for any help you can give. 

Thanks Scotch, for the info.  Like I said I'm not knowledegable about either.  I saw a few references to DOSBOX only very recently when I had ocassion to ask myself the same question Lysdexia poses.   I am curious to see it how this discusion come out. 

Btw,  here is a page I found that lists a number of emulators for the mac, some are free and some aren't.  I don't know that it will be helpful but here it is anyway.

Cheers.

http://www.macwindows.com/emulator.html

[dosbox]

lysdexia,

I don't know much about Mac OSX but perhaps something like dosbox would work for you.  It's open source and you can download it from the link. 

Possible Bug:

When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error  "stack corrupted after function call".  If I put the identical statement in the room script it works just fine.   Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()?