Originally by: Shin Hu

---

Originally by: Mister Xerox

---

Originally by: CCP Lingorm

---

Hope that answers all the questions and brings this thread upto date with a wall of black and blue.

---

Hey, uh, guys... how difficult would it be to add a layer mask?

If it's a BPO (-1 runs) = Layer mask (to make it blue)
If it's a BPC (+X runs) = No layer mask (it's just plain gray/white).

Yes, it would be very handy to see runs remaining as we see with ammo stacks, but if it would be to heavy on the DB then we can forgo that. But I don't see how a simple client-rendered mask/nomask would be so heavy on the engine.
Note: Client rendered, so no additional server calls are required. The client querries the server and layers the items as they're parsed.

---

Ok, again. The point is: There is no Run-Entry in the Inventory-list!

---

function OnOpen/Init/Whatever
 Cache = LocalCache::GetInventoryData( );
 ItemList = Server::GetInventoryList( PilotID, LocationID );

 // walk through the list of items
 foreach Item in ItemList do
 // handle case if TypeID is that of a blueprint
 if Item->TypeID equals TYPES_BLUEPRINT then
 // do we have data for this ItemID
 if not isset Cache->ItemID->AttributeID then
 Attributes = Server::GetItemAttributes( ItemID, AttributeID )

 // IconID in this case (when uninitialized) would be ICON_BLUEPRINT_UNKNOWN
 if Attributes->IsOriginal then
 Cache->ItemID->AttributeID->IconID = ICON_BLUEPRINT_ORIGINAL
 else
 Cache->ItemID->ItemName += " Copy"
 Cache->ItemID->AttributeID->IconID = ICON_BLUEPRINT_COPY
 /endif
 /endif
 else
 // Normal item code goes here! (or skip if it's S&I window)
 /endif
 /endforeach
/endfunction

Originally by: Sigras

---

ummmm . . . cant we just make the blueprints tab of the science and industry window drag-able?

it already sorts by copy and original

---

Originally by: CCP Lingorm

---

OK, to clear up a few more misconceptions.

There is a unique entry for Each generic BPO, it has some normalised attributes (Copy time, Mineral requirements etc stored in a reference table), I buy a BPO and start researching it. I now get a unique entry for my BPO and the 'parent' reference for it is the Generic Entry, the normaliased data for my BPO is now created, this consists of ONLY entries where my BPO is different from the Generic type.

I create a Copy of my BPO, this is now created in the user space and will get all the attributes of my BPO instance copied to it and a number of runs value added (not quite true the number of runs will be changed form -1 (infinite) to a positive value) but it's parent still references the generic BPO not my BPO instance.

So automatically assuming that any InvID on a blueprint in the 'user useable' ID range is false as BPO's can exist in that range.

We use this structure as it keeps the size of the database to the absolute smallest, fasted we can make it. The Inv Table only contains fields that are used by ALL types of objects in EVE, so all those differing variables are 'normalised' off into what we call the 'Dogma' Attributes. So to get access to these vaules you have to know the invID of the item (and potentially it's parentID) you then do a cross reference on the inventoryDogma attributes to find out what attributes are assigned to this item (you also add all the generic attributes of the parent if applicable and your instance only stores the changed stuff).

As you can see, it is a complicated system, but it works perfectly to reduce the stored data to the absolute minimum.

---

Originally by: CCP Lingorm

---

itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity (this is in the staticDB dump we provide)

---

Originally by: CCP Lingorm

---

Hope that answers all the questions and brings this thread upto date with a wall of black and blue.

---

Originally by: CCP Lingorm

---

Originally by: Slanty McGarglefist

---

Edited by: Slanty McGarglefist on 20/06/2008 19:36:34
Posted here by request from Matthew;

Wait! So you're telling me that its impossible to add three letters before the name of the Blueprint like;

BPC Raven
BPO Heavy Neutron Blaster
BPO Arbitrator
BPC Large EMP Smartbomb

Etc and so on!?!!?

or just make it part of the name.
_______________________

---

Yes it is not possible to add 3 letters, cos the 'Name' of the item is contained in the type information not in the inventory system. An inventory item can not have a unique name, ships get round this because they are a 'location' in EVE, this means that they can contain other things (modules, cargo, pilots) and thus have an entry in the Locations tables which allows them to have a unique name rather than the Type name.

---

Originally by: CCP Lingorm

---

After that you would need to test the Loot drop system and the LP store to make sure that these changes are working correctly.

---

Originally by: Kweel Nakashyn

---

Edited by: Kweel Nakashyn on 09/12/2008 00:28:01
- an invisible BPC/BPO contener (it's a location so there is one if presence of one bpo/bpc and none if no BPO/BPC. IF there is one, then look inside of it to catch BPO/BPC, identity bpo/bpc attributes with dwords - sort itemID then having somewhere in the locator a dword saying 01110101010001 where 0 is a BPO 1 is a BPC). Maybe yes, maybe not the solution.

---

Originally by: Cheopis

---

Kweel, I do not believe CCP is willing to even seriously consider making any server side changes to how their BP data is stored.

However, we don't NEED server side changes. We need icon changes, which can be addressed by client side organization of blueprints.

I still have yet to see any reason why a client side icon recolor couldn't be easily implemented. The client already sees the BP status of every BP every time you open the S & I folder blueprints tab, so the data is either already stored on the client, in which case generating code to recolor based on stored data should be childs play, or it is polling the server everytime the S & I interface is opened, which is a rediculous waste of server resources when people with thousands of blueprints open the S & I interface many times per day.

In essence either:

A) Most of what is needed for client side color differentiation of BP's is already present, in which case implementation should be relatively simple.

or

B) There is a huge waste of server side resources due to the sheer number of database inquires every time the S & I interface is opened by a manufacturer with many blueprints, in which case implementation of client-side bp type tracking should be a no-brainer for reasons of database access reduction. Verification of BP type at the server could be performed before each build or research action.

---

Originally by: Kweel Nakashyn

---

Edited by: Kweel Nakashyn on 08/12/2008 23:57:18

Originally by: CCP Lingorm

---

itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity (this is in the staticDB dump we provide)

---

Ok, i see your problem now.

Since no blueprint are contraband, is it possible to hide the bpc attribute in this field ? Or hide somewhere in another other field ?

---

Originally by: Since no blueprint are contraband, is it possible to hide the bpc attribute in this field ? Or hide somewhere in another other field ?[/quote

---

I'm pretty sure you will find booster blueprints are contraband.

Originally by: Cheopis

---

Originally by: Sigras

---

ummmm . . . cant we just make the blueprints tab of the science and industry window drag-able?

it already sorts by copy and original

---

Yup, which is why it should be extremely easy to implement a client side code for recoloring BP's - the data is already there. If it's not already stored on the client, then it is polling the server every time you open that screen, which is absurd and wasteful.

---

Originally by: Shaka Quatuic

---

ummm... I dont know if this has been touched on before, but why not make it so that BPOS and BPCs (but mainly BPOs) can be renamed like assembled ships? this would completely solve the issue of identifying what is what, using a mechanic already built-in to the game.

---