AGS 3.6.2 - Release Candidate (RC 3)

[RootBound]

A couple things in the editor that should be easy to reproduce I hope:

1. When selecting a hotspot from the drop down menu in the room editor, the previously edited hotspot remains the highlighted color one in the room, until a new click in the room happens. It used to be that when you select a new hotspot from the menu, the newly selected hotspot would immediately become highlighted and the one in color, so you could see which hotspot was which just by using the drop down menu.

2. If I delete all the text from a GUI button, the editor switches to editing the GUI as a whole and not the button.

[Crimson Wizard]

2. If I delete all the text from a GUI button, the editor switches to editing the GUI as a whole and not the button.

Please clarify the steps for this? Simply deleting a text in button's property does not do anything.

[RootBound]

I see now this is unrelated to the button. I think it used to be the case that to select the parent GUI in the editor, one had to click on a part of the GUI with no controls. Now that happens when clicking outside the GUI in the empty space between the properties panel and the GUI itself. This isn't necessarily a problem, just a new behavior I wasn't aware of.

[RootBound]

Well, I just crashed the engine somehow. I had the player's speech style set to Sierra-Style with Background, but didn't have a speech view assigned, so it defaulted to LucasArts style, as expected. Then I selected a speech view, and running the game crashed it with an "illegal exception" error when the player starts talking.

This is the error I got:




The crash dump files says "The thread tried to read from or write to a virtual address for which it does not have the appropriate access."

EDIT: Silly me, I realized the problem. I was using a blank template but did not have a custom speech text box GUI set up (set to "none" in General Settings) and there was no text box GUI at all. The game no longer crashes once I add a text box GUI and select it in general settings.

[Crimson Wizard]

This another temp build:
https://cirrus-ci.com/task/6401719766089728

Fixed:
1. Hotspot selection not repainted properly.
2. Engine crashing when trying to draw a default speech box without textwindow gui.

[greg]

Another walk-based issue I spotted:

Character.AddWaypoint() appears to be restricting characters' movement to walkable areas.

From the manual and previous versions, "any moves made with this command ignore walkable areas."

[Crimson Wizard]

Character.AddWaypoint() appears to be restricting characters' movement to walkable areas.

I don't see it restricting movement, but I see that it teleports character back to walkable area when it finishes walking if there was Walk with eWalkableAreas just before adding a waypoint, because of these fixes I made. This logic is broken now.

I just noticed now that previous versions of AGS never fixed character's position in the end of walk, only if "StopMoving" was called explicitly. Somehow I understood this wrong. Now it works differently than before, and this affects a number of other things.

Engine only fixes the position if the walk is marked as "walking by walkable areas". So if the walk was started by a normal Walk with eWalkableAreas , AddWaypoints don't change that, and engine still considers this walk to be a walk over walkable areas. This is a property of whole "walk", not each segment.


EDIT:
Of course this means that AGS historically had this error: if you call AddWaypoint after Walk with eWalkableAreas, and then call StopMoving in script while character is walking on a non-walkable area, then the character will be moved to the nearest walkable area. Because it remembered that the first walk was done using eWalkableAreas.

Now the situation is worse because I made that automatic fixup after the end of walk, so it's going to happen every time character finishes walking after AddWaypoint.

What are the options of fixing this?
Option 1. Whenever AddWaypoint is called, the walk is marked as "eAnywhere". Of course this will mean that if character is stopped during first walking stage, they will not get position fixed even if it was called with eWalkableAreas.
Option 2. Modify the walking logic to store the "uses walkable areas" flag per stage. This will also require to modify savegame format because walking plan is saved there.

EDIT 2:
And then there's also a problem of backwards compatibility, because the new fix in the end of walking may change the position where the character ends up...

It's quite possible that I made a mistake with this fix. I did not find why does the character end up on the nonwalkable area at all. Is it that pathfinder makes a mistake and sets the end of the path there, or is it that character makes a mistake when moving?
Maybe I should change this to not search for walkable area, but place at the explicit coordinates that were found by the pathfinder instead.
And if this contradicts old game behavior, then do this only for the games made with the new version of AGS, to keep old game behavior unmodified...

I will have to make tests that implement faulty case when character ends up on a non-walkable area, and include these into automatic tests, to keep these potential problems visible at all times.

[Crimson Wizard]

@greg I made a temporary fix for AddWaypoint, where it should not reset character to walkable area if called right after Walk(..., eWalkableAreas):
https://cirrus-ci.com/task/4886250328424448

I need to take some time and think of what would be a correct fix for this, make better test games and revisit the problem of character ending up on a non-walkable area, which reasons I did not understand in the first place.

UPDATE
Also, I found out that the mismatch of the final position is related to character scaling.
AGS has some confusing logic about lowering down character speed, where it would try to make it do fraction of normal step. If that's done, it's also applied to the final step, so character has a chance to never truly reach the destination and stop 1-2 pixels away from it.

I could not yet explain how it gets into non-walkable areas. I tested the specific case that you PMed to me, and was able to confirm that this did not happen in 3.6.1. I recall that I was doing a number of fixes for walking accuracy in 3.6.1, but can't remember doing anything about that in 3.6.2... I will investigate a bit more.

UPDATE 2
Okay, I finally found the difference between 3.6.2 and 3.6.1 that was causing that original problem with character ending on a non-walkable point.

Basically, there was another coordinate fixup done by the engine when the character stops walking, and this fixup is being missed in 3.6.2 after my code rewrite. If I re-enable that fixup, then the character does not get there in the first place.

[Crimson Wizard]

I have made another fix to the walking, restoring an older behavior which I accidentally broke about 2 months ago (in 3.6.2 beta). Hopefully it still works, I dont expect this to have noticeably effect compared to the previous temp build:
https://cirrus-ci.com/task/5780593608228864

[greg]

Thanks, CW!  That build fixes the three previous walk issues I'd experienced.

[Crimson Wizard]

Finally had a chance to look into this one:

I've also observed a change in how the "walks onto region" event is triggered:

Let's say we have the following configuration:

• The room has region1 where the "walks onto region" event calls region1_WalksOnto().
• As part of the scripting in region1_WalksOnto(), the player walks off, back onto, and back off of region1.

In previous versions, once region1_WalksOnto() completes, the player regains control of the game.

In RC1, once region1_WalksOnto() completes, "walks onto region" is automatically triggered again.  This results in an infinite loop, and the player never regains control of the game.

The fixed build is here:
https://cirrus-ci.com/task/4676821372895232

I should note that while testing this I also found another, older mistake, which was present all the way since at least AGS 3.2.1: The region retriggered if player character ended blocking walking at its edge pixel, because the engine remembers that region changes from 0 to N at the final step.

Strictly speaking, the engine was always working incorrectly. There's too much technical details to tell, but in brief, the truth is that it always registered region events, even when player makes a blocking walk. But these events do not have a chance to call the script right away, because engine cannot run new script while in blocking action. And because of how event queue was implemented, these region events got overwritten afterwards.
But there was still a slight chance that they would trigger after the blocking walk finishes.

This is easy to demonstrate, if you take any older version of AGS. Make "stand on region" event display some message on screen. Then script character to have a blocking walk over that region, just across it. As soon as it finishes walking, there will be 2-3 "stand on region" script runs, even though the character is no longer on the region.

[Crimson Wizard]

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

Changes:

Editor:
- Fixed hotspots and other mask items were not redrawn correctly after user changed selection using a navigation bar (regression since 3.6.2 beta).
- Fixed a check for an imported room mask size did not correctly account for the room's mask resolution setting (it worked, but mishandled some edge cases).
- Fixed translation compiler mistreating escaped opening bracket in a text line (`"\["`); it must keep it as-is, because "[" char is a old-style line break in AGS.

Script API:
- Added static Dialog.Stop() function, a OO-style alias to StopDialog().
- Added Game.InBlockingWait property, that tells whether game is waiting for any blocking action or a Wait* call to complete.
- Added optional "width", "height" and "layer" parameters to SaveScreenShot().
  SaveScreenShot() now accepts paths containing standard file tokens (`$SAVEGAMEDIR$` etc).

Engine:
- Engine will no longer quit with error if any object is assigned a non-existing sprite, but continue, using a sprite 0 as a placeholder instead.
- Fixed Character.SayAt clamping speech position to the screen's bottom and right edge (regression since 3.6.2 beta).
- Fixed character may rarely finish walking on a non-walkable pixel.
- Fixed calling Character.StopMoving() after AddWaypoint() succeeded a regular Walk() call with eWalkableAreas parameter will wrongfully teleport the character to the nearest walkable area, even though AddWaypoint is supposed to ignore walkable areas.
- 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.
- Fixed a AudioChannel did not report a correct Position right after a AudioClip.PlayFrom() call.
- Fixed Button resizing to sprite 0 size if NormalGraphic is set to 0 (default button look).
- Fixed object's look not updated after it was assigned a dynamic sprite, redrawn, sprite deleted, object redrawn without a sprite (used a placeholder), and then another dynamic sprite assigned with coincidentally the same number.
- Fixed objects begin to have incorrect z-sort order after changing room at least once (regression since 3.6.2 beta).
- Fixed font outline index limited to 127 (although we theoretically support higher font numbers).
- Fixed font outline parameters not initialized correctly if engine is built by a system that treats "char" as unsigned 8-bit type.
- Fixed accessing DynamicSprites in script could crash a game after restoring a save, if that save was made with eSaveCmp_DynamicSprites component excluded.
- Fixed a crash upon InventoryScreen() call in case there are no items (regression since 3.6.2 beta).
- Fixed a crash caused by any text messages using default text window (regression since 3.6.2 beta).
- Fixed voice lipsync triggering character body animation along with the speech if character went to idle state during a dialog (regression since 3.6.2 beta).
- Fixed SDL log level was defaulting to "verbose" if not read from config (should be "info").

Compatibility:
- Fixed old rooms with rare x3 resolution not displaying correctly.

Plugin API:
- Fixed a crash in IAGSEngine::OpenFileStream() if the stream failed to open for any reason.

WinSetup:
- Fixed "Save and Run" command sometimes caused 2 engine processes, one of which terminated later. This did not prevent a game from running, but could result in temporary CPU and memory overload.

[glurex]

I think I found a bug. If I modify any line in any script, then close it from the tabs and click 'Yes' when prompted with 'Do you want to save your changes before closing?', I get an 'Unhandled Error'. At first, I thought it only happened in version 3.6.2.8, which I just downloaded. But after testing, I see it also occurs in 3.6.1.30.

Spoiler

Code: ags

 Version: AGS 3.6.1.30 [In version 3.6.2.8 is the same message]

System.ArgumentOutOfRangeException
   en WeifenLuo.WinFormsUI.Docking.DockContentCollection.GetVisibleContent(Int32 index)
   en WeifenLuo.WinFormsUI.Docking.DockContentCollection.get_Item(Int32 index)
   en WeifenLuo.WinFormsUI.Docking.DockPaneStripBase.TabCollection.get_Item(Int32 index)
   en WeifenLuo.WinFormsUI.Docking.VS2005DockPaneStrip.EnsureDocumentTabVisible(IDockContent content, Boolean repaint)
   en WeifenLuo.WinFormsUI.Docking.VS2005DockPaneStrip.OnPaint(PaintEventArgs e)
   en System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   en System.Windows.Forms.Control.WmPaint(Message& m)
   en System.Windows.Forms.Control.WndProc(Message& m)
   en WeifenLuo.WinFormsUI.Docking.DockPaneStripBase.WndProc(Message& m)
   en System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   en System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

A serious error occurred and the AGS Editor may now be in an unstable state. You are STRONGLY ADVISED to shut down the editor and restart it. Before saving your work, make a backup copy of your game folder in case any data has been corrupted.

Code: ags

Error: System.ArgumentOutOfRangeException

   en WeifenLuo.WinFormsUI.Docking.DockContentCollection.GetVisibleContent(Int32 index)

   en WeifenLuo.WinFormsUI.Docking.DockContentCollection.get_Item(Int32 index)

   en WeifenLuo.WinFormsUI.Docking.DockPaneStripBase.TabCollection.get_Item(Int32 index)

   en WeifenLuo.WinFormsUI.Docking.VS2005DockPaneStrip.EnsureDocumentTabVisible(IDockContent content, Boolean repaint)

   en WeifenLuo.WinFormsUI.Docking.VS2005DockPaneStrip.OnPaint(PaintEventArgs e)

   en System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)

   en System.Windows.Forms.Control.WmPaint(Message& m)

   en System.Windows.Forms.Control.WndProc(Message& m)

   en WeifenLuo.WinFormsUI.Docking.DockPaneStripBase.WndProc(Message& m)

   en System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

   en System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

   en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[close]

[Crimson Wizard]

I think I found a bug. If I modify any line in any script, then close it from the tabs and click 'Yes' when prompted with 'Do you want to save your changes before closing?', I get an 'Unhandled Error'.

I cannot reproduce this in either version... there might be some conditions for this error to happen.

[glurex]

How strange! I just created a brand-new game to test it (I used the Bass template), and the error happened. Here I'm attaching a video:

https://www.mediafire.com/file/x7ldm9l7yi4f592/VID_20250315_210842.mp4/file

[Crimson Wizard]

How strange! I just created a brand-new game to test it (I used the Bass template), and the error happened. Here I'm attaching a video:

Does this happen if you close unmodified tab, or close modified and choose to not save?

[glurex]

Does this happen if you close unmodified tab, or close modified and choose to not save?

No, the error only happens when I close the tab and choose to save. It also doesn't happen when I run the game (F5) in the editor after modifying the script. And in the room scripts, the error never occurs.

[glurex]

I continued testing with brand-new games, and the same error occurs with all the templates except the blank template. Throughout my tests, I noticed that on some occasions, the first time I modify the first script in the list (e.g., TwoClickHandler.asc in the BASS template), the error doesn't happen. However, from the second time onward, it always does. The error only happens with Script (.asc) not the Header (.ash).

I also noticed that saving the game after modifying the script doesn't trigger the error. So, as long as I don't close the tab with the script and choose to save, everything remains safe enough.

[Crimson Wizard]

I continued testing with brand-new games, and the same error occurs with all the templates except the blank template. Throughout my tests, I noticed that on some occasions, the first time I modify the first script in the list (e.g., TwoClickHandler.asc in the BASS template), the error doesn't happen. However, from the second time onward, it always does. The error only happens with Script (.asc) not the Header (.ash).

I also noticed that saving the game after modifying the script doesn't trigger the error. So, as long as I don't close the tab with the script and choose to save, everything remains safe enough.

So far I have not much ideas and was not able to reproduce this problem myself.
I opened a bug ticket for now:
https://github.com/adventuregamestudio/ags/issues/2704

[edmundito]

I was reading through the changelist, and I'm very impressed with all the changes in this version, despite the focus on 4.0. I want to thank all the contributors who made this possible. Great job, y'all!