lmsdev / lspdfr-api Goto Github PK

A function to grab vehicle info, for use in things like my speed radar, or FinKone's plate checker, would be extremely useful.

Requested to put this here so LMS doesn't forget

• IsPedACop()
• IsCopInPursuit()
• RemoveCopFromPursuit()
• IsPlayerArresting
• (GetPedPlayerIsArresting)
• (eg. Set accessor to peds persona variables to more easily change just one feature eg. citations)

Some "bugs" (things that give trouble for me):

• Player gets stuck to a infinite loop, if tries to open door with passenger being CanBePulledOutOfVehicles == false
• Cops on foot far away from pursuit get stuck on aiming loop (big problemo to me with partners)
• Somethings seems to block the melee task, when ped is assigned to melee pursuit suspect?

As of now there is no way of assigning a cop an arrest/pursue/etc task in or out of a pursuit.

Methods for acquiring the current active callout or pursuit or pullover so that we can further interact with them, such as acquiring the ped in a pursuit that we did not create, or acquiring the name of a callout.

We had a similar function with the LSPDFR API where we could get the current ped in a pullover too and override the AI behavior. It would be nice to get that again.

This sort of relates to Issue #5, but I was just watching a video by BayAreaBuggs, and he used the plate checker feature of FinKone's Police Radio. FinKone has a selection of "flags" that come back on a vehicle, but it appears to be random.

Is there a way we could have a selection of preset flags added to LSPDFR for this? Such as, vehicle stolen, or used in a hit and run recently, etc? That way, FinKone's radio could use those same flags, and all the data would be consistent.

Just an idea.

A function to disable LSPDFR taking over the AI of peds added to a pursuit would be great. That way, we could have peds in a pursuit, so backup still recognizes them as a suspect, but we can also control their AI and make them do things such as fight back, rather than always flee.

The ability to set a ped as arrested, and also transfer "ownership" (Who he/she follows) SetpedAsArrested doesn't work AFAIK.

I'd love the ability to be able to register callback methods for pertinent events.

For example, right now, I determine whether or not a Ped has been 'stopped' and then issued a warning by polling for Functions.IsPedStoppedByPlayer and determining if the result has changed since the last time I ran it. This works, but I don't actually know if a citation was issued, or if it was actually a warning that was given.

An ability to register a callback method for this kind of event (pullovers too!) would save polling (especially over a larger number of Peds, presumably this has a performance impact) and avoid a fairly significant burden of evaluating and checking state information.

This is sort of an extension on issue #2, but I thought it deserved it's own request.

Could we have a function (returning a bool) which would tell us if a callout is currently active?

Following suggestions to greatly improve the current callout frequency system, both for developers and users:

1. Remove all frequencies except low, medium and high. Currently, various callout packs exploit the 'always' frequency which disadvantages plugins that use lower ones significantly. Callouts can now be forced during testing using the API function so 'always' is no longer needed.
2. Allow individual callout frequencies to be edited at runtime. Because the callout frequencies are currently determined by a value in the callout attribute, this cannot be edited at runtime.
   Allowing this to be edited at runtime allows for far greater user customisation for their desired patrol types via an INI file.
3. Add a new console command: "StartCallout callout" where callout is replaced by the name of the desired callout. A custom RPH AutoCompleter could easily be added to populate a list of valid values to the user. Again, this allows for far greater flexibility for people that want to do a specific kind of patrol avoiding the need to spam X, hoping to get some specific callout they want.

Cheers.

Posting this as a reminder for LMS, from this thread: http://www.lcpdfr.com/forums/topic/53351-peds-ignore-lspd-when-their-persona-is-set

LMS, I added the Acknowledged label, as you acknowledged this on the forums as a bug.

Hi LMS/Sam!

Is there any way you could put a bool that toggles the Available for Calls option?

In L.S. Noire I've tried using this:

private static void CalloutFiber() { while (true) { if (Functions.IsCalloutRunning() == true) { Functions.StopCurrentCallout(); } GameFiber.Yield(); } }

But that calls the End() and some callouts don't have checks in their End() so it crashes the game... (Bad callout devs, haha).
Thanks!

One prime example would be the GTA IV Key sync, which enabled users to view their statistics once something is done. (ie. tracking of the number of arrests,citations, most patrolled area, etc....). With this enabled, once multiplayer clans start to become common, users will be able to share their statistics to determine if they're fit for the clan itself.

Let's start using this Git repo again! =P

I'm not sure if there's already a way to do this programmatically, but it would be nice if there was a function we could call that would put a ped into that 'stopped' state where you can interact with them. Like when you hold 'E' to stop a ped, or when you ask a driver to step out of their vehicle. You can either interact (ask for ID/cite/warn) with them by pressing 'E', or place them under arrest by holding 'E'.

Can we have a function that would do this? I found SetPedAsArrested(Rage.Ped) in the API namespace, but I don't think that does the same thing, based on the name of the function. (I haven't tried it yet, though.)

@LMSDev?

I'd like a way to register new on-duty station locations, causing a police station blip to show up there and prompting the user to press E to go on duty. This would allow people who use map mods to go on-duty at custom stations they've added. Now that YMT and YMAP files can be modified, it's possible to actually alter the map directly through OpenIV - for example, I've converted the unused heliport near the marina into a coast guard station for Coastal Callouts and would like to register it as a police station where users can go on duty.

Suggested API call: void CreatePoliceStation(string StationName, string DepartmentName, Vector3 OnDutyPromptLocation, float OnDutyPromptRadius, Camera ZoomOutCam)

• StationName and DepartmentName would be shown as the text when you go on-duty (as existing stations already do)
• OnDutyPromptLocation would be the position the player needs to stand at to trigger the "Press E to go on duty" prompt, and would also be the position of the blip.
• OnDutyPromptRadius would be the distance from the location the player must be within.
• ZoomOutCam would be the camera for the zoom out that happens when you go on duty, just before the screen fades into character selection. Not sure how this works internally, maybe make it a Vector3 or something instead. Some way to choose where the camera goes to when you go on duty.

It would also be nice to register jail dropoff points, although with Arrest Manager being widely used perhaps that's not as important these days.

Would fasten development a lot!

Sometimes users can miss important information if a scanner audio message doesn't play, while other scanner audio is superfluous. Right now, PlayScannerAudio will just not play your audio if some other scanner audio is already playing when you call it, and there's no way to ensure that some other audio isn't already playing.

I'd like an overload on PlayScannerAudio and PlayScannerAudioUsingPosition to force the audio to play, even if it has to wait a bit until the previous audio is finished. Just a bool as an additional parameter.

Also, it occurs to me that PlayScannerAudioUsingPosition could be eliminated and just included as an overload as PlayScannerAudio(string, Vector3).

Adding this so LMS doesn't forget.

From this thread: http://www.lcpdfr.com/forums/topic/53351-peds-ignore-lspd-when-their-persona-is-set

"I don't know if this is feasible for you guys, but there might be a workaround for this...

Would it be possible for you guys to add the ability to add 'notes' that would show up when you ran a Ped through the police computer?

Rather than trying to set a Ped's persona, could we define custom text that would show up when you ran their name through the computer? So instead of setting a Persona with IsCop set to true (and possibly causing conflicts elsewhere), could we set the Ped's 'notes' to be, 'Subject is an off duty police officer'? It would open up other possibilities too. Like, you could have a Ped show in the computer as, 'Subject has a mental illness', or 'Subject has a history of violence against police; use caution'."

It would be nice to be able to specify a specific vehicle and set of peds to occupy it in the RequestBackup method. An overload, RequestBackup(Vector3, EBackupResponseType, EBackupUnitType, Vehicle, IEnumerable<Ped>), could achieve this. This would allow plugins to take advantage of the built-in backup response system, while also allowing them to send a particular unit as required for a callout or other plugin. For example, one might wish to dispatch a park ranger or army vehicle as backup in a particular area. Being able to still specify the EBackupUnitType is necessary I believe, as that affects things like the ped's props (e.g. SWAT units have vests, others get holsters) and possibly how the AI behave.

Copied from this API forum thread.

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.

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 or LHandle which could be used to retrieve information about the callout, like 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 (former), or pulled over and successfully stops (latter). Maybe also OnOfficerApproachDriver(LHandle pullover) which would trigger the first time you get the "Press E to interact with driver" prompt for a given pullover. 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.

I'm doing a road block plugin and I want the cops I spawn to have the same AI as the LSPDFR cops. So to spawn them I use Cop() from the namespace LSPD_First_Response (I read somewhere that it doesn't work, but I tried it and works). I know that this namespace will be private so what I want is the function to create a cop in the API namespace.

And also would be nice to have a way to add them to a pursuit and assign them a vehicle so if they are spawned out of a vehicle and they are added to a pursuit they will enter the assigned vehicle.

Thanks.

The same arguments on those events as with Events.OnPulloverAskedPedToLeaveVehicle

I'd like a way to get a list of all cops. Something like Ped[] Functions.GetAllCopPeds(). I assume LSPDFR already tracks that, you see various log entries about "cop manager" and we know it can automatically pull in ambient officers into a pursuit. Even better if I can get a list of all cops who are involved in a pursuit, e.g. Ped[] Functions.GetCopsInPursuit(LHandle).

Copied from this API forum thread.

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.

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 (or maybe an LHandle or something else like that) would be a unique handle to that menu entry.
• void RemoveMenuItem(uint handle). Remove a menu item which had been added by AddMenuItem.
• List<uint> GetMenuItems() to get all menu items associated with the current callout.

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.

The ability to get the current callout's name would be very helpful, especially to me at the moment. Right now i am comparing the class created (read from the RPH log), however it is a workaround and very ugly, especially when it could simply be Functions.GetCurrentCalloutName(get;)

Hopefully you decide to make my life easier :)

Thanks.