Weapons

[StoneMasons4106]

So I actually had the DRG API idea a while ago, glad someone actually did it lol.

Have you thought about including weapons, builds, overclocks and the like?

If so, I'd be happy to offer my assistance and contribute as needed. :)

[MoritzHayden]

Glad you're getting value from it!

I've played with the idea of having weapon and overclock data, but never moved forward with it due to the ever-changing nature of stats as the game devs make tweaks and additions.

I know the folks at karl.gg have a bunch of .php and .sql files which they use to populate their database, and they serve up that data via a GraphQL API. The data in those files could be transformed into JSON and served up via this API as well, but it might be a duplicate effort.

What do you envision the request and response looking like if this data got added to DRG API, and what's your use case for it?

[StoneMasons4106]

I had no idea that karl.gg already had something like that already in place, though it would make sense, and it would mean less maintainability on your end.

I guess I envisioned Bosco being able to provide weapon stats on the fly without having to go into karl.gg or the game itself. Something like /build class:[class] weapon:[weapon] build:[build]. The build argument would be in the traditional 5 number format I think a lot of us have gotten used to using, 23221 for example.

Of course if karl.gg already has a GraphQL API then the response could in theory just come from them and the weapon stats provided could be formatted for Discord. Just a thought

[MoritzHayden]

I could see that being useful!

I think there would be a slight advantage of having the data in DRG API itself, just because it would reduce the points of failure and the data is relatively static anyways.

I guess the first step would probably be to settle on a JSON schema for the weapon/overclock/build data. There could potentially be two new API endpoints for DRG API to serve the data: one which takes no parameters and returns the complete data, and one which takes class, weapon, and build parameters and returns stats for that specific configuration. I think adding the latter endpoint would help with offloading some of the processing from Bosco and other downstream services. Once the schema and new endpoint(s) are ready, a new /build or /stats command can be added to Bosco which consumes the new endpoint(s).

[StoneMasons4106]

Yeah that makes a ton of sense.

I wonder if you could even build in a command/function to automatically pull and update the data from karl.gg so that when the data is updated, it's a one click auto-update and it would make maintainability easy.

Schema could look something like this on a high level:
{ "class": "Gunner": { "weapon": "Autocannon", "base_stats": { ... }, "t1": { "1": { ... }, "2": { ... }, "3": { ... }, }, "t2": { "1": { ... }, "2": { ... }, "3": { ... }, }, "t3": { "1": { ... }, "2": { ... }, "3": { ... }, }, "t4": { "1": { ... }, "2": { ... }, "3": { ... }, }, "t5": { "1": { ... }, "2": { ... }, "3": { ... }, }, "overclocks": { ... }, }, }