Topics

[AGS 3.4.0 and higher]

DOWNLOAD DragDrop 1.3.0 MODULE
DOWNLOAD DragDropCommon 1.3.0 MODULE
DOWNLOAD Demo game

Additionally, latest sources of both the script module and the demo game may be found in this repository:
https://github.com/ivan-mogilko/ags-script-modules

Full documentation for this module is now available here:
https://github.com/ivan-mogilko/ags-script-modules/wiki/Drag-&-Drop-module

Module supports AGS 3.4.0 and higher.
Compatible with AGS 4.0.


DragDrop and DragDropCommon are two modules that make it possible to drag things around in AGS. What is the difference between these two?

DragDrop module implements an abstract drag-and-drop functionality. This means that the module does not drag any actual game object on its own, but rather calculates the dragging and dropping action, and tells you what and how happens, so that you could script the actual object movement. You might say, this module provides an idea of dragging, rather than dragging itself .

The upside of such approach is that you may script dragging of anything, both standard AGS objects and your own custom things, even non-ordinary pseudo-objects. For example, you may use this module to script dragging a line from point A to B, or draw a rectangle by dragging one of it's corners. The downside is that you have to be ready to do some extra work, and understand scripting well.

When you need to just make normal ordinary game objects dragged around in your game, this is what DragDropCommon module is for. DragDropCommon supports drag-and-drop for Characters, Room Objects, GUIs and GUI controls, and inventory items, right out of the box, only with a minimal setup.

NOTE: DragDropCommon module actually depends on DragDrop module, so you will have to add both to your game if you want to use DragDropCommon.

[Double Click]

DOWNLOAD DoubleClick 1.1.0 MODULE
DOWNLOAD KeyListener 1.0.0 MODULE

Both modules require AGS 3.4.0 or higher.
Now they are compatible with AGS 4.0.

Module sources may be found in my GitHub repository:
https://github.com/ivan-mogilko/ags-script-modules


Other script modules by me:

Spoiler

DragDrop
Timer
TypedText

[close]

Double Click

As of now, AGS does not have built-in mouse double-click events. DoubleClick module solves this by detecting when player made two consecutive clicks within short duration.

Usage is very simple:

Code: ags

function on_mouse_click(MouseButton mb)
{
  if (mb = eMouseLeft)
  {
    if (DoubleClick.Event[eMouseLeft])
    {
      player.SayBackground("Double-clicked!");
    }
    else
    {
      // regular click
    }
  }
}

DoubleClick supports claiming events similar to standart ClaimEvent() function. If you are detecting double clicks in several modules, you may use DoubleClick.ClaimThisEvent() to not let double-click "through" to lower scripts.

DoubleClick.Timeout property is used to set up max timeout (in milliseconds) which may pass between two clicks for them to be considered "double click". Default is 300 ms.



Key Listener

KeyListener is a more sophisticated script module, that keeps track and record of the particular key and mouse button states in your game. Since AGS is limited in which key and mouse events it reports to the script, this module may be a useful workaround.

With KeyListener you do:

• Setup which keys or mouse buttons to listen (track) and change that list dynamically at any moment in the game;
• Optionally configure deduction parameters, such as maximal time between two key presses while they still counted as a sequence;
• Enable and disable listener work at will.

With KeyListener you acquire following information about any of the listened keys and mouse buttons at any time:

• Is key currently up or down;
• Was the key just released or pushed;
• Has the player double clicked a mouse button;
• How long was the key up or down (in milliseconds);
• How much times was the key tapped in a sequence;
• How much times was the key "auto-repeated" while being held down;

NOTE that if you are using KeyListener, you do not need DoubleClick module.


Concepts

On sequencing.
Sequencing is pressing same key (or mouse button) over and over again, when every next press was made within certain time limit since the previous one. KeyListener lets you configure the maximal waiting time (timeout), default value being 300 ms. You are able to know when the key was "sequenced" another once, and how many times it was pressed in sequence already ("sequence length").

On key autorepeats.
In KeyListener terminology, a key's autorepeats start to occur periodically when the key is being held down for some time. This simulates the common operating system behavior, which can be easily observed in any text editor: when you press and hold the key first only one letter is typed, but after small amount of time it starts typing same letter again and again automatically, without you releasing and pressing key again.
You may configure two parameters related to key repeats: the first delay, which has to pass before key begins "repeating", and the (usually shorter) period between repeat count increments.
You may get when autorepeat occurs, and how many times this key was autorepeated.

Signal properties
Since AGS does not support custom callbacks (calling your own functions when something happened in script module), KeyListener tells you about immediate events by setting certain signal properties. These properties are easily distinguished by "Evt*" prefix.
The positive values on signal properties only set for 1 game tick (update), and are reset immediately afterwards. They literally mean that the key event has just occured, and you should react to that. The next tick they will be reset until some key event occurs again.
You will have to check these properties periodically, in the "repeatedly_execute" or "repeatedly_execute_always" functions of GlobalScript or your own custom script to know when the related events occur.

Lifetime of key records
Another important peculiarity is that some properties are kept for just 1 tick more after key state changes, before getting reset. These are KeyUpTime, KeyDownTime and KeyAutoRepeatCount. This is done so to allow you get their final value after being notified about key state change. For example, you may want to know how long the key was held down right after it was released.


Module API

Following are properties of the KeyListener class, that are exposed for use in your scripts:

Code: ags

struct KeyListener
{
  ///////////////////////////////////////////////////////////////////////////
  //
  // Setting up
  // ------------------------------------------------------------------------
  // Functions and properties meant to configure the listener's behavior.
  //
  ///////////////////////////////////////////////////////////////////////////
  
  // Enables or disables KeyListener, without cancelling tracked keys settings
  import static attribute bool Enabled;
  
  /// Commences or ceases to listen keycode
  import static void ListenKey(eKeyCode keycode, bool enable = true);
  import static void ListenMouse(bool enable = true);
  /// Stops listening all keycodes
  import static void StopListenAllKeys();
  
  /// Resets all listener parameters to default values
  import static void ResetToDefaults();
  
  /// Get/set minimal time (in milliseconds) for a held down key to be down to be considered "repeating"
  import static attribute int KeyAutoRepeatDelay;
  /// Get/set period (in milliseconds) between each "repeating" key count
  import static attribute int KeyAutoRepeatPeriod;
  /// Get/set maximal period (in milliseconds) between two key taps while they still considered a sequence
  import static attribute int KeySequenceTimeout;
  
  
  ///////////////////////////////////////////////////////////////////////////
  //
  // Event signals
  // ------------------------------------------------------------------------
  // Properties meant to signal user about keys events.
  //
  ///////////////////////////////////////////////////////////////////////////

  /// Gets if key was just pushed
  readonly import static attribute bool EvtKeyPushed[];
  readonly import static attribute bool EvtMousePushed[];
  /// Gets if key was just released after being held down
  readonly import static attribute bool EvtKeyReleased[];
  readonly import static attribute bool EvtMouseReleased[];
  /// Gets if key command was repeated for a held down key
  readonly import static attribute bool EvtKeyAutoRepeated[];
  readonly import static attribute bool EvtMouseAutoRepeated[];
  /// Gets if key was tapped another time in sequence
  readonly import static attribute bool EvtKeySequenced[];
  readonly import static attribute bool EvtMouseSequenced[];
  /// Gets if key was tapped twice in sequence just now
  readonly import static attribute bool EvtKeyDoubleTap[];
  readonly import static attribute bool EvtMouseDoubleClick[];
  
  
  ///////////////////////////////////////////////////////////////////////////
  //
  // Key records
  // ------------------------------------------------------------------------
  // Properties meant to tell gathered information about keys the listener
  // is listening to.
  //
  ///////////////////////////////////////////////////////////////////////////

  /// Gets if key is currently held down
  readonly import static attribute bool IsKeyDown[];
  readonly import static attribute bool IsMouseDown[];
  /// Gets how many times the pressed down key command was repeated
  readonly import static attribute int  KeyAutoRepeatCount[];
  readonly import static attribute int  MouseAutoRepeatCount[];
  /// Gets how many times the key was tapped in sequence
  readonly import static attribute int  KeySequenceLength[];
  readonly import static attribute int  MouseSequenceLength[];
  /// Gets how long (in milliseconds) the key was not pressed
  readonly import static attribute int  KeyUpTime[];
  readonly import static attribute int  MouseUpTime[];
  /// Gets how long (in milliseconds) the key was held down
  readonly import static attribute int  KeyDownTime[];
  readonly import static attribute int  MouseDownTime[];
};

Examples of use

Example 1: Some simple actions.

Spoiler

Code: ags

function game_start()
{
  // We are going to track spacebar and the mouse buttons
  KeyListener.ListenKey(eKeySpace);
  KeyListener.ListenMouse();
  // Start tracking
  KeyListener.Enabled = true;
}

Code: ags

function repeatedly_execute()
{
  if (KeyListener.EvtMouseDoubleClick[eMouseLeft])
  {
    // player double clicked with mouse; do something
  }
  
  if (KeyListener.EvtMousePushed[eMouseLeft] && KeyListener.MouseSequenceLength[eMouseLeft] == 2)
  {
    // this is essentially the same as above
  }
  
  if (KeyListener.IsKeyDown[eKeySpace] && KeyListener.KeyDownTime[eKeySpace] > 1000)
  {
    // player is holding space bar for more than 1 second
  }
}

[close]

Example 2: displaying particular key records on GUI.

Spoiler

Code: ags

int key;
function game_start()
{
  key = eKeyA;
  KeyListener.ListenKey(key);
  KeyListener.Enabled = true;
}

function repeatedly_execute() 
{
  Label1.Text = String.Format("Key is down: %d", KeyListener.IsKeyDown[key]);
  Label2.Text = String.Format("Key just pushed: %d", KeyListener.EvtKeyPushed[key]);
  Label3.Text = String.Format("Key just released: %d", KeyListener.EvtKeyReleased[key]);
  Label4.Text = String.Format("Key uptime: %d", KeyListener.KeyUpTime[key]);
  Label5.Text = String.Format("Key downtime: %d", KeyListener.KeyDownTime[key]);
  Label6.Text = String.Format("Key repeats: %d", KeyListener.KeyAutoRepeatCount[key]);
  Label7.Text = String.Format("Key taps: %d", KeyListener.KeySequenceLength[key]);
  Label8.Text = String.Format("Key double tap: %d", KeyListener.EvtKeyDoubleTap[key]);
  Label9.Text = String.Format("Key sequenced: %d", KeyListener.EvtKeySequenced[key]);
  Label10.Text = String.Format("Key repeated: %d", KeyListener.EvtKeyAutoRepeated[key]);
}

[close]

The module is currently in BETA stage and needs extensive testing.
Comments, critism, suggestions and bug reports are welcome.

.

Hello, I would like to ask if anyone knows a relatively short term depicting the kind of adventure game interface, which simulates first person view and lets to choose direction to go by clicking on compass or any similar kind of GUI control.

Some examples:
[imgzoom]https://lh4.googleusercontent.com/-nKrPC3pOW2w/TYWr1Rnt36I/AAAAAAAAAJk/715flFyM5nc/s1600/uninvited-mac7.png[/imgzoom]
[imgzoom]http://www.abandonia.com/files/games/449/Companions%20of%20Xanth_6.png[/imgzoom]


Is there any name that depicts this style of UI/gameplay?

[Case 1:]

My attention was brought to this when I was testing someones game and found bizzare savesystem behavior. I cannot remember if I've seen this before, but assuming a lot of people around use Default template for their games, I believe this situation relates to many games, just had not been noticed or covered yet (?).

Okay, so here is how Default template saves a game when user already typed saves name and clicks on Save button:

Code: ags

////////////////////////////////////////////////////////////////
  int gameSlotToSaveInto = lstSaveGamesList.ItemCount + 1;
  int i = 0;
  while (i < lstSaveGamesList.ItemCount)
  {
    if (lstSaveGamesList.Items[i] == txtNewSaveName.Text)
    {
      gameSlotToSaveInto = lstSaveGamesList.SaveGameSlots[i];
    }
    i++;
  }
  SaveGameSlot(gameSlotToSaveInto, txtNewSaveName.Text);
////////////////////////////////////////////////////////////////

(I removed some lines that are not important.)

What we have here is an algorithm of finding a slot to save the game into. How does default template do that?
It searches through all saves it found in the directory, until the name of the save matches with what user typed in the text box, or until it hits the end.
In the first case it saves game in the slot number, equal to the slot number with matching name, and in the second case it saves to the slot number equals to the total number of files in the list + 1.

Now, consider two test cases.

Case 1: we have several saves with properly ordered slot numbers:

agssave.001 -- named "Save 1"
agssave.002 -- named "Save 2"
agssave.003 -- named "Save 3"
agssave.004 -- named "Save 4"

User types in "Save 3" and game finds it in the slot 3. The game gets properly written into agssave.003 again.
User types in "New Save", games cannot find such slot and assigns slot number to the number of saves + 1, that is 5. The new game gets properly written into agssave.005.

Case 2: we have some save numbers missing in the beginning. How did this happen? Well, for instance, we were copying saves to other computer and missed some. Or maybe person uploaded single save to demonstrate a bug in the game, or something like this.

agssave.003 -- named "Save 3"
agssave.004 -- named "Save 4"

User types in "Save 3" and game finds it in the slot 3. The game gets properly written into agssave.003 again.
User types in "New Save", game cannot find such slot and assigns slot number to the number of saves + 1, that is... 3.
And the game is written to the existing file named agssave.003, overwriting game which we did not want to overwrite.
This also means, that player will now have a very low limit of save slots.

[Please, read before using]

This is a preliminary release of AGS 3.3.5. It is meant for public testing and gathering user opinions.

NOTE: This might be the last update to AGS 3.3 line; I am planning on bringing AGS 3.4 into beta stage next, and continue from that onwards.


Installer: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.exe
ZIP archive: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.zip
No-MP3 engine: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5-noMP3.zip


Please, read before using
This update adds a serious change that may be, though, not noticeable at first (and many players will probably not notice it at most times).
The change was discussed at: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52897.0

Since 3.3.5 AGS does not allow to write any files into other path rather than "$SAVEGAMEDIR$" (personal user saves directory) or "$APPDATADIR$" (all-users game data directory). An attempt to open file for writing at any other path from script will make engine automatically remap the path to $APPDATADIR$. If your game is built in Debug mode, it will also print a warning into "warnings.log".

At the same time the players are allowed to set up their own custom path to write game saves & data in. This basically works as remapping $SAVEGAMEDIR$ and $APPDATADIR$ to custom location. Game script will be "unaware" of this, and work as usual.

Conceptually, AGS is gradually leaning towards using only "symbols of file locations" rather than actual, explicit locations.

Furthermore, winsetup will now write config file into game saves location, rather than game's installation directory. If config file is present in the game installation folder, then it is used as "default" read-only config file. The config in saves folder overrides default one.
This way it should be totally safe to install any AGS game into C:/Program Files, without having administrative rights, or even have it installed on device with read-only access.


Changes since version 3.3.4:

Editor Features:
- Path to resource's (sprite, audio) source file is now saved as relative one if the file is
  located inside game project's folder.
- Removed arbitrary limit of the script imports (was 50000).
- Script allows struct member qualifiers to be in any order.
- Better detection of integer constants overflow in script.
- Removed arbitrary limit of integer default value of +/-32000. Integer values are now limited
  by correct 32-bit values (-2147483648 to 2147483647).
- Support for negative constants in enums.
- Better folding markers and indentation guides in script editor.

Editor Bug Fixes:
- Fixed compiler crash if unknown keyword used after "readonly".
- Fixed compiler did not properly report incorrect type of dynamic array in function declaration.
- Fixed compiler did not report proper type name in case of syntax error sometimes.
- Fixed mouse cursor flicker above the script editor.

Engine Features:
- Removed unconfigurable mouse cursor's acceleration.
- Support for mouse cursor speed control: may be defined in configuration and changed in script).
- A config option for keeping consistent cursor speed relative to user's desktop resolution.
- Support for locking mouse inside window: automatic lock is enabled in configuration, and user
  may use Ctrl+Alt combination to lock/release mouse at any time.
- Restricted writing game files to special system directories
  (game is forbidden to write files into installation directiory or by absolute path).
  For old games unsafe paths are remapped.
- Support for player defined saves & game file directory.
- -v/--version command line argument makes engine display its version and bail.

Engine Bug Fixes:
- Fixed crash if screenshot is taken while game window was minimized or moving.
- Fixed alpha blend did not work properly for speech portrait if blinking frame did not have alpha channel.
- Fixed Display and Say script commands were displaying text for minimal amount of time under certain conditions.
- Fixed legacy audio functions did not start digital music playback if MIDI driver failed to initialize.
- Fixed game was run in smallest possible window if graphics driver failed to initialize fullscreen mode.
- Fixed "--help" command line argument not working all times depending on its order.
- Fixed engine did not always properly closed application window when running debug build.

Script API:
- Supported late_repeatedly_execute_always() callback in script, called after game has updated, but
  before it is drawn.
- Added Mouse.ControlEnabled (readonly) and Mouse.Speed properties.
- Added System.HasInputFocus property which tells if game currently has focus or runs at background.

Cosmetics & convenience:
- Clarified disabled MIDI option name in WinSetup.
- Extended information displayed if graphics driver failed to initialize.
- Clarified error messages for running unsupported games.

[Problem]

Problem

Since Windows Vista a program requires administrative rights to write into "C:/Program Files" folder. This means that if an AGS game was installed there, it won't be able to create or change any files in its directory. This refers to:
* configuration file,
* saved games,
* custom files written by game script.

In the previous versions of AGS this issue was partially fixed by letting games to save into special folders ("Saved Games" and "AppData" folders). If a correct subfolder name is provided by game developer, then saved games are written in "Saved Games / GameFolder" automatically.

However, three problematic cases remain.

1) Configuration file is still located in the game directory. If inside "Program Files", WinSetup utility cannot write to that file without admin rights.
Also, if we make game itself modify configuration file at any point (for example, if you can change these options from script), the game won't be able to do so without admin rights too.

2) Script may create custom files in game directory.

3) It is still allowed to create saved games in game directory (if you do not provide save folder name).


Expectations

The game should write files without issues regardless of where it is installed, in accordance to contemporary conventions.

I would like to find and implement a solution for upcoming 3.3.5 release.


Preliminary proposition

1. Game / WinSetup writes all files in special folders ("Saved Games" or "AppData", etc).

2. When game reads a save file or custom data file, it first check corresponding "special" folder; only if file is missing it may also check paths related to game installation dir. This will make it compatible with games that do not have a "proper" installer (distributed in archive), and also backwards compatible.

3. When game reads configuration, it first reads the config file found in installation directory, then reads the one in "special folder". This way the newer file in "special" location overrides the "default" config file in the installation dir (if there is any).

4. The file paths supplied by script are remapped when required. For instance, if script does not tell to write file either in "Saved Games" or "AppData", then the path is still converted to "AppData".
In order to avoid file name conflicts, some prefix / subfolder may be added in that case too.

5. The "Save folder" string option in General Settings may actually become obsolete; the subfolder name for game files inside "special" folders may be equal to game's title. Or we may leave it, and use game title as default, if game developer did not provide subfolder name.



Complications

This proposal, if implemented, may lead to number of complications, or rather inconveniences.

1. Similar to saved games, if game saves some data depicting user progress in a custom file, it should be searched in a special folder when user wants to move saves to another computer.
2. When editing config file by hand, user should find it in a special folder as well. Ofcourse, this refers primarily to options that may be changed by game itself (in the future), due the overriding rule mentioned above.

Possible solution: when compiling/packaging game add shorcut files leading to corresponding special folders (saved games and app data).

3. The file location conventions may differ on different platforms (although ports are already more strict with savedgames than Windows version).

[EDIT:]

What will people think if we move the issue tracking to YouTrack service?
YouTrack site.

We need a combined tracker, because currently part of issues are registered at the AGS forum tracker, and another part at the GitHub tracker, attached to our source code.

Both have different ways of displaying and managing tickets, and both have particular cons, IMO, that do not let me choose any of these two easily.

For instance, GitHub tracker has a simplistic yet very flexible way of grouping issues with tags, and is generally good for co-developers, but it could be rather confusing for regular end-users: not only issue filtering is uncommon, but also it is integrated into repository page, with lots of unrelated screen elements.

The forum tracker has a stricter ticket arrangement and probably more common in view, but it is very inconvenient in terms of customization (I fear introducing any additional field would require manually hacking PHP scripts and modifying site database).


YouTrack does not have the mentioned disadvantages, it does not have anything unrelated on screen, is easily customized and automated, and has numerous different ways to display and filter issues.
Also it can do integration with GitHub, thus binding with code repository will be kept.

I think YouTrack was created having both IT and other applications (management, etc) in mind. I am interested in opinion on whether it will be easy to use for regular end-users (AGS members have varied experience with IT stuff after all).

This is a very basic tracker we set up for evaluation:
http://adventuregamestudio.myjetbrains.com/youtrack/issues
YouTrack demo video:
http://www.youtube.com/watch?v=A8sWYBe7pO8

=======================================================================================
EDIT: How to login to YouTrack?
You either create a free account specifically for YouTrack, or login using your -
* GitHub
* Google
* Yahoo!
* Yandex
account. To do the latter you need to type in your credentials, then click on the corresponding system logo, instead of the "Submit" button.
=======================================================================================


Recently we have successfully applied for JetBrains Open Source license for TeamCity build server, which gives us free build service with some advantages, and there is a chance we may add another Open Source license for YouTrack service hosted on cloud server, with unlimited number of reporter accounts.

I wanted to tell about this, but was not sure where to post.
I mentioned this couple of time before in random threads, that I wanted to [ temporarily ] quit my job and devote more time to critical issues in AGS.
My company seniors have suggested a half-time work schedule instead, and I accepted. Since October (starting next week, to be precise) I am working half-time on my job (2 days a week).

This decision was made not only because of AGS. Mainly I was feeling like I am heading a wrong way in my life, getting desperate over doing not what I liked to do, and wanted to try something else.

I cannot say I will use all the time I have now solely for AGS project, but definitely I will be able to do more. Most importantly, this will allow me to work on bigger improvements that are hard to deal with when you have just small amount of free time per week.

Well, that's it .

We need to move the "Templates" and "Demo Game" folders to some standard shared location in Windows to prevent security issues in Win Vista and later.

One of the possible paths could be %ALLUSERSPROFILE%. In Win XP it is "C:\Documents and Settings\All Users", and in Vista and later ones it is "C:\ProgramData".

On other hand, we may choose "Public" documents folder on recent systems.

Which makes more sense? Any other ideas?

[UPDATED July 2020]

UPDATED July 2020

The automated builds may be found here:
https://cirrus-ci.com/github/adventuregamestudio/ags

For latest dev version updates (the "master" branch), in particular:
https://cirrus-ci.com/github/adventuregamestudio/ags/master

There was a request made by Calin Leafshade: http://www.adventuregamestudio.co.uk/forums/index.php?issue=520.0
Basically it is about switching from using absolute paths to original sprite/audio files to relative ones.

While it is totally clear that this will benefit users who store original assets relative to the project folder (locally to project folder, or close to it), the question that bothers me is, would not that break a use of shared resources for someone?

Is this a common method for some of the AGS users to have a shared resources folder somewhere on their computer to take sprites/audio files from, regardless of where the game project itself is located?

I came to this question because I personally have a "library" of sprites for creating small test games, and this library is located in some place which is completely irrelevant to location of my AGS projects. Is this uncommon to how people work with AGS?
I am worried that changing to relative paths in all cases could break work for someone.

I've come to the decision that we need to change the data version format in both source project and compiled game.
For legacy reasons they are currently defined as a simple number in a sequence, with higher number meaning later and more advanced data content.

However, this does not suit well the parallel development when older and newer versions of AGS are being worked on and updated simultaneously.
It is possible that we would like to change data format in update to current stable version. In such case the next number may already be taken by version in development.
Picking even higher number will technically work, but it creates a confusing situation when a format id in AGS release with lower version is higher than the one in the next WIP version.

Besides, the single sequence of numbers cannot explicitly describe the situation when two branches of development have unique features.
For example, AGS 3.3.4 may have data format-changing features A,B,C, and AGS 3.4.0.6 has features A,B,C and D,E,F. Then we release an update 3.3.5 with feature K. This feature is not present in any release of the 3.4.0 yet.

If we use single number sequence, as described above, we may have, e.g:

AGS Release	Data Version	Features
3.3.4	10	A,B,C
3.3.5	20	A,B,C,K
3.4.0.6	15	A,B,C,D,E,F

This may be confusing for developers, because they need to keep these differences in mind, and also there is no easy way to write a version check for Editor or Engine, to let it detect more advanced version, and therefore at least provide a sane error message when trying to open unsupported project.

Even less this would suit if someone would make alternative variants of AGS for their own use or amusement.



The most flexible implementation would be to store a list of feature string IDs inside game data, and have program compare this list to the ones it supports.
For example, game data may have this written in some data header:
- FEATURE__CustomResolutions
- FEATURE__NewPathfinder
- FEATURE__ScriptAPI_KeyPressEmulation,
and whatnot.

The question is, will or not this be too complex for AGS? Or will it be too complex for current moment?



Another alternative that I was thinking about is more simple, although less explicit: use long versions strings. For example, we may call data format 3.3.XXX, where XXX is an internal number of data format update. Or this may simply be equal to release number: 3.3.4, 3.3.5, 3.4.0.6, etc.
This version will be compared by comparing each part individually, therefore it will always be known whether data format comes from lower or higher version of AGS.

The downside of this implementation is that the program would still need to know which is a latest format of previous version it supports.
To clarify, in the situation I described above, AGS 3.4.0.6 will support formats 3.3.4 and 3.4.0.6, and when given a game with data format 3.3.5 it will know that although this data format belongs to previous major version 3.3, it is still not supported in 3.4.



I would like to hear other devs opinions on this problem, for the solution has to be aimed for long future use.

[* Custom resolutions.]

AGS 3.4.0

Introductory topic

AGS 3.4.0 is the next version of Adventure Game Studio Editor and Engine, being in development since mid-2014. Currently it is in relatively stable stage (you actually can make games with it), but its main planned features are not yet fully implemented, therefore we call it Alpha version.

As previously, we try to keep backwards compatibility with previous versions, meaning that:
1. You should be able to load your game project made with previous versions of AGS Editor, and continue to work on it, possibly with only minor changes to script (or enabling compatibility mode in General Settings).
2. You should be able to run your previously compiled game with new 3.4.0 engine without recompilation.

This thread is meant to serve for preliminary acquaintance with the new version.


The notable features of AGS 3.4.0 are:

* Custom resolutions. Since AGS 3.4.0 you will be able to create games with any size, and run it in any display resolution using existing scaling filters.
* Extended build system with support to build game for multiple platforms. AGS 3.4.0 supports extensions that let it compile games for additional platforms (e.g. Linux). They are optional, and require installing extra files to AGS folder, as well as enable them in project's General Settings.
* Custom properties are now mutable. Custom properties may now be changed at runtime.
* Extended AGS Script. A number of new commands and constructions were added to AGS script language, such as user-defined managed structs, "for" and "switch" blocks. Few existing features were improved, for example now it is possible to define static extender functions and have dynamic arrays in structs.
* Extended Dialog Options customization. You may now easily create custom rendered dialog options that animate and react to key presses.

TO BE UPDATED

This topic has been moved to AGS Engine & Editor Releases.

http://www.adventuregamestudio.co.uk/forums/index.php?topic=50021.0

This topic has been moved to AGS Engine & Editor Releases.

http://www.adventuregamestudio.co.uk/forums/index.php?topic=51051.0

This topic has been moved to AGS Engine & Editor Releases.

http://www.adventuregamestudio.co.uk/forums/index.php?topic=51425.0

This topic has been moved to AGS Engine & Editor Releases.

http://www.adventuregamestudio.co.uk/forums/index.php?topic=52398.0

[Welcome to the AGS Releases forum!]

Welcome to the AGS Releases forum!

This forum is for announcing the releases of the new versions of AGS.

Currently only moderators can create topics here, but regular users may still post in these topics.

There are few notes on posting here.

DO POST here if:
- you want to clarify something about changes in the new AGS version,
- you are getting troubles when installing or running new AGS version, or
- you are getting troubles when running the game produced with new AGS version.

Spoiler

- you want to express how you feel about new version of AGS.

[close]

NOTE: we also have an Issue Tracker for reporting bugs and suggesting new features; the only caveat is that you need a github account:
Official release issue tracker


DO NOT POST here if:
- you need help creating your game with AGS, scripting or using editor in general; these kind of questions should be posted in Beginners' Technical Questions or Advanced Technical Forum,
- you have suggestion on changing something in AGS (add new feature, improve or change how AGS works), or discuss current development; for this please post in Engine Development or Editor Development forums.
- you have questions on using game template, script module or plugin that was released by someone else; in such case please post in template/module/plugin - related thread. Usually such thread may be found in the Modules & Plugins forum.
- you found bugs in a game made by someone else; in such case you should rather post in the game-related thread (look in Completed Game Announcements) or contact the authors of the game elsewise.


These rules may be updated in future if such need arises.

I think that it might have become a problem that the final release announcements are posted in "Development" sections. That became a short tradition when we started releasing our first builds ourselves.

I think this may be inconvenient for both developers and common users, because the topics of very different purposes (release announcements, questions, bug reports and developer discussions) are mixed up in one subforum. There are other reasons, for example: Engine and Editor development discussion is divided, but the release announcement is related to both of them. Also, the subforum description reads "For discussing and planning the development of the AGS" which may be misleading for end users.

Can we create a new subforum called, for instance, "AGS Releases" and put it into "AGS Support" (above Beginner's questions)?
What would you think about this?