#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 |
| Version: | 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)
Change History (11)
by , 10 years ago
| Attachment: | qfg1vga-1.003 added |
|---|
comment:1 by , 10 years ago
| Summary: | QFG1 VGA rapidly purchased potions do not appear in inventory → SCI: QFG1 VGA - rapidly purchased potions do not appear in inventory |
|---|
comment:2 by , 10 years ago
| Keywords: | original script added |
|---|
comment:3 by , 10 years ago
comment:4 by , 10 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 , 10 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:6 by , 8 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 , 8 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 , 8 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 , 8 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 , 8 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.
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.