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.

[rofl0r]

(more details and dl link for the game are in #655)

[rofl0r]

seems there's a roughly 5x5 pixel wide area above the stairs that when clicked moves you down. it's quite hard to hit it, after i found it accidentally it still takes about 5-10 clicks each time to find it again (it's the same on all the maniac mansion mania titles). not sure if this is intentional as i don't have windows/wine to test the original exe's, but it seems really odd.

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

[rofl0r]

what i notice is if you're away, then click on the "go to stairs" the actor will walk there and you keep on clicking on the same spot and he will not go down. once he's on the scripted position, you have to click on the right end of the staircase handle or slightly above, otherwise you dont get him to walk down. when you're in a small distance to the right though, and click on the hotspot, it works.

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

[rofl0r]

debug features

interesting, how can those be enabled ?

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

[rofl0r]

yes, i've played it 'til the end (it's a quite short game). i didn't experience any issues with savegames using 3.4.1.x (neither loading nor saving), please see attached savegame collection https://0x0.st/z8__.xz

[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 https://github.com/scummvm/scummvm/commit/c3a0553e25983651f4f823503e9c56ba8bcd3432, 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 : 1c226816e2c3c9c18c3afb976e05535401fc5db4

Went a "configuration" way for easier experimenting.