AGS 3.4.0 - RC2 (Release candidate)

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

Previous topic - Next topic

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.

SMF spam blocked by CleanTalk