LSPDFR API Namespaces

[Stealth22 804]

To the LSPDFR Team: So we have been reading posts from Cyan about the API, saying that we should only be using the API namespace, and the others will all be marked private in a future release.

I wanted to make a list of the classes I am using, in the hope that those will not be hidden, or that a workaround can be provided.

Also, if some classes and/or functions are going to be moved, could we get a list of those so that we can make the necessary code changes beforehand? (i.e. Make the changes to our plugins in a separate branch, so when the new version of LSPDFR is released, callout plugin updates can be released immediately?)

• LSPD_First_Response
  • Nothing being used in here yet...but it would be nice to have a way in the future of seeing if the Police Computer is active, to prevent key bindings from interfering while running a suspect's name.
  • I also just found the PedInteraction class, and that would be very useful to me, if it could be somehow included later.
  • I could make use of the NativeHashes class too, but that one definitely isn't critical. More for code organization than anything else, not a big deal. I just like Constants better than hardcoding function hashes/names.
• LSPD_First_Response.Engine.Scripting
  • I don't use anything in Functions yet, but I can definitely see myself doing so. Perhaps the spawn point functions.
  • I definitely use the WorldZone class (and it's properties!), as well as the GetZoneAtPosition function within it.
• LSPD_First_Response.Engine.Scripting.Entities
  • I have tried to use the Persona class, with some difficulty (see my other thread for details on that)
  • I use Vector3Extension extensively, so I would hope that this class will be sticking around
• LSPD_First_Response.API
  • Using this one for obvious reasons...
• LSPD_First_Response.Mod.Callouts
  • I am assuming that the Mod.Callouts namespace will be sticking around, since that one is sort of...essential, haha

So yeah, just from looking at the Object Browser, as far as I can tell, that's what my plugin uses right now. A lot of these classes would be very useful. There are a couple that are critical to Code 3 Callouts.

Obviously, most of these things need to be marked private. As a software developer by trade, I completely understand. But some of these functions are being used by developers, so if their namespaces need to be private, it would be nice if some of them could be implemented in the API namespace as well.

Thanks!

Edited August 4, 2015 by Stealth22

[LukeD 1,860]

To the LSPDFR Team: So we have been reading posts from Cyan about the API, saying that we should only be using the API namespace, and the others will all be marked private in a future release.

I wanted to make a list of the classes I am using, in the hope that those will not be hidden, or that a workaround can be provided.

<snip>

Everything should be private, it defeats the purpose of an API if we can access everything not meant to be accessed.
However that being said most of the functionality you and others use would be brought into the API in some way so that we can access them through the API, allowing correct management of it.

You don't need those namespaces either, they are not critical. Most of the things you choose to do can be done so with natives until the API can provide us with those features.

[darkfire59 0]

Could we make this thread a suggestion for all of the Classes/funtions, we wish to keep access to?

[Stealth22 804]

Everything should be private, it defeats the purpose of an API if we can access everything not meant to be accessed.However that being said most of the functionality you and others use would be brought into the API in some way so that we can access them through the API, allowing correct management of it.

You don't need those namespaces either, they are not critical. Most of the things you choose to do can be done so with natives until the API can provide us with those features.

Yes, I agree with you. I'm not a kid, and I develop software for a living, so I understand that everything should be centralized within the API namespace.

But if all these other namespaces are going to be locked down, then there should be some way to access at least some of these functions through the API namespace.

[LukeD 1,860]

Yes, I agree with you. I'm not a kid, and I develop software for a living, so I understand that everything should be centralized within the API namespace.

But if all these other namespaces are going to be locked down, then there should be some way to access at least some of these functions through the API namespace.

Again, you don't need to be worrying about the access going. Look at the LCPDFR API and look at all the extra stuff we had and/or requested. Now look at the LSPDFR API. BIIIIIG difference.
I'm not fighting or calling people out, I'm just saying several people seem to be panicking about having access to these things revoked. Try to remember you shouldn't even know these namespaces exist. How would you have gotten by if that was the case. I'm 100% certain you would have, I don't doubt anyone's ability here, I'm here to provide help and support not question if you should be modding or not :)

[Cyan 4,982]

I think a key part of this is understanding that the API is only for interacting with LSPDFR and providing functionality between external addons and LSPDFR.

It is not meant to be an open library for GTA V development. Any future development will obviously reflect this.

Edited August 4, 2015 by Cyan

[LMS 2,065]

Yeah, don't worry, it's not that we wanna cut out stuff really. The problem right now is though that we can't really manage external input through proper API classes, but our internal stuff is called directly. This can cause some side effects, because you don't know how you are supposed to use the internal classes or we didn't intend such access at all. I don't wanna hurt API development at all and I'm more than willing to add all the stuff you need in the future, I just don't wanna expose internal classes.

@Albo1125: Sorry, but that's just not possible. We can't just expose such crucial components nor allow changes to it. We'd have to think of different ways, like giving you the ability to set a ped as arrested manually for instance.

[Stealth22 804]

I think a key part of this is understanding that the API is only for interacting with LSPDFR and providing functionality between external addons and LSPDFR.

It is not meant to be an open library for GTA V development. Any future development will obviously reflect this.

 

Yeah, don't worry, it's not that we wanna cut out stuff really. The problem right now is though that we can't really manage external input through proper API classes, but our internal stuff is called directly. This can cause some side effects, because you don't know how you are supposed to use the internal classes or we didn't intend such access at all. I don't wanna hurt API development at all and I'm more than willing to add all the stuff you need in the future, I just don't wanna expose internal classes.

@Albo1125: Sorry, but that's just not possible. We can't just expose such crucial components nor allow changes to it. We'd have to think of different ways, like giving you the ability to set a ped as arrested manually for instance.

Understood.

Keep in mind that with the list I made, most of it is "I'd like to be able to use this at some point". The spawn point functions for example...well, I wasn't paying attention before, so I didn't even know they were there, and I made my own logic for getting a spawn point. So I don't need them.

Looking at the classes again, right now, all I'm using is WorldZone and the Vector3 extension methods. WorldZone I can do without, if I had to. I could probably find a workaround to that one.

It'd be nice if the Vector3 extensions could be kept in somehow, or at least, if someone could show me how to write my own implementations of them, haha. Its not that I wouldn't be able to do those myself, its just my knowledge of the Vectors and coordinates is terrible.

EDIT: LMS, am I just blind, or are you sneaking guides into the forum without our knowledge?? 

http://www.lcpdfr.com/forums/topic/53516-vector3extension-class/ 

Edited August 4, 2015 by Stealth22

[LukeD 1,860]

 

It'd be nice if the Vector3 extensions could be kept in somehow, or at least, if someone could show me how to write my own implementations of them, haha.

 

Revived LMS' response to this from the old API Example thread:

http://www.lcpdfr.com/forums/topic/53516-vector3extension-class/#comment-350567

[Stealth22 804]

Revived LMS' response to this from the old API Example thread:

http://www.lcpdfr.com/forums/topic/53516-vector3extension-class/#comment-350567

Or you just hacked LMS' account AND went back in time to July 16 in the process!  

EDIT: While you're at it, do you think it would be worth splitting all of those old posts into a new thread? There was a lot of useful info in there for newbies.

Edited August 4, 2015 by Stealth22

[LukeD 1,860]

Or you just hacked LMS' account AND went back in time to July 16 in the process!  

Dinosaurs are known for their incredible hacking skills. And time travel.

Also I'll be going back through the old thread at some point and pulling out valuable resources to add to the API forums.

 

[LukeD 1,860]

I just thought I'd say that I've managed to eliminate all the unintended API functions from my mod, managed to find workarounds for all of them. The only ones I'm using now are from the vector3 extension and mod.api.

Thankyou for giving us a heads up about the others disappearing before removing them :) 

Good job, I hope it hasn't put you in too much of a difficult position. :)
Regarding Vector3 extensions see a few replies up I linked to the actual vector3 extensions file that you can take (LMS kindly uploaded it for us all), this will allow you to continue to use the vector3 extensions class even after LSPDFR makes it internal.

As for Mod.API that obviously stays....cause its the API :P

[Stealth22 804]

Good job, I hope it hasn't put you in too much of a difficult position. :)Regarding Vector3 extensions see a few replies up I linked to the actual vector3 extensions file that you can take (LMS kindly uploaded it for us all), this will allow you to continue to use the vector3 extensions class even after LSPDFR makes it internal.

As for Mod.API that obviously stays....cause its the API :P

Same here...I only needed WorldZone for the audio, really, but since I ditched NAudio, I didn't need it anymore. It was easier than I thought to switch to the API audio.

And yeah, I "borrowed" LMS' code for the Vector3 extension methods. 

[alexguirre 780]

I still need the WorldZone so some of my callouts, such as the illegal hunter, don't spawn in the middle of Los Santos. I will try to find a workaround 

[LukeD 1,860]

I still need the WorldZone so some of my callouts, such as the illegal hunter, don't spawn in the middle of Los Santos. I will try to find a workaround 

Not anywhere near as detailed as the world zones are but use the following to get the difference between Los Santos and Blaine County
From my minor testing it only returns 1 or the other:

ZONE::_GET_MAP_ZONE_AT_COORDS

Hashes: 0x7EE64D51E8498728 0xB5C5C99B

---

Hash _GET_MAP_ZONE_AT_COORDS(float x, float y, float z)
// 0x7EE64D51E8498728 0xB5C5C99B

---

Returns a hash representing which part of the map the given coords are located. Possible return values: ${city} ${countryside}

 

[alexguirre 780]

Not anywhere near as detailed as the world zones are but use the following to get the difference between Los Santos and Blaine CountyFrom my minor testing it only returns 1 or the other:

 

ZONE::_GET_MAP_ZONE_AT_COORDS

Hashes: 0x7EE64D51E8498728 0xB5C5C99B

---

Hash _GET_MAP_ZONE_AT_COORDS(float x, float y, float z)
// 0x7EE64D51E8498728 0xB5C5C99B

---

Returns a hash representing which part of the map the given coords are located. Possible return values: ${city} ${countryside}

 

 

OK, thanks. For what I want that's enough. I will implement it in my callouts as fast as possible 

[alexguirre 780]

Not anywhere near as detailed as the world zones are but use the following to get the difference between Los Santos and Blaine CountyFrom my minor testing it only returns 1 or the other:

I already implemented the worldzones . But the Persona I suppose it is going to public although it is in LSPD_First_Response.Engine.Scripting.Entities, am I right?

[LukeD 1,860]

I already implemented the worldzones . But the Persona I suppose it is going to public although it is in LSPD_First_Response.Engine.Scripting.Entities, am I right?

I'm not the best person to answer that however I would expect something similar would allow you access to Personas via the API. We had such functionality with the LCPDFR API at a later date so I would be surprised if it didn't return.

[alexguirre 780]

I'm not the best person to answer that however I would expect something similar would allow you access to Personas via the API. We had such functionality with the LCPDFR API at a later date so I would be surprised if it didn't return.

Looks like I still need the WorldZone  to get the RealAreaName. I trying to use the native GET_NAME_OF_ZONE but I can't get it to work, For what I need it, it isn't anything crucial so I can remove it if the WorldZone ends up been private

 

EDIT: now I no longer need the WorldZone, I made that function myself. 

Edited August 9, 2015 by alexguirre