Access the API without being a direct Plugin

[CQoute 19]

I'm just wondering if i can detect whether the player is on duty etc. or access the API without being a LSPDFR specific plugin. This is because LSPDFR is just the icing on the cake as such, but not needed for my plugin to operate.

[FtDLulz 293]

I'd like to know if we could do this too -- right now it's just saying the file doesn't exist if I try an access anything API related in a non-LSPDFR plugin.

[Cyan 4862]

I don't think this is possible, no. That being said, you have full access to the Rage Plugin Hook as an LSPDFR plugin, so there shouldn't be much need to.

[FtDLulz 293]

I don't think this is possible, no. That being said, you have full access to the Rage Plugin Hook as an LSPDFR plugin, so there shouldn't be much need to.

So we can create a plugin like normal and put it in the LSPDFR Plugins folder instead, and once we load LSPDFR it will act like a normal plugin?

If so, that's pretty nice. I had no idea.

[CQoute 19]

That's fair enough, but that also means that our plugin is dependent on LSPDFR where some users may not wish to install LSPDFR... May have to look into getting the values by some other means.

I actually have no problem referencing and accessing the LSPDFR dll from the ResolveEventHandler way. Its just that when i do LSPD_First_Response.Duty.OnDuty, it always returns false.

[Stealth22 800]

So is there a way to do this at all?

I just found out last night that my Keep Calm plugin (which now works), interferes with callouts.

How, you ask? Well, I've been testing my callout plugin, and I was pulling my hair out wondering why my callout peds were so timid, and were not doing much of anything. The answer was, Keep Calm. It was setting Ped.BlockPermanentEvents to true, which was intended to keep them from panicking in the event of gunfire.

Unfortunately, that meant that peds would block out ANY kind of event. It basically takes away their ability to think and react...they do only as they are told, and thats it. Once I disabled Keep Calm and tested my callouts again, everything was fine.

Basically, I'd like to have Keep Calm detect if a callout is active, and if so, disable that plugin until the callout is over.

Doable? 

[FtDLulz 293]

So is there a way to do this at all?

I just found out last night that my Keep Calm plugin (which now works), interferes with callouts.

How, you ask? Well, I've been testing my callout plugin, and I was pulling my hair out wondering why my callout peds were so timid, and were not doing much of anything. The answer was, Keep Calm. It was setting Ped.BlockPermanentEvents to true, which was intended to keep them from panicking in the event of gunfire.

Unfortunately, that meant that peds would block out ANY kind of event. It basically takes away their ability to think and react...they do only as they are told, and thats it. Once I disabled Keep Calm and tested my callouts again, everything was fine.

Basically, I'd like to have Keep Calm detect if a callout is active, and if so, disable that plugin until the callout is over.

Doable? 

I hope so. Otherwise it seems the API's useless unless you're making a callout, 'cause I can't seem to get the API to work unless I put my plugin in the LSPDFR plugin folder, which then messes up positioning and other things.

[Stealth22 800]

I found a temporary fix...I made Keep Calm ignore any peds that are on foot, and set that flag to true for any peds that are in a vehicle. CouthInk4 tested it for me, and I just played LSPDFR over lunch. It seems to work fine.

It remains to be seen if it will interfere with any vehicle related callouts.

[LMS 2055]

I don't really think it will work. Plugins run in different AppDomains, so when your plugin is loaded with a reference to LSPDFR, chances are it will load LSPDFR into its own AppDomain again. This is why your plugins are loaded by LSPDFR explicitly, to guarantee they are in the same AppDomain.

[GooseJS 0]

I found a way to get around putting the plugin into the LSPDFR folder. Well, I didn't find it, but I found that this person found a way to get around it. If you download the police radio plugin by FinKone, there is a GTA V.exe.config. If you take this and place it into your root GTA V installation folder, you will no longer get the FileNotFound exception!

[FtDLulz 293]

I found a way to get around putting the plugin into the LSPDFR folder. Well, I didn't find it, but I found that this person found a way to get around it. If you download the police radio plugin by FinKone, there is a GTA V.exe.config. If you take this and place it into your root GTA V installation folder, you will no longer get the FileNotFound exception!

Yeah, found that out just yesterday. Pretty nice though :P

[Cyan 4862]

You don't get a FileNotFound exception, but as far as I'm aware, you're not tying into the instance of LSPDFR that is running, you are essentially creating another one.

[Ethenal 13]

Maybe this could be accomplished with reflection? I'm unfamiliar with .NET reflection but it seems to be pretty powerful - however, the thing LMS said about the AppDomains may render that pointless. Might be worth looking into though.

[CQoute 19]

You don't get a FileNotFound exception, but as far as I'm aware, you're not tying into the instance of LSPDFR that is running, you are essentially creating another one.

I was under the impression that static properties shouldn't need to rely on an instance. That's why I assumed LSPD_First_Response.Duty.OnDuty would work as its called statically.

[LMS 2055]

I was under the impression that static properties shouldn't need to rely on an instance. That's why I assumed LSPD_First_Response.Duty.OnDuty would work as its called statically.

Keep in mind that the scope for statics are AppDomains though.

[CQoute 19]

Keep in mind that the scope for statics are AppDomains though.

 figured it would've been something like that, thanks for clearing it up though...

[LMS 2055]

Sure there is, you just have to take AppDomain remoting into account. All API calls have to be made on/in/from the LSPDFR AppDomain. I've attached a very basic example on how it could work. When you go on duty and then run the test plugin code you should get "False" from the first check and "True" from the second. Also added the source since I didn't test it, but you should get the general idea.

 

Helper.rar

[FinKone 1305]

 

Excited to try this if I ever get some free time.

[LMS 2055]

So what I'm currently getting (probably me being too stupid to fix it, hehe):

Hidden Content

The plugin attribute seems to be defined in your Class1, so I don't really get what the problem is. 

The lib is just the compiled version of the AssemblerHelper source file so you don't have to. It is not supposed to work as a plugin, but a normal library. You can reference it from your project and then use its functionality like shown in Class1. I guess you have to place it into the game root folder so your plugin can load it properly when referenced too.

[Stealth22 800]

Excited to try this if I ever get some free time.

Ditto. Haven't got the time at the moment, but I'll be looking into that soon.