Messages

166

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: June 03, 2016, 06:17:31 PM »

More bugs (in my private build from trunk):

• It's no longer possible to retain numbered filenames for decompiled scripts. The application is setting the file names to their script names regardless of what you do.

That's an intentional change. It will automatically set filenames now.

There's a bug with setting filenames in the current release. Case is not ignored. In QFG1 EGA for instance, script 32 is called Rock and script 54 is called rock.  Needless to say, only the latter is saved when decompiling (or rather script 32 is created first, then script 54 overwrites it. Also in the same vein, sorting by script name in the explorer doesn't ignore case, so all Uppercase scripts come first, followed by lowercase ones.

[edited: I was mixing up case sensitive and insensitive. SCI companion is currently case sensitive for script names. ]

167

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 20, 2016, 04:55:25 PM »

*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.

I've taken another look at some other LB1 scripts, with an eye to the species order... am I reading this correctly? If I look at the Script Resource for Feature.sc (script 998), I see there are 7 classes and they start at index 24 (in hex). So does this mean using the "dummy" method of correctingit, I would have to insert 36 dummy classes before the "Feature" class?

168

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 19, 2016, 08:54:16 PM »

Well, they probably just removed that script then forgot it was accessed in an if statement that (apparently) never gets hit. Dunno if it's bad coding practice - maybe just the victim of a compiler that didn't treat this as an error.

You're absolutely right. I'm making wild assumptions without knowing any of the facts.

I saw LB1 doesn't use this feature, so there was no need to include the SORTCOPY.SC script with the game.

And there ya go.

If you're interested in this missing script, here some information:

I'm very interested in this sort of stuff. The Sierra games of old have given me thousands of hours of entertainment over the years, at least, and I find it fascinating to peel back the layers or look behind the curtain, so to speak.  Thank you very much for sharing.

169

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 19, 2016, 09:11:51 AM »

Did you decompile all the scripts in the game?

Yup. Decompiled them all a couple times each.  Which script number is generally User.sc?
(And just to double-check, SCICompanion's About Box says it's version 3.0.1.7, which I believe is still the latest official release...)

That's the general gist of it, but this is specific to species indices - it has nothing to do with procedures or methods. Each class (or species) has a number associated with it.

Ah, I was mixing up classes and procedures. So the fact that 999 itself wasn't compiling was a bit of a red herring.

I wonder how prevalent missing procedures are in Sierra games in general... I've already seen Colonel's Bequest has a couple. Heck, there's a whole missing script file referenced in there (984).

Well I've decompiled a lot of games, and this is the first I've seen of it that I can remember. Although I think there are still some mysterious compile errors in decompiled games that I haven't had time to look into - so perhaps this was the cause of those too.

I don't know if it decompiled properly or not, but it sure looked like it decompiled properly. Script 996 has the reference to phantom script 984, and even references a specific procedure from it:

Code: [Select]

(proc984_0 alterEgo gSFeatures gCast gFeatures)It's funny, LB1's showing several areas that I would consider to be bad coding practice.  This if statement that leads to a procedure call that doesn't exist, for one. For another I believe there's a 1 in 600 chance of the game crashing on startup at the copy protection screen.

Correct, it shouldn't need to be included.

And it did. The compiled script now behaves exactly as expected.

btw, I hope you're not making a patch to remove the fingerprint "copy protection".

I'm certainly not doing any such thing for distribution purposes.  At some point in the future I want to create my own game in the vein of QFG (There's been a bit of a boon of those types of games lately, Quest for Infamy, Heroine's Quest, Betrayed Alliance), but for now I'm satisfying myself with decompiling/commenting existing games, making minor bug fixes, then making slight mods to existing games. But mostly just soaking in the SCI coding structure.

170

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 18, 2016, 11:30:46 PM »

Ok, it looks like the LB1 issue (and presumably KQ4) only happens right after a decompile, right?

No, I should have been clearer. That's how I first got the crash. I could then immediately re-open SCICompanion, hover over the lines I specified, and watch it crash again.

So let me see if I understand this: each script keeps a lookup table of index numbers for each procedure/method in it. SCICompanion will automatically generate that lookup table based on the order each procedure appears (a perfectly logical approach). The Classic Sierra compiler generated that lookup table based on some other reference (likely some sort of text file), the consequence of which is that lookup indexes will not necessarily be in order.

Any script (A) that includes a reference to another script's (B) procedures does so by referencing (B)'s lookup table index. So my recompiled 414 script failed to work because it was referencing procedure index 5 in SCICompanion's compiled 999.scr, when it needed to reference index 6 in Classic Sierra compiled 999.scr.

I'm happy for you to add automagic anywhere you want, but I'm not one for waiting. I like your idea of adding in a dummy procedure in the 3rd spot so the other indexes realign. I suspect I wouldn't need to add the other two dummy's to padd out the end of the table, but 'ellifiknow. As for compatibility with SCI Studio... I'm new to this scene, so my opinion shouldn't have that much weight, but honestly my impression has always been that there was minimal serious development on SCI Studio anyway due to the whole chicken/egg thing with VGA support.
 
I wonder how prevalent missing procedures are in Sierra games in general... I've already seen Colonel's Bequest has a couple. Heck, there's a whole missing script file referenced in there (984).

Soon as I get the chance I'll try the dummy filler method. I'll have to compile 999 for SCICompanion's benefit, but I shouldn't have to include that if I wanted to patch a vanilla copy of LB1, should I?

171

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 17, 2016, 09:16:47 PM »

Okay, so I'm now able to consistently reproduce the crashing I'm seeing.

I've seen is in both Laura Bow 1 (v1.000.046) and KQ4 SCI (v1.006.004). I think it's related to tooltips in some way.
In either game, I opened it up fresh, then decompiled the scripts 3 or 4 times. Then open script 000's source.

In KQ4 scroll down to procedure proc0_7 and hover the mouse over "setLoop:" for 2-3 seconds (below in gEgo , i.e. line 517).
In LB1 scroll down to procedure proc0_25 and hover the mouse over "said:" for 2-3 seconds (line 727).

Then SCICompanion will crash with an unhandled exception. (Unhandled exception at 0x00e0eb1e in SCICompanion.exe: 0xC0000005: Access violation reading location 0x000000f0.)

I also was able to make some progress on script 414 not compiling in LB1. It turns out it wasn't actually a problem with script 414, but one of the procedures in a referenced script (999).  So I made some changes to script 999 allowing it to compile, and then 414 compiled without complaint. 
However, I was surprised that I wasn't able to then take just 414 into a vanilla copy of LB1.  It would crash in both SCI and SCUMMVM.  I had to recompile all the other scripts (after correcting some minor compiler errors in a handful of other scripts) and I was able to get that running. 

So this brought up a couple of questions for me:
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?

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?

172

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 14, 2016, 11:10:25 PM »

I'll try and take better repro notes the next time it happens, but from memory it felt pretty random. Open a previously decompiled KQ4 or LB1, open a script (701 for KQ1, 414 for LB1) by double-clicking on it in the built-in explorer, change a couple procedure names or local variables with the built-in replace command, add some comments at non-specific intervals or locations, grab a coffee (two sugars), return to find it crashed.
It definitely wasn't after saving... I lost my work a couple times, so I started saving pretty religiously.

173

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 13, 2016, 11:40:02 PM »

Charles as in 'Unknown Hero"?

Yup, that's me. I see a lot of familiar names around these forums. I read about SCICompanion from MusicallyInspired's KQ6 post on the ScummVM forums.

That said, some games still have problems recompiling be it due to code errors by Sierra, assembly code blocks that the decompiler couldn't decompile, or still yet some minor problems with the decompiler itself. It's not exactly perfect.

Sierra coding errors would only be a problem if troflip's compiler is significantly different from sierra's original compiler, wouldn't it? (Which, I guess "significant" is really subjective... could just be stricter, for all I know)  And I was under the impression that (in theory) the asm code segments troflip's decompiler creates are recompilable as is... or do they need to be reconfigured by hand into Sierra Script before they can be recompiled?

Global find and replace would be nice, but I've just been using another editor (visual studio) for that.

Yeah, I'd probably use the same... or Notepad++. Either way, not too crazy. How well does SCI Companion handle scripts being changed out from under it? Or should I just close out SCICompanion beforehand then reopen after?

SCI Companion compiles scripts in the background to handle symbol lookups, tooltips, autocomplete, etc...

Okay, I figured it had to be doing something in the background the way it was crashing. Same thing happened when I was in KQ4, too.  I hope it's not related to the fact I was renaming local variables.... for the foreseeable future, that's going to be my strongest use-case.

I always get the later SCI versions mixed up... which came first... SCI32, or SCI 2?

174

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: May 12, 2016, 11:04:10 PM »

I just came across this project last week, and holy cow I am super impressed! SCI Companion 3 looks amazing. I am in complete awe over the features and amount of work you've put into this. I read through most of this thread and when I got to the part about LipSync support, I just about lost it. That is above and beyond anything I'd ever expected anybody to do.

My mind reels at the possibility of creating mods to some of my favorite Sierra games (goblin's hideout in QFG1? Extra planet in SQ3?), or fan patches for bugs/spelling/consistency, like the SQ1VGA thread, or creating enhancements to existing games like the SQV Fan Talkie thread. Simply amazing!

That said, I gave the latest version a try (3.0.1.7?) and I came across a couple of problems:
In theory, I should be able to recompile any script I've decompiled, right?
Laura Bow 1 was giving me some problems when I tried to recompile script 414. And would actually outright crash. Unhandled exception style. Not sure exactly why. It wasn't in response to me *doing* anything, unless it was trying to do something in the background.
Also, the Find/Replace wasn't working as I'd expected. I enjoyed adding comments to the decompiled code, trying to figure out how it works -- it's like doing the crosswords, for me -- and renaming variables and procedures as I learn what they're for. Trouble is I couldn't find any global Replace command (like the global find CTRL+SHIFT+F), without which it's practically impossible to rename global variables/procedures.
And the CTRL+H replace doesn't replace within the whole document ... only from the cursor down. I have to click it again to replace from the top. Not to mention the message it gives -- "<string> not found" -- is a little less useful than something like "3 occurrences replaced" or similar.

Anyway, these are mostly minor annoyances on what is otherwise and amazing program. If I'm using it wrong, can somebody please let me know the proper way?