Decompilation Archive

[Collector]

Great. Could we have game/interpreter version info included for each decompiled source?

[EricOakford]

Just added a readme file containing the interpreter and game versions (where available). For the most part, though, it's only really important for the full games.

[Collector]

Great. I just noticed that you have the LSL2Demo under funseek. This is ambiguous since there is the Fun "Seekers Guide to East Madera County".

[Collector]

Not to get too pedantic, but what about a readme in each game's entry with the versions info? I am not sure if it is possible with GitHub, but it would be nice if there was a way to download each repo separately as individual zips instead of the entire thing..

[EricOakford]

Gave each game its own readme file with version info and known issues.

I just noticed that you have the LSL2Demo under funseek.

You must be referring to this commit.
No, I think you might have been confused by the fact that I touched up a few scripts for the Fun Seeker's Guide at the same time as the LSL2 demo.

[ZvikaZ]

Thanks for uploading these games to GitHub.

Can you please also upload the other games, such as SQ3 (and I don't remember what else there is in this thread...)

[MusicallyInspired]

I'm sure he's getting to it. It's probably a lengthy process.

[EricOakford]

It is indeed a lengthy process. But now I have decompilations of LSL2 and SQ3 ready! SQ3 has been tested to completion with no known issues, and LSL2 is currently being tested.

[MusicallyInspired]

Appreciate your hard work!

[OmerMor]

Thanks Eric!

Why are the binary SCO files needed?
Do they contain any information not contained in the script files?
If they're needed for SCI Companion, would it be possible to re-create them from the scripts?

I think my question was overlooked.
Can anyone here please answer?

[lskovlun]

I think my question was overlooked.
Can anyone here please answer?

Back in the old days I had a tool that created (SCI Studio) .SCO files from script files. That's how I created my first SCI games. The main things they gave you that the script files don't have were the names of exports and variables. I think what they mainly give you nowadays (what with the decompiler and everything) is not needing to do full builds all the time.

[Kawa]

They contain names and exports and such, so the compiler can link smarter than Sierra's did. I don't think they're actually needed for present purposes.

[troflip]

I believe I could have gotten rid of them for SCI Companion (along with the 'use' statements), but I just made it have "compatibility" with SCI Studio as a first step, so they got left in.

If there are any scripts with cross dependencies (script A calls procedure in script B, and script B calls procedure in script A), then they are kind of needed with the current setup. Otherwise you'd need to remove the dependencies temporarily to get one of the scripts to build and produce a .sco.

[OmerMor]

Thanks for the answers!
I'm only bothered because they add some friction when maintaining SCI projects over source control such as github.
I guess if there was some CLI tool (like Lars mentioned he once wrote) that could create SCO files from scripts, then with a bit of automation we would be able to get rid of these files altogether.

[gumby]

I think there is a command line compiler.  SCI Studio (or maybe a tool that Brian made) had this capability.

Edit: scc.exe?