@Bolte with regards to patches like JFLP, the version absolutely matters as memory addresses are different. This could very well be the cause of @Timmy51m’s crashes here.

Curious, I’ll hold off on adding this and see if I can’t replicate the crash on a pure vanilla install and get a faulting module this afternoon. At what point does the crash occur, presumably when attempting to spawn the NPC?

@josbyte I’ll add this to the wiki, but which dll file is the crash occurring in? My guess would be common.dll or freelancer.exe but I don’t have the time to replicate the crash at the moment

@CommanderArgelo said in Dropping a phantomloot cargo from an NPC:

@IrateRedKite Yeah, it’s very tricky. What I found out is that [PhantomLoot] is like a drop for everyone, everywhere, sort of like a Global drop.

Thinking about if, you could restrict the drops by toughness if you’re not dealing with too many NPCs.

On the FLHook stuff, once the plugin is rewritten for the new version, it’ll be available and open for anyone to use and is relatively straightforward to just set up and use. I’d quite like to make a client-side version of this as well, which will hopefully be made more straightforward by the upcoming FLUF project from @Laz, as I kind of want this stuff to work in singleplayer as well.

Lootprops and Phantomloot is a bit tricky, my understanding is [PhantomLoot] entries only kick in during missions.

We had a similar problem crop up working on BMOD and ended up writing an FLHook plugin specifically to handle this. However the merged version for 4.0 is a bit buggy at the moment and this is of course, multiplayer only. It’ll be rewritten and fixed for 5.0, but that might be a little way off.

Hi there, welcome to the Starport! All [ShieldGenerator] entries have their maximum capacity reduced by a percentage that’s defined in the offline_threshold key. By default in vanilla this is 0.15, which would account for your 850 shield value. I think this was probably going to be part of some other feature that got cut and was left in, as there doesn’t seem to be any reason for it in vanilla.

You can set this value to 0 to simply give shields the value they have in the inis ingame.

@JustNdrew HD Edition decodes the INI files so they can be modified, a lot like the 1.3 SDK. For the purposes of modding, they do the same thing, but HD Edition is newer and has some errors fixed.

In terms of tools, that’s all I use + a text editor to edit the INIs by hand. I use VS Code, but Notepad++ is quite popular. As the files are just exposed to modify, there’s no real need for special tools for things like factions and bases

@JustNdrew A modern toolkit (Generally what I’d use at the moment, YMMV), is as follows:

• LancerEdit - For modifying models, working with UTFs, textures, etc
• FL Mod Studio - Mostly for system editing
• FLInfoCardIE - For adding/modifying infocards and text
• Skotty’s ALE Editor - For creating and editing particle effects

For decompressed INIs to work on, 1.3b SDK works, but I prefer Freelancer HD Edition when I’m starting a new project now.

Most older tools do still work and are fine if you can figure them out! ones I’d avoid because they cause problems are Freelancer Explorer and the Milkshape model importer, but mostly everything else is fine to use if it works.

@maximilianps Copilot (and other LLMs) regularly output made-up or wrong information and for a niche topic like Freelancer, that already has a fair bit of poorly checked information out there anyway I’d probably end up having to rewrite whatever it generated. I’m quite happy working on the wiki as and when I find the time at the moment.

I’m generally opposed to using LLMs for anything at all, but that’s a topic for elsewhere and I don’t want to derail this thread!

Hi there, welcome to the Starport!

Guides are pretty time-consuming to write, and there’s few enough in English so as other posters here have mentioned, there’s even fewer in German language. However, there’s a ton of resources about INI editing on the TSP KnowledgeBase that might be helpful, and the Discord/these forums are a great place to ask questions on how to do things as people are usually more than willing to help.

On tools, I would recommend staying away from the 1.3b SDK as it has a few known issues. The current ‘base’ for fresh mods with the INIs exposed tends to be Freelancer HD Edition or the full JFLP patch, which incorporates the old SDK and corrects some of the errors.

As a modern alternative to Freelancer explorer, might I recommend FL Mod Studio ? It has a full 3d editor and works much more reliably. LancerEdit also has a system editor, but my understanding is that it’s currently a work in progress and may be missing critical features.

@josbyte I’ve amended both of these offsets in the wiki. 8381a was actually already present as I had this when we had a file generator write ‘nan’ into the price field, so it’s any sort of invalid value here. Have updated it to make it clear that 0 isn’t an option for prices!

Had a bit of thought about this and I’m not sure there is a way to specifically lock the fov inside a cockpit. Have you tried offsetting the cockpit models forward a bit to try and reveal more of them?

@josbyte Added to the wiki, thanks for the addition

@Venemon Can’t stay away huh? Thanks for the contributions, I’ve added these to the crash offsets page.

The list:

HUD
Miscellaneous
Missions
NPCs
Reputation
Server Operation
Systems
Turret View and Mouse
Visibility
Visual Effects

Having gone over this category list and checking offsets within each page against the json, we seem to be done! I added a few extras from Visibility, and need to comb recent activity in this thread to make sure there’s nothing new I’ve missed, but we’re nearly ready to do a category/accuracy pass and retire the old page I think!

I’m tracking issues with a few offsets here: https://github.com/TheStarport/StarportDocusaurus/issues/12 so if there’s any that need adjustment/investigation and it’s not a straightforward fix, please add to the issue

IrateRedKite created this issue in TheStarport/StarportDocusaurus

open Offsets that need modifying/format adjustments before being added to the Limit Breaking 101 Page #12

@Venemon I think with these adding an adjustment to the post with a disclaimer saying that these crash and recommending the alternative offset might be the way to go, as these addresses are potentially useful for additional reverse engineering!

@Gold_Sear Sorry for the radio silence on this, I’ve been otherwise engaged! I’ve accepted your PR and fixed a few syntax issues with the merge. Hopefully will have some time this evening to make a push and finish off a few more sections.

@Gold_Sear Accepted your PR! I’ll update my list of what’s done. Hoping to get a bit of work done on this today

@adoxa Thanks! I don’t suppose you have this set up running in the other direction too? (UTF -> XML) We’ve got a local script that converts things in the other direction for upload, but I’ve found for quite a few of the folks working on the mod, UTFXML simply won’t run properly when invoked via a script, and I think it’s a similar set of dependency issues.

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,