SCI1.1: Talkers. They're weird.

[Kawa]

So here's a thing regarding talkers.

With each talker in their own script, like in most Sierra games (SQ5 Droole and Flo being script 1885 and 1886 respectively), it seems the template game doesn't use them the way one might think:

Script 1001, chelsie.cs

Code: [Select]

(instance public Chelsie of CDTalker //listed as #1 in the exports table. A CDTalker has back 21, font 4, x 53, y 70.
(properties
view 1001
font 53 //override CDTalker's 4
)

(method (init)
DebugPrint("Chelsie:init()")
(super:init(tBust tEyes tMouth))
)
)
Script #0, main.sc

Code: [Select]

(instance public Ilira of CDTalker
(properties
view 1002
font 53 //again, override CDTalker's 4
)

(method (init)
DebugPrint("Ilira:init()")
(super:init(tBust tEyes tMouth))
)
)
And then, also in main.sc:

Code: [Select]

(instance testMessager of Messager
(properties)

(method (findTalker talkerNumber)
(var temp0)
DebugPrint("testMessager:findTalker(%d)" talkerNumber)
= gCurrentTalkerNumber talkerNumber
= temp0
(switch (talkerNumber)
(case NARRATOR
gSQ5Narrator
)
(case CHELSIE
DebugPrint("Chelsie, you're up!")
ScriptID(1001 1)
)
(case ILIRA
DebugPrint("Ilira, express yoself!")
Ilira //mind you, this is in the same script!
)
// Add more cases here for different narrators
// (case 8
//ScriptID(109 7)
//)
)
(if (temp0)
return temp0
)(else
return (super:findTalker(talkerNumber))
)
)
)
I've set up the two "touching yourself" messages accordingly. With tracing DebugPrint calls, this yields the following:

Code: [Select]

testMessager:findTalker(3)
Ilira, express yoself!
Ilira:init() //<-- this happens.
CDTalker:init()
CDTalker: positions set, calling super:init()...
Talker:init()
testMessager:findTalker(2)
Chelsie, you're up!
//Something is missing here.
Talker:init()Net result: Chelsie's portrait appears in the top-left corner, her dialog is in font 0 (despite having changed Talker's font to 4 in my tests?), on a light gray (7) background. Meanwhile, Ilira has none of these issues, with a nice tan dialog (as CDTalker specifies) and a funky chunky font.

So yeah. What's missing here that causes Chelsie to not init?

[Kawa]

Okay this is weird. I could find no meaningful differences between this, LSL6, and QFG1V, but somehow, exporting Chelsie as #10 fixed it? Now both characters are separated like that, as intended.

[lskovlun]

Okay this is weird. I could find no meaningful differences between this, LSL6, and QFG1V, but somehow, exporting Chelsie as #10 fixed it? Now both characters are separated like that, as intended.

You may be running into a memory problem here. We (the ScummVM team) ran into a problem with LSL5 once where, when switching egos, things were not handled properly. It happened to work in SSCI, because of a coincidence regarding memory layout. You should probably be looking for previous talkers (not Ilira; as you say, she's in script 0 and therefore special). If the Chelsie object happens to be loaded on top of a previous talker, problems could arise due to global variables not being updated. The different memory management in ScummVM might provide a clue - have you tried it?

[Kawa]

I only have these two and the narrator, though. I'll have to see if I can re-break it before I can try ScummVM but I'll do so now.

...and of course it won't break again.

[lskovlun]

...and of course it won't break again.

Then it's probably a case of changing something global (adding/removing a global variable or class) without recompiling the world.
Either that, or forgetting to recompile the talker script itself.

[troflip]

Yeah, my guess is that your whole problem was just that some scripts needed to be recompiled.

[Kawa]

Plot twist: I've made a point of using the Compile All button almost exclusively. But what the hey, it works now.

[lskovlun]

Troflip, does the Compile all thing track dependencies?

[troflip]

It does not. It probably wouldn't be too hard to add support for that, so a "full compile" can be done a little more quickly. But I haven't invested time into that.

Ideally you'd only want certain things to trigger recompiles of other scripts (changing exports, addingn classes, moving global variables around). And determining if one script has a dependency on another isn't just a case of looking at the "uses", since you'd also have to scan for ScripdID calls too... Which pretty much requires a compile (the syntax parsing is the most expensive step of compiling). So I guess I'd need to track dependencies in some separate file or something.

So maybe it's not so trivial.