20 replies · 350 views · thread synced · 5 days ago
· View on torn.com
About this thread
Posts archived:21 / 21 posts (100%) · the total is Torn's reply count + the opening post at the last fetch
Counted by TornLife from the archived posts.
Archived posts
21
Discussion span
→
Authority score
61 / 100
Historical score
40 / 100
Story score
48 / 100
Engagement score
65 / 100
People posting, likes and official posts are not counted for this thread yet: on threads longer than one page they come from a periodic pass over the archive, which has not covered it.
Most-liked replies
Chedburn[1]Admin
· 5 likes · Actually maybe this is preferable... [image: i.gyazo.com]
Chedburn[1]Admin
· 3 likes · I expect I can simply show all faction stats (that are required for challenges) in a single faction API request. hosps { [total] = 1234 [user1] = 111 [user2] = 222 [user3] = 333 } Could work? And hopefully minimal …
Chedburn[1]Admin
· 2 likes · All of these will be available via 'faction' => 'contributions' on the 14th Jan. Can use '&stat=X' to grab the one you want. However, the caching system may immediately break it when it's live, we'll have to see. medicalitemsused criminaloffences …
(API requests are fine to directly make a bug report right?)
I want to pull the steadfast information, for current members (So it does need to return if they are a current member or not) That way, I (or DocTorn, and other scripts) can add the 4 stats together. Currently, in order to do this it would need 4 non-api requests because this information is not all loaded on the page refresh.
I was wondering if you could add this data into the API. (See screenshot below)
I guess it isn’t, makes our side of development easier, but I understand. We can pull the faction member list in a separate call and do the checks ourselves.
You can do a workaround by pulling a list of current faction members. then join that list to the DocTorn export.
You can join the two tables with an inner join in a database, or in Excel you can do a VLOOKUP of current member IDs on the Doctorn list.
Bottom line, unless you're doing something requiring millions of API calls, the 100-per-minute constraint will still allow you to process data quickly. One thousand calls can be done in just over 10 minutes. Embed a SLEEP call in your code to ensure you are maintaining a steady rate of 95-98 calls per minute and Bob's your uncle.
Let me know if you need help on the development side. I'm all for expanding API capabilities if it provides value, but for developer convenience there's usually a way to deal with it as-is.
I actually would've preferred it without the `in_faction` since it's easily cross-referenceable with `basic` in a single call, but yeah, option 2 for me too.