LSL5 value %s from tex files not getting through in recompiled scripts

[miracle.flame]

There are numerous occasions of %s and %d being used in tex files and we've realized that for example in 15.tex which is easily reproduced by clicking the Sierra icon in main menu there are values missing at the instances of %s like the version number down below in the example screenshot. The curious part is that this does not seem to be a problem of the localized 15.tex itself as it works fine (displays the values) when used as a patch file with original resources. However the recomplied scripts we work with can't display these %s values at least for 15.tex but possibly other places as well. Is there any obvious cause and possibly also a fix for this?

[OmerMor]

The values for the version and date are read from a "version" file (in Main.sc).

Maybe your version file is empty?

[miracle.flame]

There is no instance of "version" in Main.sc as of decompilation result.
There is a Version file containing those strings in game root though.

ANOTHER EDIT:
There's this snippet containing VERSION in sysLogger.sc but I've tried to recompile with originally decompiled version of the code and it did not make difference.

Code: [Select]

code_04cb:
pushi    3
pushi    1
lofsa    {GAME}
push   
pushi    #name
pushi    0
lag      gGame
send     4
push   
call     localproc_000e,  6
pushi    3
pushi    1
lofsa    {VERSION}
push   
lsg      global27
call     localproc_000e,  6
pushi    2
pushi    7
lofsa    {QA-DATE}
push   
call     localproc_000e,  4
pushi    3
pushi    1
lofsa    {ANALYST}
push   
lea      @temp138
push   
call     localproc_000e,  6
pushi    3
pushi    1
lofsa    {SEVERITY}
push   
pushi    11
pushi    952
pushi    10
pushi    81
lofsa    {FATAL}
push   
lofsa    {F}
push   
pushi    81
lofsa    {NON-FATAL}
push   
lofsa    {N}
push   
pushi    81
lofsa    {SUGGESTION}
push   
lofsa    {S}
push   
calle    proc255_0,  22
push   
call     localproc_000e,  6
ldi      1
sat      temp0
ldi      1
sat      temp6

[OmerMor]

I'm talking about this part: https://github.com/historicalsource/leisure-suit-larry-5/blob/341bc91b5529c3243220a7fe77cc6b041c8022d4/SRC/000.SC#L262-L272

Code: [Select]

; set up & read in the version number & version date
(= version         {x.yyy.zzz})
(= versionDate     {mm/dd/yy})
(= versionPhone    {991-999-9999})
(= versionIntPhone {992-999-9999})
(= cfgHandle (FileIO fileOpen {version} fRead))
(FileIO fileFGets version         11 cfgHandle)
(FileIO fileFGets versionDate     20 cfgHandle)
(FileIO fileFGets versionPhone    20 cfgHandle)
(FileIO fileFGets versionIntPhone 20 cfgHandle)
(FileIO fileClose cfgHandle)


[miracle.flame]

OK, this seems to be the leaked original source which is heavily different from the decompiled files and I have almost no idea what to make of this considering all the possible instances where %s and %d are used.

Maybe the most obvious question should have been
If you were to localize LSL5 including scripts how would you go about it in the first place?

[doomlazer]

Are you removing the %s and %d in your translated strings or something? %s is replaced by a string in code and %d by a decimal. %s and %d indicate where in the string the values are replaced.

[OmerMor]

Exactly.

The code just replaces these %s placeholders with version and versoinDate variables.

Here's the original source again: https://github.com/historicalsource/leisure-suit-larry-5/blob/341bc91b5529c3243220a7fe77cc6b041c8022d4/SRC/ABOUT.SC#L116-L139

Code: [Select]

(Format @string
  "Written Exclusively in S.C.I.\n
  \"Sierra's Creative Interpreter\"\n
  \n
  System Programmers\n
  Jeff Stephenson, Robert E. Heitman,\n
  Dan Foy, Larry Scott, John Rettig,\n
  J. Mark Hood, Chris Smith,\n
  Terry McHenry, Eric Hart, Chad Bye,\n
  Mark Wilden, Ken Koch, John Crane,\n
  Steve Coallier, and Randy Moss\n
  \n
  Quality Assurance\n
  Robin Bradley\n
  Joe Perry\n
  \n
  Additional Written Material\n
  Josh Mandel\n
  \n
  Version %s %s
  "
  version
  versionDate
)


[miracle.flame]

%s %d remain intact in all the .tex files we've translated. For example in 15.tex the line with version goes Verze %s %s
There's no "version" and "versionDate" following those in the tex file.

it's just that the recompiled scripts don't seem to have those variables nor values anywhere like they are in the snippet above.
I don't even understand that (= version         {x.yyy.zzz}) part. It's supposed to display 1.000 value in the end.

[doomlazer]

Can you post the format statement you're using to display the message?

The code should be reading a file in the game folder called VERSION. If you open it with a text editor do you see a version number, date and some other stuff?

[miracle.flame]

I may have added some more details to my previous post before you've replied, sorry for that.
There is a Version file containing those strings in game root.
But there are no instances of "version" nor "versionDate" anywhere in the decompiled script files besides the sysLogger mention before.

[miracle.flame]

How or where do I find the format statement to display the message?

this is the 15th script aboutCode.sc

Code: [Select]

;;; Sierra Script 1.0 - (do not remove this comment)
(script# 15)
(include sci.sh)
(use Main)
(use DCIcon)
(use Cycle)
(use Obj)

(public
aboutCode 0
)

(instance aboutCode of Code
(properties)

(method (doit &tmp [temp0 200])
(Load rsVIEW 993)
(proc0_14
15
0
33
global23
30
1
70
222
80
{Sierra p?edstavuje}
)
(cycleIcon loop: 2)
(proc0_14
15
1
33
global23
30
1
82
cycleIcon
70
180
80
{??fov?}
)
(cycleIcon loop: 3)
(proc0_14
15
2
33
global23
30
1
82
cycleIcon
70
200
80
{Pracovn?ci}
)
(cycleIcon loop: 1)
(proc0_14
15
3
33
global23
30
1
82
cycleIcon
70
200
80
{Ho?i ze skupiny}
)
(cycleIcon loop: 0)
(Format @temp0 15 4 global27 global181)
(proc0_14
@temp0
33
global23
30
1
82
cycleIcon
70
222
80
{Hacke?i}
)
(Format @temp0 15 5 global182 global112)
(proc0_14
@temp0
33
global23
30
1
70
222
80
{Placen? reklamn? ozn?men?}
)
(proc0_14
15
6
33
global23
30
1
70
266
80
{Dal?? Laffer?v sm?ch}
)
(proc0_14
15
7
33
global23
30
1
70
234
80
{Ukon?en? produkty}
)
)
)

(instance cycleIcon of DCIcon
(properties
view 993
cycleSpeed 15
)

(method (init)
((= cycler (Fwd new:)) init: self)
)
)


[Kawa]

version and versionString are what the original source calls global27 and global181.

SCI Companion decompilation:

Code: [Select]

(Format @temp0 15 4 global27 global181)
(proc0_14 @temp0 33 global23 30 1 82 cycleIcon 70 222 80 {The Hackers})
Sluicebox's decompilation:

Code: [Select]

(Format @string 15 4 gVersion gVersionDate)
(TPrint @string 33 gSmallFont 30 1 82 cycleIcon 70 222 80 {The Hackers})
Where 15 4 means Text resource 15, entry 4, and that is what contains the %s %s bit.

The original:

Code: [Select]

(Format @string
"Written Exclusively in S.C.I.\n
\"Sierra's Creative Interpreter\"\n
\n
(Cut out a bit here -- Kawa)
\n
Version %s %s
"
version
versionDate
)
(TPrint @string
#font smallFont
#mode teJustCenter
#icon cycleIcon
#width 222
#title {The Hackers}
)
Here, the Sierra SC compiler will take the string from the code and put it in a text resource, replacing it with 15 4 as this is script number 15 and that's the fourth inline string. {} strings are kept as part of the script resource.

A VERY IMPORTANT DETAIL HERE is that @string/@temp0 is only 200 integers long, so only 400 bytes, 400 characters. If the text line you're passing to Format is too long, Nasty Things may happen.

[miracle.flame]

Alright, I have found the culprit in our Main.sc

Code: [Select]

(instance LSL5 of Game
(properties)

(method (init &tmp [temp0 6] temp6 temp7)
(= gStopGroop stopGroop)
StopWalk
Timer
Polygon
PolyPath
LLRoom
IconBar
Inv
(ScriptID 982)
(super init:)
((ScriptID 16 0) init:)
(UnLoad 130 16)
(= gLl5DoVerbCode ll5DoVerbCode)
(= gLl5FtrInit ll5FtrInit)
((= gLl5KDHandler ll5KDHandler) add:)
((= gLl5MDHandler ll5MDHandler) add:)
((= gLl5DirHandler ll5DirHandler) add:)
(= gPseudoMouse PseudoMouse)
((= gLongSong longSong) owner: self flags: 1 init:)
((= gLongSong2 longSong2) owner: self flags: 1 init:)
(= gLl5Timer ll5Timer)
(= gCamcorderTimer camcorderTimer)
(= global27 {x.yyy.zzz})
(= global181 {mm/dd/yy})
(= global182 {991-999-9999})
(= global112 {992-999-9999})
(= temp7 (FileIO 0 {Version} 1))
(FileIO 5 global27 11 temp7)
(FileIO 5 global181 20 temp7)
(FileIO 5 global182 20 temp7)
(FileIO 5 global112 20 temp7)
(FileIO 1 temp7)
((= gIconBar IconBar)
add: icon0 icon1 icon2 icon3 icon4 icon5 icon6 icon7 icon8 icon9
eachElementDo: #init
eachElementDo: #highlightColor 0
curIcon: icon0
useIconItem: icon6
helpIconItem: icon9
disable: 6
disable:
state: 3072
)
That (= temp7 (FileIO 0 {Version} 1)) is where it happened because we've translated (almost) everything in {} brackets. This broke the reference to file name I suppose. This is going to be fun to debug all other %s references.

Thank you guys, I knew your knowledge would point me to the right direction. 

[Kawa]

So you translated a filename without renaming the file. It tried and failed to open the actual, nonexistent file "verze".

What a reveal.

[doomlazer]

I've made worse mistakes.