Adding "original" flag in Blueprints

[Kyria]

This is more likely a feature request for the blueprint endpoint when it's going to be available within ESI.

Currently, in the XML API, the "only" way to identify a BPO from a BPC is to use the "quantity" value. Regarding the doc :

Typically will be -1 or -2 designating a singleton item, where -1 is an original and -2 is a copy. It can be a positive integer if it is a stack of blueprint originals fresh from the market (no activities performed on them yet).

This works, but in one case: ancient relics.

Why ? Because they are stackable. So when you expect to do a quantity >= -1 to see if it's a BPO, you are going to get ancient relics as BPO too. And if you only do quantity == -1 you will miss all "fresh from market" BPO you just bought.

Can you add a "Original" flag, to make the difference between "quantities" and the blueprint "state" (Copie/Original) ?

Thanks

[polarina]

You can tell if a particular itemID is a stack or not by checking the singleton flag from the asset list endpoint.

[Kyria]

Considering both examples:

• you buy 10 of any existing BPO, you will have a stack of 10 BPO until you use them for the first time. (iirc, it's the case, but it's long passed since I actually bought some...)
• you have a stack of 10 ancients relic (let's say, Wrecked Armor Nanobot) you will see "10" in the quantity field.

Are you sure the first one (the stack of BPO) will be flagged as "singleton" in the asset list ? I don't want to buy right now a stack of bpo to check my assets list, but as the quantity in the blueprint endpoint is >0, I assume it won't be "singleton" in the assets list either.

Besides, even if the stack of bpo is marked as "singleton" in the asset list, I don't think that having to query the assets list to know if it's a singleton or not just to know if it's actually BPO's or a stack of ancient relic is the best solution and cannot be changed / improved.

I just want the BPs after all, not necessarily the full assets. :)

[polarina]

Any blueprint that is a stack or in a stack (that is, singleton is 0) is an original. Blueprint copies can not be stacked. Only when singleton is 1 you check rawQuantity to tell if the blueprint's an original or a copy.

You can tell ancient relics apart from blueprints by looking at the type's group_id and category_id. Blueprints have a category_id of 9, ancient relics have 34.

[Aidansavage]

Since this was referenced earlier today, I figured I could add to it.

  {
    "item_id": 429879373,
    "type_id": 17333,
    "location_id": 1025518295995,
    "location_flag": "Hangar",
    "quantity": -1,
    "time_efficiency": 20,
    "material_efficiency": 10,
    "runs": -1
  },

This is an portion of a return from the blueprint endpoint as it is now. It's a bit hamhanded to figure out information on the blueprint as it is, so instead, perhaps the following-

  {
    "item_id": 429879373,
    "type_id": 17333,
    "location_id": 1025518295995,
    "location_flag": "Hangar",
    "blueprint_type": "Original" (Original/Copy/Artifact)
    "quantity": 1, (integer still, but only >1 if a stack of more than 1 fresh bpo, otherwise stays 1)
    "time_efficiency": 20,
    "material_efficiency": 10,
   // "runs":  included for posterity, but if b_type is original, runs could be omitted. copies and artifacts should return it still
  },

#blamesaeka

[ghost]

I'm doing this now as part of work involved in cleaning up https://github.com/ccpgames/esi-issues/issues/792

It'll be an "is_blueprint_copy" flag though, because the nature of the BPO/BPC flag makes it easier to spot BPCs than BPO's inside all your massive dragon hordes of stuff 😄

[ghost]

Code for this has been submitted. Due to where our branches are at for the next expansion it's not going to hit TQ until the 29th, but it's coming down the pipe 🎉

[ccp-zoetrope]

The attribute is_blueprint_copy has now been added to /v3/corporations/{corporation_id}/assets/ and /v3/characters/{character_id}/assets/

[Kyria]

@ccp-zoetrope well, actually the initial request was to have that information within the blueprint endpoint... Can you reopen it please ? (if required, I can make a new issue) Thanks !

[GoldenGnu]

In my humble opinion: The implementation of this is worse than what we had before. It's a tri-state attribute: [Not a blueprint], [BPO], [BPC] Now we only have two returns for is_blueprint_copy true or omitted. Because if it's false, it's automatically omitted by ESI boolean logic. Please change the implementation to either return false when it's a BPO or change it to an optional enum with the values copy/original

[ccp-zoetrope]

@GoldenGnu you make a good point, I'm going to have to look at doing it this way instead.

[Kyria]

Wondering about this: in what "category" would fit ancient relics for t3 inventions with such enum (iirc currently it's "original" if using quantity only to check) ?

Can we get an enum like copy / original / relic to reflect the differences, since ancients relics cannot be used for anything but invention ? Or at least "copy" since they are not "original" blueprints ?

[Seavert]

Not sure if I'm mad or is direction of this discussion, but request was about /blueprints/ endpoints, not /assets/. Where all items are BPOs and BPCs. In such environment boolean is_blueprint_original or is_blueprint_copy are exhausting info. It would allow to make runs optional and remove weird negative values from runs and quantity.

Adding blueprint attributes to /assets/, with 99% of irrelevant stuff is not a good idea imo. At least until full absorption of /blueprints/ by /assets/.

[GoldenGnu]

Yerh, I know we kinda highjacked this issue, sorry...

What we want is a way to identify if a blueprint is a copy, original, or relic.

The thing is, it would be really nice if it was consistent across all endpoints that deals with blueprints: Assets/Blueprints/Industry Jobs/Contract Items/~~Killmails (killmails are outside my knowledge area, but, I wanted to include it as they can be in the cargo)~~. Are there any more?

So a solution that would work for all endpoints is an enum with: copy/original/relic. For endpoints that return both blueprints and other items the enum value can be made optional and omitted for non-blueprints and for endpoints that only returns blueprints it can be made required.

Edited: Updated to fix the misunderstanding

[cvweiss]

Blueprints are handled in killmails with the singleton flag. Nothing further needs to happen with the killmail endpoint.

[Seavert]

Sure, I meant is_blueprint_original, not is_blueprint (fixed there). Are relics just stackable BPCs? If so, than separate flag isn't so important. Normalized quantity would just show positive number of items in stack.