Author Topic: SCI Companion V3 - alpha build notes/bugs/feature requests  (Read 393391 times)

0 Members and 2 Guests are viewing this topic.

Offline Charles

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #750 on: June 30, 2016, 07:19:42 AM »
Tying procedure names to this text matching functionality could be a bit problematic because each function might have that tuple located elsewhere in its signature.

I don't think I've ever seen a case of that... seems like it's always the first two parameters.

I agree that non-matching signatures would be an edge case at best. In the limited examples I've seen in QFG1, all the tuples are located at the start, so they can all take advantage of passing &rest to the Print statement. It is variable whether the tuple is one parameter or two, so it kinda has to appear first in the Print statement (and thus any Print wrappers). Unless there's a specific counter-example?

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #751 on: June 30, 2016, 08:18:09 AM »
It matches by procedure name, so as long as you find out the name of the local procedure by decompiling first (the given name just involves it's offset in that script resource), then you could add it to the decompiler.ini and re-decompile.
That's what I thought. Thanks.

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #752 on: June 30, 2016, 04:28:58 PM »
I agree that non-matching signatures would be an edge case at best. In the limited examples I've seen in QFG1, all the tuples are located at the start, so they can all take advantage of passing &rest to the Print statement. It is variable whether the tuple is one parameter or two, so it kinda has to appear first in the Print statement (and thus any Print wrappers). Unless there's a specific counter-example?

Here's a counter-example:
Quest for Glory 2, script 25, rm250::handleEvent, right at the end of the method, it calls proc2_28, which was originally named SayThanks:
Code: [Select]
((Said 'thank') (SayThanks keapon 250 12))
Here's the original SayThanks procedure:
Code: [Select]
(procedure (SayThanks)        ; Pass a "You're welcome" string
   (if (<= (++ roomThanks) 2)    ; Not more than twice per room visit
      (SkillUsed HONOR 10)
      (SkillUsed COMM 5)
   )
   (Say &rest)
)

And here's the Say procedure from script 23 (proc23_0):
Code: [Select]
(procedure (Say  whom)     ; Kludge to keep args as far strings
   (whom  messages: &rest)
)

Adding the SayThanks procedure to the decompiler.ini file does not work.

BTW, to further complicate things, the Say procedure is accepting multiple tuples, for example:
Code: [Select]
(Say keapon 250 6 250 7)
Here's another problem:
I tried to add the keapon::showText method and its base Talker::showText to the decompiler.ini file, but it didn't work as well.
It is also used in the same rm250::handleEvent method. Here's a snippet:
Code: [Select]
(keapon showText: 54)

Offline troflip

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #753 on: June 30, 2016, 04:35:36 PM »
Here's another problem:
I tried to add the keapon::showText method and its base Talker::showText to the decompiler.ini file, but it didn't work as well.

It only works for procedures at the moment.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline troflip

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #754 on: June 30, 2016, 04:51:27 PM »
btw, have we seen any indication of how the compiler managed this?

There is a tool that extracts quoted strings into a text file, which was then presumably processed in to a text resource. Ok, so that gets them into the text resource.

But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #755 on: June 30, 2016, 04:55:50 PM »
But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.
You can see an example of {} versus "" in CHARSAVE.SC which Omer posted a few days ago.

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #756 on: June 30, 2016, 06:24:09 PM »
btw, have we seen any indication of how the compiler managed this?

There is a tool that extracts quoted strings into a text file, which was then presumably processed in to a text resource. Ok, so that gets them into the text resource.

But then how did the compiler handle turning the text strings into tuples? I don't recall seeing anything that differentiated {} strings from "" strings, or that performed that functionality. And it was certainly never mentioned in any of the docs we have.

Here's what I was able to gather:

A special SCI file with a .TC extension was used. It contained named arrays of text messages. Each file was assigned a unique script #.
The TC files were compiled using the TC.EXE tool (text compiler?).
This tool generated header *.TH files, and the TEXT.* resources.
The generated TH file defined 3 symbols for each array:
  • ArrayName.FILE: The file #
  • ArrayName.FIRST: The index of the first text message
  • ArrayName.LAST: The index of the last text message

Here's an example from MSG254.TC in QfG2:
Code: [Select]
; msg254.tc -- Text messages for QG2 Keapon Laffin (compile with tc)

;Note:
;    compile using "tc filename"
;    filename must end in .TC
;    include filename.TH in your .SC file
;    Names have max length of 9 characters
;    do not use parens or quotes in comments
;    does not support includes or defines
;    must have quotes around sentence

(script# 254) ; msgKeapon


(KeaponHi
"Buon giorno!__Good and tag!__Buenas Dias, Senor Caws.__I haven't seen
   you in so long."
"Hello!__Bone Jar!__Hi, guy!__Set a spell, take your shoes off!__What
may I do to you?"
  "Konnichiwa!__Come and tell me who!__Hola!__How now, brown cow?"
)

(KeaponHi2
  "Top o' the morning to ya!__Mar Haba!__What's New, Pussycat?"
  "Hail, fellow, well met!__What da ya know, Joe?"
  "Ahoy, Goy!__Howdy, Duty.__What's up, Doc?"
)

The resulting MSG254.TH looked like this:
Code: [Select]
(define KeaponHi.FILE 254)
(define KeaponHi.FIRST 0)
(define KeaponHi.LAST 2)

(define KeaponHi2.FILE 254)
(define KeaponHi2.FIRST 3)
(define KeaponHi2.LAST 5)

The TH file was included by the dependent script, for example in RM250.SC we have:
Code: [Select]
(include msg254.th)
The included definitions allowed the SC script to refer to the text resource.
The Talker class used a msgFile property to construct the text tuple. It was assigned for example in the keapon Talker instance, like that:
Code: [Select]
(instance keapon of Talker
   (properties
      ; ...
      msgFile     KeaponGNR.FILE
      ; ...
   )

KeaponGNR is one of the text arrays in MSG254.TC. All of them had a FILE symbol with value of 254, so any of them could be used to initialize the msgFile property.

The keapon::showText method was called with the text index like this:
Code: [Select]
(keapon showText: KeaponSpells.FIRST)
The keapon::showText method called the base Talker::showText with the text index. Talker::showText used the msgFile property to build the complete text tuple:
Code: [Select]
   (method (showText what)
      (self messages: msgFile what)
   )

Offline troflip

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #757 on: June 30, 2016, 06:49:25 PM »
Hmmm... that sounds like kind of a convoluted process. There are still raw "" text strings in the source code though. It doesn't *only* use defines created by those tools. (don't have QFG2 handy at the moment to see if maybe raw strings didn't make their way into text resources).

What you're describing sounds more like the precursor to message resources (indeed, it looks like QFG2 EGA is classified as SCI1, not SCI0 - and uses concepts like Talkers). I'm not convinced compiling SCI0 worked this way.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #758 on: June 30, 2016, 07:03:09 PM »
Hmmm... that sounds like kind of a convoluted process. There are still raw "" text strings in the source code though. It doesn't *only* use defines created by those tools. (don't have QFG2 handy at the moment to see if maybe raw strings didn't make their way into text resources).

What you're describing sounds more like the precursor to message resources (indeed, it looks like QFG2 EGA is classified as SCI1, not SCI0 - and uses concepts like Talkers). I'm not convinced compiling SCI0 worked this way.
The CHARSAVE.SC file I referred to is not from QfG2, but QfG1... and yes, 'convoluted' is the word I would use for this as well. I have seen other (*cough*) code that uses the TC program to generate text resources, but uses simple calls (Print, GetFarText, Format, etc.) with explicit numbers to refer to the strings.

EDIT: The QfG2 talker system is indeed a precursor to the more modern ones, but it is special as well; it has to support Said strings, for example, and quite some engineering effort was spent on this.
« Last Edit: June 30, 2016, 07:05:24 PM by lskovlun »

Offline troflip

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #759 on: June 30, 2016, 08:36:39 PM »
But in the QFG1 charsave script, the original that Omer provided had some double-quoted strings (and no including of .th header files). In the compiled script resources, those end up being string tuples, and those strings are in the text resources.

So clearly there was some mechanism other than this TC.exe thing that was used.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #760 on: June 30, 2016, 08:44:41 PM »
But in the QFG1 charsave script, the original that Omer provided had some double-quoted strings (and no including of .th header files). In the compiled script resources, those end up being string tuples, and those strings are in the text resources.

So clearly there was some mechanism other than this TC.exe thing that was used.
That's not what I meant. The QfG1 script does not use TC (that I can tell), but does use {} and "". The former strings are stored in the script resource, the latter are automatically put in the text resource. The two approaches are mutually exclusive (you can't use TC if you have a script with the same number, or at least you'd have to be very careful). Also, the weird convention with _ for space is demonstrated (several spaces are folded to one by the compiler, if you really want several spaces you need to use the underscore). This makes it easier to have an string that spans several lines of source, in that you don't have to terminate it because newlines and spaces just get folded as needed.

Offline troflip

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #761 on: June 30, 2016, 09:20:14 PM »
Ok, just a mis-communication. Yes, I know about {} and "", and the underscores. SCI Companion has all that same logic too.

I was just wondering about the process Sierra used to extract the "" strings and stick them in the text resource. Because I've tried the sierra compiler (SC.exe that Omer provided), and I'm pretty sure it didn't do that. Maybe I was using a later version of SC.exe, and that functionality was removed because most stuff moved to message resources?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #762 on: July 01, 2016, 03:02:47 AM »
I was just wondering about the process Sierra used to extract the "" strings and stick them in the text resource. Because I've tried the sierra compiler (SC.exe that Omer provided), and I'm pretty sure it didn't do that. Maybe I was using a later version of SC.exe, and that functionality was removed because most stuff moved to message resources?

Sierra used the SCI message extractor tool (XMESSAGE.EXE) to extract double-quoted text strings into text resources.
They used a batch file to go over all the script files, and generated the text files using that tool.

For example:
Code: [Select]
xmessage c:\ll3\400.sc > F:400.txt

Offline lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #763 on: July 01, 2016, 11:29:28 AM »
xmessage (in conjunction with rmessage) is intended for translation, it is not the main tool for text resource generation (that is, in fact, the compiler; I've checked). What xmessage does, if you look closely, is it generates pairs of original strings and empty strings. You then edit the file, replacing the empty strings with translations and run rmessage, which updates the .SC file with the translated strings.
Finally, the compiler can be run to generate text resources.

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #764 on: July 01, 2016, 11:58:19 AM »
Thanks Lars! I trust your knowledge in SCI much more than mine!  :D


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.064 seconds with 23 queries.