I have tried to find a way to get a better identification than RAGE.ped, but cant.
I need it for several methods including this one:
 

                    if (Game.IsKeyDown(System.Windows.Forms.Keys.NumPad2))
                    {
                        Ped purper=null;
                        Ped[] suspectGroup = Game.LocalPlayer.Character.GetNearbyPeds(2);
                        if (suspectGroup[0] != null)
                        {
                            purper = suspectGroup[0];
                            Game.DisplaySubtitle("~b~PrisonerTransport requisted FOR: " + purper, 5000);

                        }                      
                        //int id = 0;
                        Functions.RequestSuspectTransport(purper);
                    }

 

It is the 'id' of this precise ped that is needed. The message shows only RAGE.ped, but that is not precise enough, to get any respond from game-engine. I know the method is functional, because i have arrested myself 😛
If i replace the instance purper with Game.LocalPlayer.Character, i get arrested. So RAGE.ped is not precise, Game.LocalPlayer.Character is.

Can i get a precise 'ID' on the RAGE.ped i have infront of me, and in suspectGroup[0]?

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.

11 hours ago, LMS said:

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.

Many thanks!
I have made some experiments, that has given strange results.
Firstly i did not use a blib to identify the RAGE.ped. Instead i gave the focused ped a helmet. That way i was easy to see if i addressed the right one.
I also omitted the instantiation of a Ped to hold the focussed ped. Instead i used the array directly
And that 'works', but in very strange way.
Code:
Ped[] suspectGroup = Game.LocalPlayer.Character.GetNearbyPeds(1);
                        if (suspectGroup[0] != null)                     {

                            suspectGroup[0].GiveHelmet(false,

HelmetTypes.RegularMotorcycleHelmet, 1);
Functions.RequestSuspectTransport(suspectGroup[0]);
This is the result:

 

The strange thing here is that the

Functions.RequestSuspectTransport(suspectGroup[0]);

Does not work.
It is strange because, if i instead stops a complete random pedestrian, and smack a helmet on that instance, then the transport arrives, and he is being forced into the van (???)

That is:
A caught and subdued RAGE.ped  is ignored, but a random ped on the street will get transport.
I really cant understand this.

Is this a bug?

 

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?

54 minutes ago, LMS said:

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?

The caught/subdued RAGE.ped is the result after a dispatch from default game-engine in LSPDfr. -IOW, i do not have any other plugins running, only my own. The ped has surrendered after a chase, and is arrested with default method ( E for surrender/ Handcuff ).
In this state the ped must be brought to kneeling position for the ingame Suspect-transport ( Backup Transport Local-unit )
That works every time, so the ingame/ default method is flawless, but depends on using the Backup menu.
I wanted a keypress for the same function.
Using code
Functions.RequestSuspectTransport(suspectGroup[0]);
will however not send the Transport-unit.
The helmet-trick was to make sure that i addressed the ped i focused.
That works, and proofs that it is the correct RAGE.ped that is addressed in the code.
To my surprise using the same code
Functions.RequestSuspectTransport(suspectGroup[0]);
And only that, there are no arrest-sequence, handcuffing or kneeling, any RAGE.ped will get picked up by the Suspect-transport

Here shown with a colleague 😛


Thats why i wonder if there is a bug.
It looks like the RAGE.ped has a state-sequence?
It is even more obvious with 'dead' peds
Here
All these peds has been declared 'dead' by the ambulance crew. I can however reradout health  ~140, and these peds can not be cleaned away with

World.CleanWorld(false, true, false, true, false, false);

Because they are indeed not dead, but they wont delete() either

Spoiler

                            if (corpse)//.Health <= 210)
                            {
                                corpse.IsPersistent = false;
                               //corpse.Dismiss(); //nop
                                corpse.Delete(); //Neither..  

What state could they have?
Is my method for addressing a ped the only one? I cant find any other than building an array and then addressing [0]. item

 

Edited November 11, 20223 yr by GTAbear
more info

I have done some more tests
After first stages of the arrest-sequence TAKEDOWN the ped IS transported, but there is a severe glitch between the two TASKS cmd. The ped will 'oscillate' between the on-stomach position and the upright-follow position for < 1 secd, then the transport-ped 'win' the TASK-'battle', and the purp-ped is dragged to the suspect-transport , in correct fashion.

 

Stages 2 of the arrest-sequence HANDCUFFING is the reason for the no-function of suspect-transport.
A handcuffed ped will not be recognized in [0] -(and i cant place a helmet).
Making the ped stand-up (Q) does not change that.
Is there a 'responsibility' setting so the handcuffed ped now 'belongs' to the cop-ped that placed the handcuff?
That could be the reason

 

Yet one more observation that proves my theory about 'ownership' after the handcuff-phase.
Here

i attempt to take control over a Ped that has been handcuffed by an AI-cop.
As seen on the picture the target-Ped is not even recognizing the mesh of my avatar, there are no collision, so my avatar-mesh can overlap the mesh of the AI-Ped, and i cant interact with the 'foreign-arrested' AI.
On the other hand the AI-cops cant interact with the Peds i have taken ownership of. They are left on the pavement, if i dont invoke the next phase of the logic sequence -eg the transport.

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.

On 11/21/2022 at 11:52 PM, LMS said:

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.

Hi, did you find a reason for this glitz in the code?

I gave it a quick test and the log contains the answer:

 

Requesting control failed for SuspectTransportManager #1 (Blocker); current is PlayerSuspectTransportNew #1 (Blocker)

 

Essentially both components are running at the same priority and hence control cannot be granted, and the transport is not initiated. I assume the best way forward would be to add another parameter to RequestSuspectTransport that allows the developer to specify whether they want to force the transport - in that case it would remove the ped from its current controller and transfer ownership to the transport manager. Nice find!

@LMS I have been slow to react to your fix -Sorry!
I have re-inserted the transport code, and it works!
This is the working code:

Spoiler

//Call transport
                        if (Game.IsKeyDown(System.Windows.Forms.Keys.NumPad2))
                        {
                            Ped purper = null;
                            Ped[] suspectGroup = Game.LocalPlayer.Character.GetNearbyPeds(2);
                            if (suspectGroup[0] != null)
                            {
                                purper = suspectGroup[0];
                                Game.LogTrivial("######### Signal from Transport req. array 0: "+ suspectGroup[0]);//Shows RAGE.Ped
                                Functions.RequestSuspectTransport(purper);
                            }
                            else //ikke aktuelt
                            {
                                purper = suspectGroup[1];
                                Functions.RequestSuspectTransport(suspectGroup[1]);
                                Game.DisplayNotification("######### Signal from Transport req. array 1: "+ suspectGroup[1]);
                            }

                        }

Thank you so much for your help and fix!