Community
SCI Programming => SCI Community How To's & Tutorials => Topic started by: troflip on November 06, 2015, 09:46:38 PM
-
I've spent several days compiling documentation for the SCI 1.1 template game, and I've just finished a first pass at it.
There are a number of classes that weren't immediately obvious what they do. They are:
- Smopper
- PriorityTalker
- VelocityMover
- AnimDialog
- Inset: what does this do? Used in lb2 and sq5). Involved with Rm::setInset
- Tutorial. Waits for player to do a verb on a noun, then displays message. But how exactly is it used?
- RegionPath ... KQ6 RgBasement is an example usage. Seems related to Path.
If anyone wants to quickly look into these, or knows more about them, that would be great to report your findings here! If not, I'll dig into them a little deeper in the next few days.
-
Will do, Captain!
Inset
I've already done some research into Inset, since I figured it'd be good for one of the shots in my game. Unfortunately it didn't work out without crashing at the end so I considered that the main screen was simple enough and just made the inset a different room. Now, what are insets? They can be full-screen images like the babe closeups in Larry 6, or they can be smaller views like the little chest on the beach in King's Quest 6. They allow you to show a separate scene as a "child" of sorts of the room, with its own cast, while leaving the original on pause in the background. If you were to look closely at the beach chest in KQ6, you'd find Alexander's knee is still visible behind the chest image.
I find the beach chest to be one of the simplest examples to study that I know of. It's in rm200 if you want it. (Note: global2 = gRoom)
AnimDialog
A bit of a file misnomer I think, since the important bit is the ChoiceTalker class in that same file. It's used for the dialogue trees in SQ5. I've tried studying it before but it was quite the maze. I personally find QFG3's Teller more interesting.
Tutorial
None of the games I have decompiles for seem to actually use this. A global search returns the same set of results for each game save the GK1 Demo, EcoQuest 2, and Hoyle's Classic Cards. And that last one is a false positive to boot! The rest (LB2, KQ6 (CD only), LSL6, SQ5, SQ6) are all the same results with maybe a temporary local set to gGame:script instead of gGame:script directly. They never seem to actually do anything with this functionality, leaving me with no examples to work from. Reminder: I have more SCI1/11 games than those I just listed, and decompiles for all.
RegionPath
Seems to be related to actors that follow a path through several rooms. I'm currently looking at the tram in LSL6, will update. The torpedo rays in Codename Iceman were easier to work with. What I've found so far is that RegionPath instances must provide their own (method (at param1)) that returns a particular value. Mostly, these are picked from a local array:
//Example from Codename ICEMAN, scubaRg.sc
(local
rayPath1Ats[13] = (
32767 //Start of a path node
57 //Room 57, westDeadEndRm
249 110 //Starting coordinates
340 110 //Exit stage right
32767
56 //Room 56, caveEntranceRm
-20 133 //Enter stage left
150 150
-32768 //End the path
)
)
(instance rayPath1 of RegionPath
(properties
endType 0
theRegion 305
)
(method (at param1)
return rayPath1Ats[param1]
)
)The various endType values would probably be best figured out by experimentation.
But wait, there's smores! A given room entry needs not have only two coordinates -- some of these rays have three!
-
Splitting off into a second post for no good reason...
Smopper
What the hell does that word even mean? Fun fact, the only games I have decompiles for that contain and use Smopper are EcoQuest 1 and Space Quest 5, plus my own not anymore it doesn't haha. And SQ5 doesn't even use it directly, but through a subclass FiddleStopWalker. Simple fact is, as I've demonstrated before, that if you have your view with eight walk loops and a standing loop, a smopper will let you actually use that last loop. All these other games I've looked at? They use StopWalk, which to me makes so much more sense. So the choice is yours; do you put setCycle(Smopper -1) or setCycle(StopWalk -1) in your SetUpEgo? They're basically functionally identical, just go about it differently.
If you'd rather have your standing frames in a different view, just pass that view's number instead of -1.
PriorityTalker
Seems to be unique to SQ5, at least as far as my collection shows. Basically just a Talker with ever so slightly-different DrawCel calls, in that it respects priority. Hence the name.
//Talker::show
DrawCel((send bust:view) (send bust:loop) (send bust:cel) + (send bust:nsLeft) nsLeft + (send bust:nsTop) nsTop -1)
//PriorityTalker::show
DrawCel((send bust:view) (send bust:loop) (send bust:cel) + (send bust:nsLeft) nsLeft + (send bust:nsTop) nsTop priority)
-
Splitting off into a second post for no good reason...
Smopper
What the hell does that word even mean?
I'm guessing it means "Smooth Stopper". It actually looks like it has quite a bit more functionality than StopWalk - in particular, it supports different views for slowing down and starting, in addition to "in motion" and stopped. FiddleStopWalker seems to be sq5-specific, since it contains references to starting and stop views, and also knows whether roger is wearing a red uniform or a blue uniform. By that measure, it should probably be removed from the template game, or at least modified and commented such that that is obvious. I assume it would be useful, but generating all those views is a lot of work, and most people wouldn't do it.
Keeping StopWalk is probably useful though (even though the template game doesn't use it... maybe it should).
-
Keeping StopWalk is probably useful though (even though the template game doesn't use it... maybe it should).
Template Guy is all set up for Smopper/StopWalk, and of like 50 games I have only two use Smopper, so why not?
I think the more interesting, easier to set up, and altogether more often-used fiddler would be the separately-animated head that looks around a bit when you stand in place long enough.
-
Your Template Guy is set up to use StopWalk, but not the more complex features of Smopper - there aren't any starting and stopping views.
-
Your Template Guy is set up to use StopWalk, but not the more complex features of Smopper - there aren't any starting and stopping views.
Exactly my point.
-
Looks like VelocityMover is related to Roger being a fly, so it can probably be removed. Doesn't seem very general purpose.
-
And that's all of the items on the list.
Relatedly, I added a resetCycle() method to my ego as a clearer shorthand for setCycle(StopWalk -1). Great for ending incidental animations, and if I ever want to replace it it's just the one line. Could be nice in general?
-
Could be nice, yeah.
I think I'll leave Tutorial in, since it is actually referenced by some of icon classes (still can't figure out how to use it though).
It would be nice to clean things up by removing a bunch of the rarely used classes from the template game, and have them available as "add ons". But their script numbers need to be listed in DisposeCode to be disposed of properly, so that's not so trivial.
-
I think I'll leave Tutorial in, since it is actually referenced by some of icon classes (still can't figure out how to use it though).
Or you compare the icon classes of SQ5 to those in one of the many other games to safely remove it. I think I will do that myself.
Edit: never mind that's fuckin' asm I'm outta here.
-
Hey Kawa,
if you know git (and I guess you do), why won't you collaborate on cleaning up the template game w/troflip?
The files are here: https://github.com/icefallgames/SCICompanion/tree/master/SCICompanion/Files/TemplateGame/SCI1.1/src (https://github.com/icefallgames/SCICompanion/tree/master/SCICompanion/Files/TemplateGame/SCI1.1/src).
You can just send him pull requests with your edits.
Just sayin' ... :)
-
Git and I don't get along, sorry.
And here's OmerMor making flattering presumptions about me again~
-
I just checked in a big update to the template game. I'm using reStructuredText for documentation, so now the function/class comments in code are in that format, and I have functionality that pulls them out of code and creates the appropriate documentation.
-
The following seem like scripts that could be optional "add ons"
- ChoiceTalker
- Smooper
- Inset
- SmoothLooper
- RegionPath
- Door
- FlickerCycler
- Flags
- Flip
- PriorityTalker
- PAvoider
- PChase
- PFollow
- ROsc
- MCyc
- FeatureEditor
- DialogEditor
- PolygonEdit
- Blk
- Approach
- Track
- DPath
- RelDPath
- DCIcon
- Wander
- Follow
- Chase
- Tutorial
- RegionPath
- Orbit
- Gauge
That would bring the number of scripts in the game by default from 87 to 56, which seems a bit more manageable.
-
No, no. Nothing "optional" about ChoiceTalker and PriorityTalker. Especially not PriorityTalker.
-
Really? Both those are only used in SQ5, so they're not exactly common.
-
They're less than "optional". One of them is (IMHO) a mess to use, and the other is literally a talker with priority instead of -1 in its drawcel calls.
-
Ah, got it. Yeah, I was gonna combine PriorityTalker with Talker, but PriorityTalker does do a *bit* more than Talker, it also needs to manage the priority underbits. Still could do it though.
As for ChoiceTalker, it's not too bad. The usage looks like this:
(myChoiceTalker:normal(FALSE)
curNoun(N_DEVICE)
curVerb(V_TALK)
curCase(0)
)
(send gTestMessager:say(N_DEVICE V_TALK 0 0 0 110))
(switch (myChoiceTalker:whichSelect)
(case 1
// etc...
)
(case 2
// etc...
)
(case 3
// etc...
)
)
What does using QFG's Teller look like?
-
As for ChoiceTalker, it's not too bad. The usage looks like this:
Okay, and how does one set up the choices?What does using QFG's Teller look like?
I forgot :D
-
Okay, and how does one set up the choices?
The first in a sequence of messages is the title, and the remaining increasing sequence numbers are the options. e.g.
3 2 0 1 8 What things do you want to do?
3 2 0 2 8 Eat some food
3 2 0 3 8 Drink something
3 2 0 4 8 Get out of here.
The only weird thing is that you have to set curNoun/curVerb/curCase, and then repeat those numbers in the say call.
-
How about a repository for extra scripts? As long as they were documented or at least had a description of the function of each script they could be added as needed. That way the template could be kept as lean as possible.
-
Well that was kind of the idea. I was thinking of a subfolder under SCI Companion that could contain script files (and people could download more, if people come up with cool scripts). They'd be accessed by some "Add script" functionality in SCI Companion.
But... that's extra work, and I'm trying to ship :P
-
What does InsetWindow do?
-
What does InsetWindow do?
It's like a BorderWindow but in instead of out. You'd think the inventory window'd use it but it doesn't -- it uses ScrollInsetWindow instead.
-
Lol, yeah, you would think it would use it.
It looks like it's like a BorderWindow, but in addition it has an interior border.
-
It looks like it's like a BorderWindow, but in addition it has an interior border.
(http://i.imgur.com/9IspakJ.png)
-
Zip file containing the documentation so far in case anyone's interested. Start at index.html.
-
That's a good documentation. It might be nice in the part about messages to include that you can have director notes in your lines.
"(TO PLAYER, FUNNY/SEXY)Hey! I'll ask the questions around here."
According to ScummVM, these are "anything but a lowercase character or a digit," in parentheses. They may appear at any point in a line, and any extra whitespace after the ) is skipped.
Yeah, that does mean "(WHAT?)" may be mistaken for a stage direction, but "(Say WHAT?)" would not.
-
The things I have left to do are:
- Kernel functions
- All the compiler/language stuff
I'll probably just include and link directly to SCI Studio help for much of that. The compiler and language features are mostly the same. Then I'll just need to document the SCI1.1 kernels.
It would be nice to have the "source" for Brian's html files, if there ever was any. That way I could possibly re-generate the html files and make it look like it fits in SCI Companion's documentation. But all I've been able to find is the .chm file (which I decompiled into html).
-
If it's well-formed, it should be easy enough to process into a nice bare intermediate. And if it was originally generated from source data, it should at least be regular (and thus parseable), if not well-formed.
-
I have them. The are what I put online. http://sierrahelp.com/SCI/SCIStudio3Help/ If it looks like what you need I can put together a zip for you.
-
That just looks like html to me.
-
I realized I had some of the SCI0 kernel functions documented by myself a while back, so I'm using that. The missing once I'm copying manually from Brian's docs. Oooph... the grammar and spelling mistakes are killing me!
-
What I have on line is from what Brian had on his site. I only played around with the formatting and made it a little more CSS compliant. I always assumed that it is what Brian used for compiling his CHM, but modified fro online use.
-
Yeah, ideally there would be something more "core" without all the html formatting. It's probably not *too* hard to just copy paste the raw text for the missing pages (mainly compiler and language features) and give them a little structure. Certainly less work than writing something to scrape that html and come up with something that works in restructuredText (which is the document format I'm using for the documentation).
-
Certainly less work than writing something to scrape that html and come up with something that works in restructuredText (which is the document format I'm using for the documentation).
Have you given pandoc a go? It supports numerous formats...
http://pandoc.org/installing.html (http://pandoc.org/installing.html)
-
My modifications and formatting to the help file are done mostly via CSS. It wouldn't take that much to do a 'site wide' search and replace. The vast majority of that style is for syntax highlighting. You would have to scrap the index and replace the HTML TOC, but most of the pages themselves should not be that involved to make usable.
-
Great idea with pandoc Lars... unfortunately, it did a terrible job :-(. It would be more work to fix up that output up than just grabbing the raw text from a browser window. All Brian's paragraphs are html tables, so it tried to make an actual table and completely messed that up. And it left in some <div> tags, lol. Quite a mess.
Collector, I'm not sure you understand what I'm trying to do. I just want to extract the text and hopefully some document structure. That's really not as trivial as search and replace. I mean, I'm sure it's possible with some regular expressions magic, but it would end up being more work than just doing everything manually.
My hope (I guess) was that Brian had used some "mark down" document format to generate the html files, and those files were still around somewhere. But maybe he didn't, he might have just written them in an html editor like FrontPage or something.
-
I just want to extract the text and hopefully some document structure. That's really not as trivial as search and replace.
<name>CelHigh</name>
<call>number CelHigh(number view, number loop, number cel)</call>
<desc>By specifying a the view, loop and cel as a parameter, it looks up the height of the cel and returns it.</desc>
<samp>var celWidth, celHeight)
= celWidth CelWide(100 1 3) // Looks up the width of loop 1, cel 3 in VIEW.100
= celHeight CelHigh(100 1 3) // Looks up the width of loop
1, cel 3 in VIEW.100</samp>That's what I produced just now with a small C# app that I fed a single page. Making it emit Markdown is trivial.
I mean, I'm sure it's possible with some regular expressions magic, but it would end up being more work than just doing everything manually.
The reason you shouldn't use RegEx on HTML is because HTML isn't a regular language. The reason you could RegEx your way through these docs is that they're reasonably regular.
-
When making CHM files I always just did simple HTML files to compose the content. It has been a while since I did anything with the Studio help file, but now that you mention it I remember that he did use a bunch of tables just for lay out. I did remove a lot of them, but I only had patience to remove the ones that were completely unnecessary. I suspect that you are right about FrontPage. Looking at his old sites his HTML leaves a lot to be desired.
-
At any rate, it wasn't too much trouble to just copy the text from the browser (then all those tables go away) and add the little bit of needed structure. I've completed "porting" over the stuff I need. The only thing I'm not going to do is the SCI0 template game class system.
In doing so, I've found a number of broken or incorrect links in his docs. It looks like he did a lot of that stuff manually, when it could have been automated. Then again, it was 2003, or whatever.
Hopefully my docs will be a little better in that respect, but I'm sure I'll still end up with typos and such :P.
-
Yeah, when I was redoing the online version I gave up on correcting typos and misspellings since all of the SCI and programming stuff made too many things to trip up a spell checker. It would have to be throughly proofread and manually done.
-
Updated docs, if anyone's interested. Includes docs for all the SCI1.1 class system and kernels, and the compiler. I used a new theme, and they look really slick now I think.
-
Looks neat. I like the new logo.
-
Just leave the British/Canadian spellings like "colour" in there. That's proper. :P
Nice work! Very modern and clean.
-
Excellent documentation!
I have a question regarding the template class system:
Do we have to retain the original names, even when they're obscure or abbreviated?
For example, why not rename SRDialog to SaveRestoreDialog? Osc to Oscillator? CT to CycleTo?
And what the meaning of SQEgo? Is it supposed to be Space Quest Ego?
What about SQ5? Why not TemplateGame/CustomGame?
-
Do we have to retain the original names, even when they're obscure or abbreviated?
For example, why not rename SRDialog to SaveRestoreDialog? Osc to Oscillator? CT to CycleTo?
Good call!
And what the meaning of SQEgo? Is it supposed to be Space Quest Ego?
Yes it is, and I've been wondering about that too. It's certainly allowed to be [your game initials here]Ego...What about SQ5? Why not TemplateGame/CustomGame?
...unlike this, because ScummVM is a DummyVM that won't recognize your game if it isn't named right. Doesn't need to be SQ5 though...
-
Excellent documentation!
I have a question regarding the template class system:
Do we have to retain the original names, even when they're obscure or abbreviated?
For example, why not rename SRDialog to SaveRestoreDialog? Osc to Oscillator? CT to CycleTo?
And what the meaning of SQEgo? Is it supposed to be Space Quest Ego?
What about SQ5? Why not TemplateGame/CustomGame?
Regarding SQ5 for the game name, this is required so that it works in ScummVM (otherwise, ScummVM will throw its hands up and say, "I don't recognize this game"). I should probably get ScummVM to add explicit support for recognizing SCI1.1 template games.
SQEgo could probably re-named. Any suggestions? TemplateEgo? I could possibly fold it into Ego too.
As for renaming, I'm leaning towards keeping the original names. I actually had renamed some... like for instance, the SCI1.1 template game still had a class called class255_0. I renamed it to GUIControl, but then I ran into issues with documentation when I needed to refer to "GUIControl for the SCI1.1 template game, or Control for the SCI0 template game", so I figured it was best to keep names similar between SCI0 and SCI1.1 as much as possible (and so I changed it to "Control"). Admittedly, this may have been a unique case, as this was in the kernel documentation which applies to both SCI0 and SCI1.1.
Like, for backwards compatibility, we shouldn't really change the SCI0 names. And I think there is value in keeping SCI0 and SCI1.1 names the same as much as possible (of course, there are some that were different, like Act vs Actor). Then again... a new template is an opportunity to make things a little better, so...
Of note, the next version of the SCI 1.1 template game will change a filename: View.sc becomes Actor.sc. I never did like the View.sc filename, but I did this mainly because the original name Sierra used was Actor.sc (based on the debug opcodes in some SCI2 games).
-
I think readable names trumps documentation backward compatibility. It should also be easy to rename the sci0 template names to the new ones.
What about adding some class diagrams to the documentation?
I made an example for the Ego class hierarchy. I think it turned out too large so it'd probably be best to draw less classes per diagram next time:
(http://yuml.me/dc548ac7)
This is the diagram source in yUML (http://yuml.me/) format:
[Obj||init();doit();dispose();showStr(buffer);showSelf();perform(object ［...］);isKindOf(className);isMemberOf(theClass);respondsTo(selectorName);yourself()]
[Feature|x;y;z;heading;noun;modNum;nsTop;nsLeft;nsBottom;nsRight;sightAngle;actions;onMeCheck;state;approachX;approachY;approachDist;_approachVerbs|init(［initCode］);dispose();initialize(param1);handleEvent(pEvent);doVerb(theVerb);notFacing();facingMe(［theObj］);isNotHidden();onMe(theObj);onMe(x y);approachVerbs(［verbs ...］);setName(theName);setOnMeCheck(omcDISABLE);setOnMeCheck(omcPOLYGON polygon);setOnMeCheck(omcCOLORS ［colors ...］)]
[View|yStep;view;loop;cel;priority;underBits;signal;lsTop;lsLeft;lsBottom;lsRight;brTop;brLeft;brBottom;brRight;scaleSignal;scaleX;scaleY;maxScale|init();dispose();showSelf();isNotHidden();onMe(x y);onMe(obj);posn(theX theY ［theZ］);stopUpd();forceUpd();startUpd();setPri(thePriority);setLoop(theLoop);setCel(theCel);ignoreActors(shouldIgnore);hide();show();delete();addToPic();lastCel();motionCue();checkDetail();setScale(theScale)]
[Prop|cycleSpeed;timer;detailLevel|doit();handleEvent(pEvent);delete();motionCue();checkDetail(param1);setScale(class params);setScale(obj params);setScale(-1 otherObj);setScale(scale);setCycle(theCycler sendParams);setScript(theScript sendParams);cue()]
[Actor|illegalBits;xLast;yLast;xStep;origStep;moveSpeed;blocks;baseSetter;looper;viewer;avoider;code|init(params);doit();posn(theX theY ［theZ］);setLoop(loop);setLoop(loopClass ［params ...］);setLoop(looper ［params ...］);delete();motionCue();checkDetail(param1);setMotion(theMover sendParams);setAvoider(theAvoider sendParams);ignoreHorizon(param1);observeControl(bits);ignoreControl(bits);observeBlocks(block);ignoreBlocks(block);isStopped();isBlocked();inRect(left top right bottom);onControl(［fUsePoint］);distanceTo(obj);cantBeHere();setStep(newX newY ［fDontSetOrigStep］);setDirection(newDirection);setHeading(theHeading cueObj cueValues);setSpeed(newSpeed)]
[Ego|edgeHit|init();doit();handleEvent(pEvent);facingMe();get(invNumber ［...］);put(invNumber ［newOwner］);has(invNumber)]
[Obj]^-[Feature],[Feature]^-[View],[View]^-[Prop],[Prop]^-[Actor],[Actor]^-[Ego]
[Obj]^-[Script]
[Obj]^-[Code],[Code]^-[Scaler]
[Obj]^-[Motion]
[Obj]^-[Cycle]
[Prop]-script >[Script]
[Prop]-cycler >[Cycle]
[Prop]-scaler >[Scaler]
[Actor]-mover >[Motion]
[Motion]-client >[Actor]
-
Ok, let's see what other people think of switching to full names for things. Kawa seemed for it.
As for UML diagrams, if you want to make some that you think are useful, I could add them. Usually my biggest problem with these is that they "rot", although this class hierarchy isn't changing, so that's not really an issue here. I don't particularly find them useful for understanding a system (especially verbose ones that list all the properties and methods), but perhaps others do?
Thinking about it some more, I think perhaps a simple class hierarchy diagram for the commonly used classes could be useful, and like you had in your diagram, their relation to movers, loopers, etc...
Let's here from others... would this be useful?
-
I like the extended class names as much as I don't like folding GIEgo into Ego 8)
That's "Game Initials".
But yeah, diagrams might be good to have. Perhaps only show the class properties that reference other classes, so for example an Egoa View's scaler property connects to the Scaler class (itself connected to Code), but the scaleX, scaleY, and scaleSignal properties are left out. This would show, at a glance, that the scaler property takes a Scaler, while the cycler property takes Cycle... which in turn reveals it could take Fwd, StopWalk...
-
Here's an initial work on a class hierarchy diagram.
Todo:
- Use color, maybe to note the different class "families"
- Prune some esoteric classes to make it cleaner
- Add missing relations
(http://yuml.me/bbd29dda)
-
Would script code not look extra cluttered with all the long class/function names? Doesn't matter to me otherwise.
-
Would script code not look extra cluttered with all the long class/function names? Doesn't matter to me otherwise.
(thing:view(13) loop(1) setCycle(Fwd)) versus (thing:view(13) loop(1) setCycle(Forward))? (class public ElysianFields of Region)? You be the judge.
After all, when do you expect to dig into SaveRestoreDialog?
-
Here's an initial work on a class hierarchy diagram.
So, a diagram that large is quite unwieldy. It's also pretty trivial to generate programmatically (SCI Companion has a dialog that lets you browse the class hierarchy in tree form - that is, the class hierarchy is readily available in code - so it would be trivial to spit out in .dot or some other kind of graph format - sphinx (the doc system I'm using) also has a plugin for generating graphs from text input), but as you said, it needs some "human" pruning.
I don't really want a large diagram like that in the official documentation. I'm trying to think of what is most useful for people. For instance, one option is to choose various core base classes (Feature, Motion, Cycler, Control, etc..) and the provide a class hierarchy diagram just for that on the doc page for that base class (or perhaps have special "features" "movers" "cyclers" pages that show the diagram). I'm not actually sure that the inheritance hierarchy is very useful anyway (who cares that MoveFwd inherits from PolyPath? All that matters is that it's a Motion class). I guess it's mildly interesting to see how Sierra designed things, but... (side rant: The SCI framework is typical of early object-oriented frameworks in that it is somewhat guilty of abusing class inheritance).
I think what's maybe more interesting is how the various classes interact (e.g. Actors need Movers and Cyclers, Rooms can have Scripts). What is a good way to show that?
-
I say yea on the extended class names. It makes it more apparent.
You had that class hierarchy in the old Companion. Gumby and I have already implemented such a feature in developer. You can export it to an XML. Something that unwieldy is probably better handled through something that is controllable like a treeview. Tutorials could use partial diagrams limited to the immediate subject.
-
Ok, well here are my proposals for renames:
Beg Beginning
Blk Block
Collect Collection
CT CycleTo
DPath DirectedPath
Fwd Forward
IconI IconItem
Inv Inventory
InvI InventoryItem
InvItem InventoryItem -> seems like this can be combined with above class.
MCyc ManualCycle
MoveFwd MoveForward
Osc Oscillate
PAvoider PolyAvoider/PathAvoider // Not sure about these....
PChase PolyChase/PathChase
PFollow PolyFollow/PathFollow
RandCycle RandomCycle
RelDPath RelativeDirectedPath
Rev Reverse
Rgn Region
Rm Room
ROsc ReverseOscillate
SL StatusLine
SQEgo GameEgo
SRDialog SaveRestoreDialog
TO TimerObject
-
You know, it just occurred to be that this might cause some issues with ScummVM. There are places where Scumm looks for classes by name to detect certain features. I poked around just a bit, and I already see one piece of code that looks for "Rm". This is making me think that the risk of changing the names might outweigh any benefit.
It's entirely possible it will cause some issues with Sierra's interpreters too. I'm sure most of the names are fine to change, but why risk it? If there is some particularly egregiously confusing name in a commonly used class, then maybe a few one-offs are ok (the Inv, InvI, InvItem, IconI come to mind).
-
Do we really need to worry about ScummVM? Outside of its debugger it does not really give anything over DOSBox. Ignoring it would also avoid its game recognition problem, too. The abbreviations are not very intuitive and could put off new users.
-
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 (http://pastebin.com/B2UEsR2R) in here. Compare and contrast with this (http://pastebin.com/f2swteZG).
-
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=findObjectByName)
https://github.com/scummvm/scummvm/search?q=getDetectionAddr (https://github.com/scummvm/scummvm/search?q=getDetectionAddr)
https://github.com/scummvm/scummvm/search?q=findSelector (https://github.com/scummvm/scummvm/search?q=findSelector)
https://github.com/scummvm/scummvm/search?q=getObjectName (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 (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?
-
ScummVM is pretty crucial for the debugger, as you mentioned Collector.
One more thing:
I found this page http://www.scriptinterpreter.com/classes (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.
-
Meanwhile, I got bored.
(http://i.imgur.com/mtKsU6S.png)
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.
-
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)
-
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.
-
Love that launcher!
-
Love that launcher!
Thank you.
*adds game.ico support, ponders internal downloader*
-
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.
-
This will break editing old games won't it? And we'll have to re-decompile Sierra game scripts? Will it also affect SCI0?
-
I'm not touching SCI0.
I'm not sure what you mean by break editing old games?
-
As in older custom SCI1.1 games with the old naming conventions in the scripts won't compile.
-
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?
-
It's okay to be cautious.
In other news the final product of my boredom is now in the stash.
-
Right, classes. I was thinking kernel functions. Duh.
-
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.
Which I have done a number of those. In fact you might say that it is a forte of mine. I have even done it commercially. This is also integral with my NSIS publisher project if I can ever find time to get back to it.
-
Which I have done a number of those. In fact you might say that it is a forte of mine. I have even done it commercially. This is also integral with my NSIS publisher project if I can ever find time to get back to it.
And if you look in the stash to find and try my launcher, you'll see DOSBox right there on the way. :D
-
I may have found a way to use more descriptive names, but still ensure compatibility. You can use the name property to assign the class's name in the resource. So from the game's point of view, the full name will never be seen.
e.g.
(class Room of Region
(properties
name "Rm"
etc...
)
)
-
That's ingenious! ;)