Programming & Tools

\Freelancer\FLARDATA\Textures
should be the folder structure

inside you have the PBR texture folders e.g. NormalMaps
Creating normal maps would be the starting point, Metalness and Roughness maps later on if you need them. HeightMaps would be a special case that you wont need that often actually.
Create the DDS files and put them into the folders using the original texture names that you can find via UTF. If you work based on original tga textures don’t forget to flip the texture before storing them as dds.
Normalmaps need to be stored as ATI2 and all others as ATI1 dds. Overwrite textures can be dxt1-5.
You dont need to manually edit the material file (but you can). You can use the ingame dev menu to set roughness and metalness values. These values get stored inside the material config file.
I personally edit the material config manually once I know the settings. This way I can group textures which have similar settings and keep everything lightweight that way.

Sweet thanks a ton! ill give them a try!

It would be possible, but do not know when I would find time for it. For now I suggest you use Adoxa’s UTF to XML converter for it. It gives all the ALEs as XML files. There you can actually use Notepad++. And then convert them back to ALEs.

I’ll add it to the list…

The eventual fix for this, courtesy of @BC46 and @Aingar turned out to be a bit more complicated. Posting it here for visibility:

struct SrvGun { void* vtable; CELauncher* launcher; }; DWORD server; UINT projectilesPerFire; typedef bool (__fastcall HandlePlayerLauncherFire)(SrvGun *srvGun, PVOID _edx, Vector *vector); bool __fastcall HandlePlayerLauncherFire_Hook(SrvGun *srvGun, PVOID _edx, Vector *vector) { projectilesPerFire = srvGun->launcher->GetProjectilesPerFire(); return ((HandlePlayerLauncherFire*) (server + 0xD840))(srvGun, _edx, vector); } __declspec(naked) void SetProjectilesPerFire() { __asm { push 0x3F800000 push [projectilesPerFire] mov eax, [server] add eax, 0xD91A jmp eax } } server = (DWORD) GetModuleHandleA("server.dll"); Hook(server + 0xD9A9, (DWORD) HandlePlayerLauncherFire_Hook, 5); Hook(server + 0xDC09, (DWORD) HandlePlayerLauncherFire_Hook, 5); Hook(server + 0xE009, (DWORD) HandlePlayerLauncherFire_Hook, 5); Hook(server + 0xD913, (DWORD) SetProjectilesPerFire, 5, true);

This also fixes some serverside issues with ammo counts saving incorrectly on client reconnect,

I appreciate the offer, if we’re up against the wall I’ll reach out.

Yep, had the user who had the issue pop up very consistently confirm that 1.03 dll fixes the issue. Much appreciated.

I wanted to give you guys a quick update after my last post. I still am working on the renderer and have fixed many bugs (mostly visible rendering issues) since the public beta release. Also there has been a lot of optimization work and I am currently working on some more optimizations for the shadow calculation/rendering. After that the list of remaining bugs is very small (and are minor ones). It should be out of beta once the last ones are fixed. Then I hopefully can start working on releasing the tools so that everyone can use it.

One recent change is the improvement of the light scattering. Now it knows where the suns are and only is enabled for them (before that it only used the first light source (not sun!) in the system). Also you now can have up to 8 suns with light scattering in one scene (the maximum limit actually is currently arbitrary set from me). You can reduce the maximum number in the settings window of the renderer (e.g. if you have a slower graphics card).
If no sun is visible light scattering is disabled now (before it was always on when in an asteroid field or nebula).

Example screenshot of 3 suns with light scattering:

One bug that has given me trouble for a very long time is some weird memory behaviour. After some time the renderer just could not reserve any more memory resulting in missing textures and crash of Freelancer shortly after. On some PCs this even was after 15 minutes when switching between many systems (I finally was able to reproduce it after switching nonstop systems for about 45 minutes on my PC). For the technically inclined: Address Sanitizer using VS2022 (https://learn.microsoft.com/de-de/cpp/sanitizers/asan?view=msvc-170 and Visual Leak Detector using VS2017) do not find anything. Also lets just say I usually know how to avoid and also find memory leaks.

My current (also not so good solution) is to enable the Large Adress Aware flag for the Freelancer.exe. After I have had the registry setting “MEM_TOP_DOWN” on for some weeks I can at least confirm that Freelancer has no problem with the flag (while the registry setting funnily broke some windows 7 control panel applications, meaning they are not large address aware). For now that solved it for our players (unless you play for lots of hours).

I suspect memory fragmentaion going on here, but that remains to be seen. I will come back to this later and it also might have disappeared by then due to my optimization work and code cleanup process.

I was planning for some time now to post some sort of FAQ thread where I explain what the renderer can do and what you need to do to convert your mod, but (as always) I did not have the time to do that, yet.