You might want to try out the search functionality of this forum 

Here a discussion about custom loading screens: https://www.swbfgamers.com/index.php?topic=13131.msg119776#msg119776

Quote from: Miraak49 on March 19, 2024, 05:12:55 PMthe first time i start my map the voice announcer will not play (when capturing/loosing CP, announcing the hero is on the battlefied) but if i press escape and restart mission then it will work just fine (this is the case for every eras)

Are you using custom sound files?
In that case it would be helpful if you could share your scripts.
I believe that sound files have to be loaded at a certain place before using them.

These "holes" in the ground can occur around terrain cutters.
However, If you used the stock map this shouldn't happen (if you didn't change anything on the terrain).

Terrain cutters are the purple boxes around certain objects.
As the name says they cut the terrain for you to create tunnel entrances or in this case a ditch.
You cannot view this attachment.

If the terrain level is not inside the purple boxes those "hole" effects may appear.
A trick is to cover the object that has the terrain cutter.
One drawback of ZE is that it's not a WYSIWYG Editor, meaning the Rendering ingame might be different (especially terrain levels).

Thank you very much, but to what do I owe the honor?
I am meerly a little heap of junk. 

I would like to thank my dad for buying me a shooter game with an age rating of 16 when I was 12.
Thanks to my mom for letting me play 5on5 matches during dinner time.

But in all seriousness, I will definately stick around and do "stuff" for the game.
Cheers 

Quote from: vonfrank on March 02, 2024, 02:46:20 PMThat 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:

Quote...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:
...
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.
.\luac_64.exe -o full-bytecode.out .\tat3a.lua  <- Will generate a bytecode file "full-bytecode.out"
Then you can decompile it:
.\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

Glad to hear that 
Great that it worked now!

Quote from: vonfrank on March 02, 2024, 11:01:30 AMIs there a way to get it to save to a file? or is that not possible?

I can make it an option.
What would you prefer?
A second argument, or using the input filename as output filename with the ".lua" extension?

lua4dec_32.exe compiled.script                                  ->   compiled.lua
lua4dec_32.exe compiled.script myscript.lua                     ->   myscript.lua
lua4dec_32.exe --input compiled.script --output myscript.lua    ->   myscript.lua

Alternatively, you can copy the text from the command prompt, but I think you knew that already.

Your feedback is really appreciated!
Perhaps I should add some more error messages if something goes wrong.

The only thing that you need to pass to the program is the file (no flags or anything else required):
lua4dec_32_deb.exe tat3a.outThe file ending does also not matter, as long as the content of the file contains valid Lua 4.0 compiled code.

Any anti-virus software is always unhappy about executing unsigned Software.
I try to look for signing tools, but I don't think that there are any free one available that get you around this problem.
In the meantime you have to trust me, that the exe does not contain malicious code.

I am assuming that you extracted the cours1a.script file directly from the unmunge tool?
If so, you still need to remove the metadata from it.
Here is a picture that might help me to get my point across:

The blue part is what you want, the rest you don't care about.

Here is a sample script file from the unmunge tool inspected with a hex editor:
ucfbh...scr_`...
NAME....bes1a...
INFO........BODY
;....Lua@.......    <- This is the part where the actual compiled script starts.
................       So, you need to remove anything in front of ".Lua@".

---

To speed up your progress I could offer to decompile the script for you.

The dependency to the DLLs should now be removed.
You should only require the exe.

While testing, I found out that there is a bug that only occurs in the release build, so the debug build is included as well: https://github.com/styinx/lua4dec/releases/tag/vP.0.1
The difference is the size of the binary and that you get a dump of the byte code.

Damn. These problems only show up outside the development environment. Sorry for the inconvenience.
I will fix it when I come home.

Side note: A double click on the executable will have no effect.
You have to pass it a file to decompile, which only works through a console (cmd, powershell).

Quote from: vonfrank on February 27, 2024, 09:19:02 PMI've been looking for a way to decompile mission.lvl files for really old addon maps in order to increase reinforcement count, unit count, and potentially change specific units altogether. Would your tool allow this?

I'm not too familiar with command-line programs, so I'm not sure if the test release is capable of that already.

The test release contains the tat3a.out sample which is a compiled script file.
To decompile the mission.lvl file you would need SleepKillers unmunge tool first: https://github.com/PrismaticFlower/swbf-unmunge

The level format is structured something like this:
- ucbf header
- file size
- some meta info
- chunk type "script"
  - chunk size
  - some meta info
  - the actual compiled script    <-- this is what you would want
- other chunks type
  - ...
- ...

The unmunge tool extracts the known chunk types into their respective formats (like meshes, textures, ...).
For unknown chunks, it just dumps the binary to a folder with a dummy extension.
Scripts have the ".script" extension and contain the meta information and chunk size besides the compiled script.
If you remove this additional information from the file you can pass it to the "luadec_32_deb.exe" program and it should print you the original script.

A compiled script starts with the following binary signature:
1B 4C 75 61 40    -> .Lua@    (. is a non printable character, @ = 40 which means Lua 4.0)
You can hex edit the file and look out for this sequence of bytes.
Remove everything infront and you are good to go.

If you need assistance feel free to reach out.

Looks like a job for the SWBF 2 guys. Seems like there are bigger differences between SWBF 1 and 2 after all.
I am sorry to have led you in this direction.

You could continue your search in some of the SWBF discords. Maybe there are more active members.

We still don't know, what you actually have put into your AddOn folder.
Maybe you can enlighten us

Have you tried it with a real modmap already?
Maybe try it with CORUSCANT: JEDI TEMPLE?
I assume that you are missing the addme.script file as well.

To answer your questions:
You either need to have the original files, or you have to do some hex editing/reading.
If you only want to inspect a file I suggest HxD: https://mh-nexus.de/de/hxd/
In the base folder of the mod map should be a "addme.script" file that contains the map name and the scripts that are loaded on startup.
Sticking with the Coruscant example:
- The map name should be in the upper half of the file: Look out for "showstr"
- The script names (with the postfixes) should be in the lower half: Should be the last readable words.

Example:
...
pluafile�␅���Cor
1�␈���showstr�␗
���CORUSCANT: JED    <--
I TEMPLE�␇���sid
...
�␗���AddDownload
ableContent�␆���
Cor1c�␆���Cor1a�   <--
��������,���
...


I just created a test release with prebuilt binaries (64-bit Windows 10): https://github.com/styinx/lua4dec/releases/tag/vP.0.0 (includes some test files)

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

Maybe you can post the contents of your mapinfo.txt?
That might help us to narrow down the problem.
It's important to have the right names for the loading scripts (cor1c and cor1a in the sample I gave you).
Usually the postifxes '...c' and '...a' are used, but not always.
I believe that Bespin maps use '...r' and '...a'.

Again, I can speak only for SWBF 1.
The folder structure should have the following layout (Mod1 being the name of the mod map).

Base Folder of the server software:
- AddOn
  - Mod1
    - Data
      - _lvl_pc
        - ...
    - addme.script
    - mapinfo.txt
- Data
- battlefront.exe
- ...


QuoteHey Metalkiller! This is a great project. I doubt I have implemented anywhere near as much as you but if there's anything you can glean from my bad implementation of bytecode parsing, go ahead:
https://github.com/phantom567459/BF1LuaDC/blob/master/LuaDC1/Program.cs

Glad you like it.
I stumbled across your code a couple of times. 
It seems to be the only other project that tries to target Lua 4.0 (besides an unfinished Python implementation).

QuoteI'll take a look in the near future and see if I can get some of the more obscure implementations documented and maybe fork your code instead to go further back in the process. I thought I tried Lua4Dec at one point but maybe I need to try again.  I know my project is a little bit different but tries to target the bytecode more directly for BF1

The trick for me, was to mimic the stack-based behaviour.
But you are right, the documentation/implementation of the interpreter is really something.

Unless you are familiar with CMake and C Code, I would recommend to wait for a first "developer" build.
There are a couple of switches that have to be changed to build the code for 32-bit lua bytecode.
The default build uses the architecture you are on which is most certainly 64-bit.
The tests also run with the 64-bit version.
However, reading through the code should be straight forward.
The important parts are in the parser.cpp file.

I will try to prepare something for usage in the next month and report back in this thread.

Hi,

I have been working on a Lua 4.0 decompiler for some time and I think it's ready enough to be shown.
What was originally planned to be a weekend project turned out to take almost half a year of off/on development.
lua4dec was initiated by my interested in SleepKillers unmunge tool which extracts lua bytecode (among other formats).
This lua bytecode can be fed into lua4dec which converts it back to human-readable lua scripts.

The project is around 90% done.
Some uncommon instructions are not implemented, and 3 or 4 instructions are missing some more attention.
But overall I am pleased with the results.
The decompiler even spawned a little side project that shows the AST of a converted script.
In the long run, I could imagine it being used to modify the bytecode and recompiling it back into the SWBF files.

Here is the link to the project: https://github.com/styinx/lua4dec

I will still continue to work on it and finish it someday.
Maybe you want to test it, leave some feedback, or improve it yourself.

Feel free to reach out.

Cheers