LMS

Yes, different issue. They would have been entirely invisible.

The fix is now public with version 0.4, please test.

The whole idea of the handle is so that things internally can change - if you need specific information exposed via a handle, please let me know.

Yes, the way I understood it he was talking about ped voices which are not played from the audio folder.

Your mods will happily co-exist.

Great to hear there is some progress! Officer audio is not stored externally anywhere but played "directly" from the game, i.e. its archives. This is where it should be replaced too.

You are not supposed to use the Compatibility Patch on the 1.0.7.0 version, it is only for the new CE version.

Right, you could also just patch their logging code, but I was more saying there is no "option" for LML currently to disable it.

I have updated the Compatibility Patch, please try again.

I have updated the Compatibility Patch, can you guys please try again?

I have implemented all requests, if you are interested in testing them please send me a PM. Thanks.

Right, so you would actually have an argument (i.e.) the ped? So the full signature would be: void sendIdCheckAnswer(Ped ped)

I have started working on your requests, can you please answer my question above.

Unfortunately, I don't think it can be reduced in any way.

They are not clashing per se, OpenIV just has a lot of verbose logging that is unfortunately triggered by how LML loads assets. In most circumstances your disks should be fast enough to sustain the logging, so most people will not notice it.

Not without modifying OpenIV I don't think. You might be able to replace most of your OpenIV mods using LML, but for custom RPFs it is still required.

When LML is present OpenIV unfortunately does a lot of excessive logging (check their logfile) which is probably hurting your performance.

Logs always help, but in this case it is most likely a broken memory offset deep down somewhere. Feel free to post anyway, perhaps one day I will have a look and update the hooks again.

Like Cyan said there seem to be very few performance complaints so it could be something else (bad asset for instance). I cannot see anything unusual in your log files, unfortunately. Does this happen in all areas and consistently? Could you please also clarify whether you've had this issue all the time or whether it started recently? LML does use more resources (since it intercepts file requests), however they are minimal compared to the actual file loading. What happens when you have LML present but no OpenIV?

Assemblies can be loaded into different "contexts" within an AppDomain. The context used by Load(byte[]) does not resolve Assemblies automatically which means for dependent types/future loads you need to keep track of your loaded assemblies and return the already loaded one if you do not want to end up in DLL hell (where fun things happen like casting MyType to MyType and getting an exception that they are not the same type despite being identical). You hook AppDomain.CurrentDomain.AssemblyResolve and in the callback you check if your specific DLL is being requested. If so, you use the Load(byte[]) overload. See here: https://docs.microsoft.com/en-US/dotnet/api/system.reflection.assembly.load

Please note that proper DLL isolation without file locking is only really possible when using a separate AppDomain which then requires you to remote all communcation (essentially IPC). You could however try hooking AppDomain.AssemblyResolve and resolve all references using the byte context. This does not create a hard link to the file and might be enough for your case.

Does this also happen when your plugin is the only active LSPDFR plugin?

LCPDFR itself works fine on the latest version of GTA IV, it is the underlying hooks that need fixes. I have released a compatibility patch for the Complete Edition when it was released, but I think R* has updated the game again and broke that. I cannot say when/if I will have another look at GTA IV, but you are more than welcome to have a look at the bad offsets yourself and see what broke.

Thanks, those requests all seem reasonable.

It is easiest to get coordinates, yes. In-game, drive to where you want it to spawn and you can type in PrintInfo in the console to display coordinates.