AGS 3.6.2 - Release Candidate (RC 3)

[Crimson Wizard]

Updated to Release Candidate 3
(Please use download links in the first post)

Contains all fixes from 3.6.1 Patch 10

Own changes:

Editor:
- Added a readonly "ProjectFilename" property to Fonts, which displays their in-project file name.
- Added "Palette index" selection for sprite's import transparency option.
- Added "Change Room Number" context menu command for the Rooms in Project Explorer.
- Fixed importing GIFs with "palette 0 / N" transparency option would refer a palette color from each individual frame's palette rather than the original GIF palette, which could lead to wrong colors used as transparents.
- Fixed Autocomplete failing in case of UNIX line endings in script file.
- Fixed Font preview could crash the Editor with out of memory error in case of a very big font.
- Fixed Editor won't won't let change existing TTF font's size if SourceFilename property is not set for any reason.
- Fixed Frame index not applied when importing sprites from a GIF (regression since 3.6.2 Beta).
- Fixed unhandled exception occuring when user right-clicks or double clicks on a informative message in the Output panel.

Script API:
- Added Room.BackgroundCount readonly property.
- Added GetWalkBehindBase() function, complementing SetWalkBehindBase().

Engine:
- Fixed GUI controls with transparency are not drawn correctly by the Software renderer.
- Fixed DynamicSprite.Rotate mistreating "degrees" argument.

[greg]

Thanks, CW!  From the fix list from 3.6.1 Patch 10, I'm still hitting the following issue in 3.6.2 RC3:

- Fixed Character movement recalculation when changing move speeds while walking, and movement path contains 45-degrees diagonal segments.

When the character moves right horizontally, then up-right diagonally at a 45-degree angle, they move at the expected speed during the horizontal segment but slow down substantially during the diagonal segment.

When the character repeats the same pattern in reverse (moving down-left diagonally, then left horizontally), they move at the expected speed through both segments.

(If you'd like me to share the walkable area mask, let me know.)

- Fixed a number of region or hotspot's "Stand on hotspot" events may unexpectedly run after a blocking character's walk, even if character is no longer standing on that region/hotspot.

I just noticed that if the player walks onto the region during room_AfterFadeIn(), regionX_WalksOnto() is no longer triggered.  Is this intended?

[Crimson Wizard]

Thanks, CW!  From the fix list from 3.6.1 Patch 10, I'm still hitting the following issue in 3.6.2 RC3:

- Fixed Character movement recalculation when changing move speeds while walking, and movement path contains 45-degrees diagonal segments.

When the character moves right horizontally, then up-right diagonally at a 45-degree angle, they move at the expected speed during the horizontal segment but slow down substantially during the diagonal segment.

When the character repeats the same pattern in reverse (moving down-left diagonally, then left horizontally), they move at the expected speed through both segments.

(If you'd like me to share the walkable area mask, let me know.)

I see now that I did not describe the fixed bug properly. The bug that I referred to occured when you call Character.SetWalkSpeed() during walk. In that case the character started walking into a slightly different direction.
If that is not what is happening, then that might be a separate issue.
Of course, I would need to know coordinates of starting, middle and ending position of a walk, and character walk speeds. If a middle position is not known, then I also need a walkable area in order to replicate this kind of movement.

- Fixed a number of region or hotspot's "Stand on hotspot" events may unexpectedly run after a blocking character's walk, even if character is no longer standing on that region/hotspot.

I just noticed that if the player walks onto the region during room_AfterFadeIn(), regionX_WalksOnto() is no longer triggered.  Is this intended?

It is intended to NOT run region "walks onto"/"walks off" during blocking walk, and IIRC that was always the case in AGS. What I have fixed is that AGS accidentally scheduled these events and could run much time later, after all the blocking actions have finished.
Is your walk blocking? Does it matter if it's "After fade in" or not?

[greg]

Of course, I would need to know coordinates of starting, middle and ending position of a walk, and character walk speeds. If a middle position is not known, then I also need a walkable area in order to replicate this kind of movement.

Sure, I've sent you a private message with the walkable area mask, the relevant information (start, end, speed), and a screencast of the behavior.

It is intended to NOT run region "walks onto"/"walks off" during blocking walk, and IIRC that was always the case in AGS. What I have fixed is that AGS accidentally scheduled these events and could run much time later, after all the blocking actions have finished.
Is your walk blocking? Does it matter if it's "After fade in" or not?

Yes, the current RC3 behavior makes sense to me, and I don't think it should be changed.

My walk during "After Fade In" is blocking, so I've altered the scripting to manually call regionX_WalksOnto() after the blocking walk.  Thanks!

[Crimson Wizard]

Of course, I would need to know coordinates of starting, middle and ending position of a walk, and character walk speeds. If a middle position is not known, then I also need a walkable area in order to replicate this kind of movement.

Sure, I've sent you a private message with the walkable area mask, the relevant information (start, end, speed), and a screencast of the behavior.

I checked this out, and what is happening is that somehow the pathfinder is confused by character walking too close to a 45-degree diagonal non-walkable wall: when the walk is from down-left to right-top position the pathfinder creates a path consisting of about 15 small chunks. When the walk is reverse, there are only 3 chunks.

You may see this, if you enable pathfinder debugging using "Debug(5,0)":
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#debug

This is not seen using above debug mode though, but I learnt from reading the path data in engine memory, that they are following a zig-zag pattern. This cannot be noticed because the zig-zag change in direction has a very small deviation so it looks like it's a straight movement.
Then, the current walking logic in the engine restricts character step by the end of each walking chunk. Meaning that if the next character's move crosses past the check point, that move will be interrupted and clamped to the end point. This makes the character make much smaller steps than it could have.

I suppose that for the long term solution engine could propagate character movement amount further after the checkpoint. E.g. if we take movement step as 1.0, we may calculate how much the remaining part of the first chunk takes from that, subtract, and then apply the remaining fraction along the new chunk. That might generally make walking around corners smoother in terms of speed (when no turning on spot is required).

Another possibility that comes to mind is to analyze the returned path, and if we notice the zig-zag pattern with very small direction deviations in between (capped at certain difference), then we smooth the path, replacing it with 1 chunk.

As for the immediate solution, I may suggest experimenting with walkable area a little, maybe adjusting it a bit would solve such issue.
EDIT: one idea i have, try to make a "cut out" 2-3 pixels into the diagonal wall, but leave the corners intact. This maybe will keep the non-walkable pixels away from path when character goes around the corner.

[greg]

As for the immediate solution, I may suggest experimenting with walkable area a little, maybe adjusting it a bit would solve such issue.

Thanks, CW!  Adjusting the walkable area's shape resolved the issue.