As far as ‘easy fixes’ are concerned, You’ve found pretty much all there is.

For Disco, I’ve hooked onto explosion damage code and rewrote it from scratch, using HitRays to decide the distance from the target instead of vanilla’s center of mass distance. This fixes the issue entirely, but the code isn’t exactly Plug&Play, nor have I made it work in SP setting.

https://github.com/Aingar/FLHook/blob/master/Plugins/Public/munitioncntl/DamageHandler.cpp#L409

Tested the player list, it does work.

Many thanks!

It does in fact serve a purpose, albeit a minor one. The final hit can eat into that offline threshold, and if so, causes your shield to reboot at a lower level.

In your example, if your shield would normally regen at 50%, meaning that it recharged 425 energy points, and was instead hit by a blast for full 1000 damage, it would recharge those 425 shield points, 150 of which would be ‘wasted’ on recharging the offline threshold. This would result in your shield coming back online at 425 - 150 = 275 shield points

Hello dear Adoxa,

I’ve been poking around with Wheel Scroll and noticed that in case of equipment dealer lists, scrolling over the text field/table to which the scroll bar is attached interacts with the scroll bar. However, chat history and player lists only react to wheel scrolling when you hover over the scroll bar directly, making it slightly unwieldy.

I found out that scrolling over those 2 fields also triggers the sub_53F330, same as all your other hooks in that plugin, and I’ve noted down the addresses they’re called from, as well as values for the Window struct used in the plugin.

If it wasn’t too much trouble, could you please include them in Wheel Scroll? Much appreciated!

MP Chat History : 0x5CFB0C name: ChatControl, type: ChatControl
MP Player List: 0x5E5294 name: NNChatButton, type: ButtonControl

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

Very odd design decision, and sadly doesn’t allow us to freely customize the range on per-model basis, but at least now we know. Much appreciated!

Hello and sorry for bothering you again.

We’re dealing with the issue of our clienthook DLLs tripping up Windows Defender as well as various antiviruses. None of our test-build DLLs were ‘accepted’ by all playtesters, and as the release of the next patch is drawing close, we’re running out of ideas on how to remedy the situation, especially since several major features are bound to clienthook code.

Stuff we already tried (in various configurations):

• Blocking the memory hacking unless common.dll is loaded
• Enabling various optimizations to try and scramble the code enough to not trigger any virus signatures
• Disabling all optimizations
• Moving to a modern compiler (visual studio 2022)
• Moving to the oldest compiler we could find (Visual Studio 2008 Express Edition)
• Adding an .rc file containing various metadata, similar to what you’re doing with your DLLs

We have never had such issues with DLLs compiled by you, so if at all possible, I’d appreciate any suggestions/wisdom you might regarding the matter.

I am aware, however the question I have is: What determines the range being used? For example, both Freeport 5 and Leon Base in Omega-41 both show up at the aforementioned 14k range, whereas most(all?) stations in New York, such as West Point Academy, show up regardless of range. As far as ini and solararchs are concerned, both are regular stations, which means that it isn’t always the 14k, and it can be affected, to an extent at least.

We have a use case in Discovery Mod that relies on limiting detection range of a specific subset of solar archetypes to a much lower amount, along the lines of 3k, but regardless of what we try, they show up at 10k. We are looking for the actual source of this detection threshold.

Hey Adoxa, I’d very much appreciate some assistance in figuring out what defines the distance at which stations and other solars show up on the ‘Solar’ tab of the scanner list.

For testing purposes I’ve used a system containing nothing but one station, which was showing up on scanners from 13.9k distance. (regardless of range of scanner I was equipping)

Initially I have attempted to find the answer in CEScanner::Update, and subsequently in ScanList::add_in_range, but didn’t end up with anything useful. I have then changed my approach and checked Freelancer.exe, using an offset found in your plugin, ShipFilter, which led me to sub_4D0490, a method called when rendering the actual contact list.

While having the scanner set to the ‘Solar’ tab, I have ran through the code with the station in range and out of range, and the divergent point was the call at Freelancer.exe+0xD1754, which leads to sub_63315B0 in common.dll. The same method is being called from within ScanList::add_in_range.

The distance check is done in the area of code beginning in Common.dll 0x63316AA, the position offset being held in the vector ranging from ESP+0x10 to ESP+0x18, from which a squared distance is calculated, which is then checked against what can only be called a ‘detection distance’, which is a sum of ESI+0xC and EBX+0xC, operation done in common.dll, 0x63316AA.

When the method is called from within ScanList::add_in_range, ESI offset value is unknown to me, but constant across both callouts, which is relatively small 115.53596
The EBX offset value is the equipped-scanner range when called from ScanList::add_in_range, but when its called from Freelancer.exe, it’s instead overriden with a seemingly arbitrary value, in my case, 14000.

Summary: While I can understand what is going on in general, I’m unable to determine the source of the two values (ESI+0xC and EBX+0xC) which when summed up become the distance detection threshold, when called specifically from Freelancer.exe+0xD1754

If any part of this is not clear, please let me know and I’ll happily assist as best I can.

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

Hi, I’ve had some players crashing sometimes when entering specific systems. After some digging it turned out that the Territory.dll was trying to access unreserved memory. The culprit turned out to be the rep movsd instruction, which is hardcoded to always copy 64 bytes of data, while the actual format strings were reserving only as much as they needed. In rare cases, they ended up being placed immediately before an unreserved block of memory, leading to out-of-bounds access attempt.

The fix was to simply make all format strings reserve 64 bytes of memory via change in stows function.

// Convert the string to wide and store it, returning the NOT of its index.
int stows(LPCSTR s, bool nl = true)
{
    int pos = ~store.size();

    int len = MultiByteToWideChar(codepage, 0, s, -1, 0, 0);
    if (len > 1)
    {
        len = 64;
        LPWSTR ws = new WCHAR[len];
        MultiByteToWideChar(codepage, 0, s, -1, ws, len);
        ws[len - 1] = '\0';
        if (nl)
            while (--len >= 0)
                if (ws[len] == '^')
                    ws[len] = '\n';
        store.push_back(ws);
    }
    else
        pos = 0;

    return pos;
}