AGS 3.3.0 Release Candidate

[Calin Leafshade]

Speaking of array ranges, it would be really useful to be able to get an array length at runtime.

Ideally arrays would be objects like in C# but some kind of C-like function would be fine too.

Code: ags

int len = ArrayLength(myArray);

[monkey0506]

From the standpoint of the AGS compiler I think that adding array.Length would be easier than allowing the C-style function, because the function would have to accept arrays of any type, and the compiler doesn't allow overloaded or generic functions.

[gargin]

There appears to be a quirk in the new script grouping system. When double clicking to expand the group, a script file often opens in response. At first, I thought this was a feature as the script that opens is often the main script file for that group. I noticed that this happens even if I expand other groups (rooms list) and the mouse lands over a script file.

This is a minor inconvenience, but it does require you to continuously close script files. Just wanted to bring it to your attention.

Another really small thing I have noticed. When using the hotkeys to switch hotspot drawing tools the cursor doesn't update until moved.

[AGD2]

Here's a fairly severe editor bug in the 3.3.0. It regards the feature mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?issue=340.0

If you drag-and-drop any dialog topic to change the order, and then compile and run the game, when clicked in-game, every topic option will point to completely unrelated topics' options in different trees. In addition, if you double-click on one of the dialog topics you dragged to a new position, the dialog script opens, but the font will look entirely different; it will appear smaller (plain arial) and without any of the color-coded formatting that the editor normally adds to scripts.

[Crimson Wizard]

If you drag-and-drop any dialog topic to change the order, and then compile and run the game, when clicked in-game, every topic option will point to completely unrelated topics' options in different trees. In addition, if you double-click on one of the dialog topics you dragged to a new position, the dialog script opens, but the font will look entirely different; it will appear smaller (plain arial) and without any of the color-coded formatting that the editor normally adds to scripts.

Yes, that's true.
This seem to occur only with dialogs that are put into folders. Also, I think I see certain logic pattern in what's happening: dialog #1 options become binded with the answers from the very first dialog in the very first folder, dialog #2 options are binded to the second dialog in the folders, etc (the dialogs in the root are counted first, then the dialogs in folders).

[AGD2]

It happened to me when I was moving dialog topics which aren't contained in folders - there are actually no dialog folders in my source code. It happened when I switched the order of dialog topics 5 and 6.

[Crimson Wizard]

Interesting. It appears that the bug in dialog script view is not related with the dialog order bug. It takes place even without changing any order.

To reproduce:
1. Load game project.
2. Open any existing dialog for editing (or create new one, if there's none).
3. Right-click on pane's header, and choose "Close". Dialog script is closed now.
4. Re-open same dialog. The script will not have any syntax highlighting.

I think this is because Scintilla (script) control becomes deinitialized, or something like that.

[Radiant]

Okay, here's another updated acwin.exe:
http://www.mediafire.com/download/6kb9e1x19nq9xpi/acwin.exe

Okay, we're doing an internal test with this build and it seems to be working. Thank you for your hard work on these betas!

It's causing an issue for us that Speech.DisplayPostTimeMs AnimationStopTimeMargin doesn't work with voice samples but only with text; we would appreciate having the ability to end speech animation (e.g.) 250 ms before the voice clip ends.

Also, it's been shown earlier in the thread that the old function SetMusicMasterVolume() cannot reduce music to zero, because it takes a value between 0 and 100 then internally adds 60 to this value before using it. Would you mind if the function were to accept values from -60 to 100, so that calling SetMusicMasterVolume(-60) does result in an internal volume of -60 + 60 = 0?

[Crimson Wizard]

It's causing an issue for us that Speech.DisplayPostTimeMs doesn't work with voice samples but only with text

I hope you mean Speech.AnimationStopTimeMargin? DisplayPostTimeMs should work with voice.

Also, it's been shown earlier in the thread that the old function SetMusicMasterVolume() cannot reduce music to zero, because it takes a value between 0 and 100 then internally adds 60 to this value before using it. Would you mind if the function were to accept values from -60 to 100, so that calling SetMusicMasterVolume(-60) does result in an internal volume of -60 + 60 = 0?

I would like to understand why it was made that way. Perhaps there was a change in volume units? Any ideas?

[Radiant]

Yes, I meant AnimationStopTimeMargin.

(edit) As I recall, AGS has these 'room music levels' that nobody ever seems to use much; these probably apply a modifier to the music's overall volume, and the lowest of those might be -60? I mean SetMusicVolume, which has a scale of -3 to +3; it wouldn't surprise me if this maps to -60 to +60 internally. If so, these would need a boundary check to treat totals of less than zero as zero.

[Crimson Wizard]

(edit) As I recall, AGS has these 'room music levels' that nobody ever seems to use much; these probably apply a modifier to the music's overall volume, and the lowest of those might be -60? I mean SetMusicVolume, which has a scale of -3 to +3; it wouldn't surprise me if this maps to -60 to +60 internally. If so, these would need a boundary check to treat totals of less than zero as zero.

Ohhh. Well, in such case this is made not right. I found a code where a room modifier is applied:

Code: ags

int newvol=play.music_master_volume + ((int)thisroom.options[ST_VOLUME]) * 30;
if (newvol>255) newvol=255;
if (newvol<0) newvol=0;

I think this may be fixed by changing this to something like

Code: ags

int newvol = play.music_master_volume + room_modifier[thisroom.options[ST_VOLUME]] * 30;
if (newvol>100) newvol=100;
if (newvol<0) newvol=0;
newvol = newvol * 255 / 100; // convert unit range

Yes, this will require to keep master_volume in 0 - 100 range throughout the code.

[Radiant]

Room volume goes -3 to +3, so that makes it -90 to +90.

Since apparently the real scale is 0 to 255, you can set master volume from 60 to 160, and room volume adds -90 to 90, so you end up with a scale of -30 to 250, with values below 0 being clipped to 0. That means that apparently, the only reason SMMV works on this particular scale is so that individual rooms can tweak their volume, but to my best knowledge nobody uses that. It also means the current code already works if you allow SetMusicMasterVolume to utilize the full 0-255 scale, only at the higher and lower ends, the room volume will no longer be able to increase/decrease it further.

Which means your suggested fix works

[Crimson Wizard]

It appears that room volume can be set in range between -3 to +5. Tested in 2.62.
+4 and +5 values are only settable with SetMusicVolume() function (which sets room volume, not general music volume).

Manual does not mention this.


EDIT: No, the first assumption was wrong.
Upon comparing with 2.62 test game I can hear that 2.62 music plays louder with the same volume setting; this means that +60 volume units are added to compensate this difference. (I do not have 2.62 code, but who knows, maybe it was made like that back then).

Also, then newer 3.3.0 engine should produce same results as 2.62. What I'd like to know, if there's a problem with dropping music volume: did that dropping worked well in previous versions of AGS, before you made an import (from 2.72)?
If it worked well prior to 3.3.0 (or 3.2.1), but no more, this means that it is rather volume drop that does not work well.
If the range of music master volume has changed from 0-100 to 60-160, then we'd need to fix volume drop accordingly.

EDIT AGAIN: err, no, something is wrong, I need to think more about this.

[Radiant]

I'm reasonably sure that mastervolume always had a range of 60-160, it's just that not many games actually have separate volume sliders for music/sound/speech, and not many players drag those all the way down to zero. It's way faster to turn the physical knob on your speaker, after all.

[tzachs]

Interesting. It appears that the bug in dialog script view is not related with the dialog order bug. It takes place even without changing any order.

To reproduce:
1. Load game project.
2. Open any existing dialog for editing (or create new one, if there's none).
3. Right-click on pane's header, and choose "Close". Dialog script is closed now.
4. Re-open same dialog. The script will not have any syntax highlighting.

I think this is because Scintilla (script) control becomes deinitialized, or something like that.

Fixed. This was indeed the issue. The same issue used to happen for scripts too, but since for some reason dialogs are implemented seperately, I had to implement the same fix there too...
Maybe some day we can unite the classes (we'll get some more features, like the "*" that is missing from the dialog when it's changed, and the fact that you don't get a choice whether to save it or not).

There appears to be a quirk in the new script grouping system. When double clicking to expand the group, a script file often opens in response. At first, I thought this was a feature as the script that opens is often the main script file for that group. I noticed that this happens even if I expand other groups (rooms list) and the mouse lands over a script file.

This is a minor inconvenience, but it does require you to continuously close script files. Just wanted to bring it to your attention.

That was actually a request, see here (in the end of the post).

[SpeechCenter]

as reported here http://www.adventuregamestudio.co.uk/forums/index.php?topic=45622.msg636470246#msg636470246
AGS.Types.Scripts.Count returns an incorrect value

A second (totally unrelated) problem I noticed in the latest beta is if I close the application, before I get the "do you wish to save" message box, the first pane closes.

[monkey0506]

If I'm not mistaken, I believe that AGS.Types.Scripts never includes room or dialog scripts, so multiplying the value by two should always give the script and header count. Although I agree that the collection should return the actual value of the objects it contains.

[SpeechCenter]

The implementation also assumes the called first adds a header, it stores it in a member and then assumes the caller adds the code script in a next call. Adding a non-header scripts adds a new item that references the script and the header from the previous call. I don't think this is an elegant way to implement this structure, but I realize a lot of this is inherited from the previous implementation where add and remove are generic but additional methods assume the header always comes before the script. So perhaps you're right that given the actual usage and the way it's implemented then multiplying by 2 is not the worst thing as long as the rest remains with this behavior.

[monkey0506]

methods assume the header always comes before the script

That's actually something that's always kind of bothered me, that implementation detail. It's functional, but it's easily error-prone. I wonder how hard it would be to just introduce a new type to wrap a script and its header together and have the scripts collection hold objects of that type... Hmm...

Edit: It appears there already is a type for that... I'd guess it was added when script folders were added. And in fact, AGS.Types.Scripts is storing them as such, but indexing them separately. I think it would make more sense for Scripts to be updated to just be a collection of ScriptAndHeaders instead of the way it is now (which is why Scripts.Count is returning what it is).

[SpeechCenter]

methods assume the header always comes before the script

That's actually something that's always kind of bothered me, that implementation detail. It's functional, but it's easily error-prone. I wonder how hard it would be to just introduce a new type to wrap a script and its header together and have the scripts collection hold objects of that type... Hmm...

Edit: It appears there already is a type for that... I'd guess it was added when script folders were added. And in fact, AGS.Types.Scripts is storing them as such, but indexing them separately. I think it would make more sense for Scripts to be updated to just be a collection of ScriptAndHeaders instead of the way it is now (which is why Scripts.Count is returning what it is).

It's not my intent to double post, but I've seen the post in the plugin thread first, but this is probably the right place to discuss a solution. So I just said that the change that was made today to the class breaks too much for the plugin interface. AGS.Types is exposed to the plugins and should be regarded as an interface. I would ask not to have the code as-is, it would make it very difficult for me to maintain the plugin.