In one of the examples i have found code for requesting backup.
The code was:
 

                        Functions.RequestBackup(vector3Pos,
                        LSPD_First_Response.EBackupResponseType.Pursuit,
                        LSPD_First_Response.EBackupUnitType.LocalUnit);

 

As vector3 i then used

                        Functions.RequestBackup(Game.LocalPlayer.Character.Position,
                        LSPD_First_Response.EBackupResponseType.Pursuit,
                        LSPD_First_Response.EBackupUnitType.LocalUnit);

It fails, NOT in VS, there it works perfectly, and build with no issues, but asa i load the plugin, the plugin crash and the error shown as '6' in this image is thrown:

 

The error claims that i am missing an assembly, but every step is supported with VS-intelisence as can be seen in 1-5 in the image

I suspect that the LSPD_First_Response-object is deprecated, and that the EBackupResponseType-object uses a different qualifying object in current version of RAGE/ LSPD:FR
My assembly are up to date, (witch also is obvious, if they were not, VS could not finish the code as seen in the image)

Is the LSPD_First_Response-object deprecated?
What do i have to use instead?

--------------EDIT--------------------------
I think i start to understand the reason for all this.
I have faulty file-folder structure in the installation of LSPD:FR.
I only have one plugin-folder, and in that folder i do not have a LSPDFR folder
I also do not know what files i need in this LSPDFR folder, but i believe that there need to be a plugin-folder inside this LSPDFR-folder.
are there any instructions for this?
AlexGuerra made me understand that i am missing files in my installation. The VS-installation is fine, and thats why i can build, but not use my plugin, asa LSPDFR-dependent methods are used
That is why i crash..

Edited October 4, 20223 yr by GTAbear
added new info

Is your plugin an LSPDFR plugin or a RPH plugin?

2 minutes ago, LMS said:

Is your plugin an LSPDFR plugin or a RPH plugin?

Yes... that is just that
I have just added new info in the orr. post.
I have faults in my installation, but where i can find a tutorial that shows the complete file-folder-structure, that i dont know
To answer your question directly, i thing it is understood inside the game-engine as a RPH-plugin, because it is in the plugin-folder of the base-game.
Afai have understood things now, it need to be two levels deeper, that is inside the LSPDFR-folder and there a NEW plugin-folder.
I dont have that, and i also do not know what other files i need to have in both these folders.
I also cant remember i have seen any instructions for how to set this up(?)
so..
\GTAV\lspdfr\plugins
That one i need to put a LSPDFR-plugin into
..But then what will happen to the RPH-methods i also used in my plugin, i have yet to be impacted from 😶
I hope this is not totally confusing, if it is -its because i feel so

 

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.

50 minutes ago, LMS said:

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.
 

Your explanation is highly appreciated!
a) is undoubtful the way to go, I just havent seen any feature-plugin based on LSPDFR-api. The example-plugins on gitHub are all Callouts. That is something i need to understand first.
All my issues in summery: If i am making a RPHook-type plugin, and f.i. change emergency-lights on a car ped-behaviour, and more, i cant also use LSPDFR-api methods in that type of plugin.
The result is that the backup-call neds to be in an other plugin, of type LSPDFR-api-plugin
Both plugins can be loaded together, and for a user it will be transparent and not matter at all, blackboxed in a way. User do not need to see if the features he use is of type RPH-plugin, or LSPDFR-api-plugin, that is solely my headache !

Shouldent there be a sticky about this. One with screen-shots of the file-folder-structure and your good explanation of the differences?



b) Maybe.. some day.. : p

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.

1 hour ago, LMS said:

they register their custom callouts when the player goes on duty, but you could also choose to do something entirely different there.

Ahh in that way! I will see if i can find out how to do that. Luckily there are many call-out examples to study.

 

1 hour ago, LMS said:

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 had thought about that, because i wouldnt be able to use the loadPlugin <myplugin> cmd in console, but instead i must unload LSPD:FR-plugin and then reload that through console!
Very good info. Many thanks!!