Community
SCI Programming => SCI Development Tools => Topic started by: spiffythedog on March 16, 2016, 05:53:55 AM
-
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?
-
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_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.
-
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.
-
Which version? I've backed up every release until now. It's displayed in the About dialog.
-
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?
-
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.
-
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_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'.
-
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.
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
-
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.
-
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.
-
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)
-
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.
-
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?
-
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.
-
The corrupt script 45 appears to be due to a branch (bnt) instruction that jumps way out of bounds:
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.
-
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.
No, kawa is right. The description and lookStr properties point to some of these strings. SCI Companion treats their values as numbers, but they are really pointers, which causes problems when you recompile the script (you probably don't even need to change anything, due to differences in code generation).
-
Ah, it looks like the property value resolution (to strings/saids) is only supported for SCI1.1+. Oops.
-
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.
That actually really helped. Replacing the decimal addresses with the actual strings themselves has completely circumvented the problem.
Another problem: decompilation of script files isn't perfect, even if the program says it is. Important properties of instances seem to be almost randomly omitted for some reason, causing corrupted graphics and cursor hotspots (eg. the monitors and dials in room 8, the bartender's body and the little purple guys in the Rocket Bar, the radar in the loading bay of DBU, etc.). Simply looking through the disassembly of each script and manually re-adding these properties fixed this.
Additionally, while the script for the Deltaur armory room was successfully decompiled with no reported errors, a conditional statement involving the droid killing you if you show him the ID 3 times was corrupted somehow, as showing him the ID for the third time causes him to threaten your extermination and then just walk into the back room like he usually does. I'm currently wrangling with this one and still no dice.
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.
I've actually been avoiding that one (eheh) and am presently focusing on problems that are more within my current abilities (that is to say, not a lot), and I haven't exactly been going through the game room by room.
Speaking of current abilities, here are a few things I managed to fix so far:
- About 95% of all grammar, spelling and formatting errors in the remaining narrator text strings have been cleaned up (while hopefully preserving the writers' proper intent)
- Offering the jetpack to the salesbug produces a response via his on-screen yellow text instead of a grey narration box like usual
- The salesbug's response to offers of common items no longer runs off-screen (as it has been properly split into two separate strings)
- Showing 'Robbie' the bar coupon in the DBU loading bay produces a mechanical/'talking' sound effect like it should
Some other things I've noticed and plan to address:
- The triple-breasted alien girl and the yellow slug guy in the bar have several animation loops that go completely unused (at least in my copy)
- Some descriptions/text strings for certain environmental features in some rooms also go completely unused (eg. DBU loading bay, the Star Generator room, etc.). As a result, these rooms just feel really barren and lacking in interactivity
Script #0 ('Main') will also be another tricky one to tackle, as that contains all the inventory descriptions and doesn't decompile cleanly in SCI Companion. Wish me luck, I guess.
-
Good luck~
-
Additionally, while the script for the Deltaur armory room was successfully decompiled with no reported errors, a conditional statement involving the droid killing you if you show him the ID 3 times was corrupted somehow, as showing him the ID for the third time causes him to threaten your extermination and then just walk into the back room like he usually does. I'm currently wrangling with this one and still no dice.
I'm not surprised that that doesn't work. it is a script bug in the original game, and I implemented a script patch for it in ScummVM. It happens to work in SSCI, but even it might be sensitive to code generation differences. The trouble is with this compound if statement:
(if
(<
(DeltaurRegion
timesShownID: (+ (DeltaurRegion timesShownID?) 1)
)
3
) ...etc...
The programmer thought that the expression (DeltaurRegion timesShownID: foo) would return foo (which would subsequently be compared to 3 in the if statement), but this is not the case. In other words, those middle three lines must be moved out of the if statement. It should read:
(DeltaurRegion timesShownID: (+ (DeltaurRegion timesShownID?) 1))
(if (< (DeltaurRegion timesShownID?) 3) ...etc...
As noted, ScummVM instead fixes this with a script patch, which a) would not decompile cleanly and b) might or might not work with altered scripts.
-
Additionally, while the script for the Deltaur armory room was successfully decompiled with no reported errors, a conditional statement involving the droid killing you if you show him the ID 3 times was corrupted somehow, as showing him the ID for the third time causes him to threaten your extermination and then just walk into the back room like he usually does. I'm currently wrangling with this one and still no dice.
I'm not surprised that that doesn't work. it is a script bug in the original game, and I implemented a script patch for it in ScummVM. It happens to work in SSCI, but even it might be sensitive to code generation differences. The trouble is with this compound if statement:
(if
(<
(DeltaurRegion
timesShownID: (+ (DeltaurRegion timesShownID?) 1)
)
3
) ...etc...
The programmer thought that the expression (DeltaurRegion timesShownID: foo) would return foo (which would subsequently be compared to 3 in the if statement), but this is not the case. In other words, those middle three lines must be moved out of the if statement. It should read:
(DeltaurRegion timesShownID: (+ (DeltaurRegion timesShownID?) 1))
(if (< (DeltaurRegion timesShownID?) 3) ...etc...
As noted, ScummVM instead fixes this with a script patch, which a) would not decompile cleanly and b) might or might not work with altered scripts.
Worked like a charm. Now it's just getting the droid's footsteps to play when he emerges from the back room (before he turns around to face you). I'm positive that its controlled by 'instant RobotWalksOut of Script', and that I need to add '(= loop 0) (= loop 5) (proc999_5 cel 0 4))' and '(droidWalkSound number: 523 loop: -1 flags: 1 play:)' somewhere as part of a conditional statement, but I'm clueless as to how.
-
You should probably go over all of ScummVM's patches for SQ1, to avoid reinventing the wheel:
https://github.com/scummvm/scummvm/blob/master/engines/sci/engine/script_patches.cpp#L3324 (https://github.com/scummvm/scummvm/blob/master/engines/sci/engine/script_patches.cpp#L3324)
-
Another problem: decompilation of script files isn't perfect, even if the program says it is. Important properties of instances seem to be almost randomly omitted for some reason, causing corrupted graphics and cursor hotspots (eg. the monitors and dials in room 8, the bartender's body and the little purple guys in the Rocket Bar, the radar in the loading bay of DBU, etc.). Simply looking through the disassembly of each script and manually re-adding these properties fixed this.
I'll take a look at why this is happening, thanks for the bug report!
[edit:] Looks like this is because the instance has more properties than the species from which it is derived declares. And we end up going down some failure path. I should be able to just have it ignore this problem I think.
Script #0 ('Main') will also be another tricky one to tackle, as that contains all the inventory descriptions and doesn't decompile cleanly in SCI Companion. Wish me luck, I guess.
What are the problems with script 0? I've attached my decompile of it (hopefully this is the same version of SQ1 VGA)
-
Another problem: decompilation of script files isn't perfect, even if the program says it is. Important properties of instances seem to be almost randomly omitted for some reason, causing corrupted graphics and cursor hotspots (eg. the monitors and dials in room 8, the bartender's body and the little purple guys in the Rocket Bar, the radar in the loading bay of DBU, etc.). Simply looking through the disassembly of each script and manually re-adding these properties fixed this.
I'll take a look at why this is happening, thanks for the bug report!
[edit:] Looks like this is because the instance has more properties than the species from which it is derived declares. And we end up going down some failure path. I should be able to just have it ignore this problem I think.
Script #0 ('Main') will also be another tricky one to tackle, as that contains all the inventory descriptions and doesn't decompile cleanly in SCI Companion. Wish me luck, I guess.
What are the problems with script 0? I've attached my decompile of it (hopefully this is the same version of SQ1 VGA)
Decompiling my script 0 resulted in a 96% bytecount success rate with a warning ('WARNING: ::proc0_10: Analyzing control flow: Expected node with two successors (then/else): 1 at 0384
Falling back to disassembly for proc0_10'). When I compile it and test in the game (usually from the start), the palette/colour scheme of the in-game menus and messages are completely wrong. I suspect that maybe there a few missing properties I need to reinstate.
-
Another problem: recompiling script 3 and then testing it in-game causes a minor bug during the dying scientist event. Directly after he collapses to the floor, Roger's right-facing walk cycle is briefly superimposed over the scientist's sprite and does a few rounds. Then it disappears and the scene continues as normal. I've tried looking through the decompiled script, but I can't seem to identify what's causing this behavior. Maybe it's somewhere else?
-
Now that I finally had some free time (as well as the new update for SCI Companion v3) to come back and tackle this, I think I'm almost done. Here is a list of changes:
GENERAL FIXES
- Grammar, spelling and formatting errors in the narrator text strings have been cleaned up (while hopefully preserving the writers' original intent)
- A number of item interactions no longer produce empty text boxes (e.g. use the bar coupon on the DBU coupon)
- Cursor no longer switches to 'Taste' instead of 'Wait' when walking through laser fence in Kerona underground
- Mugger sequence completely fixed
- Offering the jetpack to the DBU salesbug prompts his unique on-screen yellow text rather than a regular grey text box
- When offering the DBU salesbug common items as payment for a droid, his text response no longer spills off-screen (displayed with two text strings instead of one)
- Discounted ship prices at Tiny's are now displayed correctly (144 buckazoids for the scrambler and 115 buckazoids for the saucer)
- Tiny no longer negotiates the price of the ship after you've already bought it
- Description of 'Enter' button when inputting Droid Navigation Code in ship no longer reuses the one for the cartridge retrieval system on the Arcada
- Description of egg-like container of bottled-energy on top level of room 60 restored (no longer a cut-off fragment)
MISC. REVAMPS
- Reinstated 'Orat Chow death' message
- Restored animation loops for triple-breasted alien girl and yellow slug guy in the Rocket Bar (caused by a faulty if statement, loops only play when 'Detail' in original game is set below 2)
- Removed the SQ4 time pod animation when leaving Kerona
- The chimes produced by pressing the 'numpad' buttons when keying in the Navigation Coordinates now vary in pitch like they do when retrieving the cartridge on the Arcada
- Death message for fleeing from the sight of the Deltaur originally showed Roger in his red Sarien uniform with his back turned. Now it shows Roger in his blue space suit with his back turned.
- Added conditional to description of room 61 (now reflects which level you're standing on)
- The Two Guys from Andromeda now have talking animations for the Restart and Quit sub-menus (currently bugged, see below)
AUDIO
- Sound added for when mugger shoots you
- Restored missing mechanical/'talking' sound effect when offering the DBU loading bay droid the bar coupon
- Sound added when Roger collapses after getting shot in Deltaur airlock
- Laser/disintegration sounds added when shot in storage, laundry or outside armory (after missing with both gas grenades)
- Sound/animation added for getting fried by the Wally globes on the Deltaur (regardless of whether they're active or not)
- Sounds added for jumping into the waste disposal unit and getting crushed by the anvil on the Deltaur
- Restored some of the armory droid's footstep noises (only two loops remain silent, see below)
- Sounds added for death sequence when giant Sarien warrior kills you
- Sound added for getting fried by the force field surrounding the Star Generator
REMAINING BUGS
- After buying the security droid from DBU (the one you need to assemble yourself), clicking the Hand icon 3 times on the smallest box (or simply clicking on any box twice with the Hand icon and clicking the smallest box after the second message) causes Roger to walk right into the force field barrier
- Clicking any icon on the cleaning droid when on lower level of Deltaur 2F causes Roger to use the elevator and leave the screen
- Armory droid's 'talking' sound effect plays for only about a millisecond after shooting him twice
- No 'footstep' sound effects for when armory droid is just emerging from the back room
- When unmasked, Sarien officers on the upper levels initially don't produce a laser sound effect when they shoot you. The second and subsequent shots however do produce a laser sound (compiling 703.scr, which controls this behaviour, produces a warning message "Ignoring public class for export: DeltaurRegion. Line: 331, col: 6," and the game crashes when loading a save game after the Deltaur airlock or loading one from within the Deltaur itself)
- The death animation for the waste disposal only depicts Roger with a Sarien helmet (any good sprite artists willing to step up?)
- Bizarrely, the talking animations for the Two Guys during the two special death sequences in the Kerona underground (as well as the ones I added for the Restart and Quit submenus) will simply stop working when you have 10 inventory items. Arriving in the underground with more than 9 items or picking up a 10th while you're there causes the animations to stop. Sounds crazy and arbitrary, but I've tested it thoroughly, and it's the exact same result each time.
TRIVIAL NONSENSE
- Apparently, the screen was supposed to flash red when you encountered the Romulan Warbird, indicating that they destroyed you (that sequence always seemed awkward to me: they just appear and then leave!). Have no idea how to implement this
So yeah, that's all I've managed to fix so far. I probably went a little overboard on some of the text alterations, and the added sound effects might seem a little iffy (especially the digital ones). But for a first effort, I think I did a good enough job, though I'm still not quite finished. I've provided a beta for you guys to look over and give me any suggestions (is the edited 'resource.000' supposed to be this big? Just seems weird, is all). So far, this patch has only been tested in DOSBOX, so use ScummVM at your own risk.
Enjoy.
-
Restored animation loops for triple-breasted alien girl and yellow slug guy in the Rocket Bar (caused by a faulty if statement, loops only play when 'Detail' in original game is set below 2)
I quoted this on IRC. Shenanigans ensued:
<Kawa> So this one guy is making a "fix everything" for Space Quest 1, the SCI remake...
<Kawa> "Restored animation loops for triple-breasted alien girl and yellow slug guy in the Rocket Bar (caused by a faulty if statement, loops only play when 'Detail' in original game is set below 2)"
<Kawa> Below, not above.
<Jistuce> Why is Space Quest ripping off Star Trek 5?
<Kawa> You know ST5 isn't the only story with triple-breasted aliens right?
<Jistuce> But it was THE FIRST!
<Kawa> Eccentrica Gallumbits, the triple-breasted whore of Eroticon VI.
<Jistuce> Yeah, from Star Trek.
<Kawa> Her erogenous zones are thought to extend miles from her body.
<Jistuce> Just the way Kirk likes 'em.
<Kawa> From the Hitchhikers Guide.
<Kawa> Leave the comical denial to Flanders.
<Jistuce> Which was a shameless rip off of Star Trek.
<Kawa> Eccentrica is mentioned in the first book, released in 1979.
<Jistuce> DECADES after Star Trek.
<Kawa> Star Trek 5 was released in 1989
<Jistuce> First episode, man!
<Jistuce> You can't just distill the entire franchise down to one movie!
<Kawa> <Jistuce> Why is Space Quest ripping off Star Trek 5? <-- you started it.
<Kawa> You specifically called out ST5.
<Kawa> Also, Total Recall. 1990.
<Jistuce> I meant EPISODE FIVE, clearly. Jeez.
<Kawa> No you didn't.
<Jistuce> Prove it.
<Kawa> There was no triple-breasted anything in STTOS episode 5.
<Kawa> There WAS in movie 5.
<Jistuce> Are you counting from The Cage or The Man Trap?
<Kawa> That won't effectively change the answer.
<Jistuce> IT MAKES A DIFFERENCE.
<Kawa> Not if "the fifth episode" has no triple-breasted anythings in it no matter which one is "the fifth".
<Jistuce> Look, it is not my fault that you are BAD AT COUNTING.
<Kawa> I'm quite certain there were no triple-breasted anythings in the whole of STTOS season one.
<Jistuce> It's the one they don't air in reruns because Kirk and Spock dressed as nazis is offensive.
<Jistuce> (Most of that sentence is even true)
-
Amazing work spiffythedog!
And kawa: HA! ;D
-
is the edited 'resource.000' supposed to be this big? Just seems weird, is all
SCI Companion doesn't use compression when saving resources to the packages, so that's probably why it's larger.
-
SCI Companion doesn't use compression when saving resources to the packages, so that's probably why it's larger.
Imagine if it did. I could have space left on the Catdate demo diskette for a manual and such!
-
Imagine if it did.
There's nothing holding you back from using the original sierra tools to build your resource packages. Compression and all.
-
Imagine if it did. I could have space left on the Catdate demo diskette for a manual and such!
Sorry, you'll have to burn it to CD-ROM I guess :-/
But then you'll have limitless extra space for more audio or whatever! No one will ever need more than 600MB.
-
There's nothing holding you back from using the original sierra tools to build your resource packages. Compression and all.
Also multiple volumes! Besides not having the foggiest how but who's counting?Sorry, you'll have to burn it to CD-ROM I guess
Joke's on you, the demo fits on a diskette just right, even without resource compression.
-
Amazing work spiffythedog!
And kawa: HA! ;D
Thanks!
Restored animation loops for triple-breasted alien girl and yellow slug guy in the Rocket Bar (caused by a faulty if statement, loops only play when 'Detail' in original game is set below 2)
I quoted this on IRC. Shenanigans ensued:
*KAWA SNIP*
Huh. I always assumed it was a Total Recall reference, myself.
-
There are so many works with triple-breasted alien ladies dated before SQ1 it ain't even funny.
-
When unmasked, Sarien officers on the upper levels initially don't produce a laser sound effect when they shoot you. The second and subsequent shots however do produce a laser sound (compiling 703.scr, which controls this behaviour, produces a warning message "Ignoring public class for export: DeltaurRegion. Line: 331, col: 6," and the game crashes when loading a save game after the Deltaur airlock or loading one from within the Deltaur itself)
FIXED (thanks to troflips latest update)
- Bizarrely, the talking animations for the Two Guys during the two special death sequences in the Kerona underground (as well as the ones I added for the Restart and Quit submenus) will simply stop working when you have 10 inventory items. Arriving in the underground with more than 9 items or picking up a 10th while you're there causes the animations to stop. Sounds crazy and arbitrary, but I've tested it thoroughly, and it's the exact same result each time.
Still completely stumped by this one. Mouth animations seem to stop almost entirely at random (too many on-screen animations?) when triggering the death sequences on either screen. The game can't seem to handle any alterations to the speed and/or timing of the mouth animations, several of which I've already made. This happens regardless of whether or not the Restart and Quit submenus are animated. Might have something to do with 'RandCycle,sc', as that seems to control the mouth animations for these sequences.
-
Still completely stumped by this one. Mouth animations seem to stop almost entirely at random (too many on-screen animations?) when triggering the death sequences on either screen. The game can't seem to handle any alterations to the speed and/or timing of the mouth animations, several of which I've already made. This happens regardless of whether or not the Restart and Quit submenus are animated. Might have something to do with 'RandCycle,sc', as that seems to control the mouth animations for these sequences.
Maybe you should give it a try with ScummVM; if it's a memory corruption problem, it will certainly behave differently, and you'll know for sure. I'd try it myself, but it's hard to tell from your description what I need to do to reproduce it.
-
I second Lars' suggestion to try it in ScummVM... but might not ScummVM reject it because the resource package hash is different?
Can you describe the changes you've made? Did it work properly without the changes? (Trying to rule out a SCI Companion decompiler/compiler bug here).
Also, make sure you're not loading previous save games (e.g. to quickly get back to the underground) after you've made changes. That could certainly cause corruption.
-
I second Lars' suggestion to try it in ScummVM... but might not ScummVM reject it because the resource package hash is different?
Can you describe the changes you've made? Did it work properly without the changes? (Trying to rule out a SCI Companion decompiler/compiler bug here).
Also, make sure you're not loading previous save games (e.g. to quickly get back to the underground) after you've made changes. That could certainly cause corruption.
I've tested it in both ScummVM and DOSBox, and it produces pretty much the same behaviour. I've already made all the changes I need to the mouth animations in the scripts for both rooms (slowing them down, cutting out some of the dead air and keeping them on screen for longer) and can freely test/observe them, provided I do a low item run (picking up as few items as possible). Even then, there's always the possibility that the mouth animations will choke at some point near the end of either of the death sequences.
Going into the underground on a full item run (collecting every single possible item, give or take 1 or 2 items) seems to choke the animations for both the special death sequences in rooms 32 and 33 (possibly related to the current size of the inventory window?) as well as the animation loop I added to the Quit and Restart screens (this I shamelessly pinched from disk version of SQ4).
For the latter, altering the script in Main.sc from:
(method (restart/exit)
(babbleIcon view: 946 loop: 4 cycleSpeed: (* (+ global87 1) 4))
to:
(method (restart/exit)
(babbleIcon view: 946 loop: 4 cycleSpeed: 12)
seems to provide greater overall stability animation-wise when on a low item run, but it still doesn't completely guarantee that the mouth animations for the death sequences won't choke at some point near the end.
I'm sorry I can't be much clearer on this, as it all seems very convoluted and sensitive. I'm just as baffled as you guys, honestly.
-
You've modified the code and something is no longer working as you expect... I wouldn't say I'm baffled, happens to be all the time :P
ScummVM has a pretty good debugger, and since you can repro it there, you can probably diagnose this with a little work.
-
According to this (http://wiki.scummvm.org/index.php/SCI/Debug_Modes) and this (http://agisci.altervista.org/SDMFAQ094.TXT), there doesn't appear to be any known way of accessing the script debugger in SCI1 games with an interpreter version of less than 1.001.000, which SQ1VGA unfortunately seems to have. I've tried activating it in DOSBOX, which crashes the game, and ScummVM, which does nothing.
-
The debugger is a function of the interpreter. ScummVM has its own debugger: ctrl-shift-D. Then type 'help'.
-
The debugger is a function of the interpreter. ScummVM has its own debugger: ctrl-shift-D. Then type 'help'.
Ah. I had a feeling I was on the wrong track. Thankee.
-
With the help of NewRisingSun, the SQ1VGA patch has finally been released over at VOGONS!
Check it out:
http://www.vogons.org/viewtopic.php?f=7&t=53119
-
Very nice!
Why is this patch not compatible with ScummVM? I can try to reach out to them and see if they're interested in importing those fixes directly into ScummVM.
Also,
have you considered sharing your annotated scripts so the community can learn from it?
-
Very nice!
Thanks!
Why is this patch not compatible with ScummVM? I can try to reach out to them and see if they're interested in importing those fixes directly into ScummVM.
Now that you mention it, the release version of the patch actually works rather well with ScummVM, barring a few niggles here and there (the intro is slow and out-of-sync, sometimes the screen doesn't shake when a rumbling is heard on the Arcada, the graphics for the new Warbird sequence completely glitch out, etc.). The last time I tested the patch-in-progress with ScummVM, the game would randomly display text from Sarien.sc as part of the background picture, but now that no longer happens. I've just reached the Deltaur, and so far the game seems entirely finishable.
As for the ScummVM developers importing the new fixes, I guess you could try, but it seems very unlikely that NRS would be willing to cooperate or provide any assistance if they reached any major roadblocks. NRS has made it very clear to me that his new fixes were designed entirely with DOS/DOSBOX in mind, and that he wants nothing to with ScummVM or its team. Which is fair enough: a great chunk of this patch is his work, and therefore his prerogative, which I will ultimately respect.
Also,
have you considered sharing your annotated scripts so the community can learn from it?
There were a few scripts that didn't compile properly with SCI Companion (causing weird anomalies during gameplay), which necessitated NRS to use some original developer tools in order to properly implement the new fixes. If we work our way backwards through our correspondence, we should be able to pinpoint which specific scripts got borked and what effects this produced. I'll just have to get in touch with NRS again.
-
Non/badly compiling scripts are fine as well.
It could help troflip improve SCI companion.
-
Yeah, that would be very useful.
-
As I mentioned on VOGONS I am curious as to why you did this as a binary difference patch instead of just loose patch files? This is probably why ScummVM does not recognize it. The map file has been changed.
-
This is probably why ScummVM does not recognize it. The map file has been changed.
Good.
Yeah, that would be very useful.
I'll do a write-up, but it might take a while. Is there a binary build available with these issues (http://sciprogramming.com/community/index.php?topic=1420.msg10242#msg10242) corrected? Then I would only report those issues that persist.
There were a few scripts that didn't compile properly with SCI Companion (causing weird anomalies during gameplay), which necessitated NRS to use some original developer tools in order to properly implement the new fixes
I only used three original developer tools: SMF.EXE, View Editor 256, and MAKEVOLS. MAKEVOLS would claim that some view resources that were saved by SCI Companion were "corrupt". I loaded them in View Editor 256, where they displayed without problems, then immediately saved them, which produced somewhat different files that MAKEVOLS would then accept. I used SMF.EXE to reconvert Standard MIDI Files to .SND files after I made some changes to them (in particular, adding the choreography triggers to the Madonna music).
-
Hi NRS,
thank you too for working on this!
MAKEVOLS would claim that some view resources that were saved by SCI Companion were "corrupt". I loaded them in View Editor 256, where they displayed without problems, then immediately saved them, which produced somewhat different files that MAKEVOLS would then accept.
That's very interesting. Do you still have the "corrupt" and the "right" views? It would be interesting to dissect the difference between them.
-
Attached find one example. 572bad.v56 was saved by SCI Companion and was rejected by MAKEVOLS as "corrupt". Loading that file in Sierra's original View Editor 256 and immediately saving it produces 572GOOD.V56, which MAKEVOLS does accept.
-
Question. SMF.EXE was mentioned and that got me curious. Given a semi-random MIDI file with two piano tracks (left and right hand), it complains that these tracks have no device designation (true) and there's only a tempo track left.
How, then, does one designate devices to tracks? A quick glance in the EXE file suggests it's encoded in the name of the tracks...
-
The track name must start with a list of devices that should play this track and a few other things in square brackets, followed by the regular track name if wanted:
*: Applies to all devices, typically channel 16 defining loop points.
a: Track played by ADL.DRV
j: Track played by CMS.DRV
g: Track played by MTBLAST.DRV
h: Track played by GENMIDI.DRV or Windows 3.1 Extended MIDI ("High synth")
l: Track played by Windows 3.1 Basic MIDI ("Low synth")
m: Track played by MT32.DRV
s: Track played by STD.DRV
t: Track played by TANDY3V.DRV
A sound driver's function number 0 returns in CH its device letter minus ASCII 61h ('a') to the interpreter, i.e. MT-32 returns 0Ch ('m' minus 'a'). In some games, MTBLAST.DRV plays 'm' rather than 'g' tracks, and in games composed for MT-32 but with a GENMIDI.DRV added after-market, or after composition (PQ1, Laura Bow), GENMIDI plays 'm' rather than 'g' tracks as well while remapping program change numbers based on 4.PAT information.
Special characters:
!: Do not remap channel ("Locked channel"). Required for MT-32 rhythm tracks (MIDI channel 10).
#: Track is initially disabled ("Ghost channel"), but can be enabled by game. Used for multiple melody lines, for example in LSL6.
Number 0-9 before "/": Initial voice allocation (i.e. number of voices used by MIDI channel)
Number 0-9 after "/: Pre-emption priority. Channels without it cannot be pre-empted, i.e. will never be disabled for the benefit of MIDI sound effects. Sierra's MIDI code is too confusing for me to tell whether it's a higher or a lower priority that makes a channel more or less likely to be pre-empted.
Example:
"[ajmt2/1] Melody": Played by AdLib, Game Blaster, MT-32, Tandy; initially allocate 2 voices, pre-emption priority 1.
"[gm!] Rhythm": General MIDI/MT-32 rhythm track.