LMS

We had it in LCPDFR and it will return, but I can't say when.

This is part of the managed holster of LSPDFR for pistols. Unfortunately the holstered pistol is the same category as the vest, so it conflicts. I guess all I could do is add an API function that disables the holster management for a specific cop.

It does, but it has to find a valid spawn point there.

Depends on what parts of the game world have been loaded in advance, but usually 300+ will result in a lot less units.

See this:

Under "Main", add "MinimumBackupDistance" and assign a value (in metres) that backup should respect. Note that very high values may lead to no backup spawning at all.

Let me know how it works!

One idea: In the knife callout, in the if statement you listed, you don't add the ped to the pursuit instance. Hence backup will not work for that pursuit (though I think it is intended). However, since that instance never gets a suspect assigned I could imagine it being in a kinda "zombie" status where it is waiting to start for the first time and hence bugging new pursuits. Try only creating a pursuit instance if you are actually using it and report back please.

IsKeyDown basically reports the status since the last check, i.e. when the key is being held down and you call this function in a loop, it will only enter the conditional branch once (the first time). IsKeyDownRightNow however, reports the actual key state, that is whether the key is being held down right now.

Normally the AI disabled flag is per pursuit instance, so it shouldn't carry over. I'll see if I can take a look this weekend though.

When nopping/hooking the anti debug checks, at least unmanaged debugging works fine for me. Managed only works through WinDbg for me though, VS fails to get notified. Not sure, but maybe they mess with the remote debugging thread or something.

You could also use a static random instance with a semi-random seed (system tick count for example). This way calling the function again in short period of time will get you different results because you don't initialize a new instance every call.

I'm thinking of maybe having an .ini option for the minimum distance, how would that sound? The main reason we went for much closer backup was because units were often useless during pursuits when spawned too far away.

That path is read from the .pdb file and is actually a path on my computer. This is because the released version was compiled on my end and when resolving the stack trace, the information from my computer is used. The actual crash is in OnBeforeCalloutDisplayed in your code however as you can see in the first line. The lines below just show the call order to get to that line of code.

Could you post more details on the crash? I'm not really sure what LSPDFR would do to make it actually crash.

Could you elaborate a little on "create scenarios"? Do you mean, like using the cops for pursuits? Since LSPDFR continuously scans for cop peds, I'd assume an option like explicitly "removing" your cop from LSPDFR is what you're after?

I think I know what's going wrong, will let you know.

Yes it will. The idea is to only break a lot of stuff once.

For a small set, a comparison as shown by Darkmyre and alexguirre is more than sufficient. If you have a very large data set (and also to reply to @Darkmyre's question whether it is efficient), a proper algorithm should be used. Just think of it as a maths problem: Let M be an euclidean space where you have a set S of points in M and a point p ∈ M. You want to find the closest point in S to p. Right now, using the naive approach, you have a runtime of O(dN) (d = dimensionality of M, N = cardinality of S) for getting the closest point. To achieve better performance, there are many different ways, such as using a kd tree (O(log N) or a voronoi diagram (best would be to use 2d then and ignore z axis to reduce space requirements or check at last) etc. You could even use Locality Sensitive Hashing if you want to (overkill for 3d most likely though).

Do you make sure to return execution via GameFiber.Yield or GameFiber.Sleep? Because all native invocations have to be synced with the game's scripting engine, there is no real multithreading and threads must return control each tick.