LSL7 script compilation to csc patch

[miracle.flame]

Greetings stars! 
Me again after a while, compilation inquiry this time.

Is there a way to get csc patch out of modified oScoreCard.sc?

We need to alter positioning of TextItems including HotTexts slightly to the left so that even longer strings don't get punched through when scoring on the Score card.

By sheer luck I have stumbled upon a thread with various internal tools including Sierra's SC compilers. Tried the latest SC_4.111.EXE for oScoreCard.sc in DosBox but it returned some complaint most probably about the script missing per-requisites as pointed out by Kawa. I have little to no knowledge about SCI scripting but I could play around those x & y coordinates of Instances to see the result in game if someone could help me figure out the compilation for the script - if even possible to achieve the csc patch in the end. 

[Kawa]

Honestly, if recompilation isn't much of an option and all you're trying to do is change some numbers, I'd rather take a hex editor to the damn thing. Disassemblies are harder to read, to be sure, especially when all the decimal numbers are shown as unmarked hex and the comments have red-herring selectors, but SCI Companion's "disassemble" output does include both offsets and the actual bytecode.

Feel free to ignore what follows, I'm just bored and rambly.


Say I made a mistake in my game and though I have source code, I can't compile it for the sake of this example. So I can't just edit this:

Code: [Select]

(iMouth view: 501 loop: 1 nsLeft: 207 nsTop: 35)But it turns out 207 is like a pixel off. Decompiling the script resource that's from, I can find the instance and method this is from and cross-reference it with the .sc file:

Code: [Select]

  00f2:7a               push2
  00f3:78               push1
  00f4:38 01f5          pushi 1f5 // $1f5 isMemberOf
  00f7:39 03            pushi 3 // $3 loop
  00f9:78               push1
  00fa:78               push1
  00fb:39 07            pushi 7 // $7 nsLeft
  00fd:78               push1
  00fe:38 00cf          pushi cf // $cf curPos
  0101:39 06            pushi 6 // $6 nsTop
  0103:78               push1
  0104:39 23            pushi 23 // $23 mark
  0106:72 0120          lofsa $0120 // iMouth
  0109:4a 18             send 18 View 501 would be 0x1F5 (so not isMemberOf), and nsLeft 207 would be 0xCF (not curPos). Ignoring some extra bits involving how a send works, we can see that for each selector, we push its number (note that 2 is somehow not described as view but it is), followed by the number of arguments (because there's little distinction between methods and property setters), and the value we want to set it to. So view: 501 becomes 2 1 501. Continue that train of thought and we know that to move Ilira's mouth one more pixel to the side, we need to find the byte sequence 38 00 CF. The disassembly says it's at offset 0x00FE. Add two to account for the resource file header, open the .scr file in a hex editor, go to 0x0100, and what do we see? 38 CF 00. If your hex editor has a data inspector, you may be able to select the two argument bytes and confirm it's 207. (If your hex editor is set to big endian/motorola byte order it'll say 52992 or -12544 instead.) And if your hex editor is particularly nice, you can just enter the new value right there, in decimal, and save.

You now have a patched script resource.

[lskovlun]

That version of SC is not the latest one, unfortunately. Sierra created The Realm with SCI 2.1, a product which was sold off and has been in development since, and that is the version of the compiler that we have. However, Sierra continued their own development, from which came SCI3 and the CSC script format. We do not have those tools.

I agree with Kawa about the solution.

[mnicolella]

Are there projects that are trying to run on the SCI3 interpreter? We have the SC source code, it could be adapted to output scripts in the new format. Would that be useful?

[lskovlun]

I'm not sure how much good it would do. In fact I question some of the design choices made in SCI3. They only made four games in SCI3 proper (and SCI3 was never ported to the Mac - the Mac versions were always SCI 2.1) - but part of the re-architecting seems to have been so that they could make those DLL-based games while keeping the backend (the Antara series, Shivers 2...). If indeed the only problem here is numerical constants, that doesn't justify lots of changes to the compiler.

[miracle.flame]

Honestly, if recompilation isn't much of an option and all you're trying to do is change some numbers, I'd rather take a hex editor to the damn thing. Disassemblies are harder to read, to be sure, especially when all the decimal numbers are shown as unmarked hex and the comments have red-herring selectors, but SCI Companion's "disassemble" output does include both offsets and the actual bytecode.

Feel free to ignore what follows, I'm just bored and rambly.


Say I made a mistake in my game and though I have source code, I can't compile it for the sake of this example. So I can't just edit this:

Code: [Select]

(iMouth view: 501 loop: 1 nsLeft: 207 nsTop: 35)But it turns out 207 is like a pixel off. Decompiling the script resource that's from, I can find the instance and method this is from and cross-reference it with the .sc file:

Code: [Select]

  00f2:7a               push2
  00f3:78               push1
  00f4:38 01f5          pushi 1f5 // $1f5 isMemberOf
  00f7:39 03            pushi 3 // $3 loop
  00f9:78               push1
  00fa:78               push1
  00fb:39 07            pushi 7 // $7 nsLeft
  00fd:78               push1
  00fe:38 00cf          pushi cf // $cf curPos
  0101:39 06            pushi 6 // $6 nsTop
  0103:78               push1
  0104:39 23            pushi 23 // $23 mark
  0106:72 0120          lofsa $0120 // iMouth
  0109:4a 18             send 18 View 501 would be 0x1F5 (so not isMemberOf), and nsLeft 207 would be 0xCF (not curPos). Ignoring some extra bits involving how a send works, we can see that for each selector, we push its number (note that 2 is somehow not described as view but it is), followed by the number of arguments (because there's little distinction between methods and property setters), and the value we want to set it to. So view: 501 becomes 2 1 501. Continue that train of thought and we know that to move Ilira's mouth one more pixel to the side, we need to find the byte sequence 38 00 CF. The disassembly says it's at offset 0x00FE. Add two to account for the resource file header, open the .scr file in a hex editor, go to 0x0100, and what do we see? 38 CF 00. If your hex editor has a data inspector, you may be able to select the two argument bytes and confirm it's 207. (If your hex editor is set to big endian/motorola byte order it'll say 52992 or -12544 instead.) And if your hex editor is particularly nice, you can just enter the new value right there, in decimal, and save.

You now have a patched script resource.

I appreciate the effort but since I have no idea how to get the scorecard script in this "other" format which I can't even name properly I am out of ideas how to even begin attempts to apply the logic in this case. 

[Kawa]

You have Sluicebox's decompilation to guide you. You can't open LSL7 in SCI Companion to check its disassembler output, but there's still SV as a fallback. Difference being you don't get the bytecode and offsets for each instruction, but all the number literals are in marked hexadecimal so there's that, and each entry point and jump target is labeled with its offset.

Looking at Sluice's decomp, you don't even need to change any actual script code, only some properties.

So let's say we want to move "Poop Deck Horseshoes" (oHorseshoes) from 212 by 117 to... let's say 200 by 117. There's only one place in the decompilation where the number 212 appears so that makes it easy. Exporting the .csc file by any means and opening it in a hex editor, we can now look for 212 or 0x00D4 (my editor lets me search for 16-bit integers as-is), and get exactly one place in the file where that number appears: 0x1CD0. The surrounding values are 0x0000 and 0x0075, being the state and y properties. The position of the Horseshoes text can now be edited at will.

I technically didn't even need SV for this beyond to extract the .csc file so most of that first paragraph can be ignored.

[miracle.flame]

Oh wow, this actually helped me enough to make it! Though there are some details I can't quite grasp.
For example:

Code: [Select]

instance oBestDressed of HotText
{
scratch         = $0
back            = $fe ; 254, mute
modNum          = $ffff ; -1
noun            = $0
plane           = $0
priority        = $262 ; 610, listenVerb
state           = $0
x               = $de ; 222, scaleBitmap
y               = $12c ; 300, keyIn
There is no 01 2C to to be found for y but there's 00 2C for this particular occurrence. So what would it be if y was $2c?

Both instance oChastity of TextItem and instance voCrossOut of View don't seem to follow the same positioning values as the HotTexts. Even when setting x value to 00 00 the instance is half way through the scorecard so I don't see how can I get the value any lower to shift the text left. Most of the other values on these instances are identical with the HotTexts so I'm getting nowhere when trying to mimic HotText values.

[Kawa]

0x012C would be stored as 0x01 0x2C in big endian/motorola format. It's stored as 0x2C 0x01 in little endian/intel format. I mentioned that in my first ramble.

My hex editor of choice, Hex Workshop, lets me find values as-is, so I can tell it to find 16-bit signed shorts with the decimal value 212 in little endian. If I were to check "big endian" that second field would change from D400 to 00D4. Checking "either" makes it D400,00D4. Other editors may have similar features, but if they don't you'll have to take care of the byte order yourself.

So what you want to look for is 2C01, not 012C. The bytes are stored little end first.

[miracle.flame]

Yey, I've managed to figure out the little end first logic the hard way. Learned something new today. Thank you Kawa.