SCI: LSL6: Controls dialog misbehaves when subtitles are disabled in the low-res talkie version

[eriktorbjorn]

Current ScummVM development version.
Engilsh low-res DOS talkie version of the game.

1. Disable subtitles.
2. Open the Controls dialog.
3. Press the "?" button.

When hovering the mouse over the different parts of the dialog, it's supposed to display text messages explaining what the controls do, but this doesn't happen. (I thought I saw it lock up under some circumstances the other day, but if so I can no longer reproduce it.)

It's also funny how (when subtitles are enabled) the game still refers to the bottom knob as "Text Speed" when, in the talkie version, it has been repurposed as "Filth". But that's harder to do anything about, I guess.

The non-talkie version does not have this problem (since you can't disable subtitles), nor does the high-res talkie version.

[eriktorbjorn]

I remembered what the other issue was: If you reopen the Controls dialog again and press "?", it doesn't even show the instruction, or it shows them so quickly that there is no chance you'll be able to read them.

All of this seems to happen when playing the original in DOSBox as well.

[eriktorbjorn]

I have a vague idea about how it could be fixed.

Perhaps the show and hide methods of ControlPanel could be patched so that they enable subtitles temporarily while the control panel is shown?

I don't know if it's possible to add a new property to the dialog to store the old value of gMsgType, but since it appears to be a bit flag it would be possible to store the "text" bit in a previously unused bit, I suppose?

[eriktorbjorn]

On second thought, those scripts are probably too short to hide a script patch in.

I think the ControlPanel::noClickMessage() method is what displays the help texts. after being called by ll6ControlPanel::noClickMessage():

	(method (noClickMessage param1)
		(Print modeless: 1 font: gUserFont)
		(gMessager
			say:
				(param1 noClickNoun:)
				(param1 noClickVerb:)
				0
				1
				0
				(param1 noClickModNum:)
		)
	)

And that's where I start to flounder. It seems that gMessager is a variable, not an object, and it points to larryMessager. But that appears to be just an extension of Messager, so maybe Messager::say() is the interesting part? I'm lost.

Either way, at some point it will have to look at gMsgType, which can be either 2 or 3. I believe 2 is speech, while 3 is speech + text. From that perspective, it looks to me as if it's Narrator::say() that's the interesting part. A breakpoint in what the debugger calls talkTitleNar::say() seems to trace the call back through Messager::sayNext(), larryMessager::sayNext(), and larryMessager::say() so maybe I am on the right track after all.

For reference, this is what Narrator::say() does:

		(if (& gMsgType $0001)
			(self startText: theBuf)
		)
		(if (& gMsgType $0002)
			(self startAudio: theBuf)
		)

Narrator::say() is a larger method, so it may be easier to hide a script patch in. I just have no idea what it could test to detect that the text has no corresponding audio to play.