lua4dec - Lua 4.0 Decompiler

[{AR}MetalKiller]

That being said, I've attempted to re-munge the file output by the decompiler, and it crashes the mission when it attempts to load in-game. I'm not sure if I'm doing something wrong with the re-munge attempt, or if there is an error somewhere in the way it decompiles?

In some of the previous messages in this topic, I wrote the following:

...While building, I re-remembered that SWBF's bytecode does not contain names of local variables, so added a prefix "local" to those. ...

These are the variables that you should see in your decompiled code.
What I missed to mention was, that the initialization of those variables is missing in the decompiled code.
There is a specific reason for that, but explaining it would probably explode the scope of this topic.
In short: There is no reliable way to determine where a local variable is initialized (at least in more complex scripts).

What you have to do by hand (unfortunately) is to add the initialization for the local variables.
These are "local1" and "local2" which stand for "ALL", "IMP" and "ATT", "DEF" respectively:

Code Select Expand

...
ScriptInit = function()
  local local0 = 1                                                    <- This part
  local local1 = 2                                                    <- and this part
  AddMissionObjective(local1, "red", "level.tat3.objectives.1")
  AddMissionObjective(local1, "orange", "level.tat3.objectives.2")
...
You can compare this to the original asset scripts if you want.

---
Skip this part, and go straight to the bottom, if you are not interested.
It only explains what the difference is between "normal" Lua bytecode and "SWBF" Lua bytecode:

I believe the move to remove local variables from the compiled script was done intentionally by the developers to make recompilation harder or obfuscate the functionality of the scripts.

If you compile a Lua script with a standard Lua Compiler, you will get a list of local variables and the position where they are initialized.
I've attached a compiler and the original tat3a.lua script in the latest test release.
Running the following command, you can compile this original script into the bytecode representation.

Code Select Expand

.\luac_64.exe -o full-bytecode.out .\tat3a.lua  <- Will generate a bytecode file "full-bytecode.out"
Then you can decompile it:

Code Select Expand

.\luadec_64.exe full-bytecode.out  <- Will generate a lua script "full-bytecode.out.lua"

If you read through the bytecode (as you casually do ) of both versions, you will notice that the "full" compiled code has a list of defined local variables, while the SWBF compiled script (from the *.lvl file) has none.
This also shows in the decompiled lua script.
Using the full bytecode, the decompiler is able to reconstruct the original script 1 to 1, while using the reduced SWBF version, it can not (local initializations are missing).

Without the information of the variable names, there is no way to reconstruct the full script.
However, the decompiler should generate only valid Lua code.
I will put this on the TODO list. 

---

Here is the latest release that gives you some error messages if something went wrong and creates a new file when you run the decompiler:
https://github.com/styinx/lua4dec/releases/tag/vP.0.2

[Ty294]

Sorry for the bump, but how difficult would this be to convert into LUA5? I was trying to use it to access some LUA scripts for Battlefront 2 Addon maps, but it told me 5 was out of range.

[Dark_Phantom]

BAD_AL has a version in his toolkit that is a little bit easier to handle than working with luac -l
https://github.com/BAD-AL/SWBF2_Xbox_mod_effort/releases/tag/0.52

I have one that works for simple lua 4.0 scripts and works well for BF1 on my Github as well that was mentioned early in the thread.

[Ty294]

The BAD_AL tool did the trick! Thanks much!

[{AR}MetalKiller]

For completeness...
Lua 5 and Lua 4 follow completely different concepts under the hood. Lua 5 is register-based while Lua 4 is stack-based. My library only supports the stack-based approach.

Good thing that you found a solution