[KQ5CD] Issue when compiling script

[L@Zar0]

Hi,
I need to modify this script, witchRegion.sc (200) of KQ5CD. When I decompile it, I get this (seems correct):



Then I compile it again (without touching it), delete files (witchRegion.sc and witchRegion.sco) in scr folder, and then decompile it again.
This is the result:



As you can see some of the variables are changed, and this results in freezing the game when I reach the Dark Forest part with the witch.
This is the first script I can not compile to use in the game, I've modified other scripts previously and they seem to work well. I could avoid to recompile this script, but first I want to know if there is any method to compile it (I need to change some values of the variables and the first procedure values) and make it work. The rest of the code, procedures and instances seems to be decompiled correctly this second time. So, the issue is only with the variables and procedures (in this case only one procedure).

I'm using SCI Compiler 3.0.1.7 (and checked also 3.1.0.3 and kawa versions without any good results). I have tried also using disassembled version, but as the variables are shown in the same way, the problem persists also.

Well, let me know if you have any idea to bypass this.

Thanks in advance.

[Charles]

I think the variables changing is a red herring.

There's no bounds-checking for arrays in SCI.  In either example, you could replace references to local1 with [local0 1] and it'd work just the same.

Here, the 2nd decompile is just taking the 1st two variables of each 9 variable array and declaring them as individual variables... but that doesn't really change anything.

If the game is breaking when you re-compile, then I would assume despite it looking correct, it's not actually decompiling correctly the first time. Try comparing your decompile with sluicebox's https://github.com/sluicebox/sci-scripts/blob/main/kq5-cd-dos-1.000.052/src/witchRegion.sc or Eric's https://github.com/EricOakford/SCI-Decompilation-Archive/blob/master/kq5cd/src/witchRegion.sc.

I've personally seen incorrect decompiling when there are nested arrays, so it could be that but who knows.

[L@Zar0]

I think the variables changing is a red herring.

There's no bounds-checking for arrays in SCI.  In either example, you could replace references to local1 with [local0 1] and it'd work just the same.

Here, the 2nd decompile is just taking the 1st two variables of each 9 variable array and declaring them as individual variables... but that doesn't really change anything.

If the game is breaking when you re-compile, then I would assume despite it looking correct, it's not actually decompiling correctly the first time. Try comparing your decompile with sluicebox's https://github.com/sluicebox/sci-scripts/blob/main/kq5-cd-dos-1.000.052/src/witchRegion.sc or Eric's https://github.com/EricOakford/SCI-Decompilation-Archive/blob/master/kq5cd/src/witchRegion.sc.

I've personally seen incorrect decompiling when there are nested arrays, so it could be that but who knows.

Thanks for answering. I used the code of sluicebox also, and the issue is the same. I will try to talk with him if I can, but I don't want to bother too much. KQ5CD is a bit of unknown land as far as I can see. I opened recently a bug in the tracker of scumm for this version of the game.

It is a good idea to initalize the array the way you say, but for now, I will use an alternative method and modify the X/Y Position of the portrait in other portion of the code (other script), so I will leave all this untouched. As a result of the tests I have done, the problem here comes when we find a procedure (localproc_0012), but I have other scripts with procedures after arrays and seem to work well. This is very odd.

I have deleted procedure 0012 (so there is not X/Y modification) but the script seems to compile well. BUT, the game freezes anyway. The original  code (in .scr format as patch) works always.

[Charles]

I?m not suggesting you should init the variables that way; I was only giving that as an example that it makes no difference to the compiler.

Can you describe in more detail how the game freezes?

[L@Zar0]

Ok, understood.

The freeze happens just going into room 22 (where the bridge is, in dark forest), it just freezes. No mouse, no movement, no toads, no witch appareance, only digital music. I can do a fast test of this for example using a compiled 200.scr SCI Companion as patch, starting a game, then use the debugger and going to "room 22". If you use the normal 200.scr, it works well, and then appears the witch and shots the fireball to Graham. It even crashes scummvm. I have to click mouse button some times to close scummvm with a crash. This is what the console reports when crashing scummvm:



Maybe there is something more that I'm not aware...

[doomlazer]

Looks like the problem is in the witchRegion zapHim::changeState. The witch's CycleTo command in state 0 never calls self for some reason.

Code: [Select]

(0
(proc255_0 {@ zapHim 0})
(= temp0
(GetAngle (witch x?) (witch y?) (gEgo x?) (gEgo y?))
)
(witch
view: (+ 442 local0)
loop: (cond
((< temp0 135) 0)
((< temp0 225) 2)
(else 1)
)
cel: 0
cycleSpeed: 2
; self is never called
setCycle: CT 1 1 self
)
)

it could be a debugging issue. If I start from outside the witchRegion the zapHim script works fine (in other witchRegion rooms at least, I couldn't reach 22 without TP).

I guess that's not really supported by the fact that it doesn't lock up in rm22 unless 200.src has been compiled by SC.

FYI, I don't get the 'local4 = 1010' when decompiling a second time using the latest SC version 3.2.5.

[lskovlun]

The CanBeHere warnings show coordinates that are quite improbable. So there is definitely either a decompilation or compilation problem.

[L@Zar0]

I would like to use the more advanced 3.2.5 versi?n of SC. But everything I compile break the game. And I dont know why. This script works with 3.2.5 as patch?

About the zap in other rooms you are right. It works well, I tested it. The only place that freezes is here, room 22.

PD: Ok, I answer myself, just tested and I can not make it work with 3.2.5, gives me a "lookupSelector" error. But it really decompiles correctly the code with the modifications in variables and the procedure. That's curious.

[Charles]

Note there is a difference between "decompiles successfully" and "decompiles correctly."

In this case it's not throwing an error when decompiling, so it is decompiling successfully, but it fully appears that the decompiled code is not an accurate representation of the original bytecode, I.e. not decompiling correctly.

[L@Zar0]

I don't want this post will be about who has reason, but we don't know if it decompiles correctly/successfully or compiles correctly/succesfully.

My assumption is that it decompiles correctly but compiles successfully, but with errors or something different. But well, it is only an assumption.

In any case, I have avoid to compile again this script (although if it is possible finally to compile it, would be interesting). And a part of that, I'm a bit worried in case some scripts that I need compiled as patch and they are necessary for my project have some unknown error.

[Charles]

It's not my intention to be assigning blame or calling anybody right or wrong. I'm just trying to make sure we're talking the same thing, to be able to better help you troubleshoot.

The decompiler is not perfect. By definition if it's returning any source code when you decompile, it has decompiled successfully. However, successful =/= correct. I believe it is decompiling successfully, but that the decompiled code is not correct.

Are you able to post your full decompiled source for room 200?  Is room 200 the only code being changed that is causing problems?  Like every other script is the original KQ5CD, but adding in your recompiled 200.scr as a patch file is breaking things?

[doomlazer]

edit: Something is corrupting with the witch. I can't figure out what.

[L@Zar0]

I finally adopted the script of sluicebox, so, you can get it from Github. I tested the original and his and the result is the same.
As I said, in a vanilla game, only compiling 200.scr as a patch and using it, this problem happens. So, there is something different in the resulting compiled code in 200.scr.

As 200.scr is a "Region", that is used inside a room, maybe the compiler "forgets" or it does not do something (like calling an offset) between the region and the own script. But who knows, I have not checked the source code of SC. I think you guys are more experienced than me with that code.

Normally, when I try to change things in a script and I do my own tool, try to compare the result with the original code. If there is any difference, I know where is the issue (more or less). I talk about tools I've done to change bitmaps (for translation) with its own structure. Of course, I can understand a compiler/decompiler is a bit more complex to reach the same result. But well, we can always compare the codes (at least in assembler we should see the differences).

PD:
The witch has also a strange property:



That observeBlocks is unknown for me, apart, the Cage block is only a defined class, without props and with only the init method without code.

PD2: Maybe there is some type of issue with regions. I tried to modify also X/Y pos of portraits of 220.scr (boatRegion), and the compiled file crashes the game also. This happens when get by the roc, got the amulet and hawk saves me. Just when doing the room change, it crashes. (Mmmm... maybe the compiler does not addresses correctly this regions?)

[doomlazer]

Ah, you're right. The cage is the problem. The cage isn't initialized with the left/top/right/bottom properties, so the witch isn't validly inside the bounds. You can test by adding the properties to the witchCage instance.

Code: [Select]

(instance witchCage of Cage
(properties
left 1
top 1
right 320
bottom 180
)
)

The question still remains, if the properties aren't in the decompile (sluicebox's doesn't have them either), why isn't this a problem for the original script code?

[Kawa]

Looking at it in SV on a whim, I see this:

Code: [Select]

instance witchCage of Cage
{
top             = $0
left            = $0
bottom          = $0
right           = $0
property_???    = $0
property_???    = $7a ; 122, 'z', release
property_???    = $c8 ; 200, height
property_???    = $a3 ; 163, clean
}That ain't right.