SCI Companion documentation

[Kawa]

Outside of its debugger it does not really give anything over DOSBox.

Besides not having to worry about the legality of including an SSCI terp. But that doesn't seem to have ever stopped anyone before.

Which reminds me, I've seen plenty official rereleases of old games (TES Arena and Daggerfall come to mind, also SC2000) that outright include their own copy of DOSBox, so your startup frontend slash configuration utility might not even need to check if there's a DOSBox installation -- there's one right there.

In unrelated news, I didn't want to bump the Original Syntax thread so I'mma sneak this in here. Compare and contrast with this.

[OmerMor]

ScummVm compatibility is an excellent argument against changing the class system.

I looked around the code and lots of places rely on class and selector names.
If you want to search yourself, try these queries:
https://github.com/scummvm/scummvm/search?q=findObjectByName
https://github.com/scummvm/scummvm/search?q=getDetectionAddr
https://github.com/scummvm/scummvm/search?q=findSelector
https://github.com/scummvm/scummvm/search?q=getObjectName

There are many hard coded names to be found, e.g. "Cursor", "Rm", "Actor", "Sound", "DSPlane", etc.
Often it is used to determine the interpreter version capabilities. It's possible that we'd collaborate with them and enable scummvm to introspect games created by SCI Companion by adding some metadata to the game. But I think it's a bit out of scope and I'm not sure it'd be worth it.

One more thing:
I found this page http://www.scriptinterpreter.com/classes, which claims that some classes had full name and abbreviated name that was used after compilation.
What do you think?

[troflip]

ScummVM is pretty crucial for the debugger, as you mentioned Collector.

One more thing:
I found this page http://www.scriptinterpreter.com/classes, which claims that some classes had full name and abbreviated name that was used after compilation.
What do you think?

I think that's Lance's page. It looks like most of those names were guesses, but they would be good suggestions *if* I were to do the rename (GradualCycler, interesting). We've had plenty of threads here about the old syntax, mostly gleaned from stuff (FeatureWriter, PolyEdit, etc...) that outputs the original code. So I think we know all the confirmed "long names".

I mean, it's probably ok to change *most* of the names, but it is adding risk, and it's not easy to test that it's been done correctly and hasn't caused some change in behavior. I *might* try renaming the Inv stuff, because that is way confusing.

[Kawa]

Meanwhile, I got bored.


Checks presence of required files for DOSBox and SSCI in startup directory, populates driver lists according to what's actually available, produces play.bat that's basically "start dosbox sierra.exe" with "-noconsole" if requested. dosbox.conf in the startup directory doesn't need to be specified. logo.jpg or logo.png in that order of preference overrules the image on top, and I may add the same for game.ico.

[troflip]

Logo looks great. Is this meant as something that people could include with their game so others can easily run it?

(thread is being derailed)

What's the deal with your original syntax file? (i.e. what's the purpose, how did you make it)

[Kawa]

Logo looks great. Is this meant as something that people could include with their game so others can easily run it?

Basically, yes.

(thread is being derailed)

Basically, yes.

What's the deal with your original syntax file? (i.e. what's the purpose, how did you make it)

Basically, boredom and a little curiosity.

[MusicallyInspired]

Love that launcher!

[Kawa]

Love that launcher!

Thank you.

*adds game.ico support, ponders internal downloader*

[troflip]

Ok, I am going to do *one* batch of renames, because it really bugs me, and I think people will find it legitimately confusing (I certainly do, and I've been starting at this code forever).

IconI -> IconItem
(InvItem + InvI) -> InventoryItem   (the two classes get combined)
Inv -> InventoryBase

And then there will be some file renames to go along with it. I've tested this with DOSBox and ScummVM and there don't seem to be any issues.

IconI.sc becomes IconItem.sc
InvI.sc becomes InventoryItem.sc contains class InventoryItem
ScrollableInventory.sc contains InventoryBase and SCrollableInventory
InvItem.sc becomes Inventory.sc and contains your actual inventory items, as well as the instance of ScrollableInventory.

[MusicallyInspired]

This will break editing old games won't it? And we'll have to re-decompile Sierra game scripts? Will it also affect SCI0?

[troflip]

I'm not touching SCI0.

I'm not sure what you mean by break editing old games?

[MusicallyInspired]

As in older custom SCI1.1 games with the old naming conventions in the scripts won't compile.

[troflip]

The changes are to the SCI1.1 template game, there are no changes to sci.sh or compiler anything. So they should still compile fine?

[Kawa]

It's okay to be cautious.

In other news the final product of my boredom is now in the stash.

[MusicallyInspired]

Right, classes. I was thinking kernel functions. Duh.