AGS 3.6.2 - Beta 5 -- a WIP 3.6 update

[greg]

Thanks, CW!  This is fantastic.  I just tested it out, and I'm now able to re-organize and alphabetize sprite folders!

[Crimson Wizard]

Updated to Beta 4
(Please use download links in the first post)

Editor:
- Property Grid now displays Custom Properties right in the main properties list for each item that supports them.
- Support reordering folders in Sprite Manager with drag & drop.
- Script's Autocomplete will now work for dynamic array's Length property.
- Editor will now report any script functions that *look like* event functions, but not assigned to corresponding events, as warnings when compiling the game.
- Fixed dragging an item into the folder in Project Explorer could move it into a wrong folder if the folders have similar names only different in letter case.

Scripting:
- Support zero-length dynamic arrays. This may be useful if you need to have a dynamic array with no elements, but don't want to bother about checking a null pointer.

Script API:
- Added Character.Following property that returns another Character that this one follows after.
- Added System.DisplayFPS property that toggles FPS counter (a replacement to Debug(4, 1)).

Engine:
- Removed arbitrary limit of 2k bytes for the result of String.Format().
- Fixed calling Character.Animate() during idling state could cause incorrect error, reporting invalid animation loop. (This is regression in 3.6.1)
- Fixed GUI controls get shuffled when restoring saves made by pre-3.6.2 engines (regression since 3.6.2 Beta 3).
- Fixed Game.ScanSaveSlots() erroring on GUI in saves made by pre-3.6.2 engines.

[Crimson Wizard]

We started documenting new 3.6.2 features. Their partial documentation may already be found in the manual along with the latest Beta, more will follow.

For the reference here's a wip version of "Upgrading to 3.6.2" article, that discusses important new features:
https://github.com/adventuregamestudio/ags-manual/wiki/UpgradeTo362

[Crimson Wizard]

There's a bug found in the latest 3.6.2 and 4.0 updates,

I'm not entirely certain, but i think it happens when you either declared a function without parameter names (only types), or when you are typing a function declaration and delete one of the parameters and retype its type, or something like that.

In such case editor shows error message with "index out of bounds". But you can continue to work.
The error comes from autocomplete, so while annoying, should not affect your game.

I will be posting a fixed builds soon.


UPDATE: following temp build should have this fixed:
https://cirrus-ci.com/task/6216491441324032

[Crimson Wizard]

I really wish to have any feedback on this:

I am in doubts about something again...

In the latest update I've expanded eEventGUIMouseDown and eEventGUIMouseUp events with following parameters:
- mouse button
- mouse x
- mouse y

the position is given in screen coordinates.

Would it be better to have them in respective GUI coordinates instead?

Because we are gradually approaching final 3.6.2 release, and this has to be resolved soon.


My own thinking of this is following:
the event is "mouse down/up on gui", and it refers to particular GUI, as one may notice from the parameter list, not "all or any guis".
Because it relates to particular GUI, it may be desired to know exact relative position of a click, as opposed to a case when have a "click on screen" for example.
Similarly to the case when the mouse changes position before "on_mouse_click" gets called (and that's why we need to pass click position as arguments),
a GUI may also change position before "on_event" is called. This may happen, for instance, if it's changed in gui's own OnClick event, or if there are multiple on_event functions in multiple scripts and one of them changes gui position. Not very likely in practice, but still theoretically possible.

These two considerations combined: that this event refers to a click on particular gui, and that gui position may change in between, - they make me think that it's better to pass relative gui coordinates for them.

[Crimson Wizard]

Updated to Beta 5
(Please use download links in the first post)

Editor:
- Fixed a "unterminated string" error in Dialogs was not pointing to the actual error location.
- Fixed a possible "index out of range" exception that may occur while user types a function declaration (a regression in previous 3.6.2 Beta).

Script API:
- Changed eEventGUIMouseDown and eEventGUIMouseUp events to receive click position in GUI-relative coordinates.
- Renamed File.ReadBytes() and WriteBytes() to ReadRawBytes() and WriteRawBytes() respectively, in sake of consistency with other File functions.
- Added File.ReadFloat() and WriteFloat() that safeguards the written value with a tag.

Engine:
- Increased the cap of simultaneously loaded scripts to 1024 (this includes all regular script modules, a single active dialog script, and a single active room script).
- Character.FollowCharacter() can now have a distance parameter up to 32766 (was limited to 255).
- Ensure that the objects with identical z-order (baseline) always keep same relative sort order when being drawn (note: engine does not guarantee a predefined order, only a persistent one).
- Fixed inventory cursor's crosshair hotspot was drawn incorrectly if active item's sprite has a alpha channel.

Engine Plugin API:
- Added IAGSEngine.CreateDynamicArray(), which lets plugins to create dynamic arrays.
- Added IAGSEngine.GetDynamicArrayLength() and IAGSEngine.GetDynamicArraySize(), which tell the passed array object's number of elements, and total size in bytes respectively.

[Snarky]

a GUI may also change position before "on_event" is called. This may happen, for instance, if it's changed in gui's own OnClick event, or if there are multiple on_event functions in multiple scripts and one of them changes gui position. Not very likely in practice, but still theoretically possible.

In AGS4 it's also possible to rotate GUIs, right? So presumably the eEventGUIMouseDown/Up coordinates will be relative to the rotated coordinate system. This, to me, is the main reason to prefer the GUI coordinate system, as otherwise it would be hard to work out where on the GUI you actually clicked.

[AGSGUMX7]

This all sounds good

[greg]

I don't think 3.6.2 is handling alpha channels correctly when importing new sprites.

Reproduction steps:

1. Select "Import new sprite(s) from files..."
2. Select a file that has an alpha channel.
3. Make sure "Import alpha channel (if available)" is selected, and click Import.

Expected Behavior: The imported sprite should have a transparent background.

Observed Behavior: The imported sprite has a background color in the Sprites tab, as well as when running the game.

Note that this only affects sprites imported in 3.6.2.  It doesn't affect sprites that were already imported before upgrading to 3.6.2.

[Crimson Wizard]

Reproduction steps:

1. Select "Import new sprite(s) from files..."
2. Select a file that has an alpha channel.
3. Make sure "Import alpha channel (if available)" is selected, and click Import.

Please double check what is selected in "Transparent colour" option when you import the sprite.

[greg]

This image shows the same png file imported with the following options (from left to right):

1. Imported with an earlier version of AGS: ImportAlphaChannel=True, TransparentColour=LeaveAsIs
2. Imported with AGS 3.6.2 Beta 5: ImportAlphaChannel=True, TransparentColour=LeaveAsIs
3. Imported with AGS 3.6.2 Beta 5: ImportAlphaChannel=True, TransparentColour=NoTransparency
4. Imported with AGS 3.6.2 Beta 5: ImportAlphaChannel=True, TransparentColour=TopLeft

Here's what I see:

#1 uses the alpha channel as the transparency.  This is the intended behavior.

#2 and #4 appear to be using the transparent color rather than the alpha channel.  (You can see a black outline around the sprite.)

#3 has no transparency.  This is a change in behavior from pre-3.6.2 where, even if TransparentColour == NoTransparency, the imported sprite would still use the alpha channel.

[Crimson Wizard]

@greg could you upload a original png that you are using so that I could test this? I was not able to see this black outline with the random sprites; and I cannot see any difference from 3.6.1, or 3.6.0 for example, regardless of the options.

About TransparentColour=NoTransparency, I tried with the same random sprite, and it maintains alpha transparency for some reason, although I did not expect that. I am not fully certain, but i think that this option was supposed to make the sprite opaque.

[greg]

Sure, here's the png I'm testing with:

https://www.dropbox.com/scl/fi/z1fgxxvnahpw0yfwjw84v/NE-01-SS-000.png?rlkey=w9i6bj0dqhp4cp6z4vzw3pkmm&st=lap4p1ze&dl=0

I've tested with other png files as well, though they were also created through the same pipeline (using ImageMagick).

[Crimson Wizard]

Sure, here's the png I'm testing with:

https://www.dropbox.com/scl/fi/z1fgxxvnahpw0yfwjw84v/NE-01-SS-000.png?rlkey=w9i6bj0dqhp4cp6z4vzw3pkmm&st=lap4p1ze&dl=0

I can see what is happening now.
When importing this file in previous versions, they see this file as "32-bit ARGB".
When importing the same file in 3.6.2, it sees this file as "8 bit indexed", and thinks that the image does not have any alpha channel.
This is displayed at the left-bottom corner of the Import Sprite window; and "Alpha Channel" property is false in the sprite's properties after import.

The PNG file is actually 8-bit, but I suppose that it contains translucent colors in its palette, and 3.6.2 misses this fact.

[Crimson Wizard]

@greg Please try this experimental build:
https://cirrus-ci.com/task/6105885866459136

If the Editor does not start, you may need to install a different VC redistributable on your system, because we are switching to another version:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

[greg]

Yes, that build fixed the issue.  Thank you!

I used "Replace sprite(s) from source" to refresh all the character's sprites, and the alpha channel is now displaying correctly.

[Crimson Wizard]

I used "Replace sprite(s) from source" to refresh all the character's sprites, and the alpha channel is now displaying correctly.

Hmm, interesting, I did not expect "Replace from source" to work like that, but probably it works because it remembers "Use Alpha Channel" option, and automatically combines that with the new knowledge about the source image.