Community
SCI Programming => SCI Syntax Help => Topic started by: doomlazer on October 08, 2025, 09:14:16 PM
-
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.
-
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.
-
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?
-
I meant a difference in SCI Companion versions.
-
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.
-
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.
-
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.
-
I... I didn't compile anything though?
-
but if you were to compile lb2 main I'm assuming it would swap them, witch is spooky
-
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.
-
Guess I could scrounge up a guaranteed-clean copy and look again.
-
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.
-
Then we're all on the same page. Good.
-
Does simply swapping the two class definitions help? (I'm talking about the location in the source file)
-
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.
-
This order switching seems to happen with other files as well. in rm710 ramse_a & ramses_b get flipped, but that seem benign.
Here's a list Avo gave me of scripts that seem to do this:
ClickMenu.sco
Gauge.sco
InvI.sco
Lesbian Flapper.sco
Lo Fat.sco
O'Riley.sco
Talking Bear.sco
Main.sco
rm220.sco
rm240.sco
rm260.sco
rm280.sco
rm710.sco
rm770.sco
-
Talking Bear.sco
I find that rather hard to believe. Talking_Bear.sco contains only one object, and it's an instance, not a class. It doesn't have a class number of its own. Similar for some of the other talkers.
-
oops that was a list of files to check for the problem. I assumed they all did as rm710 has the ramses a & b swap.
-
As I'm looking at the byte code, I notice recompiling might be making some small instruction changes. Like from 0x00 to 0x01 and 0x02 to 0x03. This reference (https://sciwiki.sierrahelp.com/index.php/SCI_Specifications:_Chapter_5_-_The_SCI_Virtual_Machine#The_instruction_set) seems to show there are many duplicate instructions that take the same number of bytes as parameters.
op 0x00: bnot (1 byte)
op 0x01: bnot (1 byte)
Binary not:
acc ^= 0xffff;
op 0x02: add (1 byte)
op 0x03: add (1 byte)
Addition:
acc += pop();
So why all the duplicates? Place holders?
-
It's like the reference says right at the section you linked: the lowest bit of the opcode byte species the operand size. So an opcode can take either a byte or a word, right? But when it takes no operands like bnot, that just makes both of them do the same thing.
You can tell from ScummVM's interpretation, they take the opcode byte, remember the original value for later, then shift it right to get the final opcode. So 0x02 and 0x03 are effectively both add, sharing a single handler.
What I'd like to know (not really) is when they changed that to having the "duplicates" be error-raising dummies, as seen in the SCI11 source code. That has a full 256 items worth of jump targets. With the above behavior, you might think they could've made do with only 128. But what do I know.
As for minor recompilation code changes in general, I've seen and documented some benign differences before, like "do I push1 (one byte) or do I push 1 (two bytes)?" where IIRC the original SC compiler at the time picked the latter, but SCI Companion picked the former.
-
I guess it does explain that right in the notes above the instruction list. Makes sense now. ty
Edit: SC also seems to like to replace whitespaces in instance names; such as changing 'Talking Bear' to 'Talking_Bear'