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

[MusicallyInspired]

Indeed it is a welcome addition!

[troflip]

For those decompiling things... here's an "alpha" build of the "service pack"....

http://scicompanion.com/Downloads/SCICompanionAlpha.zip

It's not really an "alpha", as it should be in pretty good shape and has pretty much all the features that will appear in the "service pack". I haven't done a thorough test pass on it I suppose, but it passed all my regression tests.

Download is a little larger because it includes the .pdb file instead there are crashes I need to debug or something.

Please don't complain about the version string in the about dialog, I don't think I updated it

Too tired right now to list all the changes, but it has most of the bug fixes/features folks have requested in this thread (including find-and-replace that no longer misses stuff earlier in the file!).

Regarding the decompiler, I *know* there are still decompiler issues, but it works quite well for the games I've recently tried decompiling: LSL3, LSL5, QFG1, QFG2, LB1, KQ6.

(LSL2 and KQ4 don't turn out too well since they are an earlier SCI0 format).

Features/bug fixes in this release:
https://github.com/icefallgames/SCICompanion/commits/master
and page back until January sometime

[Collector]

Thanks. Would it be possible to add the Ctl+A keyboard shortcut to the script list box of the decompiler?

[Kawa]

yaaaaas

[Charles]

I've downloaded the new "alpha" version and I think there's a bug with how the Decompiler handles some arrays in .sco files.

You can consistently reproduce it in QFG1-EGA, as follows:

Start with a fresh copy of the game, and decompile as you normally would. (btw, I love the new changes to the decompile dialog; It think it really flows a lot more naturally than before... including the prompting to decompile all if none are selected, and the auto-re-decompiling if any global names change.)

Everything should be fine so far. The .sco file is as expected.  (We're going to be interested in offset 0xB57).

Now Open up Main.sc and change:

Code: [Select]

global190 =  2
global191 =  2
global192 =  3
global193 =  3
global194 =  3
global195 =  4
global196 =  5
global197 =  5
to

Code: [Select]

[global190 8] = [2 2 3 3 3 4 5 5]
(fyi, global190 is spellCost). So now we've converted it to an array. 

Compile Main.sc, and it compiles without error. The .sco file is still as expected. The first position of the array is recorded as [0a 00] [67 6c 6f 62 61 6c 31 39 30 00] (aka the name is 10 bytes in length including the null terminator, and is 'global190'). The subsequent positions are each recorded as [01 00] [00], seven times. i.e. the name is just 1 byte; the null terminator.  I assume this should already be familiar to anybody familiar with the .sco file format.

At this point, everything is working correctly.

Now, to introduce the error, go back to the decompile window, and decompile just Main.sc. The new Main.sc will now show that array as

Code: [Select]

global190 =  2
=  2
_2 =  3
_3 =  3
_4 =  3
_5 =  4
_6 =  5
_7 =  5
and save that likewise into the .sco file.
I assume it is doing that in an effort to not allow duplicate filenames, by appending an '_x' to the end of the null variable. Looks like that's only a problem for global variables, too. I'm not seeing any problems in re-decompiling User.sc, for example.

Edited to say, I don't think this bug is a regression, either. I had the same problem on the current official release.

[troflip]

Thanks for the report. Yeah, I don't handle global var arrays properly in the decompiler - both in how I read from the .sco (apparently), and also no attempt is made to determine what is an array or not (that only works for temp/param/local vars) - so that means you have to do what you are doing, which is go back to the script editor, compile to generate an .sco, then go decompile your re-compiled script again.

I could try to identify global var arrays across script decompiles... but I think maybe a better thing might be to offer support for modifying global vars and public procedure names in the script editor and having these picked up by the decompiler. That is, it would generate the .sco files from your modified script, which could be picked up by the decompiler. Basically, like compiling but without actually generating a script resource.

Let me ask this: What would be your ideal workflow for decompiling? I'm thinking it would be nice to be able to just make modifications in the script editor for variable/parameter/procedure names, then press a button and re-decompile it from the original resources - and it would re-decompile all dependent scripts too, so they would pick up any new public proc names, for instance.

[Charles]

Let me ask this: What would be your ideal workflow for decompiling?

Ideally, I don't think I'd want to have to rely on decompiling to re-align things.  Obviously I'm coming from the perspective of somebody documenting existing games rather than developing one from scratch (at this point), so my workflow may be different from somebody else.  For me, as I'm going through a script (or multiple scripts) I will start commenting things immediately... all in an effort to identify what a procedure is doing or a variable is for. I'll generally do this by picking an undocumented global variable, say global593 for instance, and see it's only referenced in 2 scripts (000 and 32).  I'd already identified 32 as the Mages Maze game, and after a little more digging around, I see that variable is a counter for how many times you've played Mage's Maze. In that process, I may have uncovered other things (and left appropriate comments for them) that will help me to document other items.

I cannot fathom a simple and reliable method of preserving comments across a re-decompile.  Doesn't mean a way's not out there, it just seems far more trouble than it's worth.

I don't think it's necessary for the decompiler to identify array's from scratch, but I definitely want the decompiler to respect array's I've already created and recmpiled / recreated an sco for. 

I wouldn't want to do this for every go-round, but being able to decompile from scratch with an existing set of sco files is something I certainly feel is valuable. That way I can take advantage of the latest improvements in the decompiler (if there are further decompiler improvements... although to be honest, it sounds like you're 99.99% there for as good as can be.) And that's one situation where I wouldn't necessarily mind losing any comments I've made.

Something that would help that workflow from the get go is a simple "auto-commenting" system for global variables when decompiling. There are certain things I manually look for to start documenting a game: What scripts are a global variable used on, if any. That last part helps me determine if it's an old game features that's been pretty much removed from this release, or if it's possibly an array or not.
So, for example this kind of auto-commenting on decompile would be beneficial:

Code: [Select]

global14 ;referenced in 3 scripts: 197, 167, 015
global15 ;unreferenced
global16 ;unreferenced
global17 =  7 ;referenced in 50 scripts ('Find in all files' for more details)
global18 ;referenced in 1 script: 999
gCursorNumber ;referenced in 3 scripts: 999, 998, 000
global20 =  999 ;unreferenced
global21 =  997 ;unreferenced


[gumby]

Found a small bug.  Renaming a script in Companion doesn't rename it on the filesystem, so attempts at opening the script after the rename fails with the message that the script "... could not be opened. Would you like to see the disassembly insead?".

[troflip]

Found a small bug.  Renaming a script in Companion doesn't rename it on the filesystem, so attempts at opening the script after the rename fails with the message that the script "... could not be opened. Would you like to see the disassembly insead?".

I have code that explicitly handles this, so it should work (it works for me).

What's the circumstance? Decompiled game? Which SCI version? etc...
It looks like I don't pop up an error message if the rename failed, so maybe it's a permissions issue with the folder?

[gumby]

Brand new game, SCI 1.1. Tried running it under local admin, didn't make a difference (Run as administrator).  Seems to fail consistently for me.  My OS is Win 10 if that makes any difference.  Created multiple new games, different locations (under 'My Documents' for example), same result.

The 'About SCICompanion' reports that I've got version 3.0.1.6.  Is this the most recent build?

[troflip]

No, that's old. Use the download link I posted just above:
http://scicompanion.com/Downloads/SCICompanionAlpha.zip

[gumby]

Using that download fixed the issue I was experiencing, thank you.

[Charles]

I think I've found a bug in the new decompiler. This is from QFG1-EGA, Main.sc, Proc0_27.

Here's output from the new alpha decompiler:

Code: [Select]

(procedure (AskQuit)
(= isQuitGame (Print {How about a slice of quiche?}))
)

And here's code from the previous public release decompiler (with my defined constants and comments):

Code: [Select]

(procedure (AskQuit)
    (= isQuitGame
        (Print
            0 64                            ; Text 0, Line 64: "How about a slice of quiche?"
            PRINT_CAPTION {Giving up, huh?} ; PRINT_CAPTION = 80, 1 parameter: label
            PRINT_BUTTON {Quit} 1           ; PRINT_BUTTON = 81, 2 parameters: label, value
            PRINT_BUTTON {Don't Quit} 0     ; PRINT_BUTTON = 81, 2 parameters: label, value
            PRINT_VIEW 800 1 4              ; PRINT_VIEW = 82, 3 parameters: view, loop, cell (or 1 param: object)
        )
    )
)


[Kawa]

Oops, heheh

[troflip]

I think I've found a bug in the new decompiler. This is from QFG1-EGA, Main.sc, Proc0_27.

Here's output from the new alpha decompiler:

Can you list the repro steps you took? Like, does this only happen after renaming certain things?

When I decompile, I get:

Code: [Select]

(procedure (proc0_27)
(= global4
(proc255_0
0
66
80
{Giving up, huh?}
81
{Quit}
1
81
{Don't Quit}
0
82
800
1
4
)
)
)

Clearly I have a different version of the game, since I have 66 as the text resource, not 64. What's your game's version? Mine is 1.000.

[edit:] ok, it looks like it happens after renaming to Print, since I special case this and substitute the text resource in the code... and that functionality is broken. Don't know if it's a regression though...

(So the workaround would be to rename your Print procedure to PrintTemp or something, then do a global rename at the end)


[edit again:] It's supposed to look like this, if it were working:

Code: [Select]

(procedure (proc0_27)
(= global4
(Print
"How about a slice of quiche?"
#title
{Giving up, huh?}
#button
{Quit}
1
#button
{Don't Quit}
0
#icon
800
1
4
)
)
)