Community
SCI Programming => SCI Development Tools => Topic started by: MusicallyInspired on December 12, 2015, 12:30:02 PM
-
So I've taken the SCI Studio VGA source (which includes the VGA SCI1 template game, which is basically the source for the demo he released) and the included CLI script compiler tool. It's a little hardcoded, I had to create a specific directory structure the compiler was looking for. However, it's looking for a VOCAB.900 file now which I grabbed from his demo, but it still won't accept it. Has anyone ever gotten Brian's SCI1 Script Compiler to work?
My goal is to see if I can rig it up to work for compiling SCI1 games, or at the very least his VGA template game to start with.
-
I have been making some minimal attempts at an SCI1 template as well. Brian had released his scripts for his SCI1 template game, but it had come with no other resources. I had thought about seeing if I could strip down LSL5, which is what I believe he started from. While the game will open in the new Companion, every time I try to do anything with the resources in the new companion it makes the resources unreadable. I hadn't reported this because I know that Phil is concentrating on SCI1.1.
-
Lol, if Companion is corrupting resources, I want to know about it!
Which resources in particular?
If the goal is to make an SCI1 template game, I think you'd get further with Brian's template game using SCI Companion than his compiler...
(or rather just pruning a LSL1 VGA decompile, since it didn't look like he got very far when it comes to naming variables and such).
I've managed to load his template game into Companion (into a LSL1 VGA game) and compile a few files, but there are definitely issues. He mixes use of global[$10] and the actual global variable name. This can be worked around temporarily by renaming the first global variable from "gEgo" to "global", and replacing all uses of gEgo with global[0].
Also, "publics" is the Companion equivalent of "exports" (in (version 2) syntax), except Companion requires a number in front of each export. So those need to be renamed.
-
Here's a game.ini and src folder with some modifications. If you plop them into a LSL1 VGA game (which has the necessary class table, selector, vocab, etc... then you'll be able to compile some (most?) of them.
There are still a number of issues, in particular his use of asm labels to jump around the code in place of "proper" control structures. Companion doesn't support that.
-
I didn't realize that Companion could compile SCI1 scripts, that's why I was looking into Brain's compiler. I tried to alter something in a room in KQ5 and it did nothing, though the compile was "successful". I also tried compiling all scripts and that failed hard. But I guess that's to be expected.
I have been making some minimal attempts at an SCI1 template as well. Brian had released his scripts for his SCI1 template game, but it had come with no other resources.
I thought that it was just his VGA demo game only because I glaced at the room scripts and saw some similar text strings. I didn't delve too deeply, though.
-
There's no reason it shouldn't be able to compile SCI1 scripts, other than I have some bugs :-)
I thought it might be nice to have a VGA game with a parser, so I've been trying to get the 1990 Christmas Card functional and compiling. I thought it would be quick and easy to do and someone else could take it and run with it, but I do have some bugs. Companion mid-detects the lofsa type because it doesn't have enough info. And it guesses wrong. Interestingly, ScummVM also outputs a message that it couldn't determine the lofsa type. Then it guesses right.
Working around that, I did manage to recompile *just* room 2, and add in code that handles a Said, and it worked. However, when I recompile the whole game, something else messes up. Luckily, that interpreter includes a debugger. Unfortunately, it seems flakey. I also tried ScummVM and the game just hangs, and eventually ScummVM just crashed as I was trying to debug it.
I did encounter something strange in the Sierra debugger... before it also hung while debugging, it showed this:
A c:\ prompt.... weird... never seen that before.
-
Interesting!
-
I thought it might be nice to have a VGA game with a parser, so I've been trying to get the 1990 Christmas Card functional and compiling
Have you seen this thread (http://sciprogramming.com/community/index.php?topic=27)?
HWM and trodos already managed to write a script which uses the parser in this demo. Take a look.
-
Yes, that's what I'm using as a base. All they did was hex edit the script resource though (change a 0 to a 1, which enables the parser), it wasn't something that was actually usable, etc...
-
I added a Said for hitting the Seasoned Pro a bit ago and posted pics. Remember that?
-
Vaguely, but I can never find old threads on these boards. How did you manage that? (I guess room 2 compiles successfully, actually).
[Spent five minutes searching, but could not find the thread....]
Ok, found it by looking for your attachments:
http://sciprogramming.com/community/index.php?topic=1534.msg7853#msg7853
-
Well, by making a "bug fix" to the script resource generation code, I've been able to get all scripts but Game.sc and script 255 to compile (well, I can get them to compile, but they cause the game to crash).
If I compile Game.sc successfully, then game will freeze.
If I compile script 255 successfully, I get a "Freeway pather not available!" error displayed whenever I try to type something. No idea what that means...
-
If I compile script 255 successfully, I get a "Freeway pather not available!" error displayed whenever I try to type something. No idea what that means...
That means that the mapping between kernel function names and numbers must be redone for the older interpreter. You are invoking the Intersections kernel call (which was never used in a released game IIRC, and was always a stub) instead of Said.
I can't remember whether the VOCAB.999 file is correct in this game... Sierra stopped updating it at one point.
-
I don't think it could be a kernel number mismatch, because I'm using the decompiled code. So even if the function name were wrong, the number would end up being the same. And Said is mapped properly, because that *does* work (i.e. if I only recompile script 002, and add some Said calls, they work correctly). But is "freeway path" related to Intersections? I'll look more at it tomorrow... [edit: yes, it appears to be... I get the same freeway message if I explicitly call it]
I appears to be related to generating a corrupt script resource though... so who knows what is getting called, or what's going on....
[edit:] Ugh, it was related to a hack I had put in years ago for SCI0 games that were missing the Joystick kernel in their kernel table. It was mapping all Joystick calls (should be kernel 109) to Intersections (113)
-
Still trying to get this Christmas Card demo working properly as a kind of small side project. The scripts/decompilation seem to be working, but I can't get the vocab resources to function properly.
It's fine if you enter recognized words (I have responses for 'look' and 'look man' in the first room where the guy dances across the stage), but if you enter a non-recognized word, the game crashes, freezes or behaves weirdly.
I tracked it down to the Parse kernel call in User.sc. If I turn on the debugger (with (SetDebug)) before that call, and step over the call, I get the error message "vocab.912 not found". Again, this is only for non-recognized words.
Ok, so that means I need a vocab.912. I had been using 901/902 for the suffix/whatever vocab resources (I forget where I grabbed them from, but the 902 one looks like garbage). I tried putting them in slots 911 and 912, but that didn't work.
So instead, I grabbed 911 and 912 from KQ5 and plopped those in there. The Parse call now just hangs, or sometimes DOSBox crashes. Either those aren't compatible with the vocab.900 I'm using, or the interpreter doesn't like them, or I dunno what.
So basically, I'm trying to find a combination off vocab resources that work with this interpreter. I believe the necessary resources are 900 (dictionary), 911 (suffix) and 912 ("tree vocab"), but I haven't been able to get any to work.
I've attached the zipped up game if anyone wants to play around with it.
Note that you will always break into the debugger after typing in a line (Shift-Shift-D continues). Press tab a few times to get the Parse call, and tab again. If you've entered recognized words, everything will be fine (Shift-Shift-D to continue). Otherwise... BOOM.
Note: The current version of Companion I have out there may not compile some of the scripts correctly for this game, so things might start breaking if you compile any of them.
-
I know they're different formats, but have you tried anything with SCI0 or SCI01 VOCAB resources? Wouldn't it make sense that none of those would work from KQ5 because the parser was straight up removed?
-
I was prioritizing those with the closest interpreter numbers, and those that contain resource 911 and 912 instead of 900,901. Unfortunately there are very few of those. I'm not sure when the renumbering happened, but it seems to be right when they removed the parser!
I believe in this case (when you input a non-recognized word), it's trying to load the suffix dictionary to see if it can resolve it that way (and failing). I suppose it's possible that the 1990 Christmas Card Demo just has a broken parser, since it wasn't used.
-
I suppose it's possible that the 1990 Christmas Card Demo just has a broken parser, since it wasn't used.
That doesn't sound too unlikely.
-
Looking at ScummVM, it either tries to get 0/900/901, or 900/901/902 (for main/branches/suffixes). It never does 911 or 912, which is what the CCD appears to be expecting.
So it would be safe to assume that none of the released games with 911 or 912 vocab resources actually use them.
-
I just noticed that the syntaxFail and semanticFail methods are never called from game code. So they must be called directly by the kernel. Which means it could be making erroneous assumptions about which selectors they correspond to.
-
I just noticed that the syntaxFail and semanticFail methods are never called from game code. So they must be called directly by the kernel. Which means it could be making erroneous assumptions about which selectors they correspond to.
This is true. The reason for the numbering change-over, btw, is the introduction of support for multiple languages in SCI01. The way it works is that the interpreter chooses between 900/901/902 or 910/911/912 based on the value of the parseLang and printLang properties of the game object. Having two sets of files allowed you to switch languages on the fly. The formats should be identical, but changed from SCI0 to SCI01 (Companion does support loading them; but are you saving them properly?).
The language codes follow the international telephone codes, so in general both selectors should have a value of 1=English.
EDIT: And of course, these selector numbers are hardcoded into the interpreter (it doesn't use VOCAB.994 here).
-
Companion doesn't support editing the 901/902 resources, and I haven't changed the 900 resource (and I know that works anyway), so Companion saving them properly isn't an issue.
I don't understand what you mean by "both selectors should have a value of 1=English. "
The selectors for syntaxFail and semanticFail are 72 and 73. Not sure how that relates to 1=English.
Or you're talking about the printLang and parseLang? Those are 87 and 86, respectively.
Oh, you're saying the values should be 1 (they are), but possibly the printLang and parseLang are being looked up incorrectly because the interpreter uses hard-coded values.
So given the interpreter uses hard-coded values for printLang, parseLang, syntaxFail and semanticFail, there are two potential failure points: getting the language properly, and invoking syntaxFail/semanticFail properly.
I suspect the former is not a problem, because things work fine when entering words that don't cause syntax fails.
-
The language codes follow the international telephone codes, so in general both selectors should have a value of 1=English.
Is this consistent across all interpreter version? I have been wondering about the values for the language flag in the RESOURCE.CFG.
-
The language codes follow the international telephone codes, so in general both selectors should have a value of 1=English.
Is this consistent across all interpreter version? I have been wondering about the values for the language flag in the RESOURCE.CFG.
Yeah, I forgot to mention that. Sierra adheres to this principle strictly. The value is used in StrSplit and similar functions (mapping #S, #J, #P and so on to the corresponding numbers). Some interpreters (but apparently not the CC1990 one) take the language= value and put it in the appropriate property on startup (I can't remember whether these interpreters modify both properties or only one of them).
-
Thanks, it never occurred to me to cross compare the few I knew from the RESOURCE.CFG to the telephone codes. I have been wanting to compile a list for a reference for my installers and patches and such, but only had a few non-English RESOURCE.CFGs to check. It would be nice to have enough info on how the interpreter used this to create documentation or even a tutorial so that fan developers could do multi-language games with Companion.
-
Looking at ScummVM, it either tries to get 0/900/901, or 900/901/902 (for main/branches/suffixes). It never does 911 or 912, which is what the CCD appears to be expecting.
Also, ScummVM does access 910/911/912:
if (_foreign) {
_resourceIdWords += 10;
_resourceIdSuffixes += 10;
_resourceIdBranches += 10;
}
-
Thanks, that would have been a tough thing to search for!