Community
SCI Programming => SCI Development Tools => Topic started by: ZvikaZ on April 21, 2020, 12:00:16 PM
-
Hi.
I've seen that `global91` is used to display Torin Passage's messages. It's all over the game.
However, I can't find its definition in SCICompanion - both in the original version, and in Kawa's fork (is http://helmet.kafuka.org/sci/SCICompanion.exe correct?).
All I found is in Main.sc,
(local
...
global91
But where is the actual code?
-
global91 is just the default name for global variable #91, to be replaced by the decompiler whenever it finds that a reference to some sort of object or class is assigned to it. In most other games, that means for example global1 is renamed gGame, because the Game object assigns itself to global #1 and the decompiler notices this. And indeed, global #91 is/ the Messager in the games I checked.
What I'd like to know is how you're opening Torin's Passage in SCI Companion.
-
I will check that later, thanks.
Anyway, I'm opening it with @OmerMor's suggestion at
https://github.com/icefallgames/SCICompanion/issues/10
BTW,
Maybe you'd incorporate this into your fork?
-
Yup, that's what I've been doing all along as well. So much that I didn't understand Kawa's question at first.
Linux lets me make symlinks so I don't have to disturb the original game.
-
A'ight. Guess I'll try it myself, see why it doesn't assign a name to global91.
So what I can find here is in FRButton.sc, proc64002_14: ((= global91 (ScriptID -1504 1))
saveMessages: 1
oTextSaver: (ScriptID -1532 0)
init:
)That does not seem right. That's an unsigned word, not signed. That's supposed to be 64032, oMessager. I'm willing to bet this is what trips it up.
I might look into fixing this, but for now at least you know to look for oMessager, in script 64032.
-
Kawa, I'm amazed every time from your SCI proficiency.
Thanks for your help!
BTW,
What's the link for your updated SCICompanion fork Windows executable?
And is there a place to write feature requests and suggestions?
Or is this forum the best place?
We have two requests in this thread ;-)
- https://github.com/icefallgames/SCICompanion/issues/10
- Fix the (un)signed int bug
Thanks again
-
The issues page is probably best, though I'm more likely to notice if you open 'em on my fork's: https://github.com/Kawa-oneechan/SCICompanion/issues
-
I bring tidings!
I found out why script zero in Phantasmagoria was auto-named ScaryRoom.sc instead of Main.sc. That was my bad, messing up the logic (https://github.com/Kawa-oneechan/SCICompanion/commit/66c0cd9539b822ab8e5dd76c786a302734f342bb) when I added a disabled feature.
I also added a massager (not messager) to force ScriptID calls to not negate (https://github.com/Kawa-oneechan/SCICompanion/commit/2f9d0d9ea73dd76a70cd79b51ed053634f91a9b6) on values above 32767. In other words, (ScriptID 64032 0) will no longer decompile as (ScriptID -1532 0).
The bad news is that the above fix would not do anything for the thing that set this off, that Phantasmagoria doesn't have the decompiler name global91 anything like gOMessager or whatever. That's specifically because it uses a ScriptID call there. For comparison, if it was an object in the same script, like scaryMessager, it would (and does) decompile as (= gScaryMessager scaryMessager). Also compare with the line (= global27 {x.yyy.zzz}). The decompiler can't tell that's gVersion. But at least ScriptID calls above 32767 make more sense now.
http://helmet.kafuka.org/sci/SCICompanion.exe (http://helmet.kafuka.org/sci/SCICompanion.exe)
-
Thanks for the quick fix.
Regarding the global91 identification - I have two suggestions:
- Maybe it's possible to follow those 'ScriptID' calls, and learn from them what's going on?
- Maybe it's possible to use OmerMor's SYSTEM.SH (https://github.com/OmerMor/SCI32/blob/master/SYSTEM/SYSTEM.SH) as reference, and use it as an educated guess, whenever we don't have any better source of information from the code itself?
In this file we can see our both examples:
version 27 = 0 ;pointer to 'incver' version string
; WARNING! Must be set in room 0
; (usually to {x.yyy } or {x.yyy.zzz})
...
messager 91 ;pointer to messager (normally Messager)
-
Or maybe you can just assume global 91 is gMessager, change it yourself and redecompile.
Edit: more tidings! I cleared the SCO files for Phantasmagoria to take that screenshot and doing a fresh redeco proved me wrong! It does in fact realize that global 91 is an instance of ScaryMessager!
-
What are you doing to open the later games? Companion can't find any of the resources. Looking for only a RESOURCE.MAP file seems to be hardwired. If I rename the RESMAP.001 in Phant to RESOURCE.MAP it loads a bunch of empty resources. I am also curious as to how Companion handles the HEP files.
-
My copy of Phantasmagoria only had a RESMAP.000 to rename. Or copy, as I chose to do. And HEP files... should be handled just like any other loose resource, as long as they're in a place SCI Companion cares about.
-
What, no RESSCI.000? You need to rename that too (to RESOURCE.000).
-
That's what it did have for me to rename, yeah.
I mean, obviously I had some sort of resource data to decompile...
-
What, no RESSCI.000? You need to rename that too (to RESOURCE.000).
OK. I did not rename the actual resource volume as without knowing about the workings of the map file I assumed that it would be looking for RESSCI.000. Even though Companion was not intended for these later games, this is one change that would be nice to have; to allow Companion accept the different naming conventions.
-
And I couldn't figure out how to add that, I'm afraid.
-
Perhaps if Phil sees this he might be able to point you in the right direction.
-
And I couldn't figure out how to add that, I'm afraid.
Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.
-
And I couldn't figure out how to add that, I'm afraid.
Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.
That could explain why, after making changes to the SQ6 demo to make my SCI32 template, Companion would later erroneously detect the resource.map format as SCI1, rather than SCI2. I'd have to manually change this to the correct SCI2 every time I wanted to make changes.
-
Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.
Hi Lars,
I have found this piece of documentation for MAKEVOLS which might help:
MAKEVOLS.EXE
Version 5.00
Purpose:
Combines a game's resources into one composite volume. In addition to the resource volume, a map file of offsets and a map file of resource date/times are generated. The offsets map file is used by the game for locating resources within the volume. The date/times map file is only needed when re-running MAKEVOLS in Update mode.
So probably we should not worry about RESMDT.
-
So probably we should not worry about RESMDT.
Ah thanks, it's interesting that they ship it then. But it's a small file, so including it doesn't hurt I guess.
-
What, no RESSCI.000? You need to rename that too (to RESOURCE.000).
OK. I did not rename the actual resource volume as without knowing about the workings of the map file I assumed that it would be looking for RESSCI.000. Even though Companion was not intended for these later games, this is one change that would be nice to have; to allow Companion accept the different naming conventions.
Yeah, being able to accept other naming conventions would be a good idea. There's also the Macintosh SCI1.1 and SCI32 games, which use yet another naming convention - the resource files are labeled "Data1", "Data2", etc. From what I can tell by looking at them in ResEdit, they store all of the resources in their resource fork, and they have no data fork.
While neither Companion nor SCI Resource Viewer can open these resource files, ScummVM can, so it can play those games.
-
Opening a game in SCI Companion is complicated enough as it is. I'm not gonna try again.
-
There's also the Macintosh SCI1.1 and SCI32 games, which use yet another naming convention - the resource files are labeled "Data1", "Data2", etc. From what I can tell by looking at them in ResEdit, they store all of the resources in their resource fork, and they have no data fork.
A number of Macintosh games have a Mac-specific icon bar system. Full support for them would be nontrivial.
-
A number of Macintosh games have a Mac-specific icon bar system. Full support for them would be nontrivial.
Oh, right, I overlooked that. They also use the Mac OS save/restore dialog instead of the SCI one. I don't think ScummVM uses those anyway.
The only reason I liked the idea was so I could extract the resources from the Mac version of QFG1VGA and compare them to the DOS version. That's because I plan to make a patch that, among other things, includes the Mac version's bug fixes.
-
Does ScummVM's diskdump * debugger command not work on Mac games?
-
You'd likely have endianness problems if you managed to get the data into Companion. At a cursory glance, it seems diskdump would fail to save the Mac icon bar resources because they don't have a corresponding file extension on the PC side.
I was asked to look into that Pharkas Mac easter egg years ago. I think someone sent the disassembly to me (Omer?) and I did the decompilation manually. The disassembly probably came from SV (and had endianness problems as I recall).
EDIT: Thread here: http://sciprogramming.com/community/index.php?topic=1584.msg10916#msg10916
-
Well, true on the icon bar resources thing but if it's bugfixes you want...