How to properly translate script files of LSL5?

[Kawa]

This is the original source code:

Code: [Select]

(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?

[miracle.flame]

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.

[miracle.flame]

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?

[Kawa]

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.

[miracle.flame]

You're right! Thanks a bunch!

[miracle.flame]

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

[Kawa]

I got nothing.

[miracle.flame]

video example:
https://streamable.com/bif3bb

[doomlazer]

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 (Or do like in the dark ages of 2022 and reverse the assembly by hand). The SCI Decompile 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.

[miracle.flame]

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.

[doomlazer]

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.

[miracle.flame]

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:


Now about the slowdown it would be best to demonstrate. Initially I am running full speed for comparison:
https://streamable.com/nk13gj

[OmerMor]

Are you aware that the original code for LSL5 was leaked 2 years ago?
https://github.com/historicalsource/leisure-suit-larry-5

[lskovlun]

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.

[doomlazer]

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:


Now about the slowdown it would be best to demonstrate. Initially I am running full speed for comparison:
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.