ags3: path issues with 1271.Maniac Mansion Mania

[rofl0r]

just left of the room one starts in, there's a stair going down and according to the walkthrough https://www.maniac-mansion-mania.com/index.php/en/spiele/komplettloesungen/episoden/219-lg-episode-16-meteor-family-die-rehr-des-meteoriten.html one is supposed to be able to walk down. i didn't find any way to walk down the stairs, and suspect the pathfinding is somehow broken.

[ghost]

Hmm, I was able to do this in first attempt in original game and running latest ags3 branch. It works if I click anywhere on the stairs "object" or above it.
I will try Linux port.

[ghost]

Okay, don't know if related, but if character stands to the right from stairs clicking anywhere around them works.
If character is standing to left from stairs, or just in front of railings, then clicking above them usually make it come to the railings and stop. Clicking much higher may work though.
Clicking on stairs/railings area itself (it sais "Gehe zu Treppe") works all the time (probably it has a scripted Walk to the correct coordinates).

Original game seem to have about same behavior, I did not notice significant difference.

[ghost]

I fear this won't progress as it is now because it's difficult to understand problem description without visual feedback, and also we need to define what is correct expected behavior and what is not.

For the reference, here's a screenshot of the room with translucent walkable area overlay. I had to combine two screenshots myself because AGS only displays room and areas in game separately:
https://i.imgur.com/NEhFFZC.png
EDIT: I've got an impression that either area is drawn with positive Y offset (lower than in reality), or character has a transparent padding below his feet.

For an in-game testing we'd need to change the way debug features work from showing areas on a still screen to displaying them as transparent overlay as game progresses. Same for character walk paths.

[ghost]

interesting, how can those be enabled ?

They are run by script_debug function, but they normally are activated by command from script, so this may be complicated. For this case I hacked engine code in check_keyboard_controls and made it call script_debug(2,0) at an arbitrary key code. That draws walkable areas on screen.
Another useful command may be script_debug(5,0) that draws player character's movelist.

[ghost]

@rofl0r , an unrelated question, have you played this game further, and have you noticed any issues with the loading savegames?
I think I found an error in the new save format which is only affecting old games like this one. For me it crashes immediately as I try to load any save.

[ghost]

Oh, you are playing using 3.4.1, that explains why it worked, I was testing in wip 3.5.0 branch which has a new save format.

[ivan-mogilko]

It's been a while, and I decided to recall what was going on there, to find out that it does not work for me anymore like I described in a comment above.

The engine uses legacy pathfinder since it's a pre-3.5.0 game.

EDIT: so, apparently besides "walkable" area, a "region" mask has a small area at the stairs too. Maybe it is meant to trigger change room when player stands on it, but for some reason does not.

[ivan-mogilko]

So, what is happening is that there's a small region near the stairs, that has "on step" interaction and triggers a change to another room, but for some reason character does not stand right on it; or maybe logic of "stepping on" changed in between the versions.

For example, when the light/tint is applied by the region, engine tests not only character's position, but also tests with 3 pixel offset in 4 directions around it. But it does not do same thing for interactions, at least in the current code.

[ivan-mogilko]

Found something else interesting: if you try to get as high as possible in a room, it seems that the character can go 1 pixel further in the original game...

Ran with --test and pressing "Ctrl+A" to show walkable areas, made screenshots and compared, both original exe and the current engine has same areas. So it's something about how character walks or ends walking.

[tag2015]

I did some research on this. The issue occurs on pre-3.0 games using the Bernard-Haus resources.
I think the problem is in the find_nearest_walkable_area function which is called with granularity=3 by is_route_possible.
When it performs the sweep in the 100x100px area around the clicked coordinate, if a walkable pixel is found the coordinate is saved in the static variables suggestx/suggesty (which are later checked); but since it skips lines (due to the granularity value), the saved coordinate is not necessarily the closest to the clicked location and may offshoot.
Using granularity=1, checking all pixels, the pathfider works as it should.
I committed a tentative fix for this in scummvm/scummvm@c3a0553, clearly this is not optimal as it changes the behavior in all pre3-0 games , but I found no differences in other games (such as Apprentice or the Trilby games)

[ivan-mogilko]

@tag2015 thank you for this research. I make a guess that this setting could have been changed around the time when the users of AGS started to make more high resolution games. The old pathfinder was too slow for higher resolutions. This is also the reason why 640x400 (and higher) games originally used 1:2 walkable masks, instead of 1:1.

Perhaps this granularity may be set depending on a game resolution (or even room size, but that may be more bug prone).

[ivan-mogilko]

@tag2015 I made an experiment by extracting the room in question, and building dummy games in several versions of AGS.

It appears that the change in pathfinding occured between versions 3.0 and 3.0.1.

Changelog has this line under 3.0.1 notes:

• Improved pathfinder dealing with narrow winding walkable areas

although I cannot exactly tell if this is related.

Comparison may be done not only visually by where character stands, but also by pressing Ctrl+A to display walkable areas, and observing the "collision box" made by character inside a walkable area (if Character's Solid property is enabled). If a game is run without scaling filter, making screenshot and comparing where collision box is positioned may tell where character's position is.

EDIT: I tried your "granularity" fix, but unfortunately, it did not work for me... at least it does not change where character ends up standing in that room, if you walk straight up as much as possible.

EDIT2: Ah, I think I understand now. There are two sweeps, one in a 50-pixel radius, and another around whole area.
So, with your fix, it works but so long as I click not further than 50 pixels from the target.

[ivan-mogilko]

Pushed fix : 1c22681

Went a "configuration" way for easier experimenting.