Community
SCI Programming => SCI Development Tools => Topic started by: troflip on April 27, 2015, 04:17:25 PM
-
I'll use this thread to talk about mysterious or confusing things I've come across while decompiling scripts.
A number of scripts have objects with blank names. This is true in SCI0 as well as later versions. The template game's MenuBar and Control classes don't actually have those names in the original sierra code they came from (either LSL2 or LSL3). Instead, their names are empty. Those are the only classes with empty names in those games (I think).
In SQ5, again there is a class in script 255 with an empty name, which I believe corresponds to the Control class. It inherits from Obj.
There are also 3 other empty-name classes in SQ5:
- Script 943 has an empty-name class that has methods like draw/save/restore, and calls kernels like Graph. I don't know what it does.
- Script 948 has two empty-name classes that appear to be related to debugging (a "feature writer").
These last 3 empty-name classes inherit from 0xffff, which means they inherit from nothing, just like the Obj class.
Does anyone have any guesses as to why Sierra generated scripts with empty class names? For the decompiler, I can just give them generated names, like "Class_255_0". The latter 3 classes mentioned above all appear to be related to debugging, so I can see why they might have their names removed. But the first one is the Control class. I guess it's not actually used outside that file, so maybe it doesn't name a name. Maybe it was a way of marking the class "private" or something.
-
Regarding the empty names, I think it would have been to save a little (tiny) bit of space. The compiler and language probably supported it and then I guess it was up to the developers as to whether they chose to "blank" or shorten the name. It is already fairly clear to me that some of the class names are shortened from their original, such as PV, which is clearly the PicView mentioned in the Official Book of King's Quest, and Act, which is Actor. Obj itself could be short for Object. Anything that is abbreviated or truncated is likely to be a shorter version of the original source name. Some other examples:
Rm = Room
Rgn = Region
SL = StatusLine
Rev = Reverse
Fwd = Forward
CT = CycleTo
Blk = Block
Given that the "name" is a property (admittedly a special property), it's default value could probably be overridden, even with a blank value it would seem. The very existence of blank names is almost proof that there was a way to override the name property.
The interpreter itself doesn't really need the names, so I'm assuming that the name property was mainly for debugging purposes.
What also seems clear is that they didn't use this ability to override and shorten the name property all the time. A lot of the classes clearly have their original names, such as Feature, Script, View, Prop, Event, List, Set, Motion, MoveTo.
Regarding inheriting from 0xffff (i.e. nothing), this suggests a super class even more super than Obj that exists within the interpreter kernel itself. For a while I've been wondering if it was called RootObj since this string appears within the SCIV.EXE, but I can't seem to make the interpreter or its debugger display this string. Does anyone know when the interpreter would display this? I show its context within the SCIV.EXE below:
Objects
Fragments
Resources
Free Heap
Proc
size:%d
max:%d
cur:%d
PMach
size:%d
max:%d
cur:%d
Stack
%02x%c
%c %c
Inspect :: $%04x
RootObj
super: %s
%s:%d
%s:$%x
Inspect :: %s ($%x)
%s not a Collection.
%s is empty.
%s :: %s
Selector
%s: not selector for %s.
Property
-
I definitely agree with you about the shortened names (indeed, in the original SCI syntax thread, the feature writer I mentioned outputted full names like "Actor").
As for getting RootObject to be displayed, I haven't been able to. I tried displaying an object in the debugger which had no super class (e.g. the Obj class itself, which inherits from "root"). It's super was displayed as "I5".
Knowning that 0xffff is the marker for "root", I look at the address 0xffff, which, when it wraps around to 0x0000, had this address in it:
0x7573
And looking at that address, and interpreting it as an object, down where the value for the name selector would be, I see:
49 35 00
which is the ASCII string "I5".
So it was just showing whatever garbage happened to be at the address pointed to by the 0xffff address.
So that all makes sense, but it still doesn't help learning what "RootObject" is.
-
The feature writer might be where I saw PicView actually, rather than the book.
If someone had enough time, they could probably disassemble SCIV.EXE and see where the RootObj string is referenced. It appears among all the other debugger text but the inspector doesn't seem to recognise that name. I wonder if an early version of the interpreter displayed it as the super of Obj and it subsequently broke. It's certainly one of the mysteries.
If we identify all of the classes that inherit from 0xffff, and we then look at what is common between them, we could probably identify what the root obj provides. I'm guessing it would be all the "special" properties, such as species, super, name, -info-.
-
Interestingly, the long names Actor and PicView are used in most SCI1.1 games.
New mystery:
My decompiler is barfing on invalid offsets in some scripts' export tables. Zero often appears in a script's export table, which I think I mentioned before. However, I've now seen the value 0x3af appear in a few script's export tables (in SQ5, scripts 16 and 104), and it points to garbage (instead of a valid code or an object). It's easy to detect this when the script's code section is shorter than 0x3af (since I can see it's out of bounds), but more difficult when it does point into the middle of valid code.
SCI Viewer shows the export:
export104_0 = rm104
export104_1 = $0
export104_2 = $0
export104_3 = $0
export104_4 = $0
export104_5 = $0
export104_6 = $0
export104_7 = $0
export104_8 = $0
export104_9 = $0
export104_10 = $0
export104_11 = $0
export104_12 = $0
export104_13 = $0
export104_14 = quirkTalker
export104_15 = code_03af
3af is a valid script number (943, ClickMenu). I'm not sure if that's important.
-
I think after your latest post I may be able to provide some help here. When we first implemented SCI01 support in FreeSCI, it seemed as though every other export was zero, leading to the (unsubstantiated) hypothesis that interesting things might happen if that "other" export was not zero. Do you recognize this pattern? There definitely seems to be some additional code present in the post-01 SSCI script loader to handle that case; I haven't bothered to look at it, and the scripts seem to work without it (but then again,I'm baffled by some of the workarounds that the ScummVM people claim to be necessary). The pattern from SCI01 seems to be gone in SCI1.1, but it's possible that there are still things to be found in the relocation code (but then you'd wonder why the scripts work in ScummVM at all).
In any case, the 0x3af=943 finding is interesting.
-
I mean, I don't think the 0x3af is problematic as long as no one calls that export. Like the interpreter shouldn't even ever access that value. But of course it does matter if you're disassembling or decompiling!
It should be easy for me to see if there are other SQ5 scripts with that weird export, and if any code ever calls it (which would be *really* strange).
I haven't seen the "every other export was zero" pattern in any of the games I've looked at yet... just occasional random zeroes in the export table.
[edit:]
Ok, there's only one other script in SQ5 with that 3af export, and it's script 243. I looked at LSL6 and KQ6, and didn't find that 3af export anywhere, so it doesn't look like it's any kind of marker or anything. And no code in SQ5 calls those scripts' exports.
So I suspect it's just some garbage value that Sierra's compiler wrote out, and it never caused problems, so no one noticed.
-
Next weirdness, exports appearing multiple times:
export209_0 = sStartViewPort
export209_1 = sStopViewPort
export209_2 = viewPort
export209_3 = $0
export209_4 = $0
export209_5 = $0
export209_6 = $0
export209_7 = $0
export209_8 = $0
export209_9 = $0
export209_10 = $0
export209_11 = $0
export209_12 = $0
export209_13 = $0
export209_14 = viewPortTalker
export209_15 = $0
export209_16 = viewPortTalker
export209_17 = $0
export209_18 = viewPortTalker
-
I don't think there's anything preventing mentioning an export several times... and SQ5 was the only title (as far as I know) to be implemented in SCI outside Sierra.
-
Wasn't RAMA done at Dynamix, too? But of course that was SCI3.
-
I wasn't aware of the Dynamix thing, even though I owned the game... but the demo definitely is SCI2.1...
-
I don't think there's anything preventing mentioning an export several times... and SQ5 was the only title (as far as I know) to be implemented in SCI outside Sierra.
It's the first that I've encountered it. It does present a small problem for decompilation, since the current SCIStudio language doesn't provide any options to explicitly declare the export # for a procedure or object (but I can use the existing (generated) .sco file to track this).
-
I wasn't aware of the Dynamix thing, even though I owned the game... but the demo definitely is SCI2.1...
Just checked. I was right that RAMA was done at Dynamix. The full game was interpreter 3.000.000.
-
Interestingly, the long names Actor and PicView are used in most SCI1.1 games.
Yeah, that is very interesting. Are there any other classes using a longer version in later games? I'm wondering if we can identify a few more of the original class names by looking ahead to newer games. I've noticed some of the short names are 3 or 4 letter acronyms, which makes it a bit harder to guess. But if they use the longer names in later games, it might solve the mystery.
Once you establish original class names for various shortened names, you could get the decompiler to swap them in.
-
When we first implemented SCI01 support in FreeSCI, it seemed as though every other export was zero, leading to the (unsubstantiated) hypothesis that interesting things might happen if that "other" export was not zero.
Ok, now I'm seeing this (SCI Viewer doesn't show it directly, but you can see it in the raw bytes). I don't think it's that every other export is zero, but rather that each export is 4 bytes instead of 2. If that's correct, it should be an easy fix to make, I just need to know how to detect this reliably.
I found the code in ScummVM that handles this:
bool exportsAreWide = (g_sci->_features->detectLofsType() == SCI_VERSION_1_MIDDLE);
So I think I should be able to identify this case.
-
Another mystery. A few scripts in SQ4 load string offsets that don't point directly to the beginnings of strings in the string table.
In main:
string_2b0d = "nx.yyy"
and code loads, 2b0e, which would be "x.yyy"
In script 255 (Print):
string_1671 = "\001PrintD"
and code loads 1672 ("001PrintD") and sets it as the Dialog's name selector value (how strange is that).
x.yyy seems like a version string. I'm wondering if 'n' and '\' are special markup that indicates something to some code in the kernel which looks backwards one byte from the string provided.
-
Another mystery. A few scripts in SQ4 load string offsets that don't point directly to the beginnings of strings in the string table.
In main:
string_2b0d = "nx.yyy"
and code loads, 2b0e, which would be "x.yyy"
In script 255 (Print):
string_1671 = "\001PrintD"
and code loads 1672 ("001PrintD") and sets it as the Dialog's name selector value (how strange is that).
x.yyy seems like a version string. I'm wondering if 'n' and '\' are special markup that indicates something to some code in the kernel which looks backwards one byte from the string provided.
Finding bugs in SCI Viewer now? :) Seriously, this looks like a classic off-by-one bug to me. Also, which version of SQ4 is this? I don't see this in any of mine.
-
SCI Viewer says the interpreter is version 1.000.753
The game says "Space Quest IV Version 1.052"
I'm pretty sure the 1.052 is filled in by the interpreter/kernel.
The game calls
FormatPrint(811 0 gGlobalThatPointsToXYYY)
(and FormatPrint just forwards it to the Format kernel)
Text resource 811/0 starts with:
"Roger Wilco and the Time Rippers\nSpace Quest IV Version %s"
So somehow the kernel knows to substitute some version number for the string "x.yyy". ScummVM gets it right, so it must have that functionality in it somewhere?
As for bugs in SCI Viewer, I'm not sure what you mean. SCI Viewer correctly knows that SCI1 games use 32-bit entries for the export table (it shows things correctly).
-
Ok, I figured out what was going on... the game code does actually write to this string (I didn't expect for code to write to the string table, but that's what it does).
My decompiled code shows this in script 803:
FileIO(5 gGlobalThatPointsToXYYY 6 = local2 FileIO(0 "version" 1))
Breaking it down, this opens the file called "version" :
= local 2 FilIO(0 "version" 1)
Then this reads the contents of the version file into the buffer pointed to by gGlobalThatPointsToXYYY, up to a max of 6 characters:
FileIO(5 gGlobalThatPointsToXYYY 6 local2)
-
I was wondering if it might not be stored in the VERSION file, since some SCI games check for the file before starting. For fun I just experimented by changing the VERSION file and the game reports the same. This would make sense since some patches changed the game version and sometimes included a new VERSION file.
-
I've noticed a few things about code blocks over the past few weeks. Firstly it seems that procedures often share a code block with methods; more often than not I'd say. This makes sense I guess, since if you have a number of procedures immediately before a class definition, then the code for the methods defined in the class might be all grouped together in the same code block as the procedures. The order of "callable code units" within the code block in such a case would be the procedures followed by the methods. So far so good.
What I've also noticed is that you wouldn't get the methods for one class sharing a code block with the methods of another class. I guess this is a side effect of the compilation process. It would output the class block for one class when it gets to the end of that class definition, i.e. before it outputs the code block for the next class. This means that normally you'd get a pattern where a code block will have either all procedures (let's say if the procedures were at the end of the script) or all methods (where there are no procedures immediately above the class) or procedures at the top of the code block followed by methods. The methods and procedures are output in to the code block in the order in which they appear in the script file. That all makes sense.
Tonight I noticed something a bit strange though. It seems that sometimes we get procedures at the end of a code block, i.e. after the methods.
What does that imply? Could it mean that procedures can be defined within a class definition? I can't see how the compilation process would generate something like that if this was not the case.
What is the benefit of this? Why would they need procedures within a class? Why not make it a method?
Has anyone found byte code for a procedure appearing in a code block that has methods either side of it? If we can find an example of this, it might be stronger proof that procedures could appear within classes.
-
Tonight I noticed something a bit strange though. It seems that sometimes we get procedures at the end of a code block, i.e. after the methods.
What does that imply? Could it mean that procedures can be defined within a class definition? I can't see how the compilation process would generate something like that if this was not the case.
What is the benefit of this? Why would they need procedures within a class? Why not make it a method?
Well, what we found in the FreeSCI days is that procedures can and do use the self keyword, so they are assumed to execute in the context of some object or other.
I guess we never really looked at what code block those procedures belonged in.
As for the reasons, selector space must have been considered precious. While there was no maximum in SCI0, the selector vocab file was stored in heap memory. Having too many would limit the amount of memory available for other purposes. SCI1.1 had some reserved numbers, starting at 4096 (212).
-
In the SCI0 template game, there are three procedures that "belong" to a class:
(procedure (GetCel) of Extra
(procedure (IsSaveDialog) of SRDialog
(procedure (CueClient) of Timer
They could have easily been methods, but as Lars said, they maybe wanted to save on selectors? I don't see any cases where they get re-used between different unrelated classes, so at least code re-use doesn't seem to have been the purpose.
In my decompiled SQ5 source files, there is just one (the Timer one), which I detect by saying "oh hey, this is weird, there are property accessors in a procedure", then I look at all code in the script that calls that procedure, and hopefully (so far at least), it's always called from one class, so I mark the procedure as being "of" that class in the source code (which lets it compile while using self or property accessors).
-
Well, what we found in the FreeSCI days is that procedures can and do use the self keyword, so they are assumed to execute in the context of some object or other.
I guess we never really looked at what code block those procedures belonged in.
Yeah, I guess the use of the self keyword is pretty much absolute proof, isn't it? I wonder if using self makes sense to any procedure when invoked from within a method of a class, or whether it only makes sense to procedures that are part of the class, i.e. defined within the class, from whose method the procedure call originates. You guys probably know all this already from SCI development experience. Does SCI Studio and SCI Companion have support for procedures with calls to self?
-
Yeah, I guess the use of the self keyword is pretty much absolute proof, isn't it? I wonder if using self makes sense to any procedure when invoked from within a method of a class, or whether it only makes sense to procedures that are part of the class, i.e. defined within the class, from whose method the procedure call originates. You guys probably know all this already from SCI development experience. Does SCI Studio and SCI Companion have support for procedures with calls to self?
Clearly it has support for this, since I just outlined three procedures in the template game that do this.
There are a number of opcodes that require a "class context" to be used. Any the of property set/get opcodes, self, super, selfID. The interpreter has a notion of the "current object", and it uses that to process these opcodes (actually, super may not require that, not sure). If a class method calls into a procedure, the "current object" is still that class.
Then, separate from that, is what is needed for compiling source code. The "self" keyword (which corresponds to the "self" opcode) actually doesn't need any context. i.e. to generate the bytecode for "self", I don't need to know what the class context is. So self can appear in any procedure (maybe I should make this an error? I forget if any template game code leverages this or not).
I can't generate bytecode for any of the property opcodes, or "super", without knowing what class this is for. Thus, when used in a procedure, that procedure must be marked as "belonging" to a class (like the 3 examples in the template game) or else it's a compile error.
As for codeblocks (I'm assuming you mean the code sections in the SCI0 script files?), I doubt it matters where things are physically located in the script resource. I certainly never paid any attention to it when writing the SCI Companion compiler. So I think it has no relevance whatsoever to whether or not a procedure is used within an object context. SCI1.1 uses the separate script/heap resources with a significantly changed format, and the notion of "code blocks" doesn't really exist anymore.
-
In the SCI0 template game, there are three procedures that "belong" to a class:
(procedure (GetCel) of Extra
(procedure (IsSaveDialog) of SRDialog
(procedure (CueClient) of Timer
Yeah, I think Extra might have been one of the examples that I saw where the procedure was at the end of a code block, after methods.
-
Yeah, I think Extra might have been one of the examples that I saw where the procedure was at the end of a code block, after methods.
If you compile with SCI Companion, it looks like it's put at the beginning of a code block.
-
Has anyone found byte code for a procedure appearing in a code block that has methods either side of it?
I've found an example of the above. In script 995 in LSL5, there is a procedure in the middle of a code block, situated between two methods of the same class. The class is Inv.
For the version I'm looking at, the byte code entry addresses for the methods in the Inv class are as follows:
$60d init
$615 ownedBy
$620 showSelf
$6b3 show
$6e9 advance
$75e retreat
(there's a procedure at address $7c0)
$84a doit
$c98 hide
$d3c advanceCurIcon
These methods are all in the same code block.
There are also two procedures in this code block. One quite large one appears at the start of the code block at $01aa. The other procedure appears at $7c0, which slots between the retreat and doit methods. The procedure at $7c0 is called a couple of times by the doit method.
-
What's purpose of your investigation? Are you trying to determine what the original syntax might have been for these procedures?
Given the pattern you're seeing in the codeblocks, it's a reasonable assumption that these procedures were defined in a class in the original source code (as opposed to the "procedure blah of fooclass" that Brian used). Basically, they'd be like "private" methods, I guess.
Your version of LSL5 must be a little different than mine. In mine, the procedures are at $1ae and $7c4 (close, but off by a bit). Decompiling script 995 in LSL5, only the $1ae procedure was identified as being "of" the Inv class. $7c4 wasn't because the only class-specific opcode used was "self", which can compile without knowing which class it belongs to (I think I had to do that because there were some procedures in the SCI0 template game that were like that).
-
All of this brings to mind that I found one of the original developers that still had the original source to Freddy Pharkas. I asked him if it would be possible to see a sample of the code just to get a feel for what the original SCI was like and told him that I understood if he could not, but he quit talking to me all together.
-
I actually used to work with someone who had worked on SQ3 and KQ4 (and probably other titles). I recently bought an old copy of the KQ book, and there was even pictures of him in it. Unfortunately he left the company I worked at, oh, probably 8 years ago (I've also since left), and I don't have any contact info for him (and I can't find him on the internet - no fb or linkedin page or anything).
-
I don't know if they are under some kind of NDA and if it still applies after all of this time, but I would that after all of this time no one would care any longer. A couple that I have talked to that didn't seem so reluctant had been away from it for so long that memory failed enough that they were not able to reveal anything worth while. The person that would be fantastic to get information from would be Jeff Stephenson. I think that Lance managed to tracked him down once, but did not make contact. Not that it would be likely, but having the full original source for FPFP would have been fantastic, even if it was not the final code.
-
Yeah, that's a hard one, isn't It? People will obviously feel reluctant to discuss what were trade secrets at the time. As you say, it seems like it has been long enough. Maybe even they don't know when it will have been long enough. If there are NDAs involved, they may choose to play it safe. The games themselves are still not free, although they are much cheaper than they were. The recent interest in the rights for some of these games with sequels in mind shows that the IP might still be worth something?
I think there is a danger in discussing this on a public forum like this. It might work against us. If someone were to share information with us, they'd be fearful that we'd discuss it here and possibly mention names. That might be holding them back.
-
That is why I did not name who had the source. One of the main things that concerns me is from the view point of a preservationist. The bulk of the source for the games was pitched into a dumpster after Chainsaw Monday and I want what still survive to be saved in some way that won't disappear with the person that has it.
From the point of what we are trying to do, I have heard that often the interpreter was modified specifically for a given game and that the source for the modified interpreter was stored with the game's source. That would be interesting to see, too.
-
That's interesting about the modified interpreter source. Yeah, I agree with you about the preservation goal. It would be a shame for what exists to disappear.
Who these days "owns" the original source (for games, tools, and interpreter)? You mention that a lot of it disappeared in dumpsters after Chainsaw Monday, so from the perspective of the owners of the games thereafter, the source was probably gone at that point, and obviously no-one worked on it since. So for those bits that ex-employees have held on to, who legally owns that now? And who could make a decision for us regarding "open sourcing" it? Is there anyone who can make that call now? It might be one of the only ways for ex-employees to show what they have, i.e. if something official comes out regarding its legal status. I guess it is unlikely to go the way we'd hope for. But what would the owners take into account when considering this? It's the games themselves that they'd make money from, and the characters and story lines that they'd look to make money from in the future. What would they lose by revealing the source of these (fairly old these days) games? There are already hundreds of walkthroughs all over the net, so no harm in people finding out how to finish the game or anything like that. A reasonable legal department might be open to allowing it to be openly available.
Is there a difference between the owners of the original source of the games/tools/interpreter, and the games themselves? What I'm wondering is whether the current owners of these games (is it still Activision for most of them?) still legally own that source code that presumably they don't actually possess (due to it being thrown out)?
Assuming that nothing official is said, what are our options?
-
I actually used to work with someone who had worked on SQ3 and KQ4 (and probably other titles). I recently bought an old copy of the KQ book, and there was even pictures of him in it. Unfortunately he left the company I worked at, oh, probably 8 years ago (I've also since left), and I don't have any contact info for him (and I can't find him on the internet - no fb or linkedin page or anything).
Lucky him. It was my dream the whole way through my teenage years to one day work for Sierra. I researched all the surrounding area around Coarsegold and Oakhurst and even found the addresses and phone numbers of many of the employees in the phone book listings for that area. Absolutely crazy. I honestly can't remember where I got them from now, but we're talking before the Internet was publicly available, and I was growing up in New Zealand. The only thing I can think of is that there were US phone books on microfiche at the local library and maybe I was looking through those. I kept thinking "How I am going to end up working there when I'm over here in New Zealand?", and so my teenage self was trying to build up as much contact information as I could.
Anyway, game development moved on from the one-man does everything game that attracted me (think AGI and early SCI), and the Sierra we knew disappeared. :( The dream was gone, until the AGI/SCI fan made game scene took off. :)
-
Interesting. So for instance, CodeMasters owns LSL while ActiVision owns basically everything else. What about the source to LSL5? Or the interpreter? Who owns the interpreter? Who owns SCI? Why does CodeMasters own the source to one game while ActiVision owns the source to another? The games are separate from their sources. Take the Quake engine. It's released open source, but the game assets and resources aren't.
-
What's purpose of your investigation? Are you trying to determine what the original syntax might have been for these procedures?
Yeah, that's the main purpose. I guess it doesn't really help us much to know that, but it's nice to know what it might have looked like.
Given the pattern you're seeing in the codeblocks, it's a reasonable assumption that these procedures were defined in a class in the original source code (as opposed to the "procedure blah of fooclass" that Brian used). Basically, they'd be like "private" methods, I guess.
Yeah, I agree. It seems likely that those methods and the procedure would have been defined in the same order in the original source as they appear in the code block. And I guess they were a kind of private method. For the purposes of decompilation, we could probably say that if a procedure appears after a method within a code block then it belongs to the same class as the method. - Unfortunately I don't think we can distinguish between a procedure that is defined at the top of a class and one that appears outside the class but immediately above it. That is unless it references something that links it to the class.
Your version of LSL5 must be a little different than mine. In mine, the procedures are at $1ae and $7c4 (close, but off by a bit). Decompiling script 995 in LSL5, only the $1ae procedure was identified as being "of" the Inv class. $7c4 wasn't because the only class-specific opcode used was "self", which can compile without knowing which class it belongs to (I think I had to do that because there were some procedures in the SCI0 template game that were like that).
The version I have I got off GOG. The game tells me it is version 1.000, date 09/11/91.
-
Interesting. So for instance, CodeMasters owns LSL while ActiVision owns basically everything else. What about the source to LSL5? Or the interpreter? Who owns the interpreter? Who owns SCI? Why does CodeMasters own the source to one game while ActiVision owns the source to another? The games are separate from their sources. Take the Quake engine. It's released open source, but the game assets and resources aren't.
If you Google info about the game rights a bit, there are a lot of interesting stories coming up.
http://www.gamespot.com/articles/leisure-suit-larry-loungin-with-codemasters/1100-6205151/
http://www.spacequest.net/index.php/topic/743-is-there-any-hope-of-the-sierra-brand-being-revived-or-sold/
http://www.telltalegames.com/community/discussion/45230/telltale-s-king-s-quest-license-pulled-by-activision/p6
http://www.telltalegames.com/community/discussion/32367/who-owns-king-s-quest
http://www.fool.com/investing/general/2014/08/18/activision-blizzard-resurrects-sierra-games-and-re.aspx
https://blog.activision.com/community/games-blog/more-games/blog/2015/03/05/kings-quest-preview-gdc-sierra-the-odd-gentlemen
http://www.gameinformer.com/b/features/archive/2015/01/02/ken-williams-interview-kings-quest-sierra-game-informer.aspx
The new King's Quest game is apparently coming out later this year. Sounds like it could be quite interesting.
http://www.sierra.com/kingsquest
I guess this is the problem. Activision has started doing something quite big with the rights. But they're building the new games with the latest tools and for the latest platforms. I doubt they're actually interested in code from the early 90s. Who knows though.
As for CodeMasters, they apparently gave Replay Games a license for Larry (I thought Replay actually had the rights but sounds like its not quite the case) that allowed them to create the recent remake of LSL1. Sounds like there were plans to do others but the whole thing has apparently gone a bit pear shaped from what I've been reading this evening. That's a shame. At one point they were talking about a Larry 4 and Larry 8 but I guess these may not eventuate now.
https://steamcommunity.com/app/231910/discussions/0/613938693292790857/
Not sure if I included it in the links above, but there were suggestions that Gold Rush and Manhunter might be owned by other companies. Obviously not SCI related but still of interest.
-
Yeeeeaaaah that was a mess.
-
would imagine that Activision has the rights to SCI, but the Codemasters owning LSL and at one time The Realm does throw a wrinkle in that. Most probably do not care as it is too dated of technology and if they even looked into it probably found that Havas threw it out. they have to realize that some of the ex-employees had to have some of the material, but it would not be worth pursuing.
Other things that I would love to see are the in house tools they used and the documentation. I came across something where a person was going to start working at Sierra and was given a manual on SCI to study before he began and was describing the similarity to Smalltalk. I think that this might have been from a link that Lance posted a couple of years ago.
Here's an idea for the new Sierra, offer up SCI for free for new game development, much like some of the other game engines have been. It could help generate a new interest in Sierra.
-
Yes, I've long wondered what the official Sierra developer tools looked like...they were obviously in DOS. That would be wonderful on my old 486...
-
SCI 32 tools may have been Win32.
-
Not really interested in SCI32 (besides the prospect of decompiling/recompiling and loading/saving assets in existing games). At that point I'd just use AGS.
-
I would still like to see them.
-
Yeah. It's just less fascinating to me personally than DOS tools...
-
For completeness to have the entire SCI era.
-
Yes, I've long wondered what the official Sierra developer tools looked like...they were obviously in DOS. That would be wonderful on my old 486...
We already know what a few of them looked like, from photos in the Official Book of King's Quest. It shows the View and Picture editors for SCI. I based my design of my original DOS based AGI PICEDIT on the pictures of the Picture editor in that book. I found that book in a local computer store in New Zealand, before I wrote PICEDIT. The AGI picture editor was probably less flashy than the SCI one though but it was something to work towards at the time.
What we don't know is what the various other tools looked like.
-
would imagine that Activision has the rights to SCI, but the Codemasters owning LSL and at one time The Realm does throw a wrinkle in that. Most probably do not care as it is too dated of technology and if they even looked into it probably found that Havas threw it out. they have to realize that some of the ex-employees had to have some of the material, but it would not be worth pursuing.
...and I guess if they did obtain it from somewhere, there isn't much they could do with it. A lot of these games were made with DOS based tools. I doubt they're going to be using DOSBos to build more DOS based SCI0/1 games. Normally a company would be hanging on to source code so that they can make changes to an application. There seems to be no reason to do this for these games. Logically it seems like there should be no reason for them to hold back on allowing the tools, documentation, and source from those times to be publicly available. If they had it themselves, then it's possible that they could have been convinced to release it. But it seems more likely that they don't have it.
Do you think we'd benefit at all by approaching their legal departments to see what their view is?
Other things that I would love to see are the in house tools they used and the documentation. I came across something where a person was going to start working at Sierra and was given a manual on SCI to study before he began and was describing the similarity to Smalltalk. I think that this might have been from a link that Lance posted a couple of years ago.
Yeah, that was Mark Wilden: http://www.mobygames.com/developer/sheet/view/by_year/developerId,2205/
I think it's okay to discuss the things he's publicly mentioned on his site, in forums, and on his blog, given they're all public. Some of those pages seem to have disappeared now, but we can still see it on the Wayback Machine:
http://web.archive.org/web/20101219175024/http://www.mwilden.com/smalltalk/index.htm
http://web.archive.org/web/20110219044800/http://www.rhinocerus.net/forum/lang-smalltalk/190289-games-smalltalk.html
This one is still alive:
http://mwilden.blogspot.co.uk/2009/06/discovering-oop.html
Here's an idea for the new Sierra, offer up SCI for free for new game development, much like some of the other game engines have been. It could help generate a new interest in Sierra.
Yeah, that would be great. It reminds me a bit of what happened with sarien.net. Activision asked Martin to take his JavaScript conversions of the games down from sarien.net, but after negotiating with them, Activision agreed to allow him to put back up the first games in each series. Activision's reasons were that it would encourage more people to buy the later games in each series and Martin had to put links through to places where those games could be bought.
Interestingly though, I notice now that he has most of them back up there. Maybe he got permissions for all of the Activision AGI games. The obvious omissions are LSL1 (which CodeMasters own), Gold Rush and the Manhunter games. Also missing is Mixed Up Mother Goose, Donald Duck's Playground, and KQ4. I'm guessing that he never converted the AGIv3 games, and besides, there's probably good reasons for not hosting those particularly three games. Gold Rush and Manhunter may potentially be owned by other companies (I still need to track that down) and KQ4 obviously has a SCI version that they might want people to purchase. For Mixed Up Mother Goose and Donald Duck's Playground, it might just be a case of those not having been converted. Can you even buy those games now?
-
Collector was working with Sunlight Games on a big re-release of Gold Rush Classic and a Gold Rush Remake last year (for the anniversary?). Sierra/ActiVision definitely doesn't own it. Manhunter is probably a similar deal with whoever made them. I heard rumours of the same developers working on Mahunter 3: London, but I don't think it ever happened.
-
We do know what the SCI0 view editor looked like. http://sciprogramming.com/community/index.php?topic=288.0
Odd that you mention Sunlight as they just emailed me today about a support issue that one of their customers was having. The Manhunter games were developed by and I think are owned by the Murrys of Evryware http://www.evryware.com/ , which is starting to make games again after all of these years. Mixed Up Mother Goose has seen many conversions from AGI to SCI0 to SCI1 to SCI 1.1 MPC to SCI32. Donald Duck's Playground is one of the Disney titles that Sierra lost rights to when Sierra and Disney parted ways. Codemasters got LSL and The Realm (an online variant of SCI), which was sold to yet another company. AT&T or AOL (I forget the order) got TSN/INN (LSCI engine, another online variant of SCI)). So I guess that the properties that Activision does not have are LSL, The Realm, INN, the Disney titles, Gold Rush! and the Manhunters. There may be a couple of others, but I am not thinking of them off hand.
-
We already know what a few of them looked like, from photos in the Official Book of King's Quest. It shows the View and Picture editors for SCI.
There's an image in there with a caption: "Using a keystroke command, the artist removes solid colors to add small details like flowers, bushes and rocks". I still can't see the purpose of removing fills to do that. Anyone?
-
I can't think of a reason why it would make drawing finer details like flowers any easier. But I suppose it might sometimes be useful to distinguish the lines from the fills they contain. I'm struggling to think of such a situation though. Could it have been for performance reasons? Maybe the author of the book misinterpreted why this was being done.
-
Collector was working with Sunlight Games on a big re-release of Gold Rush Classic and a Gold Rush Remake last year (for the anniversary?). Sierra/ActiVision definitely doesn't own it. Manhunter is probably a similar deal with whoever made them. I heard rumours of the same developers working on Mahunter 3: London, but I don't think it ever happened.
I didn't even know that the anniversary version of Gold Rush existed. I have fond memories of playing the original back when it was first released. I still have the box somewhere. I think I might purchase the Android version of the remake this very day!
So I take it that The Software Farm own the rights but Sunlight Games had a license to build this? Something like that?
-
Donald Duck's Playground is one of the Disney titles that Sierra lost rights to when Sierra and Disney parted ways. Codemasters got LSL and The Realm (an online variant of SCI), which was sold to yet another company. AT&T or AOL (I forget the order) got TSN/INN (LSCI engine, another online variant of SCI)). So I guess that the properties that Activision does not have are LSL, The Realm, INN, the Disney titles, Gold Rush! and the Manhunters. There may be a couple of others, but I am not thinking of them off hand.
The Black Cauldron is still on sarien.net. Isn't that a Disney game? The web page footer states that King's Quest, Space Quest, and Police Quest are properties of Activision Blizzard but says nothing regarding The Black Cauldron that I can see. It is also interesting to note that both The Black Cauldron and Donald Duck's Playground are available to download from Al Lowe's web site. He states that as far as he knows, these games are no longer of any interest to any of his friends at Disney or Sierra, and so he says we're free to share them around. I guess these two games were one-offs, i.e. not part of a series, and I suppose therefore less profile these days. The big series games still have a lot of power.
-
Manhunter is probably a similar deal with whoever made them. I heard rumours of the same developers working on Mahunter 3: London, but I don't think it ever happened.
There was a fan that was working on a Manhunter London at one point: http://www.adventuregamestudio.co.uk/forums/index.php?topic=13363.0
Sounds like he had done quite a bit of work towards it, but sadly lost it all with a hard disk crash. I had something similar happen with an AGI remake of Scott Adams' Mission Impossible (Secret Mission) game. I'd written maybe one third of the game in 1999 and I'd even discussed it with Scott Adams over email and he gave me his approval to pursue the project, and sent me the graphics from graphical versions of the game. But unfortunately I lost what I'd written and didn't have a backup. It's quite demoralising to start over, so I never did. - That reminds me that I really must back up all the AGI and SCI folders on my PC.
Some rumours here about the Manhunter creator's maybe working on a new Manhunter game back in 2008 but I can't find any other references to that:
http://www.agdinteractive.com/forum/viewtopic.php?f=19&t=12634
It suggests that they probably still have the rights though, if the rumour was true.
-
Script 947 in SQ5 contains a DialogEditor. Has anyone seen this mentioned anywhere before? It looks like it lets you add buttons and text to a dialog in-game, then saves the source code to a file. I'll see if I can modify a script to try to invoke this dialog.
-
The Black Cauldron is still on sarien.net. Isn't that a Disney game? The web page footer states that King's Quest, Space Quest, and Police Quest are properties of Activision Blizzard but says nothing regarding The Black Cauldron that I can see. It is also interesting to note that both The Black Cauldron and Donald Duck's Playground are available to download from Al Lowe's web site. He states that as far as he knows, these games are no longer of any interest to any of his friends at Disney or Sierra, and so he says we're free to share them around. I guess these two games were one-offs, i.e. not part of a series, and I suppose therefore less profile these days. The big series games still have a lot of power.
Actually, because it was freely offered, that's why I didn't have any worries about making the sci point and click version.
-
I got the dialog editor working. All that is needed is
(DialogEditor:doit())
It was pretty confusing, but I tried adding some controls and stuff, and it generated this file:
; DialogEditor v1.0
; by Brian K. Hughes
(Print
posn: 0 -4,
addTitle: {the title},
font: 0,
mode: teJustCenter,
width: 100,
addText: {text} 69 0,
addButton: 0 {button} 0 4,
init:
)
-
I didn't even know that the anniversary version of Gold Rush existed. I have fond memories of playing the original back when it was first released. I still have the box somewhere. I think I might purchase the Android version of the remake this very day!
So I take it that The Software Farm own the rights but Sunlight Games had a license to build this? Something like that?
Correct. Everything we did had to be sent to the MacNeill brothers for approval. I assume that it was the same for the remake.
Yeah, I was forgetting about The Black Cauldron being one of the Disney titles. The fact that it is on Sarien.net and available for download on Al's site I am sure is more because like most "abandonware" is not because it has fallen into public domain but simply because the IP holder is unaware of, does not care enough or somewhere in between to pursue slapping them a C&D. But remember that we are talking about Disney.
-
New mystery:
In SQ5 (and presumably other SCI1.1 games? But not SCI0 or SCI01), several scripts have public classes.
In SCI0, SCI01, the only public exports allowed from scripts were procedures and instances. But several scripts have classes that are in the script's export table:
main (SQ5), Smopper, genetix, starCon, eureka, kiz, and more..
Anyone know why this might be? It seems kind of pointless.
It does mean that I need to add syntax support for "public" classes (and update any code that might assume that classes can't be public).
-
Maybe to enable unit-tests (which were removed in the final game)?
-
Somehow I doubt they had unit tests :P. Even so, classes are already public. There isn't any need for them to be in the export table.
Another small mystery:
The -info- property for objects in the script resources is 0x0000 if it's an instance, and 0x8000 if it's a class. Additionally a 0x0001 can be OR'd into there at runtime if have an object that is a clone of something.
However, in SQ5 (and KQ6 and LSL6), some classes have 0x8004 for their -info- property in the script resource. In all those games' cases, it's the IconI class and every other class that inherits from it. I looked in the ScummVM code, and it doesn't appear to do anything with the extra 0x0004. And nothing bad appears to happen in game if I change the 0x8004 to 0x8000... so far as I've noticed anyway.
-
Messing around in the debugger, one side-effect of setting it to $8004 appears to be that it disappears from the Objects list. I just tried changing a few objects to $8004 in the debugger and they've all gone from the objects list that shows when you press "o" or "O". Not sure if that is the only side-effect, and also not sure how useful that is. What I have noticed though is that the list you get when you press "O" can quite often (almost always actually) overlap the edges of the screen. So maybe if there were things they didn't want to see in this list, they could set that bit and it wouldn't show up in that list. Maybe they noticed how crowded it was getting and decided they didn't need to show everything in that list.
I've tested changing it in the other direction and the object appears again in the list. I could still inspect the object and could still set its properties while the -info- property was $8004.
-
That's an interesting theory Lance. I'm assuming you're using a SCI0 game to test this, since I don't think there are any SCI1.1 games with the internal debugger left in? I've only seen the 0x8004 in SCI 1.1 games. But of course, during development they still had the internal debugger in SCI 1.1, so that's a possibility. I suppose icons are pretty common.
Of course, them disappearing from the debugger in an SCI0 game might just mean the interpreter doesn't think they are valid objects anymore, and stuff might crash or behave weirdly if code tried to create "new" ones of those or something.
At any rate, I guess it doesn't matter unless it actually has some effect on the game working or not (which I haven't found yet).
-
Of course, them disappearing from the debugger in an SCI0 game might just mean the interpreter doesn't think they are valid objects anymore, and stuff might crash or behave weirdly if code tried to create "new" ones of those or something.
No, Lance is right. This flag only affects the debugger (which is why we don't act on it in ScummVM). IsObject (the kernel function that you are supposed to use to check for valid objects) looks at a value that isn't exposed to the scripts.
-
I don't think there are any SCI1.1 games with the internal debugger left in?
The debug in SCI1.1 games is triggered by "magic files" in the game's base or patch directory. http://sciwiki.sierrahelp.com//index.php?title=SCI_Debug_Modes#SCI_version_.3E_1.001.000_.28SCI1.1.29
-
I don't think there are any SCI1.1 games with the internal debugger left in?
The debug in SCI1.1 games is triggered by "magic files" in the game's base or patch directory.
Not the same thing. What Phil and I are talking about is the debug window. What this page is talking about is debug code left in scripts.
I can't see the page ("Login required"), but if it's the one by HWM, then it even credits me - so I should know :)
-
That's an interesting theory Lance. I'm assuming you're using a SCI0 game to test this, since I don't think there are any SCI1.1 games with the internal debugger left in? I've only seen the 0x8004 in SCI 1.1 games.
Yeah, it was Hero's Quest that I was playing with. So that suggests its been around for a while but its strange that SCI0 scripts didn't make use of it. It seems more useful for a lot of objects to initially be hidden and then to use the debugger to show it, rather than manually going through each object in the debugger and hiding it.
-
Ok, it turns out some SCI0 scripts do use it (LSL3, for instance). Again, for icon-related objects.
-
I'll use this thread to talk about mysterious or confusing things I've come across while decompiling scripts.
A number of scripts have objects with blank names. This is true in SCI0 as well as later versions. The template game's MenuBar and Control classes don't actually have those names in the original sierra code they came from (either LSL2 or LSL3). Instead, their names are empty. Those are the only classes with empty names in those games (I think).
In SQ5, again there is a class in script 255 with an empty name, which I believe corresponds to the Control class. It inherits from Obj.
There are also 3 other empty-name classes in SQ5:
- Script 943 has an empty-name class that has methods like draw/save/restore, and calls kernels like Graph. I don't know what it does.
- Script 948 has two empty-name classes that appear to be related to debugging (a "feature writer").
These last 3 empty-name classes inherit from 0xffff, which means they inherit from nothing, just like the Obj class.
Interestingly,some of these nameless classes refer to properties on themselves that don't actually exist. So there's still some mystery there.
-
Interestingly,some of these nameless classes refer to properties on themselves that don't actually exist. So there's still some mystery there.
I think you may be having a bug in the decompiler. Compare:
(http://www.sprogklog.dk/sci/unnamed-obj.png)
with this from your decompiled source:
(class Class_943_3
(properties
y 0
underBits 0
)
etc.
clearly the same class, but your decompiler does not see the x property.
-
Oh, I see.... SV.exe also shows a missing x property:
subclass <NIL> of Object
{
y = $0
underBits = $0
new()
yourself()
dispose()
draw()
save()
restore()
}
I think both SV.exe and I assume that the first 9 properties are fixed (selectors 0x1000-0x1007, plus 'name'). But of course this guy is missing name. And indeed, looking at the script resource, in the normal name slot is the 'x' selector.
Good catch!
-
I'm encountering a number of scripts that send multiple values to a property selector:
(flo:
view(350)
setLoop(0)
cel(0)
x(271 167) // sending two values to x.
setCycle(End self)
signal(| $0004 (flo:signal))
)
My compiler produces an error here, since it knows that x is only ever used as a property, not a method. But, this occurs in a number of SQ5 scripts (and it's not a decompile error). Not sure what to make of this. It maybe just be the result of a typo in the original Sierra source code that was never noticed? Or maybe it sends the second value to the next selector in the object selector list (in this case y)?
-
I'm encountering a number of scripts that send multiple values to a property selector:
(flo:
view(350)
setLoop(0)
cel(0)
x(271 167) // sending two values to x.
setCycle(End self)
signal(| $0004 (flo:signal))
)
In this particular case, it is obvious from the surrounding code that this should be posn(271 167)... it would be interesting to see what making this change would do to the animation in question (Flo's animation there does seem a little broken imo).
-
Another mystery: In SQ5's findTalker in Main.sc, for the narrator case we have:
(case 99
(if (== gModNum 666)
ScriptID(666 1)
)(else
gSQ5Narrator
)
)
So if we're in room 666, then it uses export 1 from that room, instead of the narrator. There is no room 666 that shipped with the game though...
-
Here's an SCI mystery that nobody ever seems to give thought to, myself included...
Just WHO in the world WAS that guy who created SCI Viewer? He popped up on the Janitorial Times (before the great resurgence), threw this tool at us, made a couple adjustments, completely disappeared, and then returned years later to tell us that the source was lost when inquiring minds were wondering about it before vanishing again. There's no name anywhere. Not in the program or the forum or anything. No way to contact him. His forum name was "sci viewer" or something simple like that. And all this time he hasn't bothered to come forward to contribute anything since, or even let us know why he bothered in the first place, or to take credit and let us thank him for his great efforts. Seriously, in one fell swoop he comes out of nowhere, creates a tool that delves into pretty much EVERY worthwhile Sierra game from AGI and beyond all in a much faster way than anybody else ever did and in a more effective way than any other tool made has, and then disappears off the face of the earth. I take it for granted but it has provided us with so much information and fun. I'm really curious about who this person was.
The original thread on the JT: http://www.spacequest.net/index.php/topic/145-sci-resource-viewer-beta-testers-wanted/?hl=viewer
-
I must say that I'm really impressed with that tool. It seems to be able to load just about any SCI game that is out there. I don't know who created it, but I had thought that that was because I wasn't around at the time that it was released. I had assumed that you all knew who had created it. If it is none of you, then I have no idea.
-
I must say, SCI Viewer has been pretty indispensable for validating that I'm writing out the data correctly, and for all sorts of other tasks.
Maybe it was made by someone who worked at Sierra back in the day! I had assumed that other folks knew who he was...
-
And it's not just SCI games. It seems to be able to load and display all the AGI games as well! Donald Duck's Playground, KQ1, KQ4AGI, Gold Rush, Manhunter 2, etc., the whole range.
It's a one-stop-shop for all your AGI & SCI viewing needs.
-
There is a claim on this page (translated with Google translate) that he prefers to remain anonymous:
http://translate.google.co.uk/translate?hl=en&sl=pt&u=http://www.tolledo.net/artigoV1/1/making-of-da-traducao-do-jogo-kings-quest-vi-em-portugues.html&prev=search
This seems a little strange though. I don't see any problem with a data viewer for a game. There must be more to the mystery than this. He can't have been worried about the backlash that a viewer tool would result in. Think about AGIStudio, WinAGI, SCI Companion and SCI Studio. Those tools have gone far beyond being viewers. Surely SCI Viewer has no reason to fear. Troflip's theory might be closer to the mark, although the comments by the author suggest that he was unfamiliar with aspects of some games and was trying to track down such games to test with. One of his comments says: "As far as I was able to find on the internet, the "Conquest" game uses SCI 1.0.", which seems like a strange comment if it were coming from an ex-Sierra employee.
-
There is a claim on this page (translated with Google translate) that he prefers to remain anonymous:
http://translate.google.co.uk/translate?hl=en&sl=pt&u=http://www.tolledo.net/artigoV1/1/making-of-da-traducao-do-jogo-kings-quest-vi-em-portugues.html&prev=search
Fascinating. This is the only other area of the internet I've even seen him mentioned.
This seems a little strange though. I don't see any problem with a data viewer for a game. There must be more to the mystery than this. He can't have been worried about the backlash that a viewer tool would result in. Think about AGIStudio, WinAGI, SCI Companion and SCI Studio. Those tools have gone far beyond being viewers. Surely SCI Viewer has no reason to fear. Troflip's theory might be closer to the mark, although the comments by the author suggest that he was unfamiliar with aspects of some games and was trying to track down such games to test with. One of his comments says: "As far as I was able to find on the internet, the "Conquest" game uses SCI 1.0.", which seems like a strange comment if it were coming from an ex-Sierra employee.
Strange...but effective to throw everyone off maybe...
-
Well, even a Sierra employee wouldn't be expected to know about ALL the games that were shipped. Admittedly, it's a far-fetched theory.
The SV.exe resources have some dialogs that are marked as Russian (see attached). They aren't in Russian, but they are tagged with that locale. Anyway, that might suggest the guy was Russian (or at least was developing on a Windows machine switched to Russian), though his English seemed pretty good in the forums.
-
That's quite interesting. Its unlikely for that locale to be in there by chance.
It was certainly a significant investment of his own time, so he was obviously a big fan. That adds to the mystery as to why nothing more was heard from him. You'd think he'd be hanging out on this forum.
Why announce it on spacequest.net? Is there anything specific to that site that might provide some clues? Does it simply imply that he was a Space Quest fan?
-
Anyway, that might suggest the guy was Russian (or at least was developing on a Windows machine switched to Russian), though his English seemed pretty good in the forums.
Yeah, the English seems very good, but reading back over his posts, there are some indications that English isn't his first language, e.g.:
"and spend the eternity trying to guess what the problem was."
"Seems to be the one of a kind (and hard to find these days). "
"A few people asked to add a support for Yamaha FB-01"
...and a few other small grammatical slips and unusual turns of phrase like that.
-
At the time, the JT was all but abandoned with all but a few people still checking it out every now and then. I recommended this forum to him more than once (when it was still scicommunity.com, before the 2-year silence period and it returned as sciprogramming.com), but he never acknowledged it. I haven't seen him on any other forums. Perhaps he was avoiding places with a lot of traffic. Given the popularity of his tool, it's possible that's why he went dark.
It makes sense if he's Russian, this wouldn't be the first time there were Sierra resource tools developed from that region. IIRC, there was an entire Russian AGI development software and interpreter written for DOS.
-
He created an account on the Wiki to link to a new version. I did have the opportunity to ask him if he still had the source but he said that he did not. Too bad as I would have liked to update the GUI to add support for a few things like bulk extraction/exporting and a few interface tweaks.
-
My guess: he's a member of a Russian game translation group. These groups often develop their own tools for extraction, modification and embedding of game resources.
-
Not a super big mystery, but most SCI1.1 games contain a Conversation class that appears to let you queue up a bunch of messages to be displayed in sequence. However, the Messager class already has this functionality, so it seems a bit superfluous (except it would allow you to queue up messages that are from different tuples)
In SQ5 and LSL6, at least, it is unused. KQ6 uses it extensively (but again, it looks like the Message class would serve just as well).
Hmm, actually now that I think about it, it would let you split a sequence of messages into multiple parts, and execute code between each (whereas if you used the MEssager functionality, the messages would be displayed in sequence without any chance to intervene).
-
Lance wondered earlier what other internal debug code might exist in the games.
I've found this text in 900.MSG in the demo of Slater & Charlie go Camping:
Making your game. Please wait...
Can't fine one or more of the following files: gamedata.res oldroom.sc.
Can't find oldRoom.sc file.
Can't find game.sh file.
No! I've changed my mind.
Do you really want to quit?
Yes, I want to quit.
I've only had a quick glance, but there doesn't seem to be code that references these strings, so it's hard to tell what they may have been used for.
It does look like something to do with reading or generating SCI code. Does anybody have the full game to check?
-
I got the full game. It also contains 900.MSG and it's identical to the demo.
How can I search for usages of the messages?
Check you PM about the game.
-
This might help (excuse the weird filenames, I had some renaming issues).
There's no script 900, and the number 900 doesn't appear anywhere related to loading a message resource. So upon a cursory glance, it would seem that there isn't any code that loads those messages.