SCI Companion V3 - alpha build notes/bugs/feature requests

[OmerMor]

The Game class (which is part of the System classes) is derived by a game specific class (e.g. Kq6), usually in main.sc.
The game is started by the kernel issuing the play: message to the object whose ID is in entry 0 of script.000.
The play method sets the global variable theGame to that instance.
The compiler will use the symbol for an instance or class as its name unless name is explicitly set.
The save/restore classes will use the theGame's name property for the filename.

Code: [Select]

game.sh
=======
(define  ROOM_ZERO               000)
...

main.sc
=======
(script# ROOM_ZERO)

(public
   FooQuest 0
   ...
)

(instance FooQuest of Game
   (method (init ...)
      (= name "FQ")
      ...
   )
   ...
)

game.sc
=======
(class Game kindof Object
   (method (play)
      ;
      ; Invoked from the kernel, this starts the game going, then goes into the
      ; main game loop of doit: then wait for the next animation cycle

      (= theGame self)
      ...
   )
   ...
)


[Kawa]

Code: [Select]

(instance FooQuest of Game
   (method (init ...)
      (= name "FQ")
      ...
   )
   ...
)

Oooooh you rascal.

[troflip]

[edit: Ninja'd by Omer]

Sounds like it's set in the same way in both template games then. It's just the name of the main Game instance.

Note that the brace syntax doesn't exist in the Sierra syntax as it does in Studio syntax (in Studio it's for creating syntax tokens with spaces and other illegal characters, in Sierra it's used for internal strings). If your object name needs spaces, it can be set with the name property. So it should be as simple as adding a name property to the Game instance.

Code: [Select]

(class Template of Game
(properties
name "KQ11"
script 0
printLang 1
_detailLevel 3
panelObj 0
panelSelector 0
handsOffCode 0
handsOnCode 0
)

So Collector, in your properties page, when you set the save game name, is it going in and editing the Main.sc script? Wouldn't it then need to recompile for that to "take"?

[Collector]

Rather SQ5SG.

[Kawa]

Rather SQ5SG.

Shit, yes. You fix one error only to leave the other. Kill me now.

[Collector]

So Collector, in your properties page, when you set the save game name, is it going in and editing the Main.sc script? Wouldn't it then need to recompile for that to "take"?

Yes, of course, but the automatic part of that in Developer was during setting up a new game. You can use the game properties dialog to change the name of an existing game and it will change the main script and it would still need to be recompiled just like any script changes. Compiling is a bit of a moot point as Gumby never wrote his compiler. That was the biggest thing left to do on his end.

[Collector]

Rather SQ5SG.

Shit, yes. You fix one error only to leave the other. Kill me now.

You grabbed the 'DIR' from the catalog file 'SQ5SG.DIR'.

[Kawa]

Close enough. I was considering how to write "SQ5SG.DIR and SQ5SG.xxx" in a concise manner, came up with the * thing, and fucked up removing the earlier idea.

Just now nearly wrote "SQ5DIR.xxx" in fact.

[troflip]

Oh, you know though... for SCI1.1 the game name has to be a known one in order for it to run in ScummVM (that's why it is SQ5 in the template game). So if someone customizes it, they can't run their game in ScummVM.

[Collector]

Is that some kind of secondary check? Most games are ID by ScummVM by the MD5 of the first 5000 bytes of a given file. In the case of SCI that is usually the map file. It is how it can determine between different versions of the same game. In any case, the template game could be submitted to ScummVM to have it IDed as a template game instead of SQ5.

[troflip]

We'd need to agree on some new mechanism for the check though. The MD5 hash obviously won't work. Maybe some sentinel value in a global variable or something. Or a file whose presence indicates a either the known SCI0 or SCI 1.1 template game.

Hmm... there's a ScummId named value in the game.ini. Where did that come from? I don't recall putting that in, but I don't know who else would.

[edit:] Oh yeah, I did add it, and it's passed as a cmd line parameter to ScummVM, but it still doesn't work if the Game class name isn't a known game.

[Collector]

At one time it would load generic AGI fan game, even if it did not recognize the game. This would need to be done on their end, but if it could just simply ID any unrecognized game as generic. I am sure that this would be harder with SCI than it was with AGI, given how much more interpreter version specific they are. If ScummVM checked the interpreter version of a game it did not recognize then it might be able to load a game generically. We would really need to talk with them after the template is finished.

[MusicallyInspired]

ScummVM has the capability to recognize SCI fangames, but it's cased out or something. I built my own version of ScummVM that adds it in. I have no idea why it doesn't detect by default. It's a simple case change. Either adding or removing a couple lines of code. Like it was disabled on purpose. And in all the time progress has been made, fangame forums opened on the ScummVM forums, and SCI fangames have been created it hasn't been enabled. I don't know what their reasoning is.

[Kawa]

What I know from my studies is that whatever specific game it's detected as unlocks certain game-specific features. Like how SCI11 RemapColors is only available in QfG4 Demo. Of course, if you're gonna detect SCI fangames, and especially SCI0/Studio or SCI11/Companion fangames, you could do things like throw in RemapColors for the latter, maybe.

[MusicallyInspired]

Random question about opening Sierra SCI games. I'm trying to open KQ5 CD version and it's having trouble understanding sound resources with embedded digital audio. It just says Resource load failed next to each digitally embedded resource. They won't even play. Is there a specific setting I can change in the version detection window to get them to load?