Note: some of the information in this document is outdated as of the release of AGAST Morningstar. Specifically, items are no longer a part of the AGAST language- use objects instead.

AGAST 1.08 contains many new features which vastly expand the power of the system. In the process of integrating these features, some existing features have been modified, and will require modifications to the source code of games developed with AGAST 1.07g. These required changes are as follows:

Classes

Classes are definitely the biggest change to hit AGAST in version 1.08. They also require the biggest change to existing scripts. Until now, the ActiveObject at the beginning of Item-on-Object events has always been the PlayerObject. As a result, you may have code that resembles the following:

event LookAt -> Shovel
{
   "It's a shovel...  looks a bit old,  though."
}

In the above example, the text would have been spoken by the PlayerObject (generally Ego). This was inconsistent with the working of other event types, such as MouseOver or Paint events, in which the object the event belonged to would be active. In implementing classes, we found it necessary to make Item-on-Object events consistent with other event types. Therefore, the ActiveObject in Item-on-Object events will always be the target object. In order to achieve the same effect as the code above, you would now have to write something like:

event LookAt -> Shovel
{
   Ego:
   "It's a shovel...  looks a bit old,  though."
}

Item-on-Default events remain unchanged for now, but are likely to be changed in the future to match other event types. It is therefore suggested that Item-on-Default events be coded in the same fashion as the latter example.

Additive Blending

AGAST 1.08 supports additive blended sprites. In previous versions of AGAST, the property AlphaEnabled was used to determine whether an object was drawn with alpha or boolean transparency. AlphaEnabled has been replaced in version 1.08 with TransparencyMode; all scripts will need to be modified accordingly.

Save/Load Support

Unlike the above changes, Save/Load support does not require changes to your existing code. However, you'll probably want to incorporate it at least into release versions of your game. In order to do so, you will need a user interface for the interpreter's Save/Load system; one has been provided in the menus.s file included in the SampleGame.