As far as I can tell, the PS2 texture are not included in the mod tools.
However, I tried my best to edit the original sky texture to mimic the texture in you video (turned down brightness and saturation).
In addition, I used the ambient color settings from PS2.
Make a copy of your original file and replace it with this lvl file (GameData/Data/_LVL_PC/RHN/Rhn2.lvl): https://mega.nz/file/0ClDQa6R#CSiLUosZ1UoFS-XcrXdW-I5PMxLErrOKicNJ8Jr3R64

You could experiment for yourself if you get the mod tools.
Simply import the stock map and ...
- Locate the file: BFBuilder/DataRhn2/Worlds/Rhn2/world1/RhenVar2.sky
- Find the sections called PS2() and PC() and copy the values (or tune it)
- Locate the file: BFBuilder/DataRhn2/Worlds/Rhn2/world1/RhenVar2_sky.tga
- Edit the texture with an image manimulation program (like GIMP) to your preferences

Attached you find a preview.

I am not aware that this asset is shipped separately.

However, it is part of the Bfbuilder tooling:
https://www.swbfgamers.com/index.php?action=downloads;sa=view;down=1219

You find the resources under assets/sides/cis.

Hi,

I recently encountered some issues with shadow volumes:

1.
I duplicated an objects geometry and used it as shadow volume.
Loading the map, the renderer seems to have an issue with Z-layering the object which results in flickering shadows:
You cannot view this attachment.
I kind of solved the problem by shrinking the shadow volume by 1%, but this results in inaccurate shadows.
It is also way harder to solve for donut shaped objects.

2.
To have the terrain throw a shadow I approximated the dimensions of a mountain to cover it completly.
Again, after loading the map, the shadow volume does not show properly.
I tried, covering the mountain and also having the shadow volume enclosed by the mountain with the same result.
The mountain contains more objects with shadow volumes, which might influence the rendering.
I also tried combining the shadow volume of the mountain with the other objects shadow volumes.
However, nothing was successful:
You cannot view this attachment.
Some part of the shadow volume is rendered correctly, but not complete.

Any idea, what causes either of the problems or how I could fix them?

Cheers!

Howdy and a happy new year to everyone (again)!

Over the holidays, I kept busy with another side project and started a Markdown file based documentation for Battlefront 1.

Why?
- Markdown is a human-readable format that can be easily processed by machines as well.
- It is convenient for referencing, linking or keyword searching.
- File-based documentation can be used offline.
- A consistent documentation format makes it easier to find, discover and add more resources.

As there is not much content yet, you are more than welcome to contribute or share ideas for improvement.
I will keep adding summaries of from forum posts and the like to fill it with some life.


---
Side note:
For a few days, I got sidetracked and wrote a Markdown subset parser that represents a Markdown folder/file hierarchy as a node structure.
This node structure can be used to generate any other format.
The currently deployed documentation uses this parser to generate HTML files.
---


You can read more about it here: https://github.com/SWBF2004/SWBFdocumentation
A deployed version of the docs can be found here: https://swbf2004.github.io/SWBFdocumentation/ (sorry, I am no artist)
And here is an image of the docs locally hosted with a working search functionality:


Cheers!

I haven't used custom sounds extensively, but your script seems fine.
One thing you might try is to uncomment the remaining gcw stuff that you replaced with cw files:

...
    OpenAudioStream("sound\\hot.lvl", "hot1gcw");
    OpenAudioStream("sound\\hot.lvl", "hot1gcw");
...
Not sure if this will have an effect.

Another thing that you might want to try is loading your "custom" resources first (before the music)
...
    OpenAudioStream("dc:sound\\hot.lvl", "hot1cw");
    OpenAudioStream("dc:sound\\hot.lvl", "hot1cw");
...


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.