QFG4: Thieves guild secret passage isn't immediately walkable

[tsoliman]

self built from git 13fa1b22a20966f3ddbcb9b2a5e48e7232250239

You're supposed to be able to walk behind the chief thief but I can't seem to. Some kind of pathfinding difference I suppose.

[tsoliman]

savegame

[mrprmiller]

I'm unable to try it because I have my own problems with SCUMMVM, but have you cured the chief thief yet? You cannot leave his guild by the exit before curing him.

[tsoliman]

@mrprmiller: You can clearly see he is still an insectoid here: ​https://youtu.be/L8HOaR7Vkr0?t=3261

[Vhati]

I can confirm the passage was accessible while Chief was an insect in the original interpreters.


QFG4 CD (English)

File - 5kb MD5 - Full MD5
RESOURCE.000 - 263dce4aa34c49d3ad29bec889007b1c - 1364ba69e3c0abb68cc0170650a56692
RESOURCE.AUD - c39521bffb1d8b19a57394866184a0ca - 71098b9e97e20c8941c0e4812d5f906f
RESOURCE.MAP - aba367f2102e81782d961b14fbe3d630 - 801a04cc6aa5d437681a2dd0b6545248
RESOURCE.SFX - 3cf95e09dab8b11d675e0537e18b499a - 7c858d7253f86dab4cc6066013c5ecec

QFG4 Floppy 1.1a + note patch (English)

File - 5kb MD5 - Full MD5
RESOURCE.000 - f64fd6aa3977939a86ff30783dd677e1 - ff42260a665995a85aeb277ad80aac8a
RESOURCE.MAP - d10a4cc177d2091d744e2ad8c049b0ae - 3695b1b0a1d15f3d324ea9f0cc325245
RESOURCE.SFX - 3cf95e09dab8b11d675e0537e18b499a - 7c858d7253f86dab4cc6066013c5ecec

[Vhati]

rm340::init() has a cond block that decides among 3 walkable areas, and the third condition includes a Feature object that exits when hero walks onto it...

• You have flag 243, failing the first condition.
  • Set when the double doors are opened. (script 340 - sDoorSlide:changeState(1))
• You have flag 254, failing the second condition.
  • Set when the wall opens up. (script 340 - sBarrelMove::changeState(8))
• Otherwise, init secritExit.

script 340 - secritExit

(instance secritExit of Feature
	(properties
		nsLeft 311
		nsTop 119
		nsRight 319
		nsBottom 126
	)

	(method (init)
		(g78_theDoits addToFront: self)
		(super init: &rest)
	)

	(method (doit)
		(if
		(and (self onMe: g0_hero) (not (g2_myCurrentRoom script?)))
			(g2_myCurrentRoom newRoom: 290)
		)
	)
# ...
)

[Vhati]

Polygon - Walkable area and passage region

[Vhati]

OP savegame does have flag 243 and flag 254.

OP's relevant global plot flag bitmask includes: 240,241,242,243,247,248,254.

• vv g 515 61826

Re-entered the room. Breakpoint tripped for the third addObstacle condition. That's definitely happening.

I can use the passage after I re-entered the room.


If OP had *just then* opened the wall, that would explain this. The walkable area doesn't update until you re-enter.


If you cure Chief, the walkable area will update immediately without needing to re-enter. (sChangeThief::changeState(1))

[Vhati]

This is original behavior, poorly designed as it may be.

The polygon update and secritExit *ought* to be in sBarrelMove. They're mostly redundant in sChangeThief.

It is clearly expected that players would open the wall, learn of the passage/statue, and re-enter after stealing it to cure Chief. Just re-entering to cure him makes the passage work before they actually cure him.

Putting the poly in sChangeThief only helps if players stole the statue first, unprompted, and then opened the wall for the first time to cure him. Then they could walk through immediately.

Had the poly been in sBarrelMove, the passage would immediately work in both scenarios. Open the wall, immediately walk through.

However I don't see how it could be moved. Even if the walkable area could be extended with supplemental polys (I'm not too familiar with Polygon objects), instead of replaced entirely, I doubt there's space to squeeze that in.

[Vhati]

I don't see how it could be moved. [...] I doubt there's space

The polys are already declared in rm340::init().

local2 is unused.

IIRC only one Polygon is at issue here. init() could store it in local2, making it available to add anywhere without declaring again from scratch.

[Vhati]

rm340::init() has a cond block that decides among 3 walkable areas, and the third condition includes a Feature object that exits when hero walks onto it...

I've got 3 patches.

• Jump in and out of the cond to always declare the 3rd polygon. Store it in local2.
• Call addObstacle(local2) from sBarrelMove.
  • This is a really tight fit. Still working on it.
• Skip the addObstacle() in sChangeThief.

[Vhati]

Looks like sBarrelMove has derelict code.

At some point during development, it was possible to move the barrel back and forth, re-hiding the puzzle mechanism. Now it only reveals once and stays put.


script 340 - barrel::doVerb(4)

(cond
	# Passage revealed flag.
	((proc0_4 254)
		# "You don't need to do anything else with the
		#   barrel. Don't bungle the job!"
		(global91 say: 6 4 27)
	)
	# Desk opened flag.
	((proc0_4 241)
		# x=116 if the barrel has already been moved to reveal the puzzle.

		(if (== x 116)
			(g2_myCurrentRoom setScript: sBarrelMove 0 1)
		else
			(g2_myCurrentRoom setScript: sBarrelMove 0 0)
		)

		# Those lines schedule sBarrelMove with "register" set to 1 or 0.
	)
	(else
		# "There does seem to be something under this barrel,
		#   but you've got no clue of what to do with it."
		(g91_gloryMessager say: 6 4 104)
	)
)

Because a cond block short-circuits, if sBarrelMove is scheduled, flag 254 can't have been set. So when sBarrelMove tests the flag, it will always be false.



script 340 - sBarrelMove::changeState()

(0
	0
	(global1 handsOff:)
	(if
		# x=116 and register=1 are synonymous.
		# Flag 254 is never true here.
		(and (== (barrel x?) 116) (not (proc0_4 254)))
		(self changeState: 6)
	else
		# States 1-5 will only run with x != 116, aka register=0.
		(= cycles 1)
	)
)
# ...
(2
	2
	(if register
		# "You slide the barrel back into place covering
		#   the lock mechanism."
		(global91 say: 6 4 18 0 self)
	else
		# "You depress the barrel tap, but nothing comes out.
		#   Instead, the barrel slides across the wall to reveal
		#   some sort of mechanism."
		(global91 say: 6 4 19 0 self)
	)
)
(3
	3
	(barrel setLoop:)
	(if register
		(barrel setMotion: MoveTo 132 148 self)
	else
		(barrel setMotion: MoveTo 116 148 self)
	)
)
# ...
(5
	5
	(g0_hero
		normalize:
		cycleSpeed: local4
		posn: (if register 149 else 159) 131
	)
	(if register (= state 11))
	(= cycles 1)
)

Any code in states 1-5 based on register=1 is derelict.

[Vhati]

​Pull Request: SCI32: Fix QFG4 guild secret passage

[Filippos Karapetis <bluegr@…>]

In 603115d:

SCI32: Fix QFG4 guild secret passage

Fixes the walkable polygon not changing when it's revealed, bug #9894