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

I am only familiar with SWBF 1. The mode map (folder) must contain a mapinfo.txt file that has the default settings set for the server manager.

Example from CORUSCANT: JEDI TEMPLE:

CW,CORUSCANT: JEDI TEMPLE CW,Cor1c,CIS,republic,200,200
GCW,CORUSCANT: JEDI TEMPLE GCW,Cor1a,alliance,imperial,200,200

Other things to check:
- Is the mod map in the correct folder (AddOn)?
- Is the mod map not in a nested folder? (something like tat3/tat3/Data/... instead of tat3/Data/...)

Cool, sounds really exciting!

May I ask why you are not bothering to extend/fork swbf-unmunge? From what I have seen, it already supports a lot of formats that are used in the Zero Engine.
Have you already compiled a list of Zero Engine games? I would be interested to see that. 

QuoteDue to some major tomfoolery on Pandemic's part , the script extraction does not fully work yet, but the plan is to convert the extracted lua bytecode to lua 5.1 bytecode so it can be fully decompiled.

Do you want to support Lua 5.1 exclusively, or do you plan to support older versions too?
SWBF 1 uses Lua 4.0 which implements a stack-based VM. I think in Lua 5.0 the switch to a register-based VM was made.

Thanks for the link, very helpful!

Howdy and happy new year, everyone 

I've been modding SWBF for well over 10 years now, admittedly less frequent and with less ambition than other modders on this forum.
In the beginning, I started having conversation with people who already knew how to mod.
There was no tutorial to follow along, and I had to figure out a lot of stuff on my own.
The classic learning by doing experience.
Although there are plenty of tutorials and documentation resources available, it always bugged me that they were spread across multiple different platforms and presented in forms that may not be appealing to beginners.
Some documents even skipped the most interesting parts because they were trivial in the eyes of the writer or just too cumbersome to explain.
Further problems were dead links, incompatible software, .... you name it.
I understand that the community is a bit smaller these days than back in the day, and the demand for a unified resource collection might be close to zero.

However, I am wondering if there has never been made an effort to collect all the information that is out there about SWBF1 and SWBF2 in one place?
I am thinking about something similar to the Blender-MSH-IO reference manual from Sleepkiller or a Wiki page in general.
Having Screenshots, cross-references, TL:DR;, ... really lowers the initial threshold for new people to get started.

I am not really trying to convince anybody of something, but just want to hear your opinions on it.

Quote from: RepComm on August 29, 2023, 09:39:02 AMhttps://github.com/derkalle4/gamespy-masterserver

This might be off topic but is this the actual master server used for swbfspy?
I am a bit surprised that it is running on VB 

Quote from: RepComm on August 29, 2023, 06:40:09 AMIf it's scanning the battlefront process then I think what is handling is an individual dedicated server, correct?

Correct

Quote from: RepComm on August 29, 2023, 06:40:09 AMThere is also a luxury that the current master server implemented is open source, so events could be generated directly in theory

Could somebody pass me a link to the code?
Cheers!

Quote from: RepComm on August 29, 2023, 06:40:09 AMPerhaps something like:
Get events and server lists from master server
Check port XYZ on dedicated server IP
 if responds ask it to forward events as if it's a dedicated server bot

Sounds like a lot of work, but a lot of fun

In the AR-Clan Discord we have a dedicated channel where a discord bot notifies players about our steam server.
People get notified when the map changes (the map name is shown) or a new player joins.
Additionally, we introduced 2 roles that tag people when there are more than 3 or more than 5 people on the server (tags occur only after a certain timeout i.e. 30 minutes).
We have a separate channel for moderators where the names of the players on the server are displayed.
The bot also notifies us if the server crashes.

The bot is written in Python and is publicly available: https://github.com/21stcenturyclan/SWBF-Server-Bot/

One drawback is that this bot is not universally reusable and will work only for one discord server.
Feel free to use/tweak the code, or contact us if you want to create a more generic bot.

---

I am not familiar with how the master server works, but our bot scans the memory of the battlefront executable (given by the PID) in a regular interval (every 3 seconds).
If certain values in the memory change, a new event is created and the bot executes an action (i.e. a channel message).

I try to explain it as easy as I can, maybe someone can help me out to make it even simpler.

When you open the fake console you see a list of functions.
Each of those functions connect to a piece within the game code.
This game code is fixed and can not be altered (trivially).
The fake console is only there to call this function dynamically (you wouldn't want to make every unit jump like a jedi on every mission).
If you want to add a new entry to the fake console, you would need to know the game code and see if the functionality exists there.
This only works by disassembling the game code and taking a stroll through the game files.
At least, that is my understanding.
I might be wrong.

The following comparison might lack a bit but here we go ...
Imagine a soft drink dispenser.
Every type of soft drink represents a functionality of the game code.
The number input thingy of the dispenser is the fake console (the script connection to the game code) where the user selects a number to get a certain soft drink.
You can not add more soft drinks to the dispenser because it is already filled.
Not all soft drinks might be accessible via a the number input, but you could connect the soft drink to the number input.
However, you would need to know the number of the soft drink.

You would either have to study how the number input is connected to the soft drink, or even harder, open the dispenser and add a new type of soft drink.

Behind every script function there is usually a function within the game code.
If your intention is to add a "RemoveWeaponOverheating" function, you would need to connect this script function with a function in the game code that implement this functionality (I doubt that there exists one).
For it to work you would need to have access to the game code or find a way to inject code into the executable.
This is not trivial.

I have only modded for SWBF1 so far, but I assume that it is not that different to SWBF2.
If you want to remove the weapon overheating only for a specific weapon you could modify the respective side (have a look at the modding tutorials).
Let's say you want to remove the overheating of the rebel pistol:
- Find the file "all_weap_inf_pistol.odf" in your custom side directory
- Open it with a text editor of your choice
- Look for the line that contains "HeatPerShot"
- Set its value to 0
- Munge your custom all.lvl side
- Make a backup of your original all.lvl
- Replace your custom all.lvl side with the original

Quote from: Sereja on June 16, 2023, 07:08:51 AMI am fine, thanks!

Well, I actually dont have SWBF installed right now, so may missing something. Also SWBF1 and SWBF2 may using different named files for same purpose. If you modding SWBF2, your file with objects coordinates may have some different name, and could be in a different directories, but it surely stored in some project folders.
msh. files doesnt realy increase much map size, but textures does.
Here the trick I used long time ago: first freeze each wall in your 3D software (I guess this function has most of them), then import your walls and save them in ZE. In your project find odf file with coordinates, open it, find coordinate at least one of the wall, copy it, and paste to all other walls. Close and save. Each wall should be in place like in your 3D software scene.

Now I got it. You mean the *.wld file where the coordinates for each individual object is stored. Thanks again for clarifying.

Note: Copying odf files won't increase the map size, but copying meshes certainly does.