Menu
▾
▴
#5172 SCI: QFG3: Crash in conversation
closed-fixed
5
2012-10-07
2010-08-06
No
Quest for Glory 3 (Dos/English)
ScummVM 1.2.0 51782
Windows 7 x64
When talking to Uhura in the village after using the dispel potion on the leopard-woman, if you choose the question about "Woo", the game will crash. No other dialogue will. It's not terribly critical, but it was kind of surprising. Crashes with the message:
"[VM]kMemory: signature mismatch via method ::export 6 (script 999, room 440, localCall 0xffffffff)!"
Um, the save game says "qfg1:, is that for qfg3?
Whoops >< fixed.
That save game is when you're about to be judged... perhaps it's a different one?
Geh, sorry. I guess they're numbered a bit differently than I thought. Made a new save, this one should be the right one at last.
the right one
Could you please check what sierra sci is doing in that case? Maybe its a gamebug. I would try to patch it in that case. Otherwise we need to figure out whats going wrong.
Can't seem to reproduce this in dosbox. You might also be interested to know that the character saves generated by ScummVM don't work in the original interpreter.
The saves are of course not compatible. The only save-files, that can be used from sierra sci are the export-character files from quest for glory series.
I was talking about the character exports :)
I guess they are only compatible SCI -> ScummVM, not the other way around.
ScummVM export files are compressed (like all ScummVM created files are). If you uncompress them, they work just fine in sierra sci.
I tried fixing this call, but then the game crashes later on anyway in other places. This looks like some sort of buggy script, so we should better patch it or ignore all of its incorrect calls
Fixed in r4766774, it was a script bug which made it loop indefinitely, thereby reading garbage data and crashing
Reopening this, as this script patch caused a nasty bug in another conversation in the game (bug #3377429).
Here's the problematic patch, for reference:
// Script 23 in QFG3 has a typo/bug which makes it loop endlessly and
// read garbage. Fixes bug #3040722.
const byte qfg3DialogCrash[] = {
5,
0x34, 0xe7, 0x03, // ldi 3e7 (999)
0x22, // lt?
0x33, // jmp [back] ---> BUG! Infinite loop
0
};
const uint16 qfg3PatchDialogCrash[] = {
0x34, 0xe7, 0x03, // ldi 3e7 (999)
0x22, // lt?
0x31, // bnt [back]
PATCH_END
};
This is very likely a script bug.
When I tried in the original, saying "Woo" worked without a crash, but afterwards I couldn't speak to Uhura again.
I looked at the relevant script, and it seems the Teller script object works with lists of options/subconversations in uhuraTeller::arrays (The current one is uhuraTeller::curArray). Each array is a list of integers corresponding to conversation options. When such an integer is negative, it is interpreted as an option with a submenu (and its absolute value is the message number for the option). The array uhuraTeller::keys contain the conversation options that trigger each array in uhuraTeller::arrays.
(So keys[1] is the conversation option leading to opening the subconversation in arrays[1].)
The problem here is that the option for "Woo" is -75, but there is no -75 in uhuraTeller::keys, so it runs out of bounds while trying to locate it. [ SSCI most likely found it somewhere later in memory and then set uhuraTeller::curArray to some bogus value, breaking conversation. ]
A fix would be changing this -75 to +75 in the locals of script 440.
One complication is that -75 is also the trigger for some puzzle points, and this is handled inside uhuraTeller::doChilld, which is the function handling submenus. So simply replacing -75 by +75 will break getting points for asking about Woo...
New strategy: force a return in uhuraTeller::doChild after handling the hero::solvePuzzle call, and prevent the submenu from actually being opened.
This is now hopefully fixed in d1e2d61b781aab5a0cc832a05a0981765fc4b0fe.