AGS 3.4.0 - RC2 (Release candidate)

Started by Crimson Wizard, Sun 19/06/2016 23:27:16

Previous topic - Next topic

Crimson Wizard

AGS 3.4.0 (RC2) released







Released: 22th August 2016

Previous stable version: AGS 3.3.5 forum thread


A minute of attention for those who did not have a chance to check 3.4.0 during its development:
AGS 3.4.0 contains a big load of changes, which may take a while to explore. The following (read-only) topic is created to make getting used to it easier:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52499.0

Also, please, read "Upgrading to AGS 3.4" topic in the manual that comes with this version. It contains important information on most notable new features and few potential problems you may encounter when upgrading older projects.

Another important note on upgrading your project to latest 3.4.0 (read under spoiler):
Spoiler

AGS 3.4.0 now has a "Script API version" and "Script compatibility level" switches, which determine a range of built-in script functions you may use in your game (also called Script API).
"Script API Version" defines the TOP limit, or the latest version of scripting your game uses.
"Script compatibility level" defines the BOTTOM limit, or which OLD functions should still be available.

When you upgrade your game project from the older versions (3.3.* and lower), the Editor automatically sets "Script compatibility level" corresponding to the version of AGS this project was last saved in. This is done for backward compatibility. But you can change that anytime. Be prepared, however, that you may have to fix certain parts of your script. Usually necessary fixes are limited to renaming functions. Also, it is suggested to do "Rebuild all files" after you change any of those two switches.
[close]



What is new in 3.4.0

Common features:
- Added support for building game for multiple platforms (Windows and Linux options are maintained now).
- Added custom game resolutions.
- Added extended WFN font support (up to 256 characters).
- Made custom property values modifiable at runtime.
- Removed limit on custom properties number (was 30 properties per project), increased maximal property name and value length.
- Removed limit on GUI Control number (was 30 per GUI), increased maximal control name length.
- Removed limit on script modules number (was 50).
- Added Locked property to room Objects.
- Added Padding property for TextWindow GUI.

Editor features:
- New splash screen.
- Exposed Clickable property for room Objects in the Editor.
- Exposed TintLuminance property for room Regions in the Editor.
- Added "Close all tabs" command for the pane's context menu.
- Added Preferences option "Prompt dialog on closing multiple tabs".
- The sprite editor now highlights drop targets when you drag sprites around.

Editor Plugin API:
- Exposed GUI Panes to plugin API.

Engine features:
- Added support for any runtime display resolution (now restricted only by your system specifics).
- Added support for vertical sync in Direct3D rendering mode.
- Made engine try to use all implemented graphic renderers in the order of priority, if user selection failed to initialize.
- Rised default sprite cache limit for desktop platforms to 100 MB (was 20).
- Game writes latest translation and mouse speed setting to config file on exit.

Scripting features:
- Added managed user structs; although currently limited to containing only non-pointer variables in them.
- Added support for dynamic arrays in non-managed structs.
THERE ARE KNOWN ISSUES:
Spoiler

It was found that dynamic arrays in struct do not work when you make an array of those struct, for example:
Code: ags

struct MyStruct
{
    int dynamic_array[];
};

MyStruct single_object; // <--- this will work
MyStruct arr_of_structs[10]; // <--- this won't work

Such array caused troubles which were too complicated to fix in time, and require more time to investigate. A decision was made to block creation of arrays of structs, containing dynamic arrays. If you try to declare one in your script you will get an error. Hopefully this restriction will be raised in the future updates.
[close]
- Added support for dynamic array as return value of the struct's member function.
- Added support for static extender functions.
- Added "do..while" kind of loop, in addition to previously existing "while".
- Added "for" operator and related loop construct.
- Added "switch" and "case" operators and related branching construct.
- Added "break" and "continue" operators working in any loop or switch.
- Added missing compound assignment operators (*=, /=, and so on).
- Made preprocessor macros usable in definition of another macro.
- Added "#region" and "#endregion" preprocessor commands.

Script API:
- Added Script API version switch to the project's General Settings. For every supported API version a "SCRIPT_API_vXXX" macro is introduced, where XXX are version numbers.
- Added Script Compatibility Level switch to General Settings. For every compatible version a "SCRIPT_COMPAT_vXXX" macro is introduced.
- Added AudioChannel.Speed property.
- Added CharacterDirection enum and optional "direction" parameter for Character.ChangeRoom().
- Added Character.FaceDirection().
- Added Character.DestinationX and Character.DestinationY properties.
- Added RunActiveOption() and Update() member functions to the DialogOptionsRenderingInfo type.
- Extended Dialog Options API: added support for dialog_options_repexec() and dialog_options_key_press() functions to improve handling of the custom dialog options; added related compatibility project option and support for "NEW_DIALOGOPTS_API" macro in scripts.
- Added game.dialog_options_highlight_color variable.
- Added File.Seek() function and File.Position property.
- Added IsInteractionAvailable() method to Hotspot, Object and Character types.
- Added Game.AudioClipCount property and Game.AudioClips[n] array.
- Added Game.IsPluginLoaded().
- Added GUIControl.ZOrder property.
- Added GUI.Click() and Button.Click() functions which call OnClick event handler of corresponding GUI or button.
- Added GUI.ProcessClick() function that processes click on GUI only, similarily to how old ProcessClick processed click on room objects only.
- Added Mouse.Click() function to simulate mouse click on screen.
- Added Room.GetProperty() to substitute global GetRoomProperty().
- Added Room.ProcessClick() to substitute global ProcessClick().
- Added SetProperty() and SetTextProperty() functions to Room, InventoryItem, Hotspot, Object and Character types.
- Added optional "luminance" parameter to Region.Tint() and Region.TintLuminance readonly property.
- Added SetAmbientLightLevel() to set global light level for anything in the room.
- Added Character.SetLightLevel() and Object.SetLightLevel() functions to set individual light levels. Negative light levels can be used in 8-bit games to produce darkening effect.
- Added System.RuntimeInfo property which returns a short description of current graphics mode, scaling filter and enabled game resources.

Editor bug fixes:
- Fixed Undo history was deleted when an Editor panel changes its docked state.
- Fixed crashes under certain circumstances when a script editor is closed.
- Fixed crash if selecting a character without a normal view in the room editor.
- Fixed Ctrl+Tab did not work for the first time when cycling through opened editor tabs.
- Fixed "Go to Line..." command did not always move cursor to correct line. Also, do not select that line.
- Made the project completely rebuild itself whenever "Enable Debug Mode" value in the General Settings differs from the setting used for the last build, to prevent inconsistency in compiled scripts.
- Fixed a crash when trying to run game setup from the Editor while "Compiled" folder does not exist.
- Fixed project items could sometimes get incorrectly arranged inside the folder.
- Fixed writing faulty timestamps in project file on some occasions that could spoil usage of file versioning control.
- Fixed Help window positioning on multi-monitor desktop.
- Fixed error in autocomplete occuring when there is a single-line comment in the end of the script.
- Fixed incorrect compiler parsing of a static function call inside array index brackets.
- Fixed compilation of struct member functions having name identical to existing global function.
- Fixed compilation of structs having members with names identical to non-basic types, global variables and game entities (such as characters, GUI, etc).
- Corrected few error messages related to struct's function declaration.
- Fixed compiler reporting errors as "runtime errors" under certain circumstances.

Engine bug fixes:
- Fixed result of using transparency parameter of the DrawingSurface.DrawImage() in 32-bit games when drawing opaque sprites over surfaces with alpha channel.
- Fixed DynamicSprite.CopyTransparencyMask() was overwriting magic transparent pixels on destination with alpha values from mask.
- Fixed the speech portrait position was not adjusted for character walking between its lines, when BasedOnCharacterPosition portrait placement is used.
- Fixed occasional pathfinding failure on straight lines with complex walkable areas.
- Fixed using '[' special character in Display-like commands discarded all of the backslashes before it (e.g. "\\[" should now print \[ as expected).
- Fixed WAVE audio not looping after restoring a game
- Fixed a bug that caused MP3 clip continuously increase its base volume if the directional volume modifier was applied.
- Fixed queued audio clips did not update their volume when default audio type volume changes.

WinSetup:
- Added support for "default_translation_name" option in the "[language]" section of the config file.


TODO
- The Manual was updated, but needs a little rereading/testing.
- Some of the game templates should be properly updated, although they could be used with minor amount of manual fixes.
- Demo Game should be tested and probably upgraded to 3.4.0.



Mehrdad

Great!!!!
Nice job CW . Thanks for your hard works
My official site: http://www.pershaland.com/

Mehrdad

I have two computers as Win 10 and Win 8.1 . Win 10 is ok but on Win8.1 I have this error when I run game . (compiled to exe is OK too)
My graphic card is  nVidia GT220

Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x0059D5C0 ; program pointer is +379, ACI version 3.4.0.8, gtags (3,22)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and post the details on the AGS Technical Forum.
------------------------------------------

What can I do?
My official site: http://www.pershaland.com/

Crimson Wizard

#3
Quote from: Mehrdad on Mon 20/06/2016 12:18:46
What can I do?
Could you upload CrashInfo***.dmp? It should appear in your game's folder.
What graphic renderer are you using?
NOTE: this is somehow related to drawing GUI controls.

Mehrdad

#4
Quote from: Crimson Wizard on Mon 20/06/2016 12:25:29
Quote from: Mehrdad on Mon 20/06/2016 12:18:46
What can I do?
Could you upload CrashInfo***.dmp? It should appear in your game's folder.
What graphic renderer are you using?
NOTE: this is somehow related to drawing GUI controls.

Yes of course.Here you are:
https://www.dropbox.com/s/jnqofb9tsqrafe0/CrashInfo.3.4.0.8.dmp?dl=0
My resolution is 640X360 and run in the windows 1280X720 . Both have same massage.
My official site: http://www.pershaland.com/

Crimson Wizard

Did this start to occur after you updated to most recent 3.4.0 version (and which you had before?), or after you added something to your game?

Mehrdad

Quote from: Crimson Wizard on Mon 20/06/2016 12:54:00
Did this start to occur after you updated to most recent 3.4.0 version (and which you had before?), or after you added something to your game?
I used 3.4.0.7 and everything was OK.
My official site: http://www.pershaland.com/

Crimson Wizard

#7
The minimal crash dumps AGS is currently writing are of little help in this situation, for it gives too little information. I was thinking about changing this before...
As an experiment, here is a 3.4.0.8 compatible build that is supposed to write detailed information:
http://www.mediafire.com/download/vj05s0s08001ita/acwin-3.4.0.8--bigger-crashdump.zip

You need acwin.exe from this archive. Could you replace this in your latest AGS installation, rebuild and rerun your game, then upload new crash dump?
NOTE: the dump file is supposed to be significantly larger, although it is hard to predict how much larger, that depends both on the game, and how far in the game the crash occurs.

E: Hmm, I tested this on some "advanced" game, and I got 160 MB file... or 40 MB when archived.
I will have to try some variants to choose better settings for dump writing.
Of course it is not like games crash with unhandled exception every day so that could be a variant for exceptional cases (no pun intended).

Mehrdad

It's very strange... First time of run it works perfect. Even I compiled it and was successful .But second time of run I have this error:

Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x0059D0D0 ; program pointer is +379, ACI version 3.4.0.8, gtags (3,22)

CW . crash info is more than 120 MB now.Is it normal? I compress it with winrar and get 32MB . Did you really want it? Because my internet is very slow for upload
My official site: http://www.pershaland.com/

Crimson Wizard

#9
Quote from: Mehrdad on Mon 20/06/2016 15:31:30
CW . crash info is more than 120 MB now.Is it normal? I compress it with winrar and get 32MB . Did you really want it? Because my internet is very slow for upload
Sorry, better not for now, maybe I will find a better way to do this.
First I will research optimal settings for the dump.

E: The error sais: "gtags (3,22)". This means that error occurs when trying to draw GUI number 3, and control number with z-order of 22. I think it is Inventory Window (from the dump contents). Also, the crash is somehow related to drawing translucent sprite (with alpha channel probably?)
Hopefully this will define area to search what is going on.

Mehrdad

Quote from: Crimson Wizard on Mon 20/06/2016 15:33:58
Quote from: Mehrdad on Mon 20/06/2016 15:31:30
CW . crash info is more than 120 MB now.Is it normal? I compress it with winrar and get 32MB . Did you really want it? Because my internet is very slow for upload
Sorry, better not for now, maybe I will find a better way to do this.
First I will research optimal settings for the dump.

E: The error sais: "gtags (3,22)". This means that error occurs when trying to draw GUI number 3, and control number with z-order of 22. I think it is Inventory Window (from the dump contents). Also, the crash is somehow related to drawing translucent sprite (with alpha channel probably?)
Hopefully this will define area to search what is going on.

OK. Problem solved.Thanks so much CW for guide . I had a ZOrder = 1 for GUI 8 in global script.This Gui is fade to transparent as you said right . I removed it and it works perfect now. But why it wasn't this error in previous versions?  And why it works in my another computer with different graphic card and Win 10?
My official site: http://www.pershaland.com/

Crimson Wizard

Quote from: Mehrdad on Mon 20/06/2016 16:06:57
OK. Problem solved.Thanks so much CW for guide . I had a ZOrder = 1 for GUI 8 in global script.This Gui is fade to transparent as you said right . I removed it and it works perfect now. But why it wasn't this error in previous versions?  And why it works in my another computer with different graphic card and Win 10?

Hmm... either I interpret these GUI numbers wrong, or the crash cause was complicated, so it happened because of one GUI, but the actual error occured when another got to be drawn.

Anyway, this is impossible to answer on these questions without some kind of test setup. Can you give some information on what was drawn on screen and how that fading GUI was configured?
Like, was it only GUI on screen, were there any controls on that GUI, and so on?
How easily this error can be reproduced - will it return if you put GUI 8 back?

Mehrdad

Quote from: Crimson Wizard on Mon 20/06/2016 16:14:20
Quote from: Mehrdad on Mon 20/06/2016 16:06:57
OK. Problem solved.Thanks so much CW for guide . I had a ZOrder = 1 for GUI 8 in global script.This Gui is fade to transparent as you said right . I removed it and it works perfect now. But why it wasn't this error in previous versions?  And why it works in my another computer with different graphic card and Win 10?

Hmm... either I interpret these GUI numbers wrong, or the crash cause was complicated, so it happened because of one GUI, but the actual error occured when another got to be drawn.

Anyway, this is impossible to answer on these questions without some kind of test setup. Can you give some information on what was drawn on screen and how that fading GUI was configured?
Like, was it only GUI on screen, were there any controls on that GUI, and so on?
How easily this error can be reproduced - will it return if you put GUI 8 back?

Yes sure . It's a complete black GUI for deactivate control game and it appear with fade in as below code.BackP is name of GUI (GUI 8)

Code: ags
function Button4_OnClick(GUIControl *control, MouseButton button)
{

    BackP.ZOrder =1;
    BackP.Visible = true;  
    BackP.Transparency = 55;
    Wait(1);
    BackP.Transparency = 45;
    Wait(1);
    BackP.Transparency = 40;
    Wait(1);
    BackP.Transparency = 35;
    Wait(1);
    BackP.Transparency = 30;
    Wait(1);
    BackP.Transparency = 25;
    Wait(1);
    BackP.Transparency = 20;
    Wait(1);
    BackP.Transparency = 15;
    Wait(1);
    BackP.Transparency = 10;
    Wait(1);
    BackP.Transparency = 5;
    Wait(1);
    BackP.Transparency = 0;
    Wait(1);
    BackP.Visible = false;
    QuitGame(0);
}

 
My official site: http://www.pershaland.com/

Crimson Wizard

I have a weird feeling of deja vu now, like I've seen very similar error a while ago... I will try to create a small test game that does this.

Still, can you elaborate, are there any other GUIs on screen, behind that fading GUI?

Mehrdad

Quote from: Crimson Wizard on Mon 20/06/2016 16:34:30
Still, can you elaborate, are there any other GUIs on screen, behind that fading GUI?

Yes. This button (button 4 in up code) is "yes" for quit game . When appear quit game I have a quit GUI (GUI 9) with 2 button : yes and no. This GUI is complete over screen . In back I have BlackP GUI that I said and it goto fade to black for deactivate control game. 
My official site: http://www.pershaland.com/

Crimson Wizard

Quote from: Mehrdad on Mon 20/06/2016 16:49:02
Quote from: Crimson Wizard on Mon 20/06/2016 16:34:30
Still, can you elaborate, are there any other GUIs on screen, behind that fading GUI?

Yes. This button (button 4 in up code) is "yes" for quit game . When appear quit game I have a quit GUI (GUI 9) with 2 button : yes and no. This GUI is complete over screen . In back I have BlackP GUI that I said and it goto fade to black for deactivate control game. 

I cannot reproduce this problem with the primitive test that does just what you described above (and uses that script). There might be something more to what is causing it.
Could you for, example, comment all that script and then start uncommenting line after line to see at which point it crashes?

Mehrdad

Quote from: Crimson Wizard on Mon 20/06/2016 18:10:35
Quote from: Mehrdad on Mon 20/06/2016 16:49:02
Quote from: Crimson Wizard on Mon 20/06/2016 16:34:30
Still, can you elaborate, are there any other GUIs on screen, behind that fading GUI?

Yes. This button (button 4 in up code) is "yes" for quit game . When appear quit game I have a quit GUI (GUI 9) with 2 button : yes and no. This GUI is complete over screen . In back I have BlackP GUI that I said and it goto fade to black for deactivate control game. 

I cannot reproduce this problem with the primitive test that does just what you described above (and uses that script). There might be something more to what is causing it.
Could you for, example, comment all that script and then start uncommenting line after line to see at which point it crashes?
Problem is in line 4:
BackP.ZOrder =1;
I tested another lines. Wasn't any problem. When I remove this line isn't any crash.
My official site: http://www.pershaland.com/

Mehrdad

I tested many parameters yesterday and today too .I disabled transparency parameters without ZOrder and works fine too .I guess problem is relative to graphic card . My older computer have GT220 and didn't update anymore (I tried it today). My newer computer haven't problem.
CW . Did you had any main change for graphic play in 3.4.0.8 ? 
My official site: http://www.pershaland.com/

Crimson Wizard

#18
Quote from: Mehrdad on Tue 21/06/2016 12:32:52Did you had any main change for graphic play in 3.4.0.8 ? 
The thing is that I have not...
The changes since 3.4.0.7 are listed here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=53510.msg636537977#msg636537977

Unless it has something to do with sprite cache defaults... which is a random thought, but you may try lowering it down to 20 MB in setup and seeing if that changes anything.

Crimson Wizard

Uploaded Linux build package for this version: https://github.com/adventuregamestudio/ags/releases/download/v.3.4.0.8/AGS.3.4.0.8.Editor.Linux.Pack.zip
(Unpack and put "Linux" folder to where you installed AGS Editor)

Crimson Wizard

#20
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

___________________________________________________________

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

Quote from: ThreeOhFour on Thu 14/07/2016 10:40:45
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 :D

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

Quote from: helpessfool on Mon 25/07/2016 20:19:15
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: ags

// in the GlobalScript.acs
function game_start()
{
  game.dialog_options_highlight_color = 10;
}

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 (laugh).

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

#27
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. :-X 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

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

Crimson Wizard

#29
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

Quote from: Crimson Wizard on Sat 30/07/2016 00:04:07
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

#31
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.

Quote from: Crimson Wizard on Sat 30/07/2016 13:41:25So, 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

#33
Quote from: Snarky on Sat 30/07/2016 17:06:51
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.

Quote from: Snarky on Sat 30/07/2016 17:06:51
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.

Quote from: Snarky on Sat 30/07/2016 17:06:51
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.


Quote from: Snarky on Sat 30/07/2016 17:06:51
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

#36
Quote from: Snarky on Sun 31/07/2016 15:38:57You 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

Quote from: slasher on Sun 31/07/2016 22:03:26
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


Crimson Wizard

#40
Uploaded Release Candidate 1. This was really just a bug fixing update. If no serious issues are found in a short while (a week?) it will be promoted to final release.
Download links updated in the first post.

Notable fixes since 3.4.0 - Beta 2:

- Fixed character and inventory custom properties were not reset to game defaults when loading save made by older version of the game which had less custom properties.
- A user found out that dynamic arrays in struct do not work when you make an array of those struct, for example:
Code: ags

struct MyStruct
{
    int dynamic_array[];
};

MyStruct single_object; // <--- this will work
MyStruct arr_of_structs[10]; // <--- this won't work

Such array caused troubles which are too complicated for a quick fix, and require more time to investigate. A decision was made to block creation of arrays of structs, containing dynamic arrays. If you try to declare one in your script you will get an error. Hopefully this restriction will be raised in the next update.

- Fixed number of mistakes in newest manual version.


Also updated 9-verb template to 1.5.2 as suggested by abstauber. He will take full responsibility if it won't work. Bahaha.

Kumpel

Hi there,

sweet new version!

I have no idea if it is a bug, but I think the voice acting script wizard isn't finding all the lines. It doesn't seem to cover any of the separated dialog scripts? Is that intended or a known problem?

Cheers
Kumpel

Crimson Wizard

#42
Quote from: Kumpel on Fri 05/08/2016 20:30:00
I have no idea if it is a bug, but I think the voice acting script wizard isn't finding all the lines. It doesn't seem to cover any of the separated dialog scripts? Is that intended or a known problem?
By "separated dialog script" you mean common dialog scripts, or something different?
I honestly do not know anything about voice acting wizard, and I cannot even think of anything we changed that would be relevant.
Would you be able to test how that worked in older versions?
Also, if this is an actual bug, I would need some kind of test case, like a small dummy project, that lets you observe the issue.

Kumpel

Yeah, I mean the common dialog scripts. My game is created with this newest version and using it's cool features pretty heavily. I can only tell you, that the 3.4.0.7 I used before couldn't even do a proper voice acting script. it just did an, besides the title and header, empty text file. So considering that, I do believe you guys did something from 3.4.0.7. to 3.4.0.10 that improved the wizard. ;)
Older version won't work with my game so I don't think, I can test it on them. But I could do a new project with one dialog script that is backwards compatible and check it out, if you want.

Another game I am doing with the older version 3.3.5. is having a different problem when trying to use the voice acting script wizard (). I have to figure that one out first (maybe I will open a thread for that in the next time, but actually I don't need a script there)

Crimson Wizard

Quote from: Kumpel on Fri 05/08/2016 23:04:39
Older version won't work with my game so I don't think, I can test it on them. But I could do a new project with one dialog script that is backwards compatible and check it out, if you want.
Yes, please.

Regarding "improvements", only thing that comes to mind is that the game building process changed (with multi-platform deployment support). If I just learn how to create voice scripts, I will compare how AGS 3.3 and AGS 3.4 do that (and possibly 3.2.1 too to be sure).

Cassiebsg

Uhm... I created voice script with no problem for my game (3.4.0.6). At least, I think it had no problem. All the lines seemed to be there.
There are those who believe that life here began out there...

Kumpel

Okay. I found the problem. First thing is, I didn't understand the important connection of auto-numbering speech lines and creating the voice acting script. But after testing the feature in an older version and getting another empty script, I got behind the order of things to do.

Now I remembered: The auto-numbering crashed AGS yesterday so I shut down the computer and went to bed. Today I didn't remember that happening and tried to do the script nevertheless. That's why it wasn't complete. While doing the auto-numbering once more it crashed again. After an AGS restart it finally did a full renumbering and after that I could create a complete voice acting script.

So the only problem still exisiting is the auto numbering occasionally crashing in both version 3.4.0.7. and 3.4.0.10. I guess it's always happening while trying to number the dialogs (right after the window telling me something like it's updating the last room of the game).

AGD2

Quote from: AGD2We just came across another bug in AGS 3.4.

The Lightlevel on tints is automatically setting wrong values in the editor Room Settings field for TintLuminence. It auto-sets values >100 and both positive and negative, values that I have not set up myself.

It also returns different values to the ones I've actually set in the editor, in-game.


Quote from: Crimson WizardRegarding your question, that is documented that Region.LightLevel has different value range in the Editor, than in Engine, because of some compatibility reasons. This was like that since very old versions of AGS.
If that matches your issue, then it is not a bug, but enforced behavior (although I believe may be annoying), that should be kept in mind. Otherwise, I need some practical example of what you do and what you get - with exact numbers.

Speaking further about this, we may probably find a way to change this in future version.

I try and get the value of a region and get erratic values, even if, in the editor, they are set properly.

I set one to 100 in the editor, but in the game it was portrayed as 175 or 437 and I need to know the values to be able to custom tint my characters adequately.

We have the project history committed on GIT (well, Bitbucket), and I was able to track down the commit where the TintLuminence got changed. Nobody manually edited the values. AGS just seemed to adjust them by itself, after some changes were committed and pushed. After the game was recompiled, the values had adjusted to negative values (-8372) by themselves.

Crimson Wizard

#48
Quote from: AGD2 on Sun 07/08/2016 20:43:37
I set one to 100 in the editor, but in the game it was portrayed as 175 or 437 and I need to know the values to be able to custom tint my characters adequately.

We have the project history committed on GIT (well, Bitbucket), and I was able to track down the commit where the TintLuminence got changed. Nobody manually edited the values. AGS just seemed to adjust them by itself, after some changes were committed and pushed. After the game was recompiled, the values had adjusted to negative values (-8372) by themselves.
Alright, I see this is something different.
I need to clarify: you set region's TintLuminance, and do not touch LightLevel? Because I was confused by your first phrase in the message.
So basically, you set TintLuminance to certain value, and after game is recompiled that value gets changed - in the region properties?
Also, you read region's LightLevel in the script (at runtime) and get some random value too.

Actually, since rooms are not saved in XML, but compiled to binary file all time, and then loaded back when you open them in the editor, I believe this narrows down to how room binary data is saved or loaded.

E: By the way, how do you get the TintLuminance during the game? I noticed there is no property exposed for that in script. Which looks like an oversight. Did you use Region.LightLevel by a chance? I think it does not return proper value in that case.

Crimson Wizard

#49
I found few issues related to setting Region's TintLuminance.
Most simple way to observe the problem is this:
1. Select Region in the editor and set UseColorTint = true with some TintLuminance value.
2. Save room, then reopen room. UseColorTint will be = false, and LightLevel is set to some seemingly arbitrary value instead.
EDIT: Hmm... I just realized this happens if you don't set TintSaturation, when it is 0, tint becomes cancelled. I am not sure this is how it worked before.

Actual issues:
1. LightLevel/TintLuminance value breaks when you reopen room. This occurs when you open room in the editor, because if you just set it once and save, in game they seem to work properly in general.
2. Glitched detection of whether light level or tint is set for the region (so far in Editor, I think engine works well in this aspect, but this needs more testing).
3. There is no Region.TintLuminance property in the script, to complement other readonly Tint* properties.
4. Region.LightLevel property returns meaningless values if colored tint is set (it should probably return default light level - 0).
5. Region.TintSaturation property returns light level instead of actual saturation, both in Light and Tint modes (this is remains of older implementation that I did not change when adding TintLuminance in this version).

EDIT:
6. In previous versions when you set ColourTint on, Saturation is 50 by default, but now it is 0 by default... which makes it easy to forget set it to something.

EDIT2:
Supposedly fixed version for test:
http://teamcity.bigbluecup.org/repository/download/AdventureGameStudio_Release/13066:id/AGS-3.4.0-RC1.zip

Crimson Wizard

Quote from: Kumpel on Sat 06/08/2016 01:24:22
Now I remembered: The auto-numbering crashed AGS yesterday so I shut down the computer and went to bed. Today I didn't remember that happening and tried to do the script nevertheless. That's why it wasn't complete. While doing the auto-numbering once more it crashed again. After an AGS restart it finally did a full renumbering and after that I could create a complete voice acting script.

So the only problem still exisiting is the auto numbering occasionally crashing in both version 3.4.0.7. and 3.4.0.10. I guess it's always happening while trying to number the dialogs (right after the window telling me something like it's updating the last room of the game).

I ran autonumbering on couple of projects I had without a crash. Could you give more details of how this happening to you? You said this always happens when it numbers lines in dialogs; are those specific dialogs (if you can tell)? Could you try to make a copy of your project and delete dialogs one by one, testing if crash still occurs, to find which dialogs causing this?

As a last resort, if you could PM me your project I would test run it under debugger.

AGD2

Quote from: Crimson Wizard on Mon 08/08/2016 17:45:14
I found few issues related to setting Region's TintLuminance.
Most simple way to observe the problem is this:
1. Select Region in the editor and set UseColorTint = true with some TintLuminance value.
2. Save room, then reopen room. UseColorTint will be = false, and LightLevel is set to some seemingly arbitrary value instead.
EDIT: Hmm... I just realized this happens if you don't set TintSaturation, when it is 0, tint becomes cancelled. I am not sure this is how it worked before.

Actual issues:
1. LightLevel/TintLuminance value breaks when you reopen room. This occurs when you open room in the editor, because if you just set it once and save, in game they seem to work properly in general.
2. Glitched detection of whether light level or tint is set for the region (so far in Editor, I think engine works well in this aspect, but this needs more testing).
3. There is no Region.TintLuminance property in the script, to complement other readonly Tint* properties.
4. Region.LightLevel property returns meaningless values if colored tint is set (it should probably return default light level - 0).
5. Region.TintSaturation property returns light level instead of actual saturation, both in Light and Tint modes (this is remains of older implementation that I did not change when adding TintLuminance in this version).

EDIT:
6. In previous versions when you set ColourTint on, Saturation is 50 by default, but now it is 0 by default... which makes it easy to forget set it to something.

EDIT2:
Supposedly fixed version for test:
http://teamcity.bigbluecup.org/repository/download/AdventureGameStudio_Release/13066:id/AGS-3.4.0-RC1.zip

Spent some time with this, trying to see if I could get the same tinting glitches to surface, and have not been able to. Seems to be fixed now, thanks CW!  I'll keep an eye on it and let you know if I notice anything amiss.

monkey0506

Did a cursory glance over the posts here and didn't see this reported, sorry if I overlooked it.

Sprite 2008 in the "Default" template seems to have been changed or improperly imported as its magenta background is not being removed. To reproduce:  create a new game with "Default" template, run game and walk down. The other player sprites seem fine.

Crimson Wizard

#53
Quote from: monkey0506 on Sun 14/08/2016 08:26:08
Did a cursory glance over the posts here and didn't see this reported, sorry if I overlooked it.

Sprite 2008 in the "Default" template seems to have been changed or improperly imported as its magenta background is not being removed. To reproduce:  create a new game with "Default" template, run game and walk down. The other player sprites seem fine.
No, I never heard about it before. I recall I am using 32-bit version of Default template since 3.3.5 (and in 3.4.0) now, so some things could be changed wrongly. It is just strange that no one reported yet. I am going to check this out.

BTW, for information, you may do pull requests to default template source as well now:
https://github.com/adventuregamestudio/ags-template-source

KyriakosCH

Thanks for your work :)

By the way, would it be a good idea (or not) to use this version already so as to build the engine for my game? Or should i wait until it is the official one (ie is it stable enough to safely create a game for both win and linux?)

This is the Way - A dark allegory. My Twitter!  My Youtube!

Crimson Wizard

#55
Quote from: KyriakosCH on Wed 17/08/2016 20:41:10
By the way, would it be a good idea (or not) to use this version already so as to build the engine for my game? Or should i wait until it is the official one (ie is it stable enough to safely create a game for both win and linux?)

Numerous developers used even earlier Alpha and Beta versions of 3.4.0 to release their games. Current one is much more stable than that.
There are couple of known issues (they are already fixed and new release is under preparation), but they are not game-breaking and related to only specific conditions.
I could say that 3.4.0 is not more un-safe than any of the previous official versions. :)


Crimson Wizard

Uploaded Release Candidate 2. All the new links are in the first post.

Changes since 3.4.0 - RC1:

- Fixed a number of mistakes around Region.Tint and Region.LightLevel introduced during 3.4.0 development.
- Added all fixes from recent AGS 3.3.5 Patches (5 & 6).
- Linux build component is now included into installer (as an optional item)! This means that it can be installed with AGS Editor, and will be uninstalled when you remove program using standart Windows means.

Mehrdad

Thanks CW for new release candidate . It works PERFECT and I haven't that error anymore . Thanks so much for your hard works ;)
My official site: http://www.pershaland.com/

Crimson Wizard

Same as with most recent 3.3.5 patch, 3.4.0 RC2 has got just reuploaded with another old bug fixed.

AGD2

When I try to compile Al Emmo's source code in v3.4.0, it's giving me a bunch of errors like this:

Non-numeric phoneme offset ' (which is then followed by a square symbol)   File syncdata.dat

I've never experienced this compile error before in previous AGS editor versions when using the same set of speech files and phonemes setup.

Gurok

#61
You say you haven't experienced this in previous AGS editor versions. Can you confirm that you've successfully compiled it with 3.3.4 or 3.3.5?
[img]http://7d4iqnx.gif;rWRLUuw.gi

AGD2

Really strange. I just tried compiling it with both v3.3.5 and v3.3.4.2 and got the same error in both of those, too.

The game was compiled with v3.3.4 and I didn't encounter the error at any point in the past. (BTW, the game only uses .pam Pamela files and no .dat Papagayo files in the speech.vox file).

Gurok

#63
Are you sure it's not this issue, AGD2?
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52398.msg636517153#msg636517153

Can you please check for a syncdata.dat file in the speech folder?

According to CW's post, you should be able to remove it. The only syncdata.dat file required is generated each time the game is compiled and placed in the project's root.
[img]http://7d4iqnx.gif;rWRLUuw.gi

AGD2

#64
Ah, yeah, that was it... again! Thanks.

Perhaps AGS could automatically delete the syncdata.dat file if it exists in the speech folder, rather than trying to parse it as a papagayo .dat file.

--EDIT--

Another issue I've noticed with v3.4.0 compiled games when running them at full-screen is that when they get closed down with ALT+X, the game remains on the taskbar and an artifact window (just a blank white screen) is left behind. Clicking on the taskbar icon maximizes the white window and a Windows dialogue box appears with a green progress bar and a spinning circle icon. It says "[Game Name] has stopped working. WIndows is checking for a solution to the problem..."

After that disappears, another identical window appears and does the same thing. Then it says "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."

This is with Windows 10, but I also noticed it with Windows 7 and v3.4.0.

Gurok

#65
I think we could potentially ignore the syncdata.dat file if it's in the Speech subdirectory, but my question is, how is it ending up there? If it's nothing that the editor does, I think the current behaviour is correct. It's telling you there's a problem with that file.

I have my own bug to report.

I am unable to build my game with anything after 3.4.0.9 or so. I'm using Calin Leafshade's sprite font plugin. The error I get is "unable to resolve import for SetSpacing" (one of the functions provided by the sprite font plugin).

At this commit (Manual: various corrections related to recent update), my game builds:
83a1153cd8317703edbaa14ff540829b069b5f7a

At this commit (Merge pull request #337 from sonneveld/xcode-build), it fails:
e1a8adde7d202758889ccb2446f65892e04bbf81

Between the pull request 337 merge and the manual corrections, there was a merge from master. It's something that happened in those two big merges, but I don't know where to begin looking. Sorry I haven't been able to narrow it down further.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Quote from: Gurok on Sat 03/09/2016 13:33:30
I am unable to build my game with anything after 3.4.0.9 or so. I'm using Calin Leafshade's sprite font plugin. The error I get is "unable to resolve import for SetSpacing" (one of the functions provided by the sprite font plugin).
Where do you get this plugin exactly, and are you using compiled binary or compiled it yourself?

Gurok

#67
Quote from: Crimson Wizard on Sat 03/09/2016 14:41:03
Quote from: Gurok on Sat 03/09/2016 13:33:30
I am unable to build my game with anything after 3.4.0.9 or so. I'm using Calin Leafshade's sprite font plugin. The error I get is "unable to resolve import for SetSpacing" (one of the functions provided by the sprite font plugin).
Where do you get this plugin exactly, and are you using compiled binary or compiled it yourself?

I'm using a DLL I found in the sprite font thread. I've uploaded a copy for you:
http://goo.gl/5xo2v7

I was using the precompiled 3.4.0.9 from this thread (downloaded a while ago).
I upgraded to the precompiled 3.4.0.11 and noticed the problem.
I did not make a backup of 3.4.0.9 :(. I couldn't find a link to the official 3.4.0.9 in the thread, so decided to switch to an old Git revision and build 3.4.0.9 again from source.
I built and rebuilt repeatedly and found that 83a1... worked and e1a8... did not.
The problem should be present with a fresh copy of 3.4.0.11. That's where I noticed it first.
A minimal test case would probably be:

Code: ags
function game_start()
{
    SetSpacing(1, 2);
}


I can give you my project files too, if you need them.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

I actually wondered, whether you are building plugin for source. We have this plugin sources in our repository, and also there is Calin's repository:
https://github.com/calinleafshade/ags-spritefont



Regarding syncdata.dat, I thought there was already a fix regarding that?

dbuske

I found that when I create an object the icon for creation does not become visible.
Thus I cannot create an object. No way to choose a picture.
What if your blessings come through raindrops
What if your healing comes through tears...

Crimson Wizard

#70
Quote from: dbuske on Mon 05/09/2016 13:43:59
I found that when I create an object the icon for creation does not become visible.
Thus I cannot create an object. No way to choose a picture.
I was trying to guess what you mean, and the only thing I can think of is that sprite 0 in your project is replaced with empty graphic (or you are using Empty Template) instead of default blue cup sprite.
If this is the case, you could either import any graphic you want to be default in place of sprite 0.
Also you may choose the object for editing in the drop-down list on top of the Properties Panel. After you selected object that way, simply change its Image to something else.

Crimson Wizard

#71
@Gurok I found what's wrong with sprite font plugin. AGS does not remove ".dll" part of plugin name now, but anything after first ".". Since plugin file is called "agsplugin.spritefont.dll" it's name gets converted to "agsplugin" and therefore never loaded.
This should be changed back, because Editor always saves plugin names with ".dll" only.

soulcypher

If I start the project in AGS 3.4.0 - RC2, will it be compatible with full release?

Crimson Wizard

Quote from: soulcypher on Mon 05/09/2016 20:00:00
If I start the project in AGS 3.4.0 - RC2, will it be compatible with full release?
Yes, we keep full compatibility with betas and release candidates.

Gurok

Quote from: Crimson Wizard on Mon 05/09/2016 16:44:56
@Gurok I found what's wrong with sprite font plugin. AGS does not remove ".dll" part of plugin name now, but anything after first ".". Since plugin file is called "agsplugin.spritefont.dll" it's name gets converted to "agsplugin" and therefore never loaded.
This should be changed back, because Editor always saves plugin names with ".dll" only.

Hi CW,

I'm sorry I haven't replied till now. I was tied up with work stuff for the past few days.

Thanks for the work in narrowing down the problem. Now that I know where to look, I might be able to have a go at patching it on the weekend (if you haven't already looked at it).

Regarding the syncdata.dat thing, I think the editor is now behaving correctly -- no crash, appropriate error message. It's just weird how that file keeps ending up in the Speech subdirectory for AGD2.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Quote from: Gurok on Wed 07/09/2016 04:14:26
Thanks for the work in narrowing down the problem. Now that I know where to look, I might be able to have a go at patching it on the weekend (if you haven't already looked at it).
I've already fixed that, in 3.3.5 branch though, since it is where this bug was first introduced.
https://github.com/adventuregamestudio/ags/commit/8a97e84d7537af6798efdf56aff65506172ef3d8

I am currently awaiting results of certain test before making new 3.3.5 patch, after which I will merge 3.3.5 to 3.4.0 again, and hopefully this is where we can make a final 3.4.0 release (and start to make patches to it instead *irony*).


Quote from: Gurok on Wed 07/09/2016 04:14:26
Regarding the syncdata.dat thing, I think the editor is now behaving correctly -- no crash, appropriate error message. It's just weird how that file keeps ending up in the Speech subdirectory for AGD2.
Hmm, I did not remember what solution we made into AGS that time. Perhaps this need a further enhancement at some point, because it is strange that editor takes any random file with *.dat extension and attempts to treat it as a lipsync data.

AGD2

It's probably just that I had deleted it from my local directory, but that it had already been committed to git in the Speech folder, and it kept getting pulled back into my local copy. That's my guess anyway.

Crimson Wizard

Quote from: AGD2 on Thu 08/09/2016 23:46:32
It's probably just that I had deleted it from my local directory, but that it had already been committed to git in the Speech folder, and it kept getting pulled back into my local copy. That's my guess anyway.
That may be easy to check: if you delete it in local copy, git should suggest you commit the deletion of this file, which would mark it as deleted in remote repository too.

Crimson Wizard

Quote from: AGD2 on Sat 03/09/2016 13:21:29
Another issue I've noticed with v3.4.0 compiled games when running them at full-screen is that when they get closed down with ALT+X, the game remains on the taskbar and an artifact window (just a blank white screen) is left behind. Clicking on the taskbar icon maximizes the white window and a Windows dialogue box appears with a green progress bar and a spinning circle icon. It says "[Game Name] has stopped working. WIndows is checking for a solution to the problem..."

After that disappears, another identical window appears and does the same thing. Then it says "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."

This is with Windows 10, but I also noticed it with Windows 7 and v3.4.0.


I tested this out and my observations are that the window remains at background only when game is run in Direct3D mode, not in DirectDraw5 mode. Can you confirm that same occurs to you?
Also, I do not have any crashes, it just hangs there until I switch to it in any way, and after that it terminates.

AGD2

QuoteThat may be easy to check: if you delete it in local copy, git should suggest you commit the deletion of this file, which would mark it as deleted in remote repository too.

I've done just that. Someone else on another branch might have also had it still in their branch and perhaps it got back in via a merge. At any rate, I've also set it to be ignored in the .gitignore file. So, we'll see if it comes back or not.

QuoteI tested this out and my observations are that the window remains at background only when game is run in Direct3D mode, not in DirectDraw5 mode. Can you confirm that same occurs to you?

Yes, I have confirmed that it only happens with Direct3D mode too. In DirectDraw5 mode, it pops up with the "Game Aborted" Windows dialog box.

QuoteAlso, I do not have any crashes, it just hangs there until I switch to it in any way, and after that it terminates.

For me, the window hangs there in the taskbar, until I click it, then it maximizes (as a black screen) and shows the "Program Has Stoped Working" dialog box with a green bar searching for a solution.

Here's a video showing the crash. For some reason, you can't see the game screen (shows as white), but you can hear the moment I pressed ALT+X with the Windows 'ding' sound, and see the subsquent hung window on the taskbar and error messages.

Crimson Wizard

Quote from: AGD2 on Wed 14/09/2016 16:36:57
For me, the window hangs there in the taskbar, until I click it, then it maximizes (as a black screen) and shows the "Program Has Stoped Working" dialog box with a green bar searching for a solution.

Here is the build which fixed that hanging window for me, could you check this out?
http://www.mediafire.com/download/zxyqx5tb9s7md3h/acwin-3.4.0--game-quit-fix.zip

AGD2

Yeah, I can confirm that fixes it on my side, too. Well done!

Crimson Wizard

Ok, that was a nasty regression due to part of program being rewritten.

I think we can release a final build now.

SMF spam blocked by CleanTalk