SCICompanion compile issues with LB2CD

[doomlazer]

SCICompanion seems to have issues with LB2CD where scripts expect WrapMusic to have the class value of 0x86 and Actions to be 0x2E, but decompiling results in a .sco file where WrapMusic is 0x2E and Actions are 0x86.

Spanish translator Avo323 discovered if you swap the WrapMusic and Actions class definitions in main, it compiles other scripts with the correct class values that they expect and you can generate working patches that don't break WrapMusic; though if main (and .hep) is exported as a patch with this method it crashes the game. Actions is defined in both main and objCue and doesn't seem to care what the class value is (or is only using objCue version), where as a broken WrapMusic breaks audio in game; sometime resulting in later crashes because of undisposed audio.

So we have a solution to create working patches (barring changes to main, which can be hex edited), but it's still frustrating that it's unknown where the fundamental issue lies. LB2 floppy was missing a vocab file, but this seems specific to a 0.sco problem. It would be better to understand the cause, but I guess I can live without knowing if need be.

Is it a case of some Sierra dev making changes to main before release and not recompiling the other scripts? Curious if anyone has insight to this, before moving on.

[Kawa]

but decompiling results in a .sco file where WrapMusic is 0x2E and Actions are 0x86.

Very, very interesting. I just checked my copy and Main.sco seems to list them with the correct values? Did I misunderstand something or is it a version difference?

In fact, just in case it was a version difference I made a backup copy of the older Main.sco, decompiled it, and checked again. Things moved a little because the bitfield procs weren't named anymore, but the numbers were the same. So either the old decomp was made in a recent-enough version that whatever ailed it was already fixed. I don't know, I just woke up.

[doomlazer]

Hmm... I thought there was only one version of LB2CD and I'm experiencing the same results as avo323. I believe mine came from GOG?

[Kawa]

I meant a difference in SCI Companion versions.

[doomlazer]

ah, I know Avo tried both an icefall games and kawa build with the same results. I always use a 'recent' nightly build, though I'm probably using something from July-ish. Will double check with the latest when I'm able, but not sure why you can't reproduce it.

[Kawa]

Latest is from October, but whatever changed must've been way earlier than that.

So perhaps there is a version difference in LB2CD itself?

*checks ScummVM detection table*

English CD version is available for DOS and Windows, but the resource.000 and resource.map files are listed with the same hashes.

[doomlazer]

Ok I guess you have to compile script 0 in SC for it to swap the values in main.sco. I thought decompiling all scripts was enough, but testing again proves otherwise.

Still weird it swaps them.

[Kawa]

I... I didn't compile anything though?

[doomlazer]

but if you were to compile lb2 main I'm assuming it would swap them, witch is spooky

[Collector]

You have game version differences dismissed as a factor, but for confirmation I believe doomlazer is correct that only one version of the MPC version was released. I have several copies and all of them are v1.000.046.

[Kawa]

Guess I could scrounge up a guaranteed-clean copy and look again.

[doomlazer]

I think your copy is fine. To clarify, it decompiles with the correct values, same as you posted in the image. It's only if you compile main that it swaps them around. It's a bit baffling why that happens when no changes have been made.

[Kawa]

Then we're all on the same page. Good.

[lskovlun]

Does simply swapping the two class definitions help? (I'm talking about the location in the source file)

[Kawa]

I don't see how that would make any difference but I also can't seem to compile the darn thing to begin with.

Edit: okay yeah I started fresh and managed to compile it, so lemme switch the two around...

And my new Main.sco has Actions on 0x2E and WrapMusic on 0x86. Reverting the order and recompiling puts them in the opposite order again.