Opened 2 years ago

Closed 8 months ago

#9894 closed defect (fixed)

QFG4: Thieves guild secret passage isn't immediately walkable

Reported by: tsoliman Owned by: bluegr
Priority: normal Component: Engine: SCI
Keywords: SCI32 original pathfinding has-pull-request Cc:
Game: Quest for Glory 4

Description

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.

Attachments (2)

qfg4-cd-thief.016 (53.0 KB ) - added by tsoliman 2 years ago.
savegame
Polygon - Walkable area and passage region.png (47.6 KB ) - added by Vhati 11 months ago.
Polygon - Walkable area and passage region

Download all attachments as: .zip

Change History (17)

by tsoliman, 2 years ago

Attachment: qfg4-cd-thief.016 added

savegame

comment:1 by mrprmiller, 2 years ago

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.

comment:2 by tsoliman, 2 years ago

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

comment:3 by csnover, 2 years ago

Keywords: sci32 added; SCI32 removed
Summary: SCI32: QFG4: Can't use thieves guild secret passageSCI: QFG4: Can't use thieves guild secret passage

comment:4 by csnover, 2 years ago

Keywords: pathfinding added

comment:5 by Vhati, 11 months ago

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

comment:6 by Vhati, 11 months ago

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)
		)
	)
# ...
)

by Vhati, 11 months ago

Polygon - Walkable area and passage region

comment:7 by Vhati, 11 months ago

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))

Last edited 11 months ago by Vhati (previous) (diff)

comment:8 by Vhati, 11 months ago

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.

Last edited 11 months ago by Vhati (previous) (diff)

comment:9 by Vhati, 11 months ago

Keywords: SCI32 original added; sci32 removed
Summary: SCI: QFG4: Can't use thieves guild secret passageQFG4: Thieves guild secret passage isn't immediately walkable

comment:10 by Vhati, 9 months ago

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.

comment:11 by Vhati, 9 months ago

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.

comment:12 by Vhati, 9 months ago

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.

comment:13 by Vhati, 9 months ago

Keywords: has-pull-request added

Pull Request: SCI32: Fix QFG4 guild secret passage

Last edited 9 months ago by Vhati (previous) (diff)

comment:14 by Filippos Karapetis <bluegr@…>, 8 months ago

In 603115d:

SCI32: Fix QFG4 guild secret passage

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

comment:15 by bluegr, 8 months ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.