Community
SCI Programming => SCI Community How To's & Tutorials => Topic started by: miracle.flame on October 22, 2023, 09:39:38 AM
-
Our team is translating the game and thanks to SCI Companion we've been able to add accented characters to fonts and translate all .tex files. However it shows there's much more text to translate and it's within the .scr files. Decompiling them, translating and recompiling seems to be the way but it fails at the very attempt to recompile the original decompiled files. Some strings easily seen in the help mode on hover over icons in top bar are lost like "Use this icon to move your character." or "Use this icon to look at things." and such. They are from n000.scr and oddly enough when decompliling everything those string are nowhere to be found in the resulting files. On the other hand using "Extract all resources" tool creates files *.scr.txt and 0.scr.txt has those strings including others from n000.scr but I can't seem to figure out how to utilize those .txt files in recompiling process.
Now I'm wondering if it's even possible to fully translate the game when the decompiled result does not contain all that's needed for full recompilation. SCI Companion seems to know how to get to those missing strings so I'm puzzled why the recompilation does not contain them. I hope I'm missing something crucial and someone here can help me figure it out.
-
I grabbed a fresh testing copy of LSL5, decompiled all, and did a "Find in Files" (Ctrl-Shift-F) for "to move your". The line helpStr {Use this icon to move your character.} was right there.
There were some mild incompatibilities like proc0_25 (aka CenterDisplay) having a (Display &rest dsALIGN 1 ... ) in it, which is forbidden by the compiler but easily resolved by slipping in a third named argument. Just that and one other slip-up and it compiled.
The bigger problem is that it wouldn't pack properly. Somehow it seemed to mistakenly build a resource.000 where it should've used resource.001, like an SCI 1.0 game would expect. And let me tell you, I am pissed as hell about that.
-
I have opened the game, Script -> Manage decompilation, selected all, hit Decompile and closed the manager, then Ctrl + Shift + F for "to move your" and have 0 occurences. I've also searched the contents of whole scr directory for no occurences. Any idea what's wrong?
-
Okay, I tried again with a confirmed clean copy. Pristine.
Decompiled it all, Ctrl-Shift-F "move your", and got several text results plus one script result. Main.sc, line 1129. Fixed the two errors from before, changed the text for icon0 helpStr and...
-
I want to believe! :)
Any explanation to why it doesn't work here? My decompiled n000.sc (Main.sc) is 32 KB in size. Line 1129 is
maskCel 1
-
Seems to be missing a bit. What's the rest of that general area? Mine's this, after changing the line:
(instance icon0 of IconI
(properties
view 990
loop 0
cel 0
cursor 0
message 1
signal $0041
helpStr {Hello?}
maskView 990
maskLoop 14
maskCel 1
)
-
1118-1135
(instance icon0 of IconI
(properties
view 990
loop 0
cel 0
cursor 0
message 1
signal $0041
helpStr 10144
maskView 990
maskLoop 14
maskCel 1
)
(method (init)
(= lowlightColor gLowlightColor)
(super init:)
)
-
I have opened the game, Script -> Manage decompilation, selected all, hit Decompile and closed the manager, then Ctrl + Shift + F for "to move your" and have 0 occurences. I've also searched the contents of whole scr directory for no occurences. Any idea what's wrong?
You're not using an old SCI Companion, are you? There was a bug many (many!) years ago involving near text strings in properties, which would have affected precisely this.
-
It's v3.0.1.7 downloaded recently from http://scicompanion.com/Downloads/SCICompanion.zip
-
Yeah, you might want to update: https://github.com/Kawa-oneechan/SCICompanion/releases
-
So I was using ancient version. You've made my day with this solution and actually a brilliant tool to work with while translating! And thank you for one of the better documentations I've seen for SCIC.
There were some mild incompatibilities like proc0_25 (aka CenterDisplay) having a (Display &rest dsALIGN 1 ... ) in it, which is forbidden by the compiler but easily resolved by slipping in a third named argument. Just that and one other slip-up and it compiled.
I can't seem to figure this out. Could you elaborate how to fix that myself? I'm getting that error while recompiling. I suppose I might stumble upon such errors in many remaining scripts.
-
In Main.sc line 557, proc0_25 has (Display &rest dsALIGN 1 etc. Now, &rest must either be the last parameter given, or be followed by an argument to start from. The fix is to change the procedure to have three arguments and provide the third for the &rest:
(procedure (proc0_25 param1 param2 theRest &tmp temp0)
(if gTheNewDialog (gTheNewDialog dispose:))
(= temp0 (GetPort))
(SetPort 0)
(Display
&rest theRest
dsALIGN
;;; etc.
The other is in rm190.sc, line 43. Brian K. Hughes wrote (sign init:) where he should've said (HollywoodSign init:). The compiler accepted it because sign was the name of a procedure, and the engine accepted it with a stumble unseen to the player (it calls the sign procedure with I suppose a numerical value for init, then ignores the result). But the end result is twofold:
1. you can't look at the sign
2. you can't properly decompile the room's init -- it becomes (proc999_0 --UNKNOWN-PROP-NAME--).
The solution is to remove that entire line with (HollywoodSign init:).
More information: https://github.com/scummvm/scummvm/commit/c7743b3422d6b95cb9252d01f69b75c76278faaf
-
Thank you so much for all your help today and for your dedication to SCI. You're making a better world.
Now off I go translating...
-
Have fun storming the castle 👋
-
I'm back with all .sc files translated and I need to ask. Why is it that after recompiling original files without any changes the talker in introduction scene is renamed from Vinnie to Vinnie_b or from Bruno to Bruno_b? Is there a way to prevent this? If not what is the proper and most effective way to fix it manually? I mean how to identify all the instances of such renaming and how to know what was it originally...?
-
This is the original source code:
(instance goon1 of View
(properties
name "Vinnie"
view vMobFlunkee1
loop tBustLoop
cel 0
x 68
y 65
)
)
(instance goon1Talker of Talker
(properties
name "Vinnie"
view vMobFlunkee1
loop tTalkLoop
nsLeft GOON1LEFT
nsTop GOON1TOP
x GOON1X
y GOON1Y
talkWidth 280
)
(method (init)
(= mouth goon1Mouth)
(super init: &rest)
)
)
You'll note that both of Vinnie's parts have different names in the code, but then the compiler takes the name property and puts that in the final result. The original names (goon1 and goon1Talker) cannot be recovered from the resulting SCR file -- all the decompiler sees is Vinnie. And you can't actually have two objects in the same code unit with the same name (you can't say (Say Vinnie "\"Now to you, Bruno.\"" #dispose: #caller: self) because the compiler wouldn't know if you mean the View or the Talker), so the decompiler has to rename them. However, object names only matter at runtime when an object has to identify itself. For example, by having a talker's name appear in a dialog box title bar. And therefore, when you recompile LSL5 from a decompilation, goon1Talker will have been renamed Vinnie_b, and that's what will appear in Vinnie's dialogue boxes.
I don't know why goon1 was also renamed to the same thing, it doesn't even survive room initialization because of an addToPic. Who knows what John Hartin was thinking? But I do know you can certainly guess what Bruno's original object names are.
And of course the inventory items have much more programmer-friendly names -- would you rather refer to AeroDork_s_In-Flight_Magazine in your code, or just magazine?
-
You're very good at explaining things, you know? Or maybe I am accustomed to understand this way. I've been through all talker instances and it seems there's not that much of this occurring so I guess it'll be just fine during testing and corrections phase.
Thanks a bunch.
-
I am quite desperate and out of ideas so I guess I'll have to ask here.
It seems the inventory item "Camcorder" available from the start of the game is not getting translated even when I change all occurrences of "Camcorder" word in LLIconItem.sc and recompile successfully. When I search further for "Camcorder" in the project via SCICompanion's Find in files there are no more occurrences of a standalone "Camcorder" word in the whole project. That being true when searching contents of all sc and tex files using Total commander.
Where is the game getting it from?
(https://snipboard.io/Ch4e8S.jpg)
-
I can confirm the string {Camcorder} appears only once. For expediency in testing, I extracted 19.scr and edited the name of the Camcorder by hand. Save for one hiccup where I accidentally put it in my copy of LSL1, I can therefore confirm that saved games will retain the original name, since they'll contain the whole of all the currently loaded script resources. If you try to use a saved game to quickly skip ahead to the PPC lobby, that will prevent edited item names from appearing. Start a new game fresh, and it'll load the edited 19.scr fresh.
Steps to reproduce:
- Save your game with an unaltered camcorder.
- Change its name
- Restore your game and see it's unchanged.
- Restart and look at the camcorder again.
-
You're right! Thanks a bunch!
-
Not sure if still relevant for this thread but I have to report a buggy result after following these steps:
1. Decompile working game
2. fix errors in Main.sc and rm190.sc
3. Recompile
Issue:
Saving with new name does not create a new save slot but replaces an existing one
Expected behavior identical within "working game":
Saving with new name creates a new save slot instead of replacing an existing one
-
I got nothing.
-
video example:
https://streamable.com/bif3bb (https://streamable.com/bif3bb)
-
Just because the scripts compile without error doesn't mean SCICompanion hasn't introduced a bug. Take a look at all the assembly code SC failed to decompile in script 990. That can be a red flag when looking for bugs introduced from decompilation, though ASM doesn't always mean a new bug has been created.
Searching for "save" with EDIT > Find In Files or in the game.ini file points to 990 as the culprit. You can verify 990.src is the problem by exporting a patch from an unmodified LSL5, which fixes the save issue SCICompanion unfortunately introduced.
If you need script 990 to compile correctly, try replacing the ASM with code from Sluicebox's SCI-Scripts (https://github.com/sluicebox/sci-scripts/blob/main/lsl5-dos-1.000/src/Save.sc) (Or do like in the dark ages of 2022 and reverse the assembly by hand). The SCI Decompile Archive (https://github.com/EricOakford/SCI-Decompilation-Archive) is another invaluable resource.
Watch out because they use different naming conventions. One of the biggest issues with converting between the multiple code versions is [SC install DIR]>include>sci.sh file, which seems to differ from the one used by Sluice's SCI-Scripts, meaning the Kernel define numbers can be wrong and crash the game when triggered in-game. You will also likely need to change the global variable names before the pasted code will compile.
Also, just a heads up, it looks like you're deleting dsAlign when you add theRest to the procedure in Main. I'm guessing that might have been just a mistake in the video, but something to be aware of. Oh, and double-click on those errors in the bottom window to go directly to the problem.
-
I appreciate your effort to help, alas I can't read SCI language and this is probably more than I can handle in attempt to provide localization for this game.
All three resources of scripts (decompiled by SCIC, Sluiceboxs' and SCI Decompile Archive) are quite different from each other.
Sluiceboxs' cannot even compile by itself as is without tons of errors, the second resource at least can compile but running the game is heavily slowed down.
I imagine that even if I'm provided straightforward guidance to fix the saving script there may be numerous other issues to come that are beyond my knowledge and seeing how much investment is needed I'm about to just quit it.
-
I'm surprised to hear that the SCI Decompile Archive introduced performance issues. I know the SDA isn't bug free, but I've never seen it cause slowdowns. Out of curiosity, could you provide some details about where you see the sluggishness?
I understand if you've decided not to pursue the project. I know how much work is involved with translating, even before dealing with bugs and other technical issues. However, I see from SCICompanion's decompile log that only nine scripts (including 990) had to fallback to ASM, so this likely wouldn't be impossible to deal with. I agree it can be difficult moving code between the three decompile versions, but I can usually do it fairly quickly.
I would be willing to remove the ASM from the nine failed scripts if you were commited to completing the project. I've attached below the SRDialog.sc file that fixes #990 for use with the SCICompanion decompiled version. This should allow you to easily edit the strings in 990 and recompile without introducing the save bug.
If you still prefer to abandon the translation, that's ok too.
-
I guess I've had rough days and made sudden decisions... maybe it would be worth trying step by step and don't mind about it that much.
Thanks for the file, I've put it among the original files decompiled by SCIC (and translated) and got these errors upon recompiling:
(https://snipboard.io/XOmUEn.jpg)
Now about the slowdown it would be best to demonstrate. Initially I am running full speed for comparison:
https://streamable.com/nk13gj (https://streamable.com/nk13gj)
-
Are you aware that the original code for LSL5 was leaked 2 years ago?
https://github.com/historicalsource/leisure-suit-larry-5
-
Omer: I was going to say the same thing... I'm not sure how easy it is to build though. I've got the original compilers working, but I haven't tried rebuilding LSL5.
-
I guess I've had rough days and made sudden decisions... maybe it would be worth trying step by step and don't mind about it that much.
Thanks for the file, I've put it among the original files decompiled by SCIC (and translated) and got these errors upon recompiling:
(https://snipboard.io/XOmUEn.jpg)
Now about the slowdown it would be best to demonstrate. Initially I am running full speed for comparison:
https://streamable.com/nk13gj (https://streamable.com/nk13gj)
Those darn kernel defines causing trouble again. I wish I could figure out why they seem to vary so much. I've replaced the defines with the values which should work. Try the updated SRDialog.sc attached below.
As for the SDA performance issue, I can see from your video that the DOSBox configuration is getting changed somehow. You can see the CPU speed shown in the bar at the top of the window is different.
First test is CPU Speed: max 100% cycles.
Second test is CPU Speed: 3000 cycles.
3000 cycles is fairly sluggish for SCI1 games. I normally use 10000 cycles to avoid slowdowns. So it's not the code causing the problem, but it's unclear why your DOSBox config is different between the two.
Are you aware that the original code for LSL5 was leaked 2 years ago?
https://github.com/historicalsource/leisure-suit-larry-5
Thanks. I searched for that but nothing came up.
-
It worked! Script compiled without errors and saving works as it should.
Thanks a lot doomlazer!
-
You're welcome!
I've gone ahead and finished the other files that failed to decompile 100% (with two exceptions).
The following are now assembly free and formatted to work with SCICompanion's decompile:
rm258.sc (#258)
rm380.sc (#380)
rm700.sc (#700)
SRDialog.sc (#990)
game.sc (#994)
InvI.sc (#995)
obj.sc (#999)
The following are not fully decompiled:
sysLogger.sc (#952) - This script was used internally by Sierra's QA department to submit bugs to the devs. Unless you are trying to restore debugging for your translation, it can be safely ignored. If you really wanted, I could remove the ASM for this script as well.
RTRandCycle (#928) - This is a strange one. There are no string literals in this script that you will need to translate so it can be ignored. However, the reason it failed to decompile is because of this line (https://github.com/sluicebox/sci-scripts/blob/c6fac2fa6806adb9e913f6cce8d47723a8932afc/lsl5-dos-1.000/src/Talker.sc#L259):
(mouth setCycle: Unknown_Class_40 temp0)
If we look at the Sierra source code, it should be this (https://github.com/historicalsource/leisure-suit-larry-5/blob/341bc91b5529c3243220a7fe77cc6b041c8022d4/SYSTEM/TALKER.SC#L178):
...(mouth setCycle: MouthSync theAudio)...
MouthSync, in the Sierra source code, is defined in sync.sc (Script #929), but script 929 doesn't seem to exist in the LSL5 resource files at all!
Depending on how you're distributing, you might want to export a 928.sc patch from an unmodified LSL5 and import that into your project. Then Rebuild Resources and delete ./scr/RTRandCycle.sc & ./scr/RTRandCycle.sco. That should get the original bytecode back into the game's resource files.
Let me know if you have any trouble recompiling the files, all of which are included in the the zip attached below!
edit: removed bad attachment
-
I've tried and the errors are:
(https://snipboard.io/Hwa3AF.jpg)
-
Sorry about that. Those should now be fixed in the zip attached below.
-
These all compiled well. :) Thank you very much! Not sure what it fixed but i believe it saved me a lot of troubles.
-
It may or may not have fixed anything, but it seemed like the best way to avoid possibly introducing bugs. Don't hesitate to reach out if you run into any problems or have questions!