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.
 

Location Id problem with EVE API -- /char/blueprints.xml.aspx --

First post
Author
Previous Topic Next Topic
GrayLensman
Galactic Protectorate
#1 - 2015-12-09 21:34:43 UTC
I just pinged the /char/blueprints API and it looks like its returning good and bad Location Ids. I have included a subset of blueprints that are all supposed to be location ID 60006220 (Pimebeka VII - Moon 16 - Carthum Conglomerate Factory) in the example XML result below - as you can see the first 3 have very sizable numbers which are not correct Location Ids.

Is anyone else experiencing this issue? Thanks!


#?xml version='1.0' encoding='UTF-8'?#
#eveapi version="2"#
#currentTime#2015-12-09 21:20:06#/currentTime#
#result#
#rowset name="blueprints" key="itemID" columns="itemID,locationID,typeID,typeName,flagID,quantity,timeEfficiency,materialEfficiency,runs"#
#row itemID="122236819" locationID="1000457030358" typeID="9945" typeName="Magnetic Field Stabilizer I Blueprint" flagID="0" quantity="-1" timeEfficiency="20" materialEfficiency="10" runs="-1" /#
#row itemID="122238851" locationID="1000457030358" typeID="11616" typeName="Tracking Enhancer I Blueprint" flagID="0" quantity="-1" timeEfficiency="20" materialEfficiency="10" runs="-1" /#
#row itemID="132011164" locationID="1000457030358" typeID="1152" typeName="Plutonium Charge L Blueprint" flagID="0" quantity="-1" timeEfficiency="20" materialEfficiency="10" runs="-1" /#
#row itemID="1019811124554" locationID="60006220" typeID="24510" typeName="Mjolnir Fury Heavy Missile Blueprint" flagID="4" quantity="-2" timeEfficiency="4" materialEfficiency="2" runs="10" /#
#row itemID="1019811124555" locationID="60006220" typeID="24510" typeName="Mjolnir Fury Heavy Missile Blueprint" flagID="4" quantity="-2" timeEfficiency="4" materialEfficiency="2" runs="10" /#
#row itemID="1019811124556" locationID="60006220" typeID="24510" typeName="Mjolnir Fury Heavy Missile Blueprint" flagID="4" quantity="-2" timeEfficiency="4" materialEfficiency="2" runs="10" /#
#/rowset#
#/result#
#cachedUntil#2015-12-10 08:05:22#/cachedUntil#
#/eveapi#
CCP Tellus
C C P
C C P Alliance
#2 - 2015-12-09 22:48:52 UTC
These locations are containers. You can find them in the AssetList endpoint.
GrayLensman
Galactic Protectorate
#3 - 2015-12-10 21:37:59 UTC
Thanks CCP Tellus, I've combined blueprints and assets to get correct location IDs.

One follow-up action...

1. The 3rd party developer documentation needs adjusting to clarfiy that the locationID needs additional logic, I'll submit a github request to update the docs located here.

One follow-up question...

1. If I understand the documentation at the link above (and for the Assets endpoint), itemIDs are only guaranteed to be unique within any given page load for that endpoint. Since the Blueprint locationID can be an Asset itemID, how likely is it for the itemID to become invalid since Assets and Blueprint endpoints could be polled at different times?

Thanks again for pointing me in the right direction.
CCP Tellus
C C P
C C P Alliance
#4 - 2015-12-10 21:58:31 UTC  |  Edited by: CCP Tellus
GrayLensman wrote:

1. If I understand the documentation at the link above (and for the Assets endpoint), itemIDs are only guaranteed to be unique within any given page load for that endpoint. Since the Blueprint locationID can be an Asset itemID, how likely is it for the itemID to become invalid since Assets and Blueprint endpoints could be polled at different times?

Item IDs are unique across the whole cluster. They do not change by itself out-of-the-blue. If the documentation says otherwise, that should be changed.

This used to be the case a long time ago before we moved over to 64-bit integers for identifiers where the IDs of deleted items were recycled.

However, there's always the slight chance that in the time between your requests for blueprints and the asset list, someone has actually deleted the container in-game. :)
Hel O'Ween
Men On A Mission
#5 - 2015-12-11 18:11:54 UTC
CCP Tellus wrote:
GrayLensman wrote:

1. If I understand the documentation at the link above (and for the Assets endpoint), itemIDs are only guaranteed to be unique within any given page load for that endpoint. Since the Blueprint locationID can be an Asset itemID, how likely is it for the itemID to become invalid since Assets and Blueprint endpoints could be polled at different times?

Item IDs are unique across the whole cluster. They do not change by itself out-of-the-blue. If the documentation says otherwise, that should be changed.

This used to be the case a long time ago before we moved over to 64-bit integers for identifiers where the IDs of deleted items were recycled.

However, there's always the slight chance that in the time between your requests for blueprints and the asset list, someone has actually deleted the container in-game. :)


Lemme chime in, as I wrote that part of the docs: there's two parts about the itemID:

1) "Also, items are not guaranteed to maintain the same itemID over time. When they are repackaged, stacks are split or merged, when they're assembled, and other actions can cause itemIDs to change. " (emphasis mine)

Correct me if I'm wrong CCP Tellus, but that seems still to be the case even today.

Which brings as to
2) "Unique ID for this item. This is only guaranteed to be unique within this page load."

Taken 1) into account, this makes sense. Example: You've got two stack of 5 DCUs each in your hangar. Both stacks have a unique itemID. You pull the AssetList. You then merge those two stacks to just one stack of DCUs. If you now happen to pull the AssetList after the cache time has expired, the itemID should have change.

(I suspect the new stack gets a completely new itemID, not identical with the former two itemIDs of the stack, but haven't tested that)

So - yes, taking 1) into account, itemID is only guaranteed for that one API call.

See CCP Garthak's explanation of the above (scroll to post 10)

EVEWalletAware - an offline wallet manager.
CCP Tellus
C C P
C C P Alliance
#6 - 2015-12-11 20:15:21 UTC
Hel O'Ween wrote:
...


You're correct. If you stack together items, assemble or reassemble ships, and so on, then you get a new item ID. And it got a new item ID because you, or someone else, did something with that item.

What I meant was that item IDs do not change if no one interacts with that particular item one way or another. If you leave an item in your cargo container, log out and come back a year later, it'll still have the same item ID.
Max Kolonko
Caldari Provisions
Caldari State
#7 - 2015-12-12 16:03:34 UTC  |  Edited by: Max Kolonko
Hel O'Ween wrote:
...

So - yes, taking 1) into account, itemID is only guaranteed for that one API call.

...



Item and stack of items is not the same item, so NO, item ID is not only guaranteed for that one API call. Its guaranteed for as long as this item is not destroyed. And adding it to a stack is essentially destroying of that item by merging it into the stack.

Taking a single ship, repackaging it and reassambling, as long as it was not added to a larger stack of >1 number of that ship will retain the ID.

EDIT: correction to the above - assembling from 1-item stack retains the stack id for assembled ship/item, but repackaging creates new item.

Read and support: Don't mess with OUR WH's What is Your stance on WH stuff?
Hel O'Ween
Men On A Mission
#8 - 2015-12-13 12:04:16 UTC
CCP Tellus wrote:

You're correct. If you stack together items, assemble or reassemble ships, and so on, then you get a new item ID. And it got a new item ID because you, or someone else, did something with that item.

What I meant was that item IDs do not change if no one interacts with that particular item one way or another. If you leave an item in your cargo container, log out and come back a year later, it'll still have the same item ID.


Smile

Yepp. Makes all sense if you think about it.

However, I remember when I started to work with the API, the intuitive approach was to equate i.e. 1 module = 1 item(ID). As soon as one starts to think 1 stack (of i.e. modules) = 1 item(ID) things make sense.

EVEWalletAware - an offline wallet manager.