Topic: AGS 3.4.0 - RC2 (Release candidate)

[Crimson Wizard]

Uploaded Beta 2 with number of changes. Links are essentially the same, you may find them in the first post.

I think the most important is an addition of another compatibility switch to complement "Script API version". Soon after beta 1 release I realized that this only switch is not enough. There are usually two problems when upgrading scripts: new functions appear that may conflict with names you use, or modify some existing behavior, and second problem is that some previously existing functions are declared obsolete and "hidden".

So, that first switch, called "Script API Version" now defines the TOP range limit of built-in functions, or the latest version of scripting your game uses.
The second switch, called "Script Compatibility Level" defines the BOTTOM range limit of built-in functions, it determines which OLD functions should still be available.

For example, if you want to use new features, but still have some of the older global functions like ProcessClick or SetVoiceMode, then you should set:
Script API version: 3.4.0
Script compatibility: 3.2.1
and you will have a full range of functions which were vailable in versions 3.2.1 to 3.4.0.

The selection currently ranges from 3.2.1 to 3.4.0, but there is a chance older variants will be added later just in case. To get really old functions you still need to turn "Force object oriented scripting" off.

When you load older game into new Editor, the Script API Version will be set to maximum, but the Script Compatibility will be automatically set to the version your game previously used.

You may change those values any time, even if only in sake of experiment.


Specific changes since 3.4.0 (Beta 1):

- Added Script Compatibility Level switch to General Settings. For every compatible version a "SCRIPT_COMPAT_vXXX" macro is introduced to script.
- Fixed queued audio clips did not update their volume when default audio type volume changes. (a pretty old bug, met by AGD2)
- Game writes latest translation setting to config file on exit. In other words, if you change game language in game, it will be saved to config and used next time you run the game.


Oh, also, I finally updated Manual, but editing TeX source is not easy for me, so watch out for any mistakes there.

[Julius Dangerous]

Great Job! Thanks! ;-D;-D;-D;-D

[ThreeOhFour]

Just wanted to drop in and say that I'm using this build myself for the first time ever and custom resolutions and dynamic properties are a dream come true! Thank you very much sir, I'm very grateful for both of these additions!

[Crimson Wizard]

Just wanted to drop in and say that I'm using this build myself for the first time ever and custom resolutions and dynamic properties are a dream come true! Thank you very much sir, I'm very grateful for both of these additions!

Great to hear

[helpessfool]

First of all, I'd like to thank you and everyone else for their hard work. I've been really impressed with what I've been able to get done with Adventure Game Studio, especially considering I'm a rube with only HTML/CSS and rudimentary JavaScript experience (i.e., I don't really have a clue about actual coding). By searching this forum, I've been able to implement all sorts of stuff quickly. Without this place, I'd have been constantly  banging my head on the wall out of frustration, desperately trying to figure out this wonderful beast we call AGS.

Instead, I've got a decent hipster 8 bit adventure game coming along quite nicely.

This update has addressed two small issues I was having with 3.3.5, which was: #1) Very slight fuzziness when the game was stretched to run at full screen (barely noticeable, and the new resolution options have fixed that), and #2) Getting the dialog options to have the highlight color I wanted without changing how the default text looked in the display and Sierra-style speech GUIs.

Well, almost on #2: In my infinite idiocy, I can't figure out where to put game.dialog_options_highlight_color. As always, I'm sure I'm missing something obvious. So if you do have spare time to help this "helpessfool," I'd appreciate it. Thanks!

[Crimson Wizard]

I can't figure out where to put game.dialog_options_highlight_color. As always, I'm sure I'm missing something obvious.

If you want to have same highlight colour for the whole length of the game, then just put it to "game_start" function in your global script. "game_start" is a function meant for initializing all kinds of stuff before the game begins. For example:

Code: Adventure Game Studio

1. // in the GlobalScript.acs
2. function game_start()
3. {
4.   game.dialog_options_highlight_color = 10;
5. }
6.  

[helpessfool]

I'd tried that. It didn't work for me. So something funky must be going on over on my end. I noticed that I don't get yellow highlights by default anymore, either. It seems to be that pink gamma color (this was before I moved it over to the beta). I'm not really sure why. Who knows what I did to cause that .

Well anyway, I don't mean to turn this into a help thread. I appreciate it. I'll figure it out one way or another.

[Crimson Wizard]

OMG, I just found a terrible mistake in 3.4.0, it appears that when you dynamically change custom properties for Inventory and Characters in script, they are not cleaned up when saved game is loaded, and previous values may remain.

For example, if you have 3 custom properties for a character, and when running the game properties A and B values get modified and game is saved. Then property C gets modified, but player reloads old save. Properties A and B get the correct values from the saved game, but property C remain unchanged, keeping new value.

I will fix this ASAP, but I wonder if anyone has been using new SetProperty functions for characters and inventory items in their games yet. I would suggest they update their games as soon as this is fixed.

NOTE: this should NOT have any effect on existing saved games, only on game behavior.

[Crimson Wizard]

Hmm, ok, this error ^ is actually related only to loading saves from older version of the game which had less custom properties.

[Crimson Wizard]

An update on what I wrote in two posts above.
I tried to solve this issue with couple of quick fixes, but then realized that there is a fundamental flaw in how dynamic properties were implemented from the very beginning. I would not like to put all technical details here, but in short, there is currently no clear distinction for "original value" of entity's property, and no way to determine whether the property was changed anytime in the course of the game.
This is really not important for maybe 90% of cases, but it may cause serious problems in case of game's update. Like in game version 1 the character started with property "Money" = 100, and in game version 2 starting "Money" became 120. But if you load old save with "Money" = 100, how do you know if that is old starting value, that has to be automatically updated to 120, or value has already changed because of some game events?

I would need to revamp internal implementation of dynamic properties to make this work. I already have general idea, which should take mediocre amount of changes.
Again, it should not break any projects or even existing games and their saves, and it will not have any impact on scripts; it will just change the way engine works with properties internally, and have to make that work more correct.

Additionally this may open possibility to add "ResetToInitialValue" script command if such need arises, but won't do that right now anyway, maybe in some future update.

[Snarky]

This is really not important for maybe 90% of cases, but it may cause serious problems in case of game's update. Like in game version 1 the character started with property "Money" = 100, and in game version 2 starting "Money" became 120. But if you load old save with "Money" = 100, how do you know if that is old starting value, that has to be automatically updated to 120, or value has already changed because of some game events?

CW, I think this might be heading down the wrong path. Are you saying that in loading old saves, the game engine should automatically adjust custom property values that had not been touched from their old to their current starting value?

Why? Once it can be adjusted in-game, a custom property is essentially just a variable, right? So are you thinking to do the same for every other variable and property in AGS? That seems like a massive undertaking (you'd have to keep track of whether every single variable had ever been changed), and wrong in principle: a developer would have no reason to think that a variable initially set to some value and then left alone, and a variable set to some value, then to another value, and then back to the first value, would be treated different. And what if some script module "touches" a variable temporarily, in order to achieve some other effect? Suddenly it's no longer "original", but the main developer might not even be aware of that. This is simply something that should not matter.

I think the Money example you give is clearly something that should be handled by the developer in resolve_restored_game(). There's been some change in game logic between the saved game and the current version, and figuring out how to bring the save in sync with the new game logic requires a deep understanding of that logic and its in-game semantics – it's not something that can be done automatically.

For example, let's say that the game is Monkey Island 2, and that in early versions Guybrush starts off with 0 money, and that's how it stays in the first section of the game. Then in a later version this is changed so that he starts off with 1 million doubloons, but as soon as he walks into town he is robbed by Largo La Grande so that he again has 0 money. Now if you simply took an old save (from a point after the robbery), and the engine noticed that the default value of "Money" had changed from 0 to a million, and that in the original save it hadn't been touched, should it then change it to 1 million? Almost certainly not.

[Crimson Wizard]

EDIT: rewrote following post to make my thoughts more clear.

1.The issue with custom properties is that they are no like any other variable in the game (fortunately or not). They are rather constants that may (since 3.4.0) optionally become variables.
Custom properties were traditionally unmodifiable, and when game updated, they always took new values even if older save was loaded. Changing this behavior may have a big negative impact.

Like, for example, they are often used to keep item and object descriptions or reactions to player interaction. If a game developer fixes a typo in such description, in previous versions of AGS it will be updated even if older save is restored, but if I make all property values saved, older saves will keep unfixed ones.

We should add explanation to the manual, explaining this behavior.

EDIT: You may even think about it this way: as long as you do not change anything, there are custom constants. When you call SetProperty, you do not change existing property, but create new custom property that overrides the default constant.

Following this concept, in the future we may even let dynamically create absolutely new properties at runtime (because there is technically little restriction to that even now), or delete them at runtime; in case of deletion, entities will still keep design-time properties, as constants.



2. From the technical side, a problem currently is that the values that match initial ones are not saved during game play. This was done to save memory and disk space, because not every game has dynamic properties (actually it can be that none has yet).
This is more important for rooms, because as player travels through them, the amount of data game has to remember increases significantly.

In other words, this means that the properties that kept original values are already going to be updated with game update when you restore a save.

So, I need to either do what I planned to do, and at least make modified values distinctive to be saved by introducing explicit "unmodified/modified" states to them.
Or I would need to keep any property value in memory and on disk, significantly increasing memory requirements, even if the game does not need that (that means most of the games).



E: Regarding example with Guybrush, that could be solved rather easily by scripting "after restore" event and forcefully changing property to 0 if the player has already passed the robbery sequence. IMO that is easier to do than to script fixing all the properties that had to be updated with new game version.

[Snarky]

(Warning: while writing this post I thought of new things and reconsidered my opinion multiple times, forcing me to change what I'd written. Hopefully it makes some kind of sense.)

I just realized that conceptually there are three possible states for a custom property:

-There's the default value: the value a property is set to if not specifically initialized for a particular object.
-There's the initial value: the value of the property for a particular object set in the editor.
-There's the current value: whatever the value has been set to at runtime for a particular object, with SetProperty().

I'm not 100% clear on which ones you are saying don't get stored as part of the save game.

So, I need to either do what I planned to do, and at least make modified values distinctive to be saved by introducing explicit "unmodified/modified" states to them.
Or I would need to keep any property value in memory and on disk, significantly increasing memory requirements, even if the game does not need that (that means most of the games).

Well, we don't know that most properties  will never be changed; that depends entirely on how people use them. I can certainly believe that for most objects the custom property is just left to its default value, but I would think that in many cases where the custom property is actually set, it will be updated at runtime.

How do regular properties behave here, BTW? E.g. something like GUI.Y – if it's set in the editor and not modified in code, where will it appear if the value has been changed between the saved game and the current game version? What if it has been modified in code? The question is fundamentally tricky, I think: there is no one behavior that will always be "right".

Personally I therefore think the priority here is to make the behavior consistent (or, rather, systematic) across regular properties, regular variables/fields, readonly "constants", #define constants, Global Variables, and custom properties. To me, the most logical distinction is that only values that can't be updated in the script should be automatically set to what they're defined as in the latest game version. (Readonly "constants" should technically then update to the new values, but if that's hard to do, I feel that the difference in terminology provides an acceptable loophole.)

For properties, I think as a dev I would prefer to have a distinction between initialized and uninitialized ones: For objects where the property has not been initialized (either set in the editor or with SetProperty()), any change to the default value will apply to them. This makes sense because the default is a constant.

With the new SetProperty() API, I don't think the property values of specific objects can be considered constants any more. So I think they should always use whatever value they were set to, either in the editor or with SetProperty(). If this takes a bit more storage, well, that's the natural consequence of introducing more variables into the game, isn't it?

If you want to be able to keep the behavior where they take on new values from the game version, instead of this modified/unmodified distinction, how about a distinction between constant and variable properties? Constants can't be changed with SetProperty(), but will take on the value set in the new game version, while variables will retain whatever value they've been set to, whether or not they've been "modified" in the code. (The same distinction could be extended to Global Variables as well.)

[Crimson Wizard]

I just realized that conceptually there are three possible states for a custom property:

-There's the default value: the value a property is set to if not specifically initialized for a particular object.
-There's the initial value: the value of the property for a particular object set in the editor.
-There's the current value: whatever the value has been set to at runtime for a particular object, with SetProperty().

Yes, precisely.

I'm not 100% clear on which ones you are saying don't get stored as part of the save game.

Nor "default" nor "initial" values were ever stored to save game, and they are not now. Also, as of now, "current" value which is equal to property's "initial" value is not getting stored either. The latter is something I wanted to change, because this is bug prone situation.

How do regular properties behave here, BTW? E.g. something like GUI.Y – if it's set in the editor and not modified in code, where will it appear if the value has been changed between the saved game and the current game version?

The current rule regarding common (not custom) entity properties here is actually very simple: everything that CAN be changed at runtime goes to the saved game.

If you want to be able to keep the behavior where they take on new values from the game version, instead of this modified/unmodified distinction, how about a distinction between constant and variable properties? Constants can't be changed with SetProperty(), but will take on the value set in the new game version, while variables will retain whatever value they've been set to, whether or not they've been "modified" in the code. (The same distinction could be extended to Global Variables as well.)

This is something that I was thinking too, however, later I realized there can be a different approach, which I noted in my previous reply (not sure if very clearly).

My proposal is to distinct between variable and constant custom property not by some "type" or checkbox at design time, but by sole fact of user setting such property in script.
Or rather we can say that user creates variable properties in script by calling SetProperty, not changes the one created at design time.

Consider following, if we have a property called "MY PROPERTY", which is defined in project Schema, and also assigned certain value for particular entity, like character, then we have following values:

- Default game-wide property value;
- Constant character's property value - you can call it "custom constant", or "extender constant";

As soon as user calls SetProperty("MY PROPERTY", "new value") in script, a NEW property variable is created, which will OVERRIDE the constant. Since then we have three values:

- Property Default;
- Entity Constant;
- Entity Variable;

When calling GetProperty, engine checks existing values in backwards order - Variable -> Constant -> Default.

Only Variable property values are kept in saves.
We may also add "delete"/"reset" command that would remove variable property value and leave constant.

I think such system also fits well with potential feature of runtime creation of arbitrary properties. It's just that they won't have any defaults, just the value you gave them (something to discuss in future).

[Crimson Wizard]

Additionally to what I said above: I realize that such concept may be confusing at first, and the main issue (I think) here is that you can only do SetProperty for properties declared at design time, which looks like illogical restriction: since it was said that SetProperty creates variable property (of same name) instead of changing one set at design time, then why cannot we create property of completely different name?

I am currently in situation when I have to release a version which was in development for nearly 2 years, and although making absolutely free dynamic properties should not be too hard, it still requires some devising first, and I would not like to dive into that, delaying 3.4.0 release again.
What if I leave this dynamic property feature in the same state as I described above, and then we allow completely free (variable) dynamic property creation in the next update, hence making this feature finally completely logical?

[Snarky]

By all means leave all of this out of 3.4.0. The API for upgrading earlier saves still has a ways to go anyway, so it doesn't really matter too much exactly how it deals with custom properties. As long as you can check which game version a save comes from (so you can know what the values of the properties used to be), it should be possible to work around any unintended side-effects from any of the alternatives.

I do understand what you're proposing. I can't say I'm thrilled about it (it strikes me as unintuitive and unnecessarily complex from the game developer side), but I suppose in 99% of cases it won't matter to devs, since it'll just appear as a single property whichever underlying value you're actually accessing. You were talking about keeping modified/unmodified state: will there be a way for devs to check, or even check whether it's an unmodified instance value or the class-default value?

[Crimson Wizard]

You were talking about keeping modified/unmodified state: will there be a way for devs to check, or even check whether it's an unmodified instance value or the class-default value?

There is no way now, as for what will be, anything is possible, but I'd rather have another round of discussion about the whole concept first, seeing as my initial proposal seem confusing.

The internal changes I plan to do now may be later developed in any direction though, they do not close any path.

[Slasher]

Hi Crimson,

i am getting used to 3.4.0 (9) and think you have done a great job mate.

When do you think it will come off Beta?

cheers

[Crimson Wizard]

When do you think it will come off Beta?

If nothing happens, it will be promoted to "release candidate" on the first week of August.

[abstauber]

Here's also a bugfix release of the 9 verb template, which you might want to include.
http://shatten.sonores.de/wp-content/uploads/2016/07/9-verb-MI-style_152.zip