Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#6706 closed defect (fixed)

SCI: QFG1 VGA - rapidly purchased potions do not appear in inventory

Reported by: tomasz89 Owned by: m-kiewitz
Priority: low Component: Engine: SCI
Keywords: original script Cc:
Game: Quest for Glory 1

Description

scummvm -v
ScummVM 1.8.0git169-gc3f3b62 (Aug 10 2014 10:58:12)
Features compiled in: Vorbis FLAC MP3 ALSA SEQ TiMidity RGB zLib MPEG2 FluidSynth Theora AAC FreeType2 JPEG PNG
Also tested with scummvm 1.7.0 from Gentoo portage: same results.

Bug Details
Buy several potions from the healer in rapid succession, then immediately check inventory. None will appear. If the inventory is checked after ~2 seconds, only the last purchase will appear.

If a pause of ~2seconds between purchases is made they will appear as expected.

Game Language
English

Game Version
QFG1VGA from Quest for Glory Anthology CD, and tested also the same version but with NRS patches (both exhibit the same problem).

Platform and Compiler
Gentoo x86_64 (gcc (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3)

Ticket imported from: bugs/6706.

Attachments (1)

qfg1vga-1.003 (32.1 KB ) - added by tomasz89 5 years ago.

Download all attachments as: .zip

Change History (11)

by tomasz89, 5 years ago

Attachment: qfg1vga-1.003 added

comment:1 by digitall, 5 years ago

Summary: QFG1 VGA rapidly purchased potions do not appear in inventorySCI: QFG1 VGA - rapidly purchased potions do not appear in inventory

comment:2 by m-kiewitz, 5 years ago

Keywords: original script added

comment:3 by m-kiewitz, 5 years ago

I was just able to reproduce this bug in SSCI as well (the original interpreter made by Sierra). It looks as if this is a script bug.

comment:4 by m-kiewitz, 5 years ago

fixed in 1f65284ada41b7156b5d68507fcdad6255694140

the actual buy/steal transaction was delayed by sierra for 60 ticks (which is a second). I don't know why and it doesn't really make sense. I changed it to 1 tick, so that the code gets executed as soon as the dialog boxes are closed. This seems to solve it.

comment:5 by m-kiewitz, 5 years ago

Owner: set to m-kiewitz
Resolution: fixed
Status: newclosed

comment:6 by tomasz89, 3 years ago

Assuming this is the way most people will get the game these days, I've just tried the GOG version and unfortunately the problem exists (again?).

comment:7 by m-kiewitz, 3 years ago

Someone just checked for me.

It seems GOG added a fan made patch, which isn't just a regular byte patch of an original Sierra script, but rather a recompiled script. Our script patch signature doesn't match with it, because the used compiler creates different byte code.

If you can start right from the start, you could simply delete the files 55.scr + 55.hep. That will remove this fan made script patch and the signature should work again.

There is a similar situation with QfG3, where quite a few fan made patches were added by GOG and the game has quite a few problems because of it.
see: https://sourceforge.net/p/scummvm/bugs/6806/

Yorick's room at the end of the game is also not patched because of those fan made patches.

It seems 6 scripts were patched that way.
31, 39, 55, 91, 96 and 222

ScummVM definitely does not need those patches. So as I said - in case you just started, then you should probably remove those files, when you play using ScummVM.

comment:8 by tomasz89, 3 years ago

Thanks. I agree that this is somewhat out of your control; what is the policy here for ScummVM? Is it a matter of ScummVM working around (or with) these versions/variants, or is it up to the user to experience misbehaviour and then find a bug report like this :)

I seem to recall a vanilla QFG+NRS causing ScummVM to warn about the situation, yet I didn't receive a dialog for this particular version.

I think the key aspect to consider is that the GOG versions are what most people are going to get from here on in....

comment:9 by m-kiewitz, 3 years ago

Atm I'm trying to rewrite ScummVM's way of saving SCI games, so that removing such script patches won't affect saved game compatibility.

In case that works out, then users could remove the patch files after updating all their saved games.

We should probably warn the user about this, still right now removing those files will basically break all saved games that include data from those scripts, which is of course unacceptable.

comment:10 by tomasz89, 3 years ago

I think it's OK to break save compatibility from time to time; it'll save show stopping bugs (like the one you mentioned in QFG3) and much anguish later. The situation is pretty much outside of your control.

I agree that a warning would be good - it'll at least prime users for the rocky road, or perhaps link them to the stuff they can do prior to launching (like removing the files you mentioned) so they don't encounter badness.

Note: See TracTickets for help on using tickets.