AGS 3.6.2 - Release Candidate (RC 1)

[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.