LB2 Floppy questions are a burden to others

[doomlazer]

I'm having trouble with the floppy version of Laura Bow 2. If I try to decompile v1.000 all the properties are replaced with "sel_". If I recompile, it produces thousands of errors.

Alternately, if I try compiling using sluciebox's sci-scripts the property names are correct, but SCICompanion doesn't recognize any of them.

In the attached pic you can see SCICompanion's decompile issue on the right, and the sci-scripts compile attempt on the left.

I've never seen a problem like this with any other game, so if anyone knows what's up or can point me in a direction to investigate further, please let me know.

Tangentially, I was pleasantly surprised to see a Patrick McGoohan quote used as a pat response for the Question Icon in LB2. Pretty funny.

[Collector]

What was number 6's quote that was used?

[doomlazer]

What was number 6's quote that was used?

The quote in the pic below is from episode 1 and the opening credits of The Prisoner. According to a quick search, it's believed to have originated from Patrick himself.

Edit: I guess they don't say it in the intro, but it's in the show somewhere.

[Kawa]

The system classes like Cursor are already "known" by SCI Companion to use the broken sel_ selectors, on some level. I just woke up so I'm not sure what that level is. This is all from the top of my head anyway so get your salt ready.

Anyway, when you try to recompile Main.sc, the compiler will check System.sco (or Obj.sco because auto-naming is funny) for dependencies so it knows what a Cursor is, right? And as far as it knows, a Cursor has these broken selector names because there's something wrong with your vocab files. But then in Sluice's Main.sc it tries to set these properties by their proper names, and that's mistaken as trying to define all-new properties.

I'd say to try recompiling from the inside out, starting with System (or Obj, again), maybe.

All I know for sure is that it works on my copy of Dagger 1.000, but its vocab 997 stops working right after #702 pushButton. It's all "bad selector" after. Which means view, loop, et al are still valid, so...

[doomlazer]

Great, that gives me a lot to look into. I always forget about those extra vocab files. Thank you.

[lskovlun]

Missing vocab files are a problem in several demos. Not many games, fortunately. The Crazy Nick's collections come to mind.

[Kawa]

The selector names vocab's right there though. It's just... *quick sickening throat noise* know what I mean?

[doomlazer]

Vocab 997 seems to be missing entirely in the v1.000 I just tested. I've got a few other copies labeled v1.000 to check, but this looks promising as importing the CD version's 997 removes a lot of the errors, but still chokes somewhere around "view".

As another digression, there is a cracked LB2 Floppy floating around which changes a single byte to always pass the Copy Protection.

This is the change to 18.scr:

Edit: this corresponds to offset 0x22746 in RESOURCE.000, only the values are 0x00 and 0x58 there

Which looks like this disassembled:


and this decompiled:

Edit: sel_145 is actually "cue:" and I'm not sure how I missed that "cracke" typo.

It's very similar to the single byte crack for LB1. It would be interesting to know when these cracks were developed and what tools were available to the cracker, but that's probably lost to time.

Another interesting method is used by Collector's modern LB2 installer. In 230.scr, it removes condition 18 from the prevRoom switch during room init, never triggering the sCopyProBack script. This is another single byte crack, but very different in how it bypasses the protection:


I'd argue the first method is slightly better as it preserves an illusion of solving the CP, even if any selection will pass. The 230.scr patch doesn't acknowledge the results either way when returning from room 18.

Personally, I think the LB2 copy protection is really cool and it's lame Sierra removed it for the CD version. The manual is interesting and you actually learn something useful from memorizing the solutions, unlike their mugshot counterparts in PQ2.

[doomlazer]

Rube's voice actor recorded the three unused lines and they exist in the audio resource, so it was possible fully patch the copy protection back into LB2CD. Not that anyone besides me wants this, but the Patch is attached below.

Edit: There are actually three copy protection checks. I forgot Acts 3 & 5, which also have the needed voice lines. I've restored everything and updated the attachment below.

Edit 2: Might as well add my LB2CD patch to enable the "Both" (text & speech) option for DOSBox users.

[Kawa]

Just for fun I extracted the 997.voc from my copy of LB2 and round-tripped it through my Voc997 tool (produced a text file, then turned that back into a voc). Put the result in the LB2 folder and did a clean recompile.

I don't know how much help this could be but here's the file I guess?

[doomlazer]

Thank you. After importing your 997.voc and decompiling, things look a lot better. However, there are still some issues to iron out. I see DoVerb methods are now StopUpd, but the majority of names seem correct.

Is your Voc997 tool released publicly? I don't see it in your SCI stash. Before I saw your post I kind of gave up, thinking it would be a nightmare trying to correct the values in a hex editor, but with the tool it might not be that bad.

[Kawa]

It's on my github: https://github.com/Kawa-oneechan/SCITools

As the readme says, you can drop any .voc file (though only 997's format is supported) onto the exe to get a .txt version of it, and vice-versa. If you just run the application directly it'll figure out which between 997.voc and 997.txt is the most recent and convert it to the other. So you can just take the text version and switch DoVerb and StopUpd around that way.

[doomlazer]

Well, the 997voc tool works great, but after further investigation I don't think 997 is the real issue with LB2 Floppy v1.000. There are several other problems that I can't seem to make sense of.

For example in rm270 SCICompanion generates this:

Code: [Select]

(local
gNarratorSel_1
gNarratorSel_0
gNarratorSel_537
local3 =  1
local4 =  1
local5 =  1
        ...

Those first three seem to be a combination of a global and selectors. So something is confusing the decompiler I guess.

Another issue is visible in rm720, which has two --UNKNOWN-PROP-NAME-- errors. Those are normally fairly easy to correct, but if I compare the code with a decompile from the CD version there shouldn't even be a property there! Removing it allows the script to compile, but seems to generate even more errors when "compiling all" afterward.

There are other quirks not really worth mentioning because I'm giving up on the floppy version altogether. I'm spinning my wheels looking at it.

[lskovlun]

Code: [Select]

gNarratorSel_1
gNarratorSel_0
gNarratorSel_537


This is because SCI Companion will try to name a variable if it can see that you are setting it to a property coming from some object. That heuristic can turn out more or less useful, depending on the circumstances. Here we see the combination of that issue along with the lack of proper selector names.

[doomlazer]

Yeah, the local names seemed to be more of an annoyance than anything.

I do want to correct my previous post though. It's not the --UNKNOWN-PROP-NAME-- problem that reveals additional errors after fixing, it's a different oddity in script 924 Messenger::dispose.

Sci-Scripts decompiles it as:

Code: [Select]

(method (dispose &tmp temp0)
(if oldIconBarState
(oldIconBarState
eachElementDo: #caller 0
eachElementDo: #dispose 1
dispose:
)
(= oldIconBarState 0)
)
(gTheIconBar state: oldIconBarState)
(= oldIconBarState 0)
Notice oldIconBarState appears five times.

But SCICompanion decompiles:

Code: [Select]

(method (sel_111 &tmp theSel_143)
(if sel_290
(sel_290
sel_119: 143 0
sel_119: 111 1
sel_111:
)
(= sel_290 0)
)
(gIconBar sel_29: sel_294)
(= sel_294 0)

In SC's decompile, oldIconBarState is sel_290 the first three appearances and sel_294 the final two times.

I first tested this with the 997.voc I modified, but SCICompanion will complain if both sel_290 and sel_294 have the same name. When I renamed sel_294 oldIconBarState2, new errors appeared in other scripts for some reason; as if they were previously suppressed by the duplicate name error, but that doesn't really make much sense.

Are all five supposed to be the same selector or not? Looking at the LB2CD code, it seems they should be separate, but I'm still hesitant to claim Slice's code is wrong; especially considering I don't understand why the floppy version is so troublesome. Supposedly there is only one floppy version (v1.000), but then why did Kawa's include a 997.voc when all the copies I've come across are missing it?

Finally, why doesn't SCICompanion think setMotion is a property or method on type "View"? If I right-click and go to definition, SC can't open the script containing the View class, but it's there of course.

The only reason I was going down this path was to port the debugger from the CD version, but oh well. Time to move on.