Nexuscrawler
New Eden Patriots E.B.O.L.A.
8
|
Posted - 2015.04.14 17:28:02 -
[1] - Quote
Hello,
about 10 months ago I posted about a (well known?) bug in the Contracts-API after being told to do so by CCP FoxFour in a Support-Ticket. Back then I did not exactly understand why it was important to create a forum post about an obvious bug and I still don't get it today (maybe a priority thing, to check if there are enough people that care about it?), but since I'd still like to finish that project of mine, I would like to ask (and maybe get a short response from CCP) whether this is actually on their list for a fix in the near future?
Old Thread: https://forums.eveonline.com/default.aspx?g=posts&m=4713259
I just tested this again and the API still gives me the wrong information as explained in my post. I thought about writing another ticket, but I decided to necro my old thread instead.
Does really nobody but me work with the Contracts-API and has to deal with Blueprints?
Thanks guys o7 Nexuscrawler
The clan's are marching `gainst the law,
Bagpipers play the tunes of war,
Death or glory i will find,
Rebellion on my mind.
|
CCP FoxFour
C C P C C P Alliance
3977
|
Posted - 2015.04.15 16:59:53 -
[3] - Quote
Well I think I know why the rawQuantity never shows up:
if (item.rawQuantity < 0) { xml.WriteAttributeString("rawQuantity", item.rawQuantity.ToString()); }
Wait... I am totally not understanding this... arg... um... will try and look into it in a few weeks... but don't hold high hopes. So much to do!
@CCP_FoxFour // Technical Designer // Team Size Matters
Third-party developer? Check out the official developers site for dev blogs, resources, and more.
|
Nexuscrawler
New Eden Patriots E.B.O.L.A.
8
|
Posted - 2015.04.16 15:49:37 -
[5] - Quote
if (item.rawQuantity < 0) { xml.WriteAttributeString("rawQuantity", item.rawQuantity.ToString()); }
If "rawQuantity" is a nullable value and is in this case "null", then that if-statement would read....
if (null < 0) { xml.WriteAttributeString("rawQuantity", item.rawQuantity.ToString()); } ....which is always "false".
But that can't be the problem really, because if "rawQuantity" has to show up, then it also has to be at least a negative value and not "null" (meaning, this works as intended), so the problem might lie a bit further up the code. I think there are a few things wrong behind the whole logic to begin with.
We have the following attributes in the ContractItems.xml:
Quote:recordID A unique key.
typeID The type of the item.
quantity The actual quantity.
rawQuantity This attribute will only show up if the quantity is a negative number in the DB. Negative quantities are in fact codes, -1 indicates that the item is a singleton (non-stackable). If the item happens to be a Blueprint, -1 is an Original and -2 is a Blueprint Copy.
singleton 1 if this is a singleton item, 0 if not.
included 1 if the contract issuer has submitted this item with the contract, 0 if the isser is asking for this item in the contract.
The first thing here is, that we don't even need the "quantity" attribute to be "-1" for knowing this to be a singleton, because we also have a seperate "singleton" attribute in every row, indicating this. The "quantity" attribute does not have to be taken into account at all, because if "singleton" is true, it should be clear, that the actual quantity will be "1" (hence a singleton).
The second thing about having to have the "singleton" attribute as a condition for "rawQuantity" to show up, is, that blueprints which have never been used for production or research are NOT "singleton", because they are still stackable and sellable over the market, insofar they are originals.
This raises another problem, because if you are going to use the value "-2" for "rawQuantity" as a code for it being an "original" and it is NOT a singleton, then where do you put the actual quantity of the blueprints in the stack? You would now need the "quantity" field for that, which (as it stands) would be set to "-1" instead.
If I apply those changes to how it currently is, then the following examples should actually lead to something like this:
Quote:A stack of 100 Tritanium recordID -> [ID] typeID -> [Tritanium ID] quantity -> 100 singleton -> 0 included -> 0/1
An assembled Drake recordID -> [ID] typeID -> [Drake ID] quantity -> 1 singleton -> 1 included -> 0/1
A blueprint copy for a Drake recordID -> [ID] typeID -> [Drake Blueprint ID] quantity -> 1 singleton -> 1 (BPCs are always singleton) included -> 0/1 rawQuantity -> -1 (to show it's a copy)
A (researched/used for production) blueprint original for a Drake recordID -> [ID] typeID -> [Drake Blueprint ID] quantity -> 1 singleton -> 1 (Because when used for research/production they get "assembled") included -> 0/1 rawQuantity -> -2 (to show it's an original)
A stack of 3 (not researched/not used) blueprint originals for a Drake recordID -> [ID] typeID -> [Drake Blueprint ID] quantity -> 3 singleton -> 0 (Because when not used for research/production they are still stack- and sellable) included -> 0/1 rawQuantity -> -2 (to show it's an original)
Please tell me if there is anything I've not taken into account with this, but to me it would be much more understandable that way. To be honest, I am not even sure if it would work the way it is currently explained in the documentation due to the reasons above. (Or I didn't understand the docs >.<)
I don't know how hard it is to fix this and I'm sure there is a lot of other work waiting to be done, so I'll just wish you the best of luck with this.
(*Ninja-Request - It would be awesome to have an indicator in the API whether items which are singletons are also damaged.)
The clan's are marching `gainst the law,
Bagpipers play the tunes of war,
Death or glory i will find,
Rebellion on my mind.
|