Hacking SQ1VGA with SCICompanion v3

[spiffythedog]

Hello there,

I've been planning on making a small patch for Space Quest I VGA using SCICompanion v3 that fixes some typos ("That's a smell jet ack, all right, but for exploring space, you need a real ship.") and prevents the Time Pod from SQ4 from materializing on-screen after you take off in the mugger's spaceship. This latter change fixes a number of continuity issues with SQ4, as in that game the pod actually appears one screen to the right (just outside the loading bay for Droids B Us) and a considerable amount of time after Roger had left, enough time for Tiny to rebrand his business and for Droids B Us to file for Chapter XI. Simply removing the time pod animation from the scene ought to fix this.

I'm just having a bit of trouble trying to change/compile the script. I've isolated the room/script number (45) and I think I've identified the specific line(s) of script that needs to be modified. But the changed syntax makes it impossible for me to compile the script file and see whether it works or not in the actual game.

It's also quite apparent that I'm a complete noob at this, and am only interested in modifying existing games rather than building them from the ground up. Is there a specific tutorial that could help me out here?   

[Kawa]

Changed syntax shouldn't prevent compilation. What does prevent compilation is broken decompiles, like radar1::doVerb: CorruptFunction_CantDetermineCodeBounds. Putting a ; on that line will fix it, but kill any interactions with that prop. Another problem is that tiny::doVerb has odd cases, and  is somewhat more difficult to fix without making the game unbeatable. Both of these appear no matter which language you decompile to.

Decompiling script 45
ERROR: Invalid branch target.
Generated [REDACTED]\space quest 1\src\rm45.sc
Decompiled 29 of 29 functions successfully (100%).
Overall bytecount success rate: 100%.

Edit: The EGA version does better, with only one of these problems. Unfortunately, it's tiny::doVerb.

Edit?: I felt like a challenge, so I did it manually. Extracted 45.scr, used a hex editor and disassembly to change the last two states from 9 and 10 to the opposite order, effectively skipping the timepod.

Code: [Select]

code_126e: dup ; 3C
ldi 9 ; 35 09, change to 0A
eq? ; 1A, if not 9...
bnt code_12af ; 30 3A 00, ...jump ahead to code_12af, the next case.
...
code_12af: dup ; 3C
ldi 10 ; 35 0A, change to 09The missing 'p' would go at 0x26CC in the extracted file.

[lskovlun]

This seems to be a regression - I tried it with an old version of Companion, and it worked fine...

EDIT: To clarify, "old" does not mean version 2, it means whatever beta version of v3 was current when I did this.

[MusicallyInspired]

Which version? I've backed up every release until now. It's displayed in the About dialog.

[lskovlun]

Looking closer, I can't even reproduce with the the latest version. Strange. Were there multiple versions of SQ! SCI? Is it choking on some change that spiffythedog was making?

[Kawa]

It's not Spiffy's changes that choke it. It seems I have the same version as he, with the added twist of the EGA version choking on Tiny's changestate, too.

[spiffythedog]

Changed syntax shouldn't prevent compilation. What does prevent compilation is broken decompiles, like radar1::doVerb: CorruptFunction_CantDetermineCodeBounds. Putting a ; on that line will fix it, but kill any interactions with that prop. Another problem is that tiny::doVerb has odd cases, and  is somewhat more difficult to fix without making the game unbeatable. Both of these appear no matter which language you decompile to.

Decompiling script 45
ERROR: Invalid branch target.
Generated [REDACTED]\space quest 1\src\rm45.sc
Decompiled 29 of 29 functions successfully (100%).
Overall bytecount success rate: 100%.

Edit: The EGA version does better, with only one of these problems. Unfortunately, it's tiny::doVerb.

Edit?: I felt like a challenge, so I did it manually. Extracted 45.scr, used a hex editor and disassembly to change the last two states from 9 and 10 to the opposite order, effectively skipping the timepod.

Code: [Select]

code_126e: dup ; 3C
ldi 9 ; 35 09, change to 0A
eq? ; 1A, if not 9...
bnt code_12af ; 30 3A 00, ...jump ahead to code_12af, the next case.
...
code_12af: dup ; 3C
ldi 10 ; 35 0A, change to 09The missing 'p' would go at 0x26CC in the extracted file.

I altered the prescribed hex values in 45.scr like you said (09->0A, 0A->09) and fixed the typos. Now Tiny calls it a 'swell jetpack' like he should with no errors. However, altering the above values doesn't seem to do anything in my game, as the time pod animation still runs like usual. Also, the next couple of hex values after '3C 35 09' are '1A 30 0C 00' rather than '1A 30 3C 00' (I'll attach a copy of my 45.scr for reference).

If it helps, the interpreter version my copy of the game uses is apparently 'T.A00.081'.

[Kawa]

Gee, that was remarkably easy the second time 'round.

Also, the next couple of hex values after '3C 35 09' are '1A 30 0C 00' rather than '1A 30 3C 00'

Could be you edited the wrong changeState method? Because "3C, 35 09, 1A, 30 3A 00" means "dup, ldi 9, eq?, bnt 0x3A bytes ahead," and the next case jumps only 0x1C bytes ahead, to the end of the method, so I'm not sure where you got those branch distances. Editing the 45.scr you provided and being careful about it shows me the same jump distances I expected, at the same offsets I expected.

Code: [Select]

1270 3C 35 0A 1A 30 3A 00 39 42 78 39 FF 38 1E 01 78 dup, ldi $a, eq?, bnt $003a, pushi $42, push1, pushi $ff, pushi $011e, $push1 ...
      ^^- change from 09
12B0 00 3C 35 09 1A 30 1C 00 39 2B 78 38 D1 01 39 06 ... dup, ldi $9, eq?, bnt $001c, pushi $2b, push1, pushi $01d1, pushi $6 ...
         ^^- change from 0A


[spiffythedog]

That did it!

I wasn't even looking at the right offsets, bugger it all. 

Thanks a million. I'll make sure you receive full credit for this.

Anyway, after taking a good look at most of the in-game text, I was startled by the amount of glaring typos, repeated phrases, uncompleted fragments and formatting errors there were. This game clearly didn't receive as much QA as other Sierra games at the time. It could definitely use a bit of proofreading and revision, which I've already started.

[Kawa]

Protip: those labels in the disassembly, code_126e and code_12af? Those are the actual offsets, minus two because resource type ID. So the dup opcodes (0x36) at those points are in the file at 0x1270 and 0x12b1 respectively.

[spiffythedog]

Well, I've cleaned up/revised all of the text strings outside those contained in the script files themselves. Altering the script files is going to be a challenge for me, as while I can alter the text strings just fine with a hex editor (with a built in copy/paste function), the definitions of the string locations themselves will remain unchanged. Can anyone help me out with this?

I've also made note of a number of other bugs/oddities that could probably be fixed:

• A number of item interactions produce empty text boxes (e.g. use the bar coupon on the DBU coupon)
• Offering the jetpack to the DBU salesbug prompts a regular grey text box instead of the salesbug's unique on-screen yellow text
• When offering the DBU salesbug common items as payment for a droid, his text response spills off-screen and cannot be read
• Tiny still negotiates the price of the ship after you've already bought it
• Missing mechanical/'talking' sound effect when offering the DBU loading bay droid the bar coupon
• No laser sound when shot in storage room (same for when shot by guard after missing big Sarien with gas grenade)
• Smelling or tasting the Wally globes while they are inactive produces no sound or animation for death scene
• Looking at certain objects on the same level as you gives the 'You can't see that from down here' message instead of the generic list of descriptions for Sarien doodads
• Looking at same objects from higher level gives generic list of descriptions, as above (need to reverse?)
• No sound for jumping into the waste disposal unit or when the armory droid crushes you with an anvil
• Clicking eye icon on waste disposal chute when on lower level causes Roger to use the elevator and leave the screen
• Sound of armory droid's footsteps briefly missing when he emerges from the back room
• Armory droid's 'talking' sound effect plays for only about a millisecond after shooting him twice
• Death sequence when giant Sarien warrior kills you is completely silent (got to be some way to remedy this, it just feels kind of cheap)

[Kawa]

If the script file for a given bug decompiles cleanly, unlike #45, you're good to go. Tiny's negotiation for example is going to be a tough one.

[spiffythedog]

It seems that altering ANY of the readily editable text strings in this game's script files with SCI Companion completely borks the integrity of the entire file. The locations of the 'look strings' for objects (and god knows what else) or possibly even the strings themselves don't appear to be shifted accordingly whenever I make a change in the editor and compile the script, resulting in garbled descriptions with the 'eye' icon or just plain corrupted text boxes.

Is there something I'm not taking into account, here?

[Kawa]

Is there something I'm not taking into account, here?

You mean besides the fact that they're hard numbers and not the strings they should be? Nah, I think that's about it.

[troflip]

The corrupt script 45 appears to be due to a branch (bnt) instruction that jumps way out of bounds:

Code: [Select]

code_21fc: dup
pushi $10a ; 266, doVerb
push2
lsp param[$1]
lsp param[$2]
super Prop, $8
eq?
bnt $f000

Could be interpreting the branch offset incorrectly, but Companion's disassembly is consistent with SV.exe (haven't checked ScummVM). My guess is that this case (the default case of the switch statement) is simply never reached in game, but there remains the question of how/why did Sierra's compiler output that bytecode?

Is there something I'm not taking into account, here?

How are you getting to room 45 when you test these changes? If this is from a save game that has script 45 loaded and is from an older version of the code, then there could be problems. This is more likely in SCI1.1 though, since you'll get the old heap resource (from the save game) mixed with the new script resource. But things can still go wrong in SCI1.0.