Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Omanpx [1906686]

Don't think level is very relevant when it comes to attack info (when level holders are a thing), unless you are making a leveling list. Also not sure how many people pull that data alongside attack info. Sounds pretty specific for your use case and creates a bad precedence (what if i need their max hp or age?). 

Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Omanpx [1906686]

Don't think level is very relevant when it comes to attack info (when level holders are a thing), unless you are making a leveling list. Also not sure how many people pull that data alongside attack info. Sounds pretty specific for your use case and creates a bad precedence (what if i need their max hp or age?). 

Bardicer [553834]

Level is relevant in that level, attacker battle stats, defender battle stats, and fair fight multiplier all factor into respect gained.  The attack log gives all the information needed to calculate the fair fight, attacker/defender battle stats given two of the three.  To calculate the base respect gained, you also need the target's level.

 

Currently, you will need to pull the attack log, the attacker basic info, and the defender basic info to get everything you need to do this.  Since Torn limits API calls to 100 per minute due to server loads, this will reduce the needed server load to get this information by 2/3.  

 

I'm not sure of Torn's hosting solutions, but I would venture that 300 API calls would cost more than 100 API calls.  Doesn't sound like much right off the jump, but if you're trying to mine the information from even a 2500 chain, that could be 2500 API calls, or 7500 API calls.  Or a 10k chain, 10k API calls or 30k API calls.  For one faction.  If 100 factions did it for a 2500 chain, you'd be looking at the difference between 250,000 and 750,000 API calls.

 

Tl;dr - The information is available elsewhere, it is relevant to an attack (respect is level based), and it will be obtained.  I'm just looking at it as a change that will likely take 1 hour to do, and save the company money in the long-term.  Good ROI from a business standpoint, which is the best precedent there is.

Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Omanpx [1906686]

Don't think level is very relevant when it comes to attack info (when level holders are a thing), unless you are making a leveling list. Also not sure how many people pull that data alongside attack info. Sounds pretty specific for your use case and creates a bad precedence (what if i need their max hp or age?). 

Bardicer [553834]

Level is relevant in that level, attacker battle stats, defender battle stats, and fair fight multiplier all factor into respect gained.  The attack log gives all the information needed to calculate the fair fight, attacker/defender battle stats given two of the three.  To calculate the base respect gained, you also need the target's level.

 

Currently, you will need to pull the attack log, the attacker basic info, and the defender basic info to get everything you need to do this.  Since Torn limits API calls to 100 per minute due to server loads, this will reduce the needed server load to get this information by 2/3.  

 

I'm not sure of Torn's hosting solutions, but I would venture that 300 API calls would cost more than 100 API calls.  Doesn't sound like much right off the jump, but if you're trying to mine the information from even a 2500 chain, that could be 2500 API calls, or 7500 API calls.  Or a 10k chain, 10k API calls or 30k API calls.  For one faction.  If 100 factions did it for a 2500 chain, you'd be looking at the difference between 250,000 and 750,000 API calls.

 

Tl;dr - The information is available elsewhere, it is relevant to an attack (respect is level based), and it will be obtained.  I'm just looking at it as a change that will likely take 1 hour to do, and save the company money in the long-term.  Good ROI from a business standpoint, which is the best precedent there is.

Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Omanpx [1906686]

Don't think level is very relevant when it comes to attack info (when level holders are a thing), unless you are making a leveling list. Also not sure how many people pull that data alongside attack info. Sounds pretty specific for your use case and creates a bad precedence (what if i need their max hp or age?). 

Bardicer [553834]

Level is relevant in that level, attacker battle stats, defender battle stats, and fair fight multiplier all factor into respect gained.  The attack log gives all the information needed to calculate the fair fight, attacker/defender battle stats given two of the three.  To calculate the base respect gained, you also need the target's level.

 

Currently, you will need to pull the attack log, the attacker basic info, and the defender basic info to get everything you need to do this.  Since Torn limits API calls to 100 per minute due to server loads, this will reduce the needed server load to get this information by 2/3.  

 

I'm not sure of Torn's hosting solutions, but I would venture that 300 API calls would cost more than 100 API calls.  Doesn't sound like much right off the jump, but if you're trying to mine the information from even a 2500 chain, that could be 2500 API calls, or 7500 API calls.  Or a 10k chain, 10k API calls or 30k API calls.  For one faction.  If 100 factions did it for a 2500 chain, you'd be looking at the difference between 250,000 and 750,000 API calls.

 

Tl;dr - The information is available elsewhere, it is relevant to an attack (respect is level based), and it will be obtained.  I'm just looking at it as a change that will likely take 1 hour to do, and save the company money in the long-term.  Good ROI from a business standpoint, which is the best precedent there is.

tiksan [2383326]

I'm sure Ched would prefer spending less on bandwidth costs from unnecessary data in the HTTP response bodies.

Bardicer [553834]

Suggestion type:
 - Minor improvement

 - Optimization / Performance

What needs to be done:
 - Add attacker level and defender level to faction > attacks endpoint

Why do you need this:
 - Currently the attack log object has the attacker and defender: name, id, faction id, and faction name.  If you want to also get their level, you currently need to make two additional API calls to the user > basic endpoint, one for each participant, just to get their level.

Consider any drawbacks of your suggestion:

 - No real drawbacks, this is information that is already available in another endpoint, this suggestion just reduces the needed API calls by 66%, from 3 to 1.  Torn will likely save a little money.

Example:

 "attacks": {
            "123": {
                   "code": "a6032a48e3874f06ed004701511f5327",
                   "timestamp_started": 1725714474,
                   "timestamp_ended": 1725714475,
                   "attacker_id": 3269692,
                   "attacker_name": "Test1",
                   "attacker_faction": 36691,
                   "attacker_level": 100,
                   "attacker_factionname": "Rabid Chihuahuas",
                   "defender_id": 1785484,
                   "defender_name": "Test2",
                   "defender_faction": 16628,
                   "defender_factionname": "Chain Reaction",
                   "defender_level": 46,
                   "result": "Lost",
                   "stealthed": 0,
                   "respect": 0,
                   "chain": 0,
                   "raid": 0,
                   "ranked_war": 0,
                   "respect_gain": 0,
                   "respect_loss": 0,
                   "modifiers": {
                                "fair_fight": 1,
                                "war": 1,
                                "retaliation": 1,
                                "group_attack": 1,
                                "overseas": 1,
                                "chain_bonus": 1,
                   },
            }
}

Omanpx [1906686]

Don't think level is very relevant when it comes to attack info (when level holders are a thing), unless you are making a leveling list. Also not sure how many people pull that data alongside attack info. Sounds pretty specific for your use case and creates a bad precedence (what if i need their max hp or age?). 

Bardicer [553834]

Level is relevant in that level, attacker battle stats, defender battle stats, and fair fight multiplier all factor into respect gained.  The attack log gives all the information needed to calculate the fair fight, attacker/defender battle stats given two of the three.  To calculate the base respect gained, you also need the target's level.

 

Currently, you will need to pull the attack log, the attacker basic info, and the defender basic info to get everything you need to do this.  Since Torn limits API calls to 100 per minute due to server loads, this will reduce the needed server load to get this information by 2/3.  

 

I'm not sure of Torn's hosting solutions, but I would venture that 300 API calls would cost more than 100 API calls.  Doesn't sound like much right off the jump, but if you're trying to mine the information from even a 2500 chain, that could be 2500 API calls, or 7500 API calls.  Or a 10k chain, 10k API calls or 30k API calls.  For one faction.  If 100 factions did it for a 2500 chain, you'd be looking at the difference between 250,000 and 750,000 API calls.

 

Tl;dr - The information is available elsewhere, it is relevant to an attack (respect is level based), and it will be obtained.  I'm just looking at it as a change that will likely take 1 hour to do, and save the company money in the long-term.  Good ROI from a business standpoint, which is the best precedent there is.

tiksan [2383326]

I'm sure Ched would prefer spending less on bandwidth costs from unnecessary data in the HTTP response bodies.

Bardicer [553834]

You're right, I'm clearly wrong.  You have clearly been doing software engineering for several decades longer than I have.

 

I'll just make the extra API calls, after all, it's free for me. ^_^

Hemicopter [2780600]

Was looking at the new uniques data in the v2 user->crimes and saw this one (disposal)

 

 

2 things that I am confused about

 

 

First, what is a "type":3? I feel like that could be changed to a value that is less opaque. I assumed that this means that it is a certain special ammo, but that is false after I looked through the archives I have access to.

250x 5.45mm Rifle Round Incendiary ammunition

250x .44 Special Round Hollow Point ammunition 

 

Now I actually have no clue what "type":3 means lol

 

 

Second, does every ammo drop result in a random round type, or could there be an outcome where this will be a fixed value for everyone, like finding a rocket launcher and RPG ammo for it? This would not be possible in the current format

 

 

splent [2088243]

Hello everyone, 

I would like to have a dedicated thread for API suggestions & improvements.

It's not certain that all of the suggestions will be accepted & implemented, but if I'm not even aware of them, it won't be possible to even add them in the first place!

In order to make everything easier to discuss & potentially plan and implement, if you have a suggestion, follow the following format:

Suggestion type:
(Concisely categorize your suggestion/request)
 - New feature request
 - Minor improvement
 - General improvement (accross multiple endpoints)
 - Optimization/Performance improvement
 - Something else

What needs to be done:
(Shortly describe what needs to be done)
 - (e.g. for the new feature request) - add API to get forum threads & posts data
 - (e.g. for the minor improvement) - restructure user>personalstats section to have statistics categories
 - (e.g. for the general improvement) - change all 1 & 0 to true & false

Why do you need this:
(Back up your suggestion or request with some information on why do you need this change)
 - (e.g. for the new feature request above) - What @Omanpx wrote in another thread: It would create more opportunities for community-run events, such as this one.
 - (e.g. for the minor improvement above) - it would make much more sense if personal stats had sections like we currently have on statistics page - attacks, finishing hits, drugs, travel, etc...Maybe even rename fields so they're not called "cantaken" but instead "cannabis", etc.
 - (e.g. for the general improvement above) - it would be easier for my app to handle booleans than manually converting all zeroes and ones to boolean values.

Consider any drawbacks of your suggestion:

! Remember that API should not provide unfair advantage over players that are unable or don't know how to use the API. The primary goal of the API is to enhance gameplay and not to provide advantage.
 - (e.g. for the new feature request above) - This could be very heavy on the BE as there is lots of information on forums. It could be hard to properly implement this feature because results from private forums should be excluded/included depending on the user.
 - (e.g. for the minor improvement above) - No concerns for this improvement.
 - (e.g. for the general improvement above) - Requires thorough testing to make sure this change is applied to all endpoints.

Example:
(Finally, provide an example of the API change) 

{
    "posts": [

    {
        "thread_id": string,
        "post_id": string,
        "player_name": string,
        "player_id": number,
        "created_dt": string,
        "modified_dt": string,
        "content": string,
        "likes": number,
        "dislikes": number,

    },

    ...

    ]
}


---

Few things to note:
- In general api v2 will have all "ID" fields renamed. E.g. "ammoID" becomes "ammo_id", and all requests will follow the same naming convetion.
- Some other fields will also be renamed. E.g. "attacker_faction" becomes "attacker_faction_id" and "attacker_factionname" becomes "attacker_faction_name", etc.
- There will be some reconstructuring done overall. E.g. "personalstats" will really have fields renamed (like in the example above) and grouped into categories (drugs, attacks, finishing hits, travel, etc.)
- I'm looking to remove all key->value arrays, so the key will be a part of an object instead. E.g. [ "1": { ... }, "2": { ... } ] becomes [ { id: 1, ... }, { id: 2, ... } ]
- Please continue posting any relavant bugs to the Bugs & Issues forum.

Thank you,

Mauro

splent [2088243]

Hello everyone, 

I would like to have a dedicated thread for API suggestions & improvements.

It's not certain that all of the suggestions will be accepted & implemented, but if I'm not even aware of them, it won't be possible to even add them in the first place!

In order to make everything easier to discuss & potentially plan and implement, if you have a suggestion, follow the following format:

Suggestion type:
(Concisely categorize your suggestion/request)
 - New feature request
 - Minor improvement
 - General improvement (accross multiple endpoints)
 - Optimization/Performance improvement
 - Something else

What needs to be done:
(Shortly describe what needs to be done)
 - (e.g. for the new feature request) - add API to get forum threads & posts data
 - (e.g. for the minor improvement) - restructure user>personalstats section to have statistics categories
 - (e.g. for the general improvement) - change all 1 & 0 to true & false

Why do you need this:
(Back up your suggestion or request with some information on why do you need this change)
 - (e.g. for the new feature request above) - What @Omanpx wrote in another thread: It would create more opportunities for community-run events, such as this one.
 - (e.g. for the minor improvement above) - it would make much more sense if personal stats had sections like we currently have on statistics page - attacks, finishing hits, drugs, travel, etc...Maybe even rename fields so they're not called "cantaken" but instead "cannabis", etc.
 - (e.g. for the general improvement above) - it would be easier for my app to handle booleans than manually converting all zeroes and ones to boolean values.

Consider any drawbacks of your suggestion:

! Remember that API should not provide unfair advantage over players that are unable or don't know how to use the API. The primary goal of the API is to enhance gameplay and not to provide advantage.
 - (e.g. for the new feature request above) - This could be very heavy on the BE as there is lots of information on forums. It could be hard to properly implement this feature because results from private forums should be excluded/included depending on the user.
 - (e.g. for the minor improvement above) - No concerns for this improvement.
 - (e.g. for the general improvement above) - Requires thorough testing to make sure this change is applied to all endpoints.

Example:
(Finally, provide an example of the API change) 

{
    "posts": [

    {
        "thread_id": string,
        "post_id": string,
        "player_name": string,
        "player_id": number,
        "created_dt": string,
        "modified_dt": string,
        "content": string,
        "likes": number,
        "dislikes": number,

    },

    ...

    ]
}


---

Few things to note:
- In general api v2 will have all "ID" fields renamed. E.g. "ammoID" becomes "ammo_id", and all requests will follow the same naming convetion.
- Some other fields will also be renamed. E.g. "attacker_faction" becomes "attacker_faction_id" and "attacker_factionname" becomes "attacker_faction_name", etc.
- There will be some reconstructuring done overall. E.g. "personalstats" will really have fields renamed (like in the example above) and grouped into categories (drugs, attacks, finishing hits, travel, etc.)
- I'm looking to remove all key->value arrays, so the key will be a part of an object instead. E.g. [ "1": { ... }, "2": { ... } ] becomes [ { id: 1, ... }, { id: 2, ... } ]
- Please continue posting any relavant bugs to the Bugs & Issues forum.

Thank you,

Mauro

DieselBlade [1701621]

What is the current lead time for these suggestions?

 

Will all of these suggestions make it into the API? If not, which ones?

 

It would be great if you could communicate somewhere what suggestions you like and what ones you're going to implement. Perhaps a list on the first post?

 

Otherwise, we're making suggestions to make our own scripts and bots more functional but we don't know if they will ever be implemented. 

splent [2088243]

Hello everyone, 

I would like to have a dedicated thread for API suggestions & improvements.

It's not certain that all of the suggestions will be accepted & implemented, but if I'm not even aware of them, it won't be possible to even add them in the first place!

In order to make everything easier to discuss & potentially plan and implement, if you have a suggestion, follow the following format:

Suggestion type:
(Concisely categorize your suggestion/request)
 - New feature request
 - Minor improvement
 - General improvement (accross multiple endpoints)
 - Optimization/Performance improvement
 - Something else

What needs to be done:
(Shortly describe what needs to be done)
 - (e.g. for the new feature request) - add API to get forum threads & posts data
 - (e.g. for the minor improvement) - restructure user>personalstats section to have statistics categories
 - (e.g. for the general improvement) - change all 1 & 0 to true & false

Why do you need this:
(Back up your suggestion or request with some information on why do you need this change)
 - (e.g. for the new feature request above) - What @Omanpx wrote in another thread: It would create more opportunities for community-run events, such as this one.
 - (e.g. for the minor improvement above) - it would make much more sense if personal stats had sections like we currently have on statistics page - attacks, finishing hits, drugs, travel, etc...Maybe even rename fields so they're not called "cantaken" but instead "cannabis", etc.
 - (e.g. for the general improvement above) - it would be easier for my app to handle booleans than manually converting all zeroes and ones to boolean values.

Consider any drawbacks of your suggestion:

! Remember that API should not provide unfair advantage over players that are unable or don't know how to use the API. The primary goal of the API is to enhance gameplay and not to provide advantage.
 - (e.g. for the new feature request above) - This could be very heavy on the BE as there is lots of information on forums. It could be hard to properly implement this feature because results from private forums should be excluded/included depending on the user.
 - (e.g. for the minor improvement above) - No concerns for this improvement.
 - (e.g. for the general improvement above) - Requires thorough testing to make sure this change is applied to all endpoints.

Example:
(Finally, provide an example of the API change) 

{
    "posts": [

    {
        "thread_id": string,
        "post_id": string,
        "player_name": string,
        "player_id": number,
        "created_dt": string,
        "modified_dt": string,
        "content": string,
        "likes": number,
        "dislikes": number,

    },

    ...

    ]
}


---

Few things to note:
- In general api v2 will have all "ID" fields renamed. E.g. "ammoID" becomes "ammo_id", and all requests will follow the same naming convetion.
- Some other fields will also be renamed. E.g. "attacker_faction" becomes "attacker_faction_id" and "attacker_factionname" becomes "attacker_faction_name", etc.
- There will be some reconstructuring done overall. E.g. "personalstats" will really have fields renamed (like in the example above) and grouped into categories (drugs, attacks, finishing hits, travel, etc.)
- I'm looking to remove all key->value arrays, so the key will be a part of an object instead. E.g. [ "1": { ... }, "2": { ... } ] becomes [ { id: 1, ... }, { id: 2, ... } ]
- Please continue posting any relavant bugs to the Bugs & Issues forum.

Thank you,

Mauro

DieselBlade [1701621]

What is the current lead time for these suggestions?

 

Will all of these suggestions make it into the API? If not, which ones?

 

It would be great if you could communicate somewhere what suggestions you like and what ones you're going to implement. Perhaps a list on the first post?

 

Otherwise, we're making suggestions to make our own scripts and bots more functional but we don't know if they will ever be implemented. 

splent [2088243]

Hey, that's a great point. Most of the suggestions will get implemented as they're very reasonable requests.

 

There are a few that could not really be easily implemented and are on hold for now. 

Here's the current status of suggestions:

Already done:

• ✅ Player revivable status
• ✅ Crimes data
• ✅ Calendar
• ✅ Racing data
• ✅ Forum data
• ✅ Hall of Fame
• ✅ Log type IDs within each log category ID
• ✅ Bounties
• ✅ Player rank in city jobs 
  
  

Will be added (soon™) or already work in progress:

• Choose between non-html & html for various selections (WIP)
• Add early discharge, is on wall to 'faction' -> 'members'
• Item UID’s added across faction endpoints
• Inventory
• Change 'signup' in 'user > profile' to timestamp
• Reverse name searches 
• Company employee value (with secretary)
• Historical API key usage
• Remaining API calls 
• Current bank investment info
• Attacklog endpoint to the API
• Auction house 
• Faction enlistment status 
• Completed trades

 

And those that are currently on hold because they're either not easily implementable (would require substantial work) or some concerns exist: 

• Item UID’s addded to market>bazaar and market>itemmarket (concern: could be very easy to track RW sales and owners -> mugging bots?)
• Add 'rankedwarassists' to public stats (comment: unsure if this one is necessary?)
• Support for IPv6 access to the Torn API (comment: out of my current scope)
• Change 'User' -> 'Bazaar' to require limited access API (unlikely: there's already a global 30s delay unless requesting information for other bazaars)
• Paginated list of all users and factions (unlikely, although not set in stone on this one yet)
• Daily active users tarball (concern: company/faction recruiters would use it to spam people to oblivion)
• OAUTH2 (gladly, but requires a lot of work. Maybe once everything else is done in v2)
• Bookie bets (concern: some players might become mugging targets. Maybe with a full-access key, but not a priority)w
• Add 'faction' -> 'armorynewsfull' (unfortunately, I can't provide the data in the desired format. The 'armorynews' selection is just a API copy of Armory News on the faction page, so I would need to parse the logs to provide the data in that format)

 

splent [2088243]

Hello everyone, 

I would like to have a dedicated thread for API suggestions & improvements.

It's not certain that all of the suggestions will be accepted & implemented, but if I'm not even aware of them, it won't be possible to even add them in the first place!

In order to make everything easier to discuss & potentially plan and implement, if you have a suggestion, follow the following format:

Suggestion type:
(Concisely categorize your suggestion/request)
 - New feature request
 - Minor improvement
 - General improvement (accross multiple endpoints)
 - Optimization/Performance improvement
 - Something else

What needs to be done:
(Shortly describe what needs to be done)
 - (e.g. for the new feature request) - add API to get forum threads & posts data
 - (e.g. for the minor improvement) - restructure user>personalstats section to have statistics categories
 - (e.g. for the general improvement) - change all 1 & 0 to true & false

Why do you need this:
(Back up your suggestion or request with some information on why do you need this change)
 - (e.g. for the new feature request above) - What @Omanpx wrote in another thread: It would create more opportunities for community-run events, such as this one.
 - (e.g. for the minor improvement above) - it would make much more sense if personal stats had sections like we currently have on statistics page - attacks, finishing hits, drugs, travel, etc...Maybe even rename fields so they're not called "cantaken" but instead "cannabis", etc.
 - (e.g. for the general improvement above) - it would be easier for my app to handle booleans than manually converting all zeroes and ones to boolean values.

Consider any drawbacks of your suggestion:

! Remember that API should not provide unfair advantage over players that are unable or don't know how to use the API. The primary goal of the API is to enhance gameplay and not to provide advantage.
 - (e.g. for the new feature request above) - This could be very heavy on the BE as there is lots of information on forums. It could be hard to properly implement this feature because results from private forums should be excluded/included depending on the user.
 - (e.g. for the minor improvement above) - No concerns for this improvement.
 - (e.g. for the general improvement above) - Requires thorough testing to make sure this change is applied to all endpoints.

Example:
(Finally, provide an example of the API change) 

{
    "posts": [

    {
        "thread_id": string,
        "post_id": string,
        "player_name": string,
        "player_id": number,
        "created_dt": string,
        "modified_dt": string,
        "content": string,
        "likes": number,
        "dislikes": number,

    },

    ...

    ]
}


---

Few things to note:
- In general api v2 will have all "ID" fields renamed. E.g. "ammoID" becomes "ammo_id", and all requests will follow the same naming convetion.
- Some other fields will also be renamed. E.g. "attacker_faction" becomes "attacker_faction_id" and "attacker_factionname" becomes "attacker_faction_name", etc.
- There will be some reconstructuring done overall. E.g. "personalstats" will really have fields renamed (like in the example above) and grouped into categories (drugs, attacks, finishing hits, travel, etc.)
- I'm looking to remove all key->value arrays, so the key will be a part of an object instead. E.g. [ "1": { ... }, "2": { ... } ] becomes [ { id: 1, ... }, { id: 2, ... } ]
- Please continue posting any relavant bugs to the Bugs & Issues forum.

Thank you,

Mauro

DieselBlade [1701621]

What is the current lead time for these suggestions?

 

Will all of these suggestions make it into the API? If not, which ones?

 

It would be great if you could communicate somewhere what suggestions you like and what ones you're going to implement. Perhaps a list on the first post?

 

Otherwise, we're making suggestions to make our own scripts and bots more functional but we don't know if they will ever be implemented. 

splent [2088243]

Hey, that's a great point. Most of the suggestions will get implemented as they're very reasonable requests.

 

There are a few that could not really be easily implemented and are on hold for now. 

Here's the current status of suggestions:

Already done:

• ✅ Player revivable status
• ✅ Crimes data
• ✅ Calendar
• ✅ Racing data
• ✅ Forum data
• ✅ Hall of Fame
• ✅ Log type IDs within each log category ID
• ✅ Bounties
• ✅ Player rank in city jobs 
  
  

Will be added (soon™) or already work in progress:

• Choose between non-html & html for various selections (WIP)
• Add early discharge, is on wall to 'faction' -> 'members'
• Item UID’s added across faction endpoints
• Inventory
• Change 'signup' in 'user > profile' to timestamp
• Reverse name searches 
• Company employee value (with secretary)
• Historical API key usage
• Remaining API calls 
• Current bank investment info
• Attacklog endpoint to the API
• Auction house 
• Faction enlistment status 
• Completed trades

 

And those that are currently on hold because they're either not easily implementable (would require substantial work) or some concerns exist: 

• Item UID’s addded to market>bazaar and market>itemmarket (concern: could be very easy to track RW sales and owners -> mugging bots?)
• Add 'rankedwarassists' to public stats (comment: unsure if this one is necessary?)
• Support for IPv6 access to the Torn API (comment: out of my current scope)
• Change 'User' -> 'Bazaar' to require limited access API (unlikely: there's already a global 30s delay unless requesting information for other bazaars)
• Paginated list of all users and factions (unlikely, although not set in stone on this one yet)
• Daily active users tarball (concern: company/faction recruiters would use it to spam people to oblivion)
• OAUTH2 (gladly, but requires a lot of work. Maybe once everything else is done in v2)
• Bookie bets (concern: some players might become mugging targets. Maybe with a full-access key, but not a priority)w
• Add 'faction' -> 'armorynewsfull' (unfortunately, I can't provide the data in the desired format. The 'armorynews' selection is just a API copy of Armory News on the faction page, so I would need to parse the logs to provide the data in that format)

 

DieselBlade [1701621]

That's great. Thank you.

 

I see you pinned the response. Will you keep that post updated?

 

Will likely help with preventing duplicate suggestions as well.

 

I'm glad all suggestions are being considered.

I wish Torn suggestions worked the same way lol

CurlyBracket [2766476]

I posted an individual thread about this, but I guess it might should go here:

 

Add user life to faction members array

 

Suggestion type:

  I'd call it a minor improvement

What needs to be done:
  Include the life blob that comes back in user responses in the faction members array (along with the existing last_action and status blobs)

Why do you need this:
  life, in particular the current life, is a key part of a person's 'status' and so if you're tracking a faction's status, it is important to know that.  Including it along with the other status data would prevent the need to make N individual user calls to get this data.

Consider any drawbacks of your suggestion:

  I could imagine there may be some additional DB load, though the fact that faction responses already include the last_action and status data for every member, I would think this wouldn't be much more load.  I don't think it creates an unfair advantage for anyone, since with a couple of api keys, it is currently possible to make the additional N user calls as often as you make the faction call. 

CurlyBracket [2766476]

I posted an individual thread about this, but I guess it might should go here:

 

Add user life to faction members array

 

Suggestion type:

  I'd call it a minor improvement

What needs to be done:
  Include the life blob that comes back in user responses in the faction members array (along with the existing last_action and status blobs)

Why do you need this:
  life, in particular the current life, is a key part of a person's 'status' and so if you're tracking a faction's status, it is important to know that.  Including it along with the other status data would prevent the need to make N individual user calls to get this data.

Consider any drawbacks of your suggestion:

  I could imagine there may be some additional DB load, though the fact that faction responses already include the last_action and status data for every member, I would think this wouldn't be much more load.  I don't think it creates an unfair advantage for anyone, since with a couple of api keys, it is currently possible to make the additional N user calls as often as you make the faction call. 

splent [2088243]

Hey, this was already added very recently: 

https://www.torn.com/swagger/index.html#/Faction/get_faction__selections_members

https://api.torn.com/v2/faction/?selections=members&key= 

It was done as part of these changes: https://www.torn.com/forums.php#/p=threads&f=63&t=16401584&b=0&a=0&start=160&to=25110548 

Thanks!

Uras_R34 [2808072]

Any chance for get info about the completed trades?