Ok, it looks like the LB1 issue (and presumably KQ4) only happens right after a decompile, right? When I re-open the game again, I can't repro it.
I had already made a fix to Companion (unreleased) to avoid the crash, but I never found the root cause. I'll try to look more deeply now.
As for the compile issue with 414, the actual problem is that the global class table (vocab 996) in that game is out of sync with the script files. It's a list of script numbers, and the position of script numbers in that file correspond to the index of a class in that script. For instance, species 5 is supposed to be the 5th class defined in script 999. The 5th class (0-based) in script 999 is Script. But, Script defines itself as species 6 in the script 999 resource. So the script resources are out-of-sync with the class table resource (vocab 996).
I forget the exact way Sierra compiled, but I think the class table was a text file in their compilation system, and the compiler looked at that. Then it would be occasionally compiled in to vocab 996 itself. I'm guessing the game doesn't do anything with vocab 996.
So, to workaround it or fix it, there are a few options:
- Tools -> Rebuild class table. The problem is, this means you have to recompile all afterwards - which is a problem if the scripts don't compile for other reasons. And it it more likely to expose any bugs in the decompiler that may have produced compilable but incorrect code, and your game will behave weirdly or crash for a hard-to-diagnose reason.
- Manually try to fix things up by inserting dummy classes in the right spots. For instance, inserting a class between Code and Collect in script 999 should fix up that particular issue with Script (999 would need to be recompiled). However, script 999 has ten entries in the class table, but only 7 scripts defined in the actual code. And I assume other scripts have similar issues, since the class table is generally out of date. So you'd need to do this for all scripts that define classes*.
- Wait for me to make a fix to the decompiler that will do this automatically :-)
- I could change the way Companion compiles to avoid this mess (e.g. by generating a classtable.txt that would be used, instead of the vocab 996), but I was trying to maintain parity with SCI Studio's compilation system. Plus that's a lot of risky work.
If I just change procedure names and variable names without changing the content/order of them, is the compiled output compatible with the existing compiled scripts?
Should be.
Can I change the contents of procedures and methods etc and expect existing scripts that call those procedures/method to continue calling them, or will they fail outright?
The contents? Sure, that will be fine. Callers are ignorant of the contents of the methods/procedures. Of course, if you change their behavior in a way that affects state the callers use....
*To do this audit, you can get the species index from the class table, and compare it to the one defined by the object in the script resource (Script->View Script Resource). The species of a class is property 0, the first entry right under the "properties:" header for each class. If you do this for script 999, you'll see the classes have species 0, 1, 3, 4, 5, 6, 7. Hmm, so actually just a single dummy class between Code and Collect should fix that particular issue up. Oh actually wait, no, you'll need to add 2 more dummy classes at the end, since we're trying to preserve the integrity of the class table. ugh, complicated.
