Using the LCPDFR.com web API to get fileID's.

[BrendenI 177]

So i'm just marking a small LSPDFR plugin update checker in Python for personal use, and i'm wondering if it's possible to use the LSPDFR web API to get fileID's based on the name of the plugin.

 

I realize how scuffed it sounds, but i'm not too sure how I would get the fileID of a plugin based on the name of it.

 

I'm fairly new to Python, so bare with me... 

 

Laugh all you want, but currently the way i'm obtaining plugins is through the RAGEPluginHook.log file lol. The reason for this scuffed approach is because i'm actually planning to put this into use for other people's games, using the RAGE logs they provide.

 

Everything is working smooth, the only hiccup is getting the current version of the plugin using the LSPDFr API. I know of this endpoint, but I just don't know how to use it with ID's and such, and hardcoding the ID's of popular plugins would kinda suck :\.

 

Attached is what info I have right now, this info is solely parsed from the RAGE log of my LSPDFR install.

 

Thanks, and sorry for my ignorance.  

Edited August 5, 2022 by DarkVypr

[Cyan 4862]

Hey DarkVypr,

 

the use case of the LSPDFR update checking API is aimed at plugin developers to use the service to check for updates in the context of their running modification.

Whilst your use case differs, this should be fine, but if you are already hardcoding the names of the plugins, is there much difference in also hardcoding the ID? The ID is generally guaranteed to not change, unless the author completely reuploads their file.

 

You should also note that some plugins' assembly versions differs from the version that they advertise on the site. The best example is probably, ironically, LSPDFR itself.

[BrendenI 177]

7 hours ago, Cyan said:

Hey DarkVypr,

 

the use case of the LSPDFR update checking API is aimed at plugin developers to use the service to check for updates in the context of their running modification.

Whilst your use case differs, this should be fine, but if you are already hardcoding the names of the plugins, is there much difference in also hardcoding the ID? The ID is generally guaranteed to not change, unless the author completely reuploads their file.

 

You should also note that some plugins' assembly versions differs from the version that they advertise on the site. The best example is probably, ironically, LSPDFR itself.

Yea this seems like really the only good way to do it. It sucks because i'll have to manually update the versions, but I'll get by.

 

This is what I was assuming, and it makes sense why it would be like this:

7 hours ago, Cyan said:

the use case of the LSPDFR update checking API is aimed at plugin developers to use the service to check for updates

 

Thanks for the response Cyan! Have a good one. Off to JSON land I go...

 

Edit: Shit im stupid. I just have to hardcode the ID's not the versions. That's not so bad lol.

Edited August 7, 2022 by DarkVypr