@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,

@Gold_Sear No worries! You need to escape the \ character in .json when it’s enclosed in quotes, otherwise it’s not read correctly! Tweaked your PR slightly here with an example: https://github.com/TheStarport/KnowledgeBase/commit/acfd904b0a79d26cdb5b72824703eca00b645ed1

0 IrateRedKite committed to TheStarport/KnowledgeBase

Update limit-breaking.json

Update: I’ve isolated the cause of this! It seems @Venemon 's patch to fix the multiple HPFire sound bug causes this behaviour! The patch is as follows in Common.dll:

PatchM(0x039F77, 0x83, 0xFA, 0xFF, 0xBA, 0xFF, 0xFF, 0xFF, 0xFF, 0xC3)

Tagging @Aingar and @Laz for interest

@Gold_Sear Apologies, I’ve been away for a week, your PR is now merged in!

I want to do a pass on the tags, I’ll take a look at this and do a cleanup on them.

It’s possible that the build for the page failed which is why it’s out of sync? I’ll take a look at that as well EDIT: Looks like there was some invalid json, which caused the page generation to fail. I’ve updated this and the page should sync again in about 20 minutes time.

I’ve run up against a vanilla bug with weapons that have multiple HPFire hardpoints: They don’t properly decrement ammo as you’d expect!

The ammo goes down properly in the weapons window tracker in the bottom right, for instance a weapon with 2 HpFires will lower its ammo count by 2 every time you fire. However if you check your ship’s actual cargo or if you try to buy ammunition from a dock after, you’ll notice that the ammo only seems to be going down by 1 each time, no matter how many projectiles are being fired simultaneously each time.

Has anyone formulated a fix for this? The behaviour seems to be consistent between MP and SP, suggesting this is something in server.dll not firing quite right. @Laz and @Aingar have already taken a peek at this and unfortunately haven’t managed to get anywhere with it. Hoping that perhaps @adoxa or @BC46 might have some insight here that we’ve missed?

@Gold_Sear Brill! I’ll cross it off the list. As we’re using unix timestamps here, it’s not a problem at all, we just need to adjust what the script that creates the page displays. If we change our mind in the future we can simply adjust the script and display the down-to-the-minute times again

@Gold_Sear Excellent work! I’m going to look at making sure Missions are done tonight.

We’re going to make an update to the page generation script for these. I’ve scoped a little issue to keep track of what needs doing. If there’s anything in addition to what’s in the comment here, please let me know and I’ll do what I can to get it added: https://github.com/TheStarport/KnowledgeBase/issues/39

IrateRedKite created this issue in TheStarport/KnowledgeBase

closed Convert limit breaking to json #8

I’ve powered through and completed the HUD section on the new limit breaking in it’s entirety, may get another chunk done this afternoon. I think I may also do a pass of this thread again and ensure any new offsets are added to the new page if they’re not already present.

Hi folks,

There’s been a bit of confusion about the state of the site recently, particularly with regards to archive, wiki and forge content. We have a pretty long to-do list here, and a lot does somewhat rely on community contributions, as we’re only a small team, so I figured I’d lay out what needs doing that community members can just jump straight in on!

• The Wiki: Efforts to fill out the ini editing section are ongoing! We’re away there’s a ton of missing content, and are accepting PR requests for more. There’s also work ongoing to finish up the new Limit Breaking 101 page.
• The Download Archive: There’s an initiative that’s stalled a bit to document the download archive properly. It came over from Xoops with zero metadata in a very messy state, and we want to ensure that the files have information attached to them going forward, as well as ensuring that things that are not Freelancer-related are removed (There’s a ton of Dungeon Siege content in there, for example). If anyone’s keen to help, head over to the thread and let us know.
• The Forge: We’re aware that a lot of content that was previously hosted on the forge isn’t available at the moment. We’d like to fix this, but accessing the files in the state we’ve got them is a pain. The files are SVN repositories and getting the source out of them is proving difficult. If anyone has any experience with these and wants to help, we’d really appreciate a hand.

@Gold_Sear Thanks for the additions!

Don’t change the format in the JSON payload right now, what we can do is set up a filter that lets you toggle between the 0x format and the one that just lists out the address so we can make sure any leading zeros are added as appropriate on the final page without a bunch of extra work. I think it’s okay to leave your PR as it is though. I don’t think it will mess up any parsing!

@Gold_Sear Fantastic! I’ve crossed it off the list.

@Laz has kindly put together a demo page where the json payload will render (this will eventually move to where the main page is when it’s done) so we can see how things will look when finished.

You can find it here: https://the-starport.com/wiki/fl-binaries/limit-breaking-v2/