SCI: KQ7: Crash on reaching chapter 4

[Tricky1975]

I am currently playing Kings Quest VII, directly from the original CD-ROM through ScummVM.
Now I could get through the first three chapters nicely, however when I reached chapter 4 during the animation in which Rosella rights for a life when coming out of the pit in Ooga Booga (at the start of this chapter) this error occurred (see linked screenshot).
Something I can do to get rid of this error or is this a bug in ScummVM?

[m-kiewitz]

This may either be a problematic resource, or even problematic code, because our current MIDI code isn't accurate.
Effectively the current ScummVM code would read out of bounds, which would be bad.

That resource is only of size 24h, but it may be actually fine. In fact I see quite a few sound resources like that in King's Quest 7.

[Tricky1975]

I don't know if it's of any use to tell you this, but I tried to start a new game directly starting in chapter 4 (which was possible due to the chapter system both KQ7 and Phantasmagoria use), and now I got past this without any trouble. I guess this is one of those bugs that happen "randomly". And I also keep in mind it may not even be attached to that specific event in the game either.

[m-kiewitz]

I doubt it's actually random, because it's a problem with a specific sound resource.
That sound resource is tiny, so either a dummy, or even just a sound resource which may reset some marker or whatever. I would have to take a look at it.
So it may be the case that when you start that specific chapter, that this sound resource is simply not accessed/played, because it's not needed in that case, and thus can't cause this crash.

It could of course also be a broken sound resource.

As I said, our current SCI MIDI code is not accurate (unless someone rewrote it in the last years). It uses time stamps to my knowledge (it's actually using common ScummVM code, used by various engines), but Sierra's SCI actually used byte offsets. This alone causes all sorts of problems, but it's not simple to fix. There are quite a few open bugs because of it, but the only proper solution is a rewrite of that subsystem.

For example the sound resource may say:

• change to instrument y
• now loop here
• play note x

and all on the same time stamp.

The loop command will currently save the time stamp.
So when the loop happens, the loop will start with "change to instrument y", which is incorrect. It should start with "play note x".

This alone may make a song use the wrong instrument for a certain channel.

And there may be further problems with the code, but as I said it may even be a broken sound resource. Broken resources sometimes happen in SCI games, where the original SCI even read out of bounds. For a DOS interpreter that's not really such a big problem. It's bad, but kinda works. For ScummVM it's unacceptable. again: I would have to take a close look at it, which I will probably do unless someone else does it first.

[m-kiewitz]

Oh, can you please tell your version of King's Quest 7?
Is it 1.51 or 2.00b?
Just to make sure I'm looking at the correct version.

You can check by reading the file called version. It's a text file. Just open it with a regular text editor.

[m-kiewitz]

that sound resource is the same in both versions, but I think it would still be better to know the version. I just checked. It also looks that's basically an empty sound resource, so maybe it's really a broken sound resource, or our code is just inaccurate and does things that it shouldn't do.

[Tricky1975]

According to the file named "VERSION" located on my CD-ROM I should have version 1.51 (which I kinda expected as I bought my copy when the game was pretty freshly released).

Oh and "random" was not meant literally. I am a coder myself and I am often faced with bugs that sometimes happen and sometimes do not making it look "random" when I'm sure it's not, but when I can't pinpoint the cause and having this happen sometimes and sometimes not, it feels "random", if you know what I mean. There was a reason I put it between quotes. 😉

[sluicebox]

I'm going to take a look at this, but bigger picture: you want to do whatever you can to play version 2.00b instead. It took them four major versions to get this right (1.4, 1.51, 1.65c). Most importantly: you can't control the walk speed until 2.00b (+ and - keys).

I've written and ranted about this: ​https://www.benshoof.org/blog/kings-quest-vii-munchausen-by-hotkey

[sluicebox]

I have investigated this and I am 99% sure there is no ScummVM bug and that this is a local problem. I suspect it involves the game being played directly off of CD. I recommend copying the files to your hard drive. I suspect your current environment is failing at basic file I/O. That would create what appears to be random errors.

The error message states that Sound 4076 has zero bytes. In fact, Sound 4076 has 38 bytes. That suggests a local problem.

As you can see, this isn't a MIDI parsing issue. There's nothing to parse!

I start these investigations with the game scripts. There is only one reference to "4076" in KQ7. It's in script 4050, as our error message says: ​https://github.com/sluicebox/sci-scripts/blob/main/kq7-dos-1.51/src/rm4050.sc

sChapter4IntroScript:changeState(3)

	(screamSound number: 4076 loop: 1 play:)

Just from that text we can see that we're in the right script, and that we should expect a scream to play, not a MIDI. Indeed, this script is supposed to play *Audio* 4076, a digital sample of Rosella screaming, not *Sound* 4076, a 38 byte silent MIDI. In SCI2, kDoSoundInit uses an Audio resource if it exists, otherwise it uses a Sound resource. That means the the game should never be using Sound 4076 at all; it only does that if the scream resource is missing.

These two distinct failures suggests that all of this is a unique local problem. Basic file I/O failure would explain both. Taking the CD out of the equation will hopefully fix this. (But again, I recommend switching to 2.00b anyway)

[m-kiewitz]

Does ScummVM ignore I/O errors?
Otherwise it would be very weird to have I/O errors, but no actual errors and just data being faulty?

[m-kiewitz]

Oh

That means the the game should never be using Sound 4076 at all; it only does that if the scream resource is missing.

And that's not for certain.Sierra sound code is complicated, and digital sounds were hacked into the engine (not our fault). I can't remember everything anymore,but it's a nightmare.

SCI even plays MIDI when the computer isn't capable of digital audio as a replacement sound. And it makes sense that the sound resource is parsed regardless.

[sluicebox]

We're talking about the scream that always occurs at the start of chapter 4, not some hypothetical. There is no weird Sierra code involved in this equation. You may not be certain, but I've investigated, so I am. =)

I am suggesting that the OP's environment is silently failing I/O inconsistently at a layer below ScummVM. I don't know exactly what that looks like, but we're talking about a mandatory scene in a popular game randomly failing in multiple low-level ways for one person, and I haven't heard any other explanation that survives basic analysis.

[sluicebox]

Four months of silence and I'm not surprised; there is no bug here, just a local problem due to incomplete / corrupt game files. It feels like that's the majority of SCI tickets that get created these days, which I guess is a good sign, but it's still kinda depressing.

My favorite thing about this bug tracker is that anyone can re-open tickets. It lets me say bold things, and take action, and be right, while also allowing people to come back later and disprove me when I'm wrong. I've closed a lot of tickets like this; guess how often that's happened! That lets us safely close invalid tickets without letting them languish for years, which as we've seen, is the default state, and one I'm proud to put an end to.

Closing as "I Was Right", er, I mean, invalid! ;)