SCI mysteries

[troflip]

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).

[OmerMor]

Maybe to enable unit-tests (which were removed in the final game)?

[troflip]

Somehow I doubt they had unit tests . 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.

[lance.ewing]

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.

[troflip]

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).

[lskovlun]

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.

[Collector]

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

[lskovlun]

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 

[lance.ewing]

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.

[troflip]

Ok, it turns out some SCI0 scripts do use it (LSL3, for instance). Again, for icon-related objects.

[troflip]

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. 

[lskovlun]

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:

with this from your decompiled source:

Code: [Select]

(class Class_943_3
    (properties
        y 0
        underBits 0
    )
etc.
clearly the same class, but your decompiler does not see the x property.

[troflip]

Oh, I see.... SV.exe also shows a missing x property:

Code: [Select]

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!

[troflip]

I'm encountering a number of scripts that send multiple values to a property selector:

Code: [Select]

               (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)?

[lskovlun]

I'm encountering a number of scripts that send multiple values to a property selector:

Code: [Select]

               (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).