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;
}