LSPDFR API feature requests

PNWParksFan · July 7, 2016

Some common issues have come up repeatedly in the LSPDFR plugin developers discord, and I think many of them could be solved with some particular additions to the LSPDFR API. Some of these are also just things I'd like to see for use in my own plugins. Anyways, I think it would be good to have a central list of feature requests, where plugin developers can discuss what they would use, and the LSPDFR developers can comment on what might be possible for future versions.

Without further ado, my current requests:

Event handlers

Right now, a lot of plugins run a bunch of loops in a bunch of gamefibers to detect things that LSPDFR knows about already. It's a big waste of resources, and inefficient from a programming perspective as well. I'd like to suggest adding a lot more event handlers in the next version of the LSPDFR API.

OnPedArrested(Ped suspect, Ped arresting_officer): An event for whenever a ped gets arrested. Event arguments should give the arrested ped, and the officer who arrested them. This would trigger for both arrests by the player and by the AI. Devs could distinguish by just checking if arresting_officer == Game.LocalPlayer.Character. I imagine this would reduce the overhead of plugins like Arrest Manager.
OnCalloutDisplayed, OnCalloutAccepted, OnCalloutDeclined, OnCalloutFinished. All of these should correspond to the equivalent methods in the LSPDFR base callout class, but would trigger for any callout, and would return some kind of callout info object which would tell you the name of the callout, current status, etc. I can see this being useful for a wide number of things... mods like Vocal Dispatch and Computer+ for example could get better integration. Ambient events could detect if a callout is active and behave differently.
OnPullover(LHandle pullover) and OnPulloverDriverStopped(LHandle pullover): For whenever a ped is pulled over. You can already get the current pullover using the API, but you have to constantly call that method to detect when a pullover start. An event would let you trigger some behavior immediately when a pullover starts.
OnPursuitStarted(LHandle pursuit): Likewise, you can detect the current pursuit but need to loop to find out when one starts. This would reduce overhead for mods which wish to affect pursuit behavior.
OnPedStopped(Ped suspect): Would return the stopped ped when stopping a ped on foot, i.e. by pressing and holding E.

There are probably other events which would help as well, but those all are ones I've been thinking about.

Menus and callout actions

There's been some concerns recently about running out of keybindings what with all of the plugins available these days all having their own menus. I'd like to propose a couple of solutions to this.

First, a "callout actions" menu which could be created within the Callout class, and would be removed when the callout is over. The way I'd do this, although obviously I'm open to other suggestions, would be to have the following methods of the Callout class, which would modify the menu for that callout. The menu would be created during OnBeforeCalloutAccepted, the menu would become available at OnCalloutAccepted, and would be removed at End.

uint AddMenuItem(string MenuEntryName, Action CallbackFunction). This would add an item to the menu. When the user clicks the menu item, it would close the menu and execute the CallbackFunction. Perhaps figure out some way to ensure the callback function is a method of the callout class owning the menu. The uint returned would be a unique handle to that menu entry.
void RemoveMenuItem(uint handle). Remove a menu item which had been added by AddMenuItem.

These actions could either be put under a new menu with a new keybind, or could be added as a tab on the N menu which would be selected by default when you press N during an active callout. I think this approach would help with a lot of the callout-specific actions which don't need to be present all the time.

For more persistent menus which users might want to access when a callout isn't active, I'd like to see a master menu. It could also be a tab under the N menu, or a new keybind. Each plugin could register one entry, which would simply be the name of the plugin. That entry would have a callback function, and whenever the user selects that menu option it would execute the callback. This would effectively allow "submenus" without requiring the LSPDFR API to implement a complicated full menu API, because the callback could be code to display a RNUI menu or other. So the "plugin menu list" might look something like [Arrest Manager, Assorted Callouts, Better EMS, Code 3 Callouts, Partner Mod, Search Warrant, Wilderness Callouts], and clicking any of those would open the main menu for that mod.

Plugin authors could still have a keybinding to open the menu directly, but set up their INI file such that the key could be None, allowing access only through the main menu. They could also have an INI option for whether to register on the main menu or not. This way, users could configure their INI files to the menus they want are available with the click of a single key, and the menus they use less frequently they can access through the master menu, without having to remember some infrequently used keyboard combination and using up yet more keys.

Additional API functionality

Some other API functionality I'd like to see improved:

PlayAudio: add a bool flag MustPlay. If true, the audio would always play, eventually. Right now if you request scanner audio and there's already one playing, yours just won't play. If the flag were true, it would wait until the current audio was finished, then play your audio. Would have to trust developers not to abuse this, and only use it for audio that's actually important to the context of the situation, and not little things like "Roger that, we're just around the corner!".
RequestBackup: add an overload to accept a Vehicle and a List<Ped>, so that you can specify the backup you want to call. Keep the current response enums in the method signature too, so you can specify that you want the unit to behave like a SWAT unit (for example).

That's all I've got at the moment, I'm sure other devs will have some good ideas to add or suggestions on how to improve these ideas. Looking forward to seeing what the next LSPDFR API release will allow modders to make!

Edited July 7, 2016 by PNWParksFan

Darkmyre · July 7, 2016

In addition to all of the above, I'd love for there to be some functions to interact with Traffic Stops a bit better - including most of all, a way to create a new traffic stop and assign peds to it.

I had a bunch of other ideas I cant remember right now, if they come back to me I'll add them.

Stealth22 · July 7, 2016

This could potentially be more useful if it was on the LSPDFR-API GitHub. LMS can keep better track of it there, I think.

PNWParksFan · July 7, 2016

56 minutes ago, Stealth22 said:

This could potentially be more useful if it was on the LSPDFR-API GitHub. LMS can keep better track of it there, I think.

Since @Stealth22 doesn't seem to like to include links