Original SCI syntax

[Collector]

So these would be the equivalent of C/C++'s *.h files?

[lskovlun]

So these would be the equivalent of C/C++'s *.h files?

Yes. They are header files giving symbolic names to the numbers found in the corresponding MSG file. And the .SH files are actually parsed by KQ8, as previously noted.

[troflip]

Does KQ8 actually depend on them for the game to run? Some of SCI1.1 games load and parse these files too, but only for the debug features that were left in.

[MusicallyInspired]

Ohh, could I also request the SQ3 source? There's some code in that game I've been curious about.

[Collector]

Here are the MoE SH files

[lance.ewing]

I was wondering if someone has done an exhaustive search across as many later SCI games as possible for scripts that generate SCI source, such as the Feature Writer?  Troflips find with the "switch" keyword was great. I'm wondering if Sierra continued to expand on the in-game code generation tools as time went on, and therefore whether we might find some gems like that in later games that might reveal more. Even if we couldn't decompile the later games yet, maybe a search across all uncompressed text for patterns that look suspiciously like source code might reveal something. I wonder how far they took these in-game code generation tools.

Script.21 in Space Quest 6 looks interesting. It appears to reveal an additional bit of original syntax:

Code: [Select]

lofsa string_047a ; " (super init: &rest)\r\n"

There is other code in the script as well, but I think an example of the use of &rest is something new. This obviously relates to the &rest op code, but what is interesting is that it appears to show that they also had the & in front of "rest" in the original source.

[troflip]

SQ3 source code attached. There were some problems in script 18, looks like there is some bad code in there (or else my version of SQ3 is corrupted or something). RadarScript::changeState branches to offset $c000, which is way out of code range. Interestingly, script 0 also has an invalid export $c000. Curious...

collector, thanks for the .sh files!

So maybe I'll standardize on having _V, _N and _C suffixes for the verb, noun and cases.

[lance.ewing]

I'm also wondering about this from Script 18 in QFG4:

Code: [Select]

lofsa string_0536 ; "[egoStats i] is %d"

I realise this isn't source, but rather is a debug message. It's a strange way of referring to an item in an array though (if that is what it is doing). Why not say :

Code: [Select]

"egoStats[i] is %d"

It hints at some connection with the original source.

[troflip]

Good find on the &rest thing. I think more interesting than the ampersand is the fact that rest doesn't take any parameters. In SCIStudio it takes a parameter that means "from this parameter and on". Does that script have the method signature text in it too? What does it look like?

[MusicallyInspired]

Thank you.

[lance.ewing]

Good find on the &rest thing. I think more interesting than the ampersand is the fact that rest doesn't take any parameters. In SCIStudio it takes a parameter that means "from this parameter and on". Does that script have the method signature text in it too? What does it look like?

These are all the strings related to the source generation code in that Script:

Code: [Select]

string_03b9 = "%d.fea"
string_03c0 = "Output File Name:"
string_03d2 = ";***************************\r\n"
string_03f1 = "\r\n"
string_03f4 = "(instance "
string_03ff = " of Feature\r\n"
string_040d = " (properties\r\n"
string_041c = " x"
string_0420 = " "
string_0425 = "%d"
string_0428 = " y"
string_042c = " sightAngle 40\r\n"
string_043e = " noun\r\n"
string_0447 = " )\r\n"
string_044c = " (method (init)\r\n"
string_045e = " (self setPolygon:\r\n"
string_0474 = " )\r\n"
string_047a = " (super init: &rest)\r\n"
string_0492 = ");"


string_04e0 = " ;********************\r\n"
string_04fa = " (curRoom addObstacle:\r\n"

Maybe in this case, &rest without anything after it would mean from the first parameter, i.e. all of them? They'd still need the additional starting parameter when starting from a parameter different from the first, otherwise I'm not sure how this syntax would cope with that case.

From these strings, it would seem that the "(super init: &rest)" call is within a method defined as "(method (init)", so apparently doesn't have any defined parameters. So I guess this means it could take some unknown number of parameters and it would pass them all through to the super init, which in this case would be the Feature init. I guess therefore that the parameters passed to this init would need to match what Feature init is expecting.

[troflip]

Well, yes, they need to match. In general, without a parameter supplied to it, I'd guess it would just pass all the parameters after the last named parameter in the signature (in this case there are no named parameters).

Given that sci studio allowed you to specify from what parameter onward was passed (which mirrors the &rest opcode), I'm just wondering if there is ever a scenario where a function passes anything other than the parameters after the last one it uses. I.e. Maybe there is no need in source code for the argument used with the rest statement.

[lance.ewing]

That's a good point. Technically the original source shouldn't need to specify what parameter to start at, since they'd be able to refer to the named parameters for those ones, then follow that by &rest for the rest. I suppose it is possible that they might want to skip the first couple of the unnamed parameters, but that would be a bit strange. It would imply that they do know what's in that parameter list, so why not name them all?

I guess that if we can find an example where the compiled byte code for a method or procedure refers directly to parameter numbers up to a certain number (e.g. let's say 4) but then it has a &rest instruction that starts at a lower number, e.g. 2, then that might answer the question.

[lance.ewing]

I think it will be difficult to spot something like this manually. It occurred to me that you could probably add a throwaway piece of code in to your decompiler to solve this problem. For every method or procedure it decompiles, if it encounters &rest, then it subtracts from the number after &rest the max param number that it encounters in the same method/procedure. If the original source always had &rest with nothing after it, then we'd expect the result to always be 1. All you'd need to do then is run a few games through your decompiler and see if this ends up being the case. I have a feeling that your theory is correct and that it will always be 1.

[lance.ewing]

Thinking about that a bit more, I wonder if you might get something other than 1 if the last named parameter is an array. I haven't looked to see how array parameters affect references to parameter by number.