Programming & Tools

Tested the player list, it does work.

Many thanks!

I can only come up with some wild guesses at this point.
Since the UI is working in game the renderer seems to be active and running normally, therefore I would assume this is not the error source.
Paths look good, therefore also not the error.
Leaving the textures as potential error source. At this point I would suggest checking if the exported textures were correctly exported as ATI2/ATI1.
You can do this by simply loading a random mat file from FL into UTF. Go to a MIPS node and import one of your textures into it (no need to save the file). The right info window should display the DDS type now. IF it does not show ATI1 or ATI2 there then the export did not work correctly.

Also keep in mind that if the texture node in UTF is called eg. “mytexture.tga” (this very often is the case) then the exported file has to be named “mytexture.tga.dds”. Do not drop the .tga anywhere in the export progress.

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.