LMS

One caveat about using .NET timers: They usually rely on system clock time and can hence elapse when the game is paused or running at a lower time scale. It might hence desirable to use the game's current tick to indicate time instead.

I did check this a while back and did not see anything that would prevent cuffed peds from being transported, but I am happy to give it an actual try in-game. I will see if I can verify it over the holidays, but feel free to nudge me if I forget.

You can certainly use FiveM vehicles without LML using OpenIV and they should work fine if they also work fine with LML. Regarding lag issues, are you running the game on a SSD? And no, you cannot have LML load the vehicle but then not use it.

What features are not included anymore?

I see what you mean now. Could you clarify the "caught and subdued" part? Is this a ped you spawn and then cuff using LSPDFR or what happens prior to that?

Thanks for sharing! We did recently update that behavior so there is a chance something went wrong. I will have a look and let you know.

First off, Rage.Ped is exactly what you need and Game.LocalPlayer.Character is also just an instance of Rage.Ped. You do not need the id/handle of the ped as that is already stored in the class. When you try to display the ped, .NET is invoking ToString() on the ped instance. However, since Rage.Ped does not have a custom implementation of that function, all it gives you is the class name as that is the best it can do. You could ask it to print the handle instead and you would see a numerical value - albeit not one you can do much with. Now that we know all this, we can assume that whatever ped you pass to RequestSuspectTransporter is a valid ped in the technical sense, but perhaps not a ped that actually can be arrested. You could try to blip the ped to see which one you are selecting.

It ultimately depends on what you are trying to test and how your plugin integrates with LSPDFR. If you are testing functionality that does not strictly rely on LSPDFR or could perhaps be stubbed fairly easily, then it might be quite easy. Say you use LSPDFR to request backup, but care about the actual behavior on scene as opposed to them spawning and arriving, your stub could have a unit spawn nearby and then your logic takes over. However, if you rely on a lot of LSPDFR functionality or functions that cannot easily be stubbed, then you probably have to do the entire reload. As for crashes when reloading too often, see Main.DisableAmbientScriptHooks in

Rockstar forgot to put the product name in the newly updated files so you will have to wait for a RPH fix.

The problem is that the dynamic call resolution is missing the return value hint, so it does not know what to return. You need to use the generic parameter to hint, such as HasEntityCollidedWithAnything<bool>(..). All functions invoked via the Natives class are dynamically resolved and there is zero type information available unless explicitly provided by you.

Well, my thinking was just hooking the generic game car spawn and calling repair on each vehicle after it was spawned. I don't think this would cause any problems as they are newly spawned (though I might find out some).

Yes, that's what I meant. Thanks for confirming. I suppose that means LML works "as intended" in the sense of how files get loaded but I do agree and see your point about looking into ways of making it more convenient. Perhaps just calling repair on each newly spawned vehicle works and it should not have any side effects (I think?). If you could confirm this for a few more models (spawn them, repair them), that would be great. Then I could see about including such an option automatically in the future.

The upper part of the component is done using the DISPLAY_ONSCREEN_KEYBOARD native. The bottom part is custom rendering by LSPDFR, no pre-defined component.

Those functions refer to the Windows clipboard.

Does this also happen when you install the vehicle through OIV?

Most of the examples choose to implement callouts, however you do not have to. If you look at their code, they register their custom callouts when the player goes on duty, but you could also choose to do something entirely different there. You would still deploy your assembly like a "traditional callout" and put it into the lspdfr plugins folder. That way, LSPDFR will load your code and you can use all its API functions because you are in the same AppDomain. The downside is that it might slow your development process a little bit because now you will have to reload LSPDFR to reload your code which will take a bit longer.

I will to clear up some of the confusion: First of all, most, if not all, of the issues you are running into are common .NET problems and are only indirectly related to RPH or LSPDFR. That being said, by using the right file structure, the problems can usually be fixed very easily. If you develop a plugin with RPH, that is, a plugin that has the RPH assembly level attribute, then you cannot easily make use of LSPDFR functions in that plugin. Why? Because when RPH loads plugins (yours and LSPDFR), they get loaded into different so-called AppDomains. An AppDomain isolates the execution of a plugin which in turn also means even if you have LSPDFR loaded and then load your plugin, your plugin will not know LSPDFR is loaded and attempt to load it again - now the file structure would matter to be able to resolve it. However, you do not really want to have LSPDFR running twice as you can imagine. There are two ways to go about it: a) If you rely on LSPDFR functionality, you might as well make your plugin a LSPDFR plugin. In that case, you install it into plugins/lspdfr and then when LSPDFR is loaded, it will load your plugin for you. RPH is not involved (directly) with loading your plugin anymore and you should not have/remove the assembly level attribute. b) LSPDFR functionality is optional for you: This is the much harder case if you are relatively new to programming so I would not recommend it, but I will mention it. You can, in theory, communicate across AppDomains and make your API calls work even if the target assembly is in another AppDomain. You would have to look into mechanism to remote between AppDomains.

Is your plugin an LSPDFR plugin or a RPH plugin?

Given that it dies while loading "sahp/vehicles.meta" I suspect that file is either bad or you do not have a gameconfig supporting more vehicles.

Try something like SET_ALL_VEHICLE_GENERATORS_ACTIVE_IN_AREA.

You can use the "disable road" natives to make traffic not spawn there or go there, but it can lead to some odd results where vehicles will u-turn in the middle of a road once they hit the disabled nodes.

What is the result you are looking for? Ped and vehicle budget are fairly reliable.

You are running a very old GTA V version which is not supported by more recent LML versions. Try downloading an older version or consider updating your game installation.

Most likely a silent crash right at game startup, usually because something else interferes. Check your eventvwr.exe -> Windows Logs -> Application for GTA 5 entries with a timestamp correlating with the game launch. Should have vfs as faulting module and an offset. If you could post a screenshot, I can probably check which pattern fails.

If those are .NET exceptions (which I presume they are), you can handle/debug/log them just like normal exception. Say you get a NullReferenceException when using a vehicle that does not exist, you could trap that in a debugger if you wanted to. It is fairly unlikely you are actually crashing RAGE Plugin Hook - that would usually result in a game termination. You are probably using API calls wrong, and it throws an exception to inform you about it so that the game does not crash.