These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

EVE API and Public CREST discussion

First post First post First post
Author
Previous Topic Next Topic
CCP FoxFour
C C P
C C P Alliance
#21 - 2014-03-25 12:45:23 UTC
Made some updates to the backlog based off some quick review. Mainly adding things that looked like they would be low hanging fruit if you will.

There is lots of stuff I still need to review in more detail and have a think about, so just because I didn't add your request doesn't mean it's being tossed.

Some general comments:

  • indizies on null-sec systems: will poke around and ask some people how they feel
  • sovereignty contested info: again will ask around
  • live market data: not right now
  • aggregate market data: hmmmm at this point seems a bit of a low use-case, would rather do things more people will use
  • dust map: I added to the list... but not really sure why you guys want it so bad since it's optimized for SD TVs
  • nearest celestial in locations: don't think thats stored in the DB, so not really possible
  • invalidIDs causing whole request to DIAF: please give me a list of all the locations this happens

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Desmont McCallock
#22 - 2014-03-25 13:09:06 UTC
Idea: SenderName in char/Notifications
Description: Same use as in MailMessages.
CCP FoxFour
C C P
C C P Alliance
#23 - 2014-03-25 13:25:25 UTC
Desmont McCallock wrote:
Idea: SenderName in char/Notifications
Description: Same use as in MailMessages.


If we give the ID I see no reason not to denormalize it.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Max Kolonko
Caldari Provisions
Caldari State
#24 - 2014-03-25 13:34:22 UTC
CCP FoxFour wrote:
Desmont McCallock wrote:
Idea: SenderName in char/Notifications
Description: Same use as in MailMessages.


If we give the ID I see no reason not to denormalize it.


Idea: denormalize everything \o/ - just kidding, but would love to have all names everywhere id of corp,character,item,etc pops up - it would have a big toll on sent data. But still its my dream to have this

Read and support: Don't mess with OUR WH's What is Your stance on WH stuff?
CCP FoxFour
C C P
C C P Alliance
#25 - 2014-03-25 13:40:46 UTC
Max Kolonko wrote:
CCP FoxFour wrote:
Desmont McCallock wrote:
Idea: SenderName in char/Notifications
Description: Same use as in MailMessages.


If we give the ID I see no reason not to denormalize it.


Idea: denormalize everything \o/ - just kidding, but would love to have all names everywhere id of corp,character,item,etc pops up - it would have a big toll on sent data. But still its my dream to have this


Working on it, considering how much we have reduced load on the API servers recently I think we can afford to add a bit of extra data.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
pmchem
Brutor Tribe
Minmatar Republic
#26 - 2014-03-25 16:12:10 UTC
Since we're talking API stuff, two things stand out to me in relation to popular goonfleet tools:

1. We have a program, GarpaUI, which essentially copies the account/character settings from one acct/char to others. There used to be an API which returned userID ( https://wiki.eveonline.com/en/wiki/EVE_API_Account_Status ) but that was apparently stealth changed. It is difficult for a third party to robustly associate a "character" settings file with a specific "user" settings file. That would be very easy if a vcode/API let you give charid of all chars associated with a specific userid.

Then, in our app, we could have the user enter said vcode and they would be able to more easily determine which account settings file to copy over the other account settings files, so that their selected accts/chars had identical client settings.

Sorry for the short description but we'll have a public release of this tool soon, so you'll get to see it in action.


2. Market data, but specifically not just 'history' but all market orders in a region for all items. IT WOULD BE OKAY IF THESE WERE TIME DELAYED, so that the API was, say, a few hours out of date. That would combat possible abuse cases. But we need accurate market data for a nullsec import guide ( http://goonmetrics.com ) which many people in GSF/CFC use. Right now we rely on a data uploader that we actually created before the Eve Market Data Relay (EMDR) existed. A good CREST market order API would obsolete both our uploader and EMDR and let CCP continue with what appears to be their long term goal in altering what's in the client cache.

https://twitter.com/pmchem/ || http://community.eveonline.com/news/dev-blogs/community-spotlight-garpa/ || Goonswarm Economic Warfare Cabal
CCP FoxFour
C C P
C C P Alliance
#27 - 2014-03-25 16:18:07 UTC
pmchem wrote:
Since we're talking API stuff, two things stand out to me in relation to popular goonfleet tools:

1. We have a program, GarpaUI, which essentially copies the account/character settings from one acct/char to others. There used to be an API which returned userID ( https://wiki.eveonline.com/en/wiki/EVE_API_Account_Status ) but that was apparently stealth changed. It is difficult for a third party to robustly associate a "character" settings file with a specific "user" settings file. That would be very easy if a vcode/API let you give charid of all chars associated with a specific userid.

Then, in our app, we could have the user enter said vcode and they would be able to more easily determine which account settings file to copy over the other account settings files, so that their selected accts/chars had identical client settings.

Sorry for the short description but we'll have a public release of this tool soon, so you'll get to see it in action.


2. Market data, but specifically not just 'history' but all market orders in a region for all items. IT WOULD BE OKAY IF THESE WERE TIME DELAYED, so that the API was, say, a few hours out of date. That would combat possible abuse cases. But we need accurate market data for a nullsec import guide ( http://goonmetrics.com ) which many people in GSF/CFC use. Right now we rely on a data uploader that we actually created before the Eve Market Data Relay (EMDR) existed. A good CREST market order API would obsolete both our uploader and EMDR and let CCP continue with what appears to be their long term goal in altering what's in the client cache.


We will NOT be adding user IDs back. Sorry, but it is just not happening.

As for the market data, hopefully at some point in the future yes, we would love to add market orders to CREST. It's something we are talking about internally and discussing the hows, whens, and whys of doing it.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Crasniya
The Aussienauts
#28 - 2014-03-25 17:21:38 UTC  |  Edited by: Crasniya
You knew this was coming from me, FoxFour:

Idea: Add DUST leaderboard data to MemberTracking for legacy corp APIs or just allow a CREST endpoint to query it.
Description: Leaderboard stats are completely public in the DUST client, as you can add any user to contacts and then see their leaderboard data. However, the system for viewing this in-game is kludgy, since you can't get it in Show Info. Also, looking at it on the aggregate is very hard, due to scale. Leaderboard sites, and alliance and corp-specific leaderboards would be vastly improved if there was a way to query this. MemberTracking would restrict the feature to corps, if an outright public query is too large to deal with or there's game reasons not to make it that easy to pull that much data on unaffiliated parties out of the client. DUST players' stats have a large part of corp eligibility and demonstrating of activity in-game.

Soraya Xel - Council of Planetary Management 1 - soraya@biomassed.net
pmchem
Brutor Tribe
Minmatar Republic
#29 - 2014-03-25 18:07:14 UTC
CCP FoxFour wrote:

We will NOT be adding user IDs back. Sorry, but it is just not happening.

As for the market data, hopefully at some point in the future yes, we would love to add market orders to CREST. It's something we are talking about internally and discussing the hows, whens, and whys of doing it.


Hey, sounds good. Could you guys at least update the API documentation on evelopedia with respect to userid? Because, well, that was annoying to discover.

I'd like to advocate for some way to sync settings between chars/accounts done by CCP itself or the client install. I dislike having to maintain a third party utility so that our multi boxers don't hate their lives after a windows/EVE reinstall or major EVE patches, etc etc. Brought this up in person at a fanfest event last year (on video, even) and there was a very positive reception and promise to look into it. It was also the most-upvoted suggestion in the CSM's 'crowdsourcing' last year but mysteriously did not make their actual list. I know it's not your department but you gotta understand where I'm coming from with that userid suggestion.

I look forward to the expansion of CREST. Thanks and good luck.

https://twitter.com/pmchem/ || http://community.eveonline.com/news/dev-blogs/community-spotlight-garpa/ || Goonswarm Economic Warfare Cabal
Innominate
KarmaFleet
Goonswarm Federation
#30 - 2014-03-25 19:24:04 UTC
CCP FoxFour wrote:

  • invalidIDs causing whole request to DIAF: please give me a list of all the locations this happens


    • After doing actual research it looks like locations are the only place it'd make a difference. While it seems to apply to mailbodies and notificationtexts as well, these shouldn't have the same nonexistent ID issues that locations does.

    "/corp/locations.xml.aspx"
    "/char/locations.xml.aspx"

    "/char/mailbodies.xml.aspx"
    "/char/notificationtexts.xml.aspx"
    Zifrian
    Federal Defense Union
    Gallente Federation
    #31 - 2014-03-25 20:37:47 UTC  |  Edited by: Zifrian
    Idea: Update that AssetList.xml API to return material level and production level for blueprints in assets.

    Description: Many industry applications, asset tracking programs and personal spreadsheets query blueprints but no information is provided on the attributes of the blueprint to use for production calculations - thus, requiring manual updates. Furthermore, the in game copy and paste functionality is more cumbersome than typical asset copy/paste as it also does not contain this information unless opening a new window through the industry interface. Other than manually updating info or the cut/paste method, the only other way to get bp data is to pull from the industry jobs API, which isn't complete and becomes almost useless when using corp pos labs because all jobs are corp and not personal.

    Alternative to the above idea:

    Idea: Add a new API for blueprint only data.

    Description: The asset API does what it says, it provides information on assets, which include blueprints. However, updating the assets API for blueprints doesn't fit because all assets do not have bp type attributes. Since blueprints in game are managed through the industry interface, it makes more sense to repeat the blueprint information contained there in its own API instead of altering the asset API. Furthermore, given the issues with changing information to show different icons for bp copies, any update to the AssetList API May be a bridge too far to cross. This change would provide a mirror to in game data and also solve the problems stated above wrt bp dat in third party apps.

    Maximze your Industry Potential! - Download EVE Isk per Hour!

    Import CCP's SDE - EVE SDE Database Builder
    RusEVERadio
    RusEVERadio Corporation
    #32 - 2014-03-26 06:27:50 UTC
    CCP FoxFour wrote:
    Music listened to while making this post:


    Will update the list as I make posts. :)

    Amazing! CCP FoxFour listening music of russian DJ"s.


    RusEVERadio - Russian EVE Online voice @RusEVERadio - twitter Our website. News, good music and spaceships
    CCP FoxFour
    C C P
    C C P Alliance
    #33 - 2014-03-26 11:44:20 UTC
    Added faction and alliance information to the API on sisi for account/APIKeyInfo: http://api.testeveonline.com/account/APIKeyInfo.xml.aspx

    @CCP_FoxFour // Technical Designer // Team Tech Co

    Third-party developer? Check out the official developers site for dev blogs, resources, and more.
    Desmont McCallock
    #34 - 2014-03-26 18:41:11 UTC  |  Edited by: Desmont McCallock
    CCP FoxFour wrote:
    Added faction and alliance information to the API on sisi for account/APIKeyInfo: http://api.testeveonline.com/account/APIKeyInfo.xml.aspx
    Great. Looks like my changes for the FW endpoint is working as expected. As soon as this hits TQ I'm gonna release a new version.

    Btw,
    Defect: MailMessages on SiSi
    Description: Calling MailMessages on SiSi returns 503 with error xml body of error code 1001 (Cache is invalid).
    CCP FoxFour
    C C P
    C C P Alliance
    #35 - 2014-03-27 08:45:01 UTC
    Added senderName to char/Notifications and removed accountKey 10000 from char/AccountBalance

    Availible for testing on Sisi.

    @CCP_FoxFour // Technical Designer // Team Tech Co

    Third-party developer? Check out the official developers site for dev blogs, resources, and more.
    CCP FoxFour
    C C P
    C C P Alliance
    #36 - 2014-03-27 08:46:13 UTC
    Also, this site should work: http://community.testeveonline.com/support/api-key

    To generate an API key for testing on Sisi.

    @CCP_FoxFour // Technical Designer // Team Tech Co

    Third-party developer? Check out the official developers site for dev blogs, resources, and more.
    CCP FoxFour
    C C P
    C C P Alliance
    #37 - 2014-03-27 09:15:43 UTC  |  Edited by: CCP FoxFour
    All seems to be good, so going to deploy these changes to TQ during DT today. :D


    • faction and alliance info in the account/APIKeyInfo endpoint
    • senderName in the char/Notifications endpoint
    • fix for accountKey 10000 showing up in char/AccountBalance

    @CCP_FoxFour // Technical Designer // Team Tech Co

    Third-party developer? Check out the official developers site for dev blogs, resources, and more.
    CCP FoxFour
    C C P
    C C P Alliance
    #38 - 2014-03-27 11:15:11 UTC
    Deployment done, all seems well, have updated the list of deployments and removed the features/fixes from the backlog list.

    Let me know if anyone runs into any problems. :)

    @CCP_FoxFour // Technical Designer // Team Tech Co

    Third-party developer? Check out the official developers site for dev blogs, resources, and more.
    Evanova Android
    Traquenard Labs
    #39 - 2014-03-27 20:11:32 UTC
    I am currently experimenting with the /alliances/ endpoint and I have a remark/suggestion about it:

    When not specifying an ID (/alliances/ID), the JSON response returns a list of "items" like in /incursions/ and others, which is nicely consistent.

    Now specifying an alliance ID (/alliances/123145/) returns a JSON that is an Alliance descriptor, so the format is way different from the list of alliances, which in turn requires some different parsing for this endpoint and its derivative.

    It would be nice if the version with ID returns a list of "items" with only one item and the version of alliance information that the /alliance/id/ endpoint provides.

    I only started working with CREST so I do not know if it applies with other calls, but such a consistent JSON format would most likely make some 1st-world lives easier.

    Evanova - The Android App for Eve Online
    Desmont McCallock
    #40 - 2014-03-27 21:58:54 UTC  |  Edited by: Desmont McCallock
    Idea: Notification Ref Type Name
    Description: Notifications endpoint returns a typeID that refers to what type the notification is. Until now we are relying on user input to 'decipher' the ID to a name (the list can be found at http://wiki.eve-id.net/APIv2_Char_Notifications_XML). It would be great if the returned data includes also the 'typeName'.