EVE-Search ForumWatch

Make BPOs and BPCs distinguishable - by Cheopis

Thu, 18 Dec 2009 07:38:00 +0000

Kweel, I'm not certain that I was able to fully understand what you said in your most recent post, but I think I understood some of it.

CCP could quite easily make a modification to the database that would allow colorization of BP's based on primary database lookups, rather than secondary. However they have indicated that the performance hit from doing that would be pretty significant on the primary database.

It's not that they are unable to make the changes like what you seem to be indicating, it's that they do not want to overcomplicate and bog down a database system that works, that they are actually trying to streamline.

That's why quite a few of us here have been requesting a client side database for blueprints.

If you have any questions about how that would work, please ask again, but take a little more time to proofread your next post please, as I was having severe difficulties understanding parts of your most recent post.

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Wed, 17 Dec 2009 00:02:00 +0000

Edited by: Kweel Nakashyn on 17/12/2008 00:03:26

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.

I think it's B.

How would you do if sbdy copy a bpo, or use it. You need to see realtime if it's there or not.

It's not a major DB change I propose. It's basically a migration. It's changing everysingle bpo/bpc into locations.
Each time you see a bpo, you would see the location instead, which have more attributes. And this could tell if it's a bpo or a bpc. I have to present things clear anyway.

I won't, cause i've got a dirty flu and can't think clearly since a week.

-edit- I'm not telling it's easy to do. If I'm to do that kind of things in my job, I'd have say 10 days for the study, 10 for the realisation and LOOOOOOOOOOOOOOOOOOOOOOOOOTS in tests :)
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Gotrek65

Mon, 15 Dec 2009 06:09:00 +0000

Will any of these options be viable when the eve servers are upgraded to HPC and/or microsoft sql server 2008?

Make BPOs and BPCs distinguishable - by Cheopis

Thu, 11 Dec 2009 09:31:00 +0000

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.

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Wed, 10 Dec 2009 23:53:00 +0000

Edited by: Kweel Nakashyn on 10/12/2008 23:53:38

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.

I'm thinking of something like this.

It'll be called a blueprint folder. More details when I'll have time, eve time is limited this week for me.
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 23:57:00 +0000

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.

I could do the pewpew for you

Sorry, had to.

I'm thinking about this problem now and i'm pretty stubborn so I will find interested things to say instead of the crap I've written.
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 23:21:00 +0000

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.

Hum, make BPO/BPC locations ?

(yeah I'm reading the thread and I'm sorry to be 3 monthes late, etc etc)
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 23:16:00 +0000

Originally by: CCP Lingorm
Hope that answers all the questions and brings this thread upto date with a wall of black and blue.

It's great you rode that thread Lingorm. I'm sure there's a simple way.
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 23:09:00 +0000

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 old field ?
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 22:55:00 +0000

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.

Is the index on the name (or maybe the name itself) stored in the generic table or in the delta stat BPO/BPC table ?

If it's in the generic table (parent), your db is not really that great, since you'd have to extract the name anyway (because each time you want to affich a BPO/BPC, you'll have to make the joint between these two tables, parent and child).

If it's the delta stat BPO/BPC (child), you can at least change its name easy. Just change the name or name index to point to a "BPC - xxxxx blueprint" when you create the BPC.

Then players could sort by names.
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Kweel Nakashyn

Mon, 8 Dec 2009 22:28:00 +0000

Edited by: Kweel Nakashyn on 08/12/2008 22:32:53
Ok.

Got another, simple, idea.

Rename them.

BPC - Raven blueprint
BPC - Orca blueprint
BPO - Damage control I blueprint
BPC - Amarr shuttle blueprint
BPO - Miner I blueprint

Then sort by names. And voila.

"simply the best" \o/

-edit- if you want technical details, you can do "kweel nakashyn's rifter", why you couldn't apply new names to these items ?
Fetchez la vache !

Make BPOs and BPCs distinguishable - by Arama Bishop

Thu, 4 Dec 2009 12:40:00 +0000

Oki, I have understand your problem with our database.

But the solution will be not to make some modification.

You put will the eve client, one local database with the item's picture.

In this case that will be not decrease the performance of your database.

Make BPOs and BPCs distinguishable - by Cheopis

Sun, 30 Nov 2009 04:33:00 +0000

It would be nice to see CCP comments on a client-side-only BPO/BPC icon color change.

If there is a favorable view from CCP, some sort of timetable would be nice.

If there is not a favorable view from CCP, then it would be nice to know why, so we can determine the appropriate arguments to use to get it done anyhow

Make BPOs and BPCs distinguishable - by wert668

Wed, 26 Nov 2009 18:06:00 +0000

You can't add this because of lag when loading items (double database or so), what about adding button only for industrial characters? 99% of time you don't need to know, but when you need, you only click and suffer from one long lag.

Make BPOs and BPCs distinguishable - by Coltane

Fri, 21 Nov 2009 19:34:00 +0000

Edited by: Coltane on 21/11/2008 19:34:55
Well, if the number of runs on a bpo is always -1... the client could display this bp in a different color.

Or do I miss something?

The idea about click'n'drag from the industry panel is also very good, I have been missing that feature already.

Make BPOs and BPCs distinguishable - by Cheopis

Fri, 14 Nov 2009 11:53:00 +0000

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.

Make BPOs and BPCs distinguishable - by Sigras

Thu, 13 Nov 2009 23:10:00 +0000

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

it already sorts by copy and original

Make BPOs and BPCs distinguishable - by FLT BoB

Sun, 9 Nov 2009 00:11:00 +0000

I don't understand why client localcache isn't used more penetratively.
surely the overhead of an occasion call to propagate the cached data is
worth the trade of slightly increased database usage.
especially when the added functionality would be such a boon to so many
people (industrials, pirates, space monkeys, etc)

regardless of how you retrieve the icon (deferred like portraits, or whatever)
it would still be a considerable aid to anyone that deals with blueprints.

-- example --

(in pseudo code, too lazy to mock it up in C)


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

Ofc, I'm assuming the Attributes table is extensible, and values in that table override base
values in the ItemList table. (IE: IconID)

Make BPOs and BPCs distinguishable - by Mister Xerox

Fri, 7 Nov 2009 14:57:00 +0000

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!

Okay... after several posts stating that a BPO has a run quantity of -1 (thus defining it as an Original), I don't follow.

something differentiates a Copy from an Original, be it a host of factors or just one, all that needs to be done is to querry that identifying field. If the ident returns 'copy' then no action is taken by the client. If the ident returns 'original' it places the appropriate layer mask (since copies outnumber originals it's a lot less CPU intensive masking only the originals).

This is only to deal with the color displayed by the client, nothing else.

Make BPOs and BPCs distinguishable - by Cheopis

Thu, 6 Nov 2009 20:29:00 +0000

Edited by: Cheopis on 06/11/2008 20:30:08
I still believe that the single best possible solution to this issue would be a client-side feature that would simply store the status of a blueprint after you determine what is it.

After the server has been queried for the information, change the color of the BP on the client, and track the blueprint. Unknown BP's would be whatever color they are now, BPO's would be a different color, and BPC's another color. This would give you three classes of BP sorted entirely client side, and only two after a single database search for each BP.

If you lose the data every now and then, big deal, organize it again. CCP would actually end up with LESS database calls over time, since players would have a clear indication of what a blueprint is after the first time you looked at it in a client.

Heck, with a client side database, you could even make a status bar on the side of each BPC so we could tell roughly how many runs were left, so it would be easier to choose the right BPC for a small or big job.

Make BPOs and BPCs distinguishable - by Shin Hu

Thu, 6 Nov 2009 15:41:00 +0000

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!
The Inventorylist is a plain db table just with basic informations that is usefull for all itemtypes.
ME/PE/Copy/Runs/... are just informations for BP's. These fields would be empty (in best case just existent with a few bytes, but as this depends on SQL EACH field would be as big as the field is, long int(16Bytes) for example), but still be loaded during query of each and every inventorylisting. Just for BP Issue there are 6 fields + on a that table which will most likely double the fields in that (and therefore double DB load).

If i understand the database correct from statement in this Topic there are 3 Tables:
Genereal Inventory-Table and spezific Iteminformation. Both are connected to a third table with general Iteminformations.

So you get in general-itemtable info about the item itself. What build-requirements and materiallist etc. NO me and NO pe OR run on those. Just info what that type of item do for ME0/PE0.
Now there is the 2nd Table of spezific item information. In that table are just the item-ID from the general-itemtable, ME, PE and RUN Information.
Now, if you list your inventory this polls your inventory-table and this give info what item it is from the general-table, as this has a fix amount of data (just as many as items are in game) and the related information where to fin details in the spezific table. The query on the spezific table is not done in this stage as this would mean a mass overload on information and just imagine how many items are there in game!

The best solution would be the idea with just use the field where the amount of an item ist stored to be used as informationfield if this is an bpo or not.
As items generaly have the ability to be repacked or not this field would be an boolean (1 bit). Just make this a 2 bit field an set states as follow:
0=Repacked
1=assembled (items like ships, modules etc)
2=BPO
3=BPC

now you could use the amount-field for whatever you want as long as you just parse this field by the client like: first 6 bit=runs, next 6=me, next6=pe.
I don't know how long this field is exactly but as you can have some billion Tritanium in one stack even a field length of 8 bit each would be possible.
As there are BP's with 1500 runs available the run-bit would have to be 9 bit at least. As ME/PE on smaller BP's is sometimes also >1000 3x 10bit would be fine for most cases.
This way you would even be able to display that information directly in the client with just one field an nearly no extraload on DB as the parsing of the amount-field could do the client (should be simple to implement to do such parsing depending on state of "package").

Make BPOs and BPCs distinguishable - by Mister Xerox

Thu, 6 Nov 2009 11:07:00 +0000

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.

Make BPOs and BPCs distinguishable - by ChaoticDemon

Sun, 2 Nov 2009 19:43:00 +0000

How about just making sort by type always put originals first at least then wouldn't have to search every bp just to find your original and put in a container also a pain if you accidently repack you container

Make BPOs and BPCs distinguishable - by Molishero

Fri, 31 Oct 2009 20:04:00 +0000

Edited by: Molishero on 31/10/2008 20:04:58
Should run client-side, outside of database. A client side fix would solve any BPO/BPC server-side network lag. This is just an example of a client side solution to this problem. If anything this would cause a slight drop in client performance but only to those who deal with 50+ blueprints at a time.

Quote:

if {blueprint.runs = "infinite"} then //Sees if the bp is a BPO
bp_tex.image = 1 //If so then it changes to the BPO icon
else
bp_tex.image = 2 //If not then it changes to the BPC icon
end if

Now I have no idea how the coding works for Eve but this is a decent example of what can be done.

Now for labs and research, why not just add an extra info slot that says how many runs are left in the BP?

Make BPOs and BPCs distinguishable - by Rev Russ

Fri, 17 Oct 2009 21:37:00 +0000

Can you please add an export button within the Science & Industry window for both corp and individual Blueprints?

The export would be csv or excel and include all the fields listed in the window including bp name, station location, me, pe, runs, copy(yes or no). And as a bonus, include the material requirements :) Please!!!

This would help me greatly in creating and updating my BPC and BPO inventory.

I also think this would help reduce the frustration of BPC's not stacking, and not being able to distinguish a bpc from bpo. Lets be honest, its only frustrating when you are updating your inventory.

Also, maybe create an export for outstanding contracts as well... but thats a different topic.

Make BPOs and BPCs distinguishable - by Malik Mantille

Fri, 17 Oct 2009 08:40:00 +0000

Edited by: Malik Mantille on 17/10/2008 08:45:47
Currently I keep bpc and bpo seperate in cans. I seperate these based on my personal knowledge of what they are. This of course in no way effects the database. To avoid a database transaction increase, how bout we simply create user per item flags, client side of course.

I highlight all my bpcs, I label them "BPC" and have a user selectable letter overlay (not part of the actual icon) that would be placed on icon in the top left (similar to t2, but not an image, just a text overlay)

so you have

[held due to lack of ascii art in forums..hold for image]

where X is the blank area that allows for the iconic overlay. Being as it is just text, it'd not be a tax on the system.

this would also not be just for the industrialists, If you don't enjoy sorting things in station cans, you could simply enjoy being able to group these items, say your pvp fit versus mission fit items in you stations

M / P you could choose as the arbitrary upper left character and this would allow you a quick glance at what is what based on your choice factors all done client side. it would of course require some work, but there is zero db side interaction so its still a decent workaround.

In conjunction with this, it may be as well good to add a "view" option for hangers.. I wanna see all my pvp fit items, since I can name the item grouping myself (pvp tackler crow) it'll have the same P overlay that all other pvp items I've grouped have, except when it comes to my choice view. So, If i have two ship fits both pvp, one for my crow, one for my jaguar I can select pvp tackler crow and those pvp jaguar mapped items will not be shown.

the data required for this would be small client side.

data:

"Label title" "overlay character" "item number"
32 char 1char int

------

Make BPOs and BPCs distinguishable - by Jed Clampett

Wed, 15 Oct 2009 08:20:00 +0000

The obvious solution is to handle Blueprints much like Ships for inventory purposes.

Add a separate inventory tab just for Blueprints which shows that BPC/BPO ME/PE info. Let people who don't care merge inventory and not show that info.

Of course you need to improve Assets windows to show this for remote locations. I am sure a similar change can be made. Such a change might even address other issues with sorting Assets.

And finally there is no reason BPCs don't have like a yellow outline in Contracts. After all the number items being shown is usually one and even when opening multiple item slections, there are seldom truly large numbers of items.

Make BPOs and BPCs distinguishable - by Jed Clampett

Wed, 15 Oct 2009 08:12:00 +0000

They could change the general inventory query by adding a couple operations to split out the Blueprints and append the blueprints at the end. That way the join for copy/original info would only need to be against blueprints.

This would minimize server loading -- particularly when their work around still involves a join with this type of information.

Code would be slightly more complex and not as elegant. And yes some work would be done for people who don't give fly crap about blueprint info....

Make BPOs and BPCs distinguishable - by Lothendra

Sun, 12 Oct 2009 13:44:00 +0000

On a related note, is there any particular reason why we can't repackage an unresearched BPO?

Make BPOs and BPCs distinguishable - by Zifrian

Sat, 11 Oct 2009 22:05:00 +0000

What about giving us the ability to right click the item and color it or something similar. Right now items in a audit container have values associated with them that makes them locked or unlocked. Is there anyway we can use this type of function to mark the item? I'm assuming it would need a new variable but this would be on the object, not the base item for the icon right?

I'm just trying to think outside of the system you have in place since it seems like changing that isn't possible, with good reason.

Make BPOs and BPCs distinguishable - by Nova Fox

Fri, 10 Oct 2009 16:47:00 +0000

Originally by: CCP Lingorm
Ah I see.

So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...

I will pass it along to software ...
[/quote

Any update on this?

Pre Order your Sisters of Eve ship today!!!

Make BPOs and BPCs distinguishable - by CCP Lingorm

Mon, 6 Oct 2009 16:53:00 +0000

Originally by: Tobin Shalim
Originally by: CCP Lingorm

Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.

When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.

Couple questions:

1. Would it be too slow to use the 'Show Info' calls for blueprints only to distinguish which are copies vs. originals and then apply the correct icon? (see #1a)

1a. If there is already coding in the DB for a certain item to be assigned a certain ID for the proper icon (ex. Kestrel BPO ID: 1, it then goes through the listing of icons until it finds iconID: 1 and applies to the UI), and there is existing coding as you said for the 'Show Info' query, could it be possible to add this coding for just the blueprints so that it runs a check if it's a BPC and then finds the proper icon for that?

2. Could this coding be done for just blueprints? From what I gather, there are assigned 'categories' for each item type, so I would think the blueprints have their own group ID which would make doing this on the DB side rather easy (but I'm not a DB Admin).

This has been discussed previously in this thread.

The answers are there.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Tobin Shalim

Mon, 6 Oct 2009 15:42:00 +0000

Originally by: CCP Lingorm

Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.

When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.

Couple questions:

1. Would it be too slow to use the 'Show Info' calls for blueprints only to distinguish which are copies vs. originals and then apply the correct icon? (see #1a)

1a. If there is already coding in the DB for a certain item to be assigned a certain ID for the proper icon (ex. Kestrel BPO ID: 1, it then goes through the listing of icons until it finds iconID: 1 and applies to the UI), and there is existing coding as you said for the 'Show Info' query, could it be possible to add this coding for just the blueprints so that it runs a check if it's a BPC and then finds the proper icon for that?

2. Could this coding be done for just blueprints? From what I gather, there are assigned 'categories' for each item type, so I would think the blueprints have their own group ID which would make doing this on the DB side rather easy (but I'm not a DB Admin).
-----

Originally by: Haakkon
I feel a great deal of patriotism at being a part of Goonswarm. We've accomplished great things... we're just mainly jerks about it

Make BPOs and BPCs distinguishable - by CCP Lingorm

Mon, 6 Oct 2009 09:46:00 +0000

Originally by: Tobin Shalim
Ok, coming from someone that has little/no DB experience aside from some very basic Access DB's I've written, I'm not so sure how well received this idea will be, but here goes....

Lingnorm, I don't see how there would be much in the way of additional DB coding that needs to be done for this, since you basically have it in there right now. Looking in my corps hanger I have a BPO, and a BPC done from that original print. I can open up the show info tab on both and see very clearly that it says the following: Original Blueprint for the BPO and: Blueprint Copy (yes, I know it's not blue, but grey doesn't work for a color on the forum).

Now, you apparently already have the DB calls in place for distinguishing the copies from the originals, so would it really be that much harder to point the DB entries that return a copy yes/no check (I'm assuming that's what you have in place, but whatever system you have would also work) to a separate icon created just for the copies? You must have something going on already for icons that are called for inventory/market queries in order for us to get the correctly displayed icons for our items, so since the distinction for originals/copies is existing, why can't you just have the copies pointed to a differently colored icon for the BPC's?

Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.

When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Tobin Shalim

Sat, 4 Oct 2009 20:23:00 +0000

Ok, coming from someone that has little/no DB experience aside from some very basic Access DB's I've written, I'm not so sure how well received this idea will be, but here goes....

Lingnorm, I don't see how there would be much in the way of additional DB coding that needs to be done for this, since you basically have it in there right now. Looking in my corps hanger I have a BPO, and a BPC done from that original print. I can open up the show info tab on both and see very clearly that it says the following: Original Blueprint for the BPO and: Blueprint Copy (yes, I know it's not blue, but grey doesn't work for a color on the forum).

Now, you apparently already have the DB calls in place for distinguishing the copies from the originals, so would it really be that much harder to point the DB entries that return a copy yes/no check (I'm assuming that's what you have in place, but whatever system you have would also work) to a separate icon created just for the copies? You must have something going on already for icons that are called for inventory/market queries in order for us to get the correctly displayed icons for our items, so since the distinction for originals/copies is existing, why can't you just have the copies pointed to a differently colored icon for the BPC's?
-----

Originally by: Haakkon
I feel a great deal of patriotism at being a part of Goonswarm. We've accomplished great things... we're just mainly jerks about it

Make BPOs and BPCs distinguishable - by Katana Seiko

Thu, 2 Oct 2009 08:23:00 +0000

Originally by: Nova Fox
I think the new color of the copies should be white, this contrast will be sharp enough for color blind people

Okay, that's a design question. I for my part don't like white icons. I think that BPCs should have more of a "used" look. If the icon looks like it's torn at some place or a little piece has been ripped off, that's way better (imo). You would have to be allmost blind to miss that one (and no, blind people don't play EVE, we don't need special icons for them).
---
"Multiple exclamation marks are a sure sign for a diseased mind." -Terry Pratchett

Make BPOs and BPCs distinguishable - by Draygo Korvan

Tue, 30 Sep 2009 06:24:00 +0000

Originally by: CCP Lingorm
Originally by: Draygo Korvan
Edited by: Draygo Korvan on 28/09/2008 21:03:29
I'm posting this here because its related:

Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail.

Nope.

Speaking as a carebear I find it rather amusing when a piewat goes off and gloats about all the BPO's he has killed, when in actual fact they are all bpc's and it was a 50/50 decision to either move them and give them away to corp members or just trash them. In fact I know of a couple of instances where people tried to give them away in local first, when no one replied they loaded them in a shuttle and set of on autopilot hoping to get ganked to lump them on someone else....

All joking aside. This would add additional load to the killmail system as it would need to do an additional query to the db to get this information, exactly the same reason we do not do it for the inventory system. So my guess is that this will not happen.

One does not bring bpo/bpc's to fleet (laggy) combat. You can always have a lag check before bothering to query. Or you can assume they are copies because that is the most likely case. I dont think people losing bpo's bpc's happens as fast as people shuffling through their inventory. The additional load should be minimal. I think the sacrifice would be worth it.
--

Make BPOs and BPCs distinguishable - by Nova Fox

Tue, 30 Sep 2009 00:26:00 +0000

I think the new color of the copies should be white, this contrast will be sharp enough for color blind people

Pre Order your Sisters of Eve ship today!!!

Make BPOs and BPCs distinguishable - by Imhothar Xarodit

Mon, 29 Sep 2009 21:20:00 +0000

Edited by: Imhothar Xarodit on 29/09/2008 21:20:46

Originally by: CCP Lingorm
Ah I see.

So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...

I will pass it along to software ...

Exactly, thank you.

With some more tinkering you could even manage to remove the need for the client to check every item's typeID if its a blueprint typeID. If it does already, then fine, but if not the check can be removed by giving the quantity field a strict value system.
Example:
A singleton BPO has a quantity of -1
A singleton BPC has a quantity of > 0
Any other items have a quantity of <= 0

This way if the client encounters a singleton item with the quantity attribute larger than zero it immediately knows it must be a BPC and can take the number to for example display it on the blueprint icon in the top right corner (so it won't be confused with the quantity counter) and/or give it a different color/border/whatever.

The only problem here is for procedures that rely on the quantity field to be 1 for singleton items. How far that is stretched I can't tell.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Mon, 29 Sep 2009 17:12:00 +0000

Originally by: Imhothar Xarodit
Looks like there is some misunderstanding here. I was not proposing to shift the normalized field to the inventory table and let all systems deal with that, that is too much, all systems should stil work with the normalized value as that is already working fine.
The suggestion merely implies giving the quantitiy field an additional meaning that is in fact only interesting for the client which does not have immediate access to the normalized table on an inventory query.
As I already mentioned, this all would only work after a BPC has been assembled/used so its singleton attribute is true. As that is the key to making the quantity field rather useless (except some other services rely on it, that i don't know). So the example with the Machariel BPO can't happen as it is not a singular item (afair). But even if it was, the deal is to have the quantity field only as additional hint for the client, not be used by the server-side S&I procedures.

Ah I see.

So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...

I will pass it along to software ...

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Imhothar Xarodit

Mon, 29 Sep 2009 16:48:00 +0000

Originally by: CCP Lingorm
Yes creating copies is a special job, but rather than modify the assigned attribute in the normalised scheme you now want it to changes to 'amount' variable in the item table, so this code will have to be tested.
(...)
Yes, but we would now have to change the field that that it is checking for the amount of runs and retest it all.
(...)
Not true, the available bpc list for invention needs to change it's filter to filter on the amount field rather than the normalised field. And then it needs to be retested to make sure it works in all cases.
(...)
The code changes are minimal compared to the amount of testing that would be involved. Because you are changing fundamental parts of some very low level systems, if they break then it would be a major problem for EVE. So sorry they entire thing would have to be retested rather extensively.
(...)
Yes actually it is. BPC'c dropped and bpc's created through the LP system use the same mechanics as the copy process, so they would need to be tested to make sure they are working correctly. It would not be good to drop a Machariel BPO instead of a BPC now would it.

Looks like there is some misunderstanding here. I was not proposing to shift the normalized field to the inventory table and let all systems deal with that, that is too much, all systems should stil work with the normalized value as that is already working fine.
The suggestion merely implies giving the quantitiy field an additional meaning that is in fact only interesting for the client which does not have immediate access to the normalized table on an inventory query.
As I already mentioned, this all would only work after a BPC has been assembled/used so its singleton attribute is true. As that is the key to making the quantity field rather useless (except some other services rely on it, that i don't know). So the example with the Machariel BPO can't happen as it is not a singular item (afair). But even if it was, the deal is to have the quantity field only as additional hint for the client, not be used by the server-side S&I procedures.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Mon, 29 Sep 2009 09:53:00 +0000

Originally by: Draygo Korvan
Edited by: Draygo Korvan on 28/09/2008 21:03:29
I'm posting this here because its related:

Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail.

Nope.

Speaking as a carebear I find it rather amusing when a piewat goes off and gloats about all the BPO's he has killed, when in actual fact they are all bpc's and it was a 50/50 decision to either move them and give them away to corp members or just trash them. In fact I know of a couple of instances where people tried to give them away in local first, when no one replied they loaded them in a shuttle and set of on autopilot hoping to get ganked to lump them on someone else....

All joking aside. This would add additional load to the killmail system as it would need to do an additional query to the db to get this information, exactly the same reason we do not do it for the inventory system. So my guess is that this will not happen.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Mon, 29 Sep 2009 09:49:00 +0000

Originally by: Imhothar Xarodit
Isn't creating copies already a special job, as you have to create a new item with number of runs on it. Would require an update to the inventory table (quantity field).

Yes creating copies is a special job, but rather than modify the assigned attribute in the normalised scheme you now want it to changes to 'amount' variable in the item table, so this code will have to be tested.

Quote:
Uhm, doesn't this already have to be treated specially? Like destroy a BPC if it was a copy and its runs were used up, reduce a copies runs left as opposed to a BPO? Would need to extend this step with an update on the quantity field.

Yes, but we would now have to change the field that that it is checking for the amount of runs and retest it all.

Quote:
This is not a concern with my solution as there are no new typeIDs required.

Not true, the available bpc list for invention needs to change it's filter to filter on the amount field rather than the normalised field. And then it needs to be retested to make sure it works in all cases.

Quote:
Most things you mention here are based on new/multiple blueprint typeIDs for BPO/BPC, that is again not a concern as my proposal doesn't involve any new typeIDs. As for the tests: All Blueprint types have also "Blueprint" in their name, so you can get those out with a query. Or use the invBlueprintTypes table instead. Point is, getting the list of affected typeIDs (namely blueprints) isn't an issue and could be thrown into an array on the client side to (combined with the quantity field) distinguish copy from original. Usual singleton items would have a quantity of 1 as it is now. If a singleton blueprint, it's number of runs would be -1 (or the equivalent used with BPO number of runs) and if quantity on a blueprint typeID was >= 1 it would be a BPC with quantity as its number of runs left. Exposing this field to the EVE API as it is now would also mean one could distinguish copy from original in asset list exports.

The code changes are minimal compared to the amount of testing that would be involved. Because you are changing fundamental parts of some very low level systems, if they break then it would be a major problem for EVE. So sorry they entire thing would have to be retested rather extensively.

Quote:
This all doesn't seem to be related to my solution.
I stil believe it is doable, with the least working overhead of all the other solutions so far. Maybe I missed some critical issue but right now I can't find any.
The thing is that my proposal does not involve any database changes, no new artifial typeIDs and no additional queries on inventory listings. Has this be brought to the actual Coders doing this production/inventory thing? And believe me, I know that nothing is ever "JUST 1 LINE OF CODE" and never will be

Yes actually it is. BPC'c dropped and bpc's created through the LP system use the same mechanics as the copy process, so they would need to be tested to make sure they are working correctly. It would not be good to drop a Machariel BPO instead of a BPC now would it.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Draygo Korvan

Sun, 28 Sep 2009 21:03:00 +0000

Edited by: Draygo Korvan on 28/09/2008 21:03:29
I'm posting this here because its related:

Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail.
--

Make BPOs and BPCs distinguishable - by Imhothar Xarodit

Sun, 28 Sep 2009 11:24:00 +0000

Edited by: Imhothar Xarodit on 28/09/2008 11:24:36

Originally by: CCP Lingorm
See my post before yours (last post on page 6), your solution woudl involve all the same changes to all the same systems. Not really doable.

Ok, lemme try this out.

Quote:
And what about the changes to the system for creating copies,

Isn't creating copies already a special job, as you have to create a new item with number of runs on it. Would require an update to the inventory table (quantity field).

Quote:
the changes to manufacturing that then needs to changed different values depending if you are building from a BPO or a BPC,

Uhm, doesn't this already have to be treated specially? Like destroy a BPC if it was a copy and its runs were used up, reduce a copies runs left as opposed to a BPO? Would need to extend this step with an update on the quantity field.

Quote:
you would also need to rebuild the Invention system to now use the new BPC items not the BPO items (cos the 2 are different now).

This is not a concern with my solution as there are no new typeIDs required.

Quote:
Then you need to test ALL of these changes and that would take longer than all the code changes because you have changed so many ground level systems that you would need to explicitly test the manufacture of every item from both BPO and BPC to make sure it is working properly, then test the refine to make sure that it is refining correctly (because the refine system is linked to BPO's), then test every possible invention permutation to make sure you had not changed something and invention no longer worked.

Most things you mention here are based on new/multiple blueprint typeIDs for BPO/BPC, that is again not a concern as my proposal doesn't involve any new typeIDs. As for the tests: All Blueprint types have also "Blueprint" in their name, so you can get those out with a query. Or use the invBlueprintTypes table instead. Point is, getting the list of affected typeIDs (namely blueprints) isn't an issue and could be thrown into an array on the client side to (combined with the quantity field) distinguish copy from original.

Quote:
Modify the loot drops for ALL entities that drop BPC's to make sure they drop the new BPC item. then all the Agent LP Store offers that offer BPC's and make sure all of these are changed.

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

And that list is just off the top of my head ... I am sure that I can come up with some more if I really put my mind to it ...

But I could be wrong ... it is JUST 1 LINE OF CODE after all. Shocked

This all doesn't seem to be related to my solution.
I stil believe it is doable, with the least working overhead of all the other solutions so far. Maybe I missed some critical issue but right now I can't find any.
The thing is that my proposal does not involve any database changes, and no additional queries on inventory listings. Has this be brought to the actual Coders doing this production/inventory thing? And believe me, I know that nothing is ever "JUST 1 LINE OF CODE" and never will be

Make BPOs and BPCs distinguishable - by Nova Fox

Sun, 28 Sep 2009 06:57:00 +0000

So if i get this right.

All blueprint are attached to the item they make and are integeral part of its inofmration or vice versa.

Because of this copies are technically the same thing as original with one difference but it still doesnt change the fact its still a part of that item.

And from what I understand serparating the item tags to create 2 new groups (bpos and bpcs) would be an extrondinary hassel as supposivly every item has a blue print resulting in man years worth of rewriting that may ultimately drag eve down further the lab path as you have a not so slim database anymore.

as much as I slam my head on this problem I see no really good comprimise of system performance for our ease unless you manage to make copies a subitem of the same item similar to the blueprint original is
/\>------------------------------V
{[Blueprint Original] Item [Blueprint copy]}

Pre Order your Sisters of Eve ship today!!!

Make BPOs and BPCs distinguishable - by CCP Lingorm

Sat, 27 Sep 2009 10:49:00 +0000

Originally by: Zinnn
Edited by: Zinnn on 27/09/2008 05:20:21
Why not just add an O or a C to the top right corner of the blueprints? If you can do T1 and T2 distinguishing, why not just a simple O or a C? Doesn't have to be hugely complicated. Blue C maybe, Red O... you know, for the color blind...

Why not make that bit of code, if it's going to be extensible to make a differentiation, why not keep that coded information in cache on the local machine so you do not have to use a lookup? or does that change the entire structure of things on the server/client end?.... anyway..

Anyway, just a thought.

Because Tech 1 and Tech 2 items are seperate items as far as the Database is concerned (they have different item ID's and thus different Icons associated with them). They do not use the same Icon with a "II" added to 1 corner, these are seperate Icons, 1 with a "II" and 1 without.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Sat, 27 Sep 2009 10:48:00 +0000

Originally by: Imhothar Xarodit
Anything new on the topic "re-use the quantity field with number of runs on singular blueprints to distinguish from originals"?

That is a solution that from my point of view requires the least work.
1. No database table redefinitions.
2. No new item/blueprint types.
3. No additional queries on inventory lookups.
4. Works as soon as a BPC has been used.
5. Needs special treatment on the client's icon display.
6. The quantity fields needs to be up-to-date with the number of runs.
7. An automatable DB update on patch day.

It all boils down to how easy numbers 5 and 6 are implementable.

See my post before yours (last post on page 6), your solution woudl involve all the same changes to all the same systems. Not really doable.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Zinnn

Sat, 27 Sep 2009 05:16:00 +0000

Edited by: Zinnn on 27/09/2008 05:20:21
Why not just add an O or a C to the top right corner of the blueprints? If you can do T1 and T2 distinguishing, why not just a simple O or a C? Doesn't have to be hugely complicated. Blue C maybe, Red O... you know, for the color blind...

Why not make that bit of code, if it's going to be extensible to make a differentiation, why not keep that coded information in cache on the local machine so you do not have to use a lookup? or does that change the entire structure of things on the server/client end?.... anyway..

Anyway, just a thought.

Make BPOs and BPCs distinguishable - by Imhothar Xarodit

Fri, 26 Sep 2009 19:37:00 +0000

Anything new on the topic "re-use the quantity field with number of runs on singular blueprints to distinguish from originals"?

That is a solution that from my point of view requires the least work.
1. No database table redefinitions.
2. No new item/blueprint types.
3. No additional queries on inventory lookups.
4. Works as soon as a BPC has been used.
5. Needs special treatment on the client's icon display.
6. The quantity fields needs to be up-to-date with the number of runs.
7. An automatable DB update on patch day.

It all boils down to how easy numbers 5 and 6 are implementable.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Wed, 24 Sep 2009 16:22:00 +0000

And what about the changes to the system for creating copies, the changes to manufacturing that then needs to changed different values depending if you are building from a BPO or a BPC, you would also need to rebuild the Invention system to now use the new BPC items not the BPO items (cos the 2 are different now).

Then you need to test ALL of these changes and that would take longer than all the code changes because you have changed so many ground level systems that you would need to explicitly test the manufacture of every item from both BPO and BPC to make sure it is working properly, then test the refine to make sure that it is refining correctly (because the refine system is linked to BPO's), then test every possible invention permutation to make sure you had not changed something and invention no longer worked.

Modify the loot drops for ALL entities that drop BPC's to make sure they drop the new BPC item. then all the Agent LP Store offers that offer BPC's and make sure all of these are changed.

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

And that list is just off the top of my head ... I am sure that I can come up with some more if I really put my mind to it ...

But I could be wrong ... it is JUST 1 LINE OF CODE after all.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Jarna Civire

Wed, 24 Sep 2009 14:48:00 +0000

Originally by: CCP Lingorm
Edited by: CCP Lingorm on 11/09/2008 16:12:10
Edited by: CCP Lingorm on 11/09/2008 16:11:23
Originally by: Xiaodown

To clarify:

Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2.

You can build a Raven from TypeID 1, but TypeID 2 is useless to the system.

So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally.

When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)".

Thus, all the code changes are in the build interface, not in the inventory interface.

Possible?

Nice idea, but what if you are not using all the 'copies' on the BPC?
Also your suggestion is a lot of work, we would have to create BPC items for EVERY BPO currently in the game and then change all the code. CCP Chronotis as started a thread about Industry upgrades for the Winter expansion and one of the ideas in that is a new BluePrint Management system (so you can load you blueprints into it and them make use of them from there ... this would remove them from hangers and the standard inventory system so they would not be subject to the current normalization issues, as this system could be tailored for blueprints(.

Go have a look at that.

I have also put the suggestions for S&I interface changes that will help this problem into Chronotis hands so that they can be looked at in conjunction with this new feature.

Lot of work? A day tops... You would need a few SQL commands.

--make new items in table
INSERT INTO Items
ItemName, Mass, ... (all fields in that table that needs ot be copied from the original entry)
SELECT ItemName + ' BPO', Mass, ... (same list of fields as above plus any changes from the original entry)
FROM Items
WHERE (limit to only select blueprints, you could even filter out any BPC that never has a BPO drop)

--make temp table to match oldIds to the newIDs just created
CREATE TABLE #IdLookup
(
OldItemId int not null,
NewItemId int not null
)

INSERT INTO #IdLookup
SELECT A.ItemId, (SELECT B.ItemId FROM Items as B WHERE B.ItemName like A.ItemName + '%')
FROM Items as A
WHERE (Same as above but filter by it not having BPO in the name)

--update the player invetory for currnet BPO
UPDATE PlayerInventory
SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId)
WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently)

--update the NPC drop table
UPDATE NPCDropCrossRef
SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId)
WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently)

--Missions Reward
UPDATE MissionReward
SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId)
WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently)

--any other tables that need to be updated should follow the same update

--update all the old item names to have the BPC name
UPDATE Items
SET ItemName = ItemName + ' BPC'
WHERE (SELECT OldItemId FROM #IdLookup)

--drop the temp table
DROP TABLE #IdLookup

Obviously you would have to put in your real table names and fill in the missing data from the SQL and test it. You may even need to update more tables that I do not know of like for the market or what have you. On the client side there would be no change, unless you wanted to make the picture of the BPO change from the current.

Make BPOs and BPCs distinguishable - by Bob Farsenbruck

Sun, 21 Sep 2009 19:50:00 +0000

Edited by: Bob Farsenbruck on 21/09/2008 19:52:36
You neednt change anything in your DB i think.... just you need make 1 other image for each blueprint. ++Are blueprints images stored in the DB???

Yes. Dont create any at the DB, just do a some image edit function for invert colours.

No. Easy, create a new blueprint icon with other colour.

Sure u have any function to get the number of copies of a blueprint (-1 = original, >-1 then copy)

if fGetNumberCopies(blueprint) = -1 then
-draw blue image (as usually)
else
-draw green image (new one image what colour u want)
endif

Make BPOs and BPCs distinguishable - by Lothendra

Sun, 21 Sep 2009 18:04:00 +0000

A client-side cache as mentioned many times before is the obvious solution. Each instance, or item_id, of a blueprint is either a copy, or an original. This NEVER changes and such its "original" or "copy" state is a perfect candidate to be cached client-side.

For example, my shuttle print is "11130//1505397645" and the client would, upon first seeing this item, query its copy/orig status, find out it is an original and then store the following in its cache:

11130//1505397645 BPO

it would then see my ogre print, "2445//736139074", query it, find out it is a copy, and append it to the cache:

2445//736139074 BPC

so the cache would look like:

11130//1505397645 BPO
2445//736139074 BPC

Thus ensuring that the next time the client sees the print in my hangar, it knows how to mark it.

What the client does with the information afterwards is just a matter of taste. Personally I like the blue colour, and would prefer a small emblem on the top right stating "COPY", but the specifics don't really matter at this stage.

Make BPOs and BPCs distinguishable - by MailDeadDrop

Thu, 18 Sep 2009 16:45:00 +0000

Originally by: cuncannon
When you ask to show info it then looks the bp up to see if its a bpo or not right, so why can't a line of code be added to look up the bp in question in the data base to see if it says bpo or not without having to go show info, then all it needs is to overlay the pic of the bpo with a big green O over the top.

You *can* do that. But here's the rub. Ever notice how doing a show info takes a second or 2? Now imagine that you are an industrialist and that you have a container of 100 BPCs (or more). Do you *really* want to have to wait a minute or two just to open that container? And consider the issue from CCP's side: they're working hard to remove lag/slowness from the game. If every time someone opens their hangar, or a container, or a ship's hold, and every blueprint had that info looked up, then you've just introduced *ALOT* more database calls on the server, making things slower for everyone.

MDD
Jump Clones: 8M and NO corp switching

Make BPOs and BPCs distinguishable - by cuncannon

Wed, 17 Sep 2009 16:36:00 +0000

When you ask to show info it then looks the bp up to see if its a bpo or not right, so why can't a line of code be added to look up the bp in question in the data base to see if it says bpo or not without having to go show info, then all it needs is to overlay the pic of the bpo with a big green O over the top.

I am not sure how the data base is set up, but for instance the database has fields with the relevent info.

BP
Icon
BPO / BPC (normally a yes / no equasion)
Number runs ect ect
now in access I know you can set a look up method to see if say the 3rd field says yes (then the icon could be changed or overlaid)

Make BPOs and BPCs distinguishable - by MailDeadDrop

Tue, 16 Sep 2009 20:42:00 +0000

I believe everyone agrees that the "correct" solution would be for BPCs to have distinct typeIDs from their parent BPOs. Lingorm has said that this cannot be because a single built item may not (presently) have more than one possible blueprint. Programmaticly what this means is that somewhere in the database there's the information that "typeID X produces typeID Y" and somewhere in Eve there is the dependency that "given typeID Y, we can find typeID X which produced Y". The obvious use for this is reprocessing (presumably there's information somewhere keyed on X that lists the materials returned when Y is reprocessed).

Assuming reprocessing *is* the stumbling block, then it seems that there should be one of two ways to crack it. Either associate the reprocessing information with typeID Y directly (i.e. associate it with "Raven" not "Raven blueprint"), or uniquely identify the entries which may be used for reprocessing (i.e. typeID X is used for reprocessing; typeID Xsub1, which is a BPC, is not used for reprocessing; both are used to build typeID Y).

Once either of those changes are done, a one-time update to the database is made to detect existing BPCs and change their typeID to the new typeID for the matching BPC (e.g. if previously "typeID for Raven blueprint", then set to "typeID for Raven BPC").

The above is predicated on my assumption that the reason a built item cannot have more than one blueprint typeID associated is tangled up in the reprocessing mechanics of the game. Lingorm, if the reason is otherwise, please elaborate on why there is a 1:1 relationship.

MDD
Jump Clones: 8M and NO corp switching

Make BPOs and BPCs distinguishable - by Detes cald

Mon, 15 Sep 2009 16:08:00 +0000

Edited by: Detes cald on 15/09/2008 16:10:19
Olso i dont know if it's a good idea but if we got something like a book or a bookcase to put the BPO that will be easier for most industrialists to handle. Because its not so easy for someone to have tons of them to handle and find the 1 that needs. I believe that storing them all there and and a index them by titles or search it will be better and in order to take 1 or 2 from that book or bookcase you can simply extract them from there and use it as the system work now

its a small addon i dont know if its easy to implement but that my opinion :)

Make BPOs and BPCs distinguishable - by Shnitz

Sat, 13 Sep 2009 05:25:00 +0000

Because the query to distinguish between the two types is "ORDERS of magnitude larger than the current system", I propose a solution that sticks to the very foundations of the EVE UI,

keep the inventory query the same, however;

by Right Clicking -> Inventory -> Commands -> Science & Industry Commands -> Highlight -> BPOS

would run the expensive query and highlight the BPO's yellow or something, until the inventory is refreshed again.

Now the number of sub-menus is not set in stone but I think 5 or 6 is a good number.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Thu, 11 Sep 2009 16:11:00 +0000

Edited by: CCP Lingorm on 11/09/2008 16:12:10
Edited by: CCP Lingorm on 11/09/2008 16:11:23

Originally by: Xiaodown

To clarify:

Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2.

You can build a Raven from TypeID 1, but TypeID 2 is useless to the system.

So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally.

When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)".

Thus, all the code changes are in the build interface, not in the inventory interface.

Possible?

Nice idea, but what if you are not using all the 'copies' on the BPC?
Also your suggestion is a lot of work, we would have to create BPC items for EVERY BPO currently in the game and then change all the code. CCP Chronotis as started a thread about Industry upgrades for the Winter expansion and one of the ideas in that is a new BluePrint Management system (so you can load you blueprints into it and them make use of them from there ... this would remove them from hangers and the standard inventory system so they would not be subject to the current normalization issues, as this system could be tailored for blueprints(.

Go have a look at that.

I have also put the suggestions for S&I interface changes that will help this problem into Chronotis hands so that they can be looked at in conjunction with this new feature.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Xiaodown

Tue, 9 Sep 2009 19:35:00 +0000

Originally by: Xiaodown
Originally by: CCP Lingorm
Originally by: Raynar Alcohol
Stuff

more stuff

Just tossing ideas out here - what about this:
An object can't have 2 creator blueprints, so this limits the ability of some otherwise seemingly workable ideas...
What if - when you produce a BPC, it gets a separate TypeID, and then the code for the actual production is tweaked to account for it?

I.e. essentially when you build something from a BPC, the build system would recognize that it's not the right TypeID of Y to build X item, but it would intercept this, send the BPC to a subroutine whereby your BPC is altered or destroyed (based on how many runs you build) before returning it to you (or not), and what actually gets installed in the job system is a standard [BPO + normalization code to turn it into essentially a BPC as they work now].

So, basically, when you create a BPC, you would create an item with a different TypeID that is (as the code stands now) worthless and incapable of actually doing anything, and then the code changes would all be on the science/technology tab to correctly interpret them.

So, you want to build something from a BPC, but it's the wrong TypeID. The build system accepts your BPC of different type, reads its attributes, and creates a BPO with the normalized data to make it a [BPC with X, Y, and Z specs], and installs that into the actual job. Meanwhile, it keeps your (worthless, wrong TypeID) BPC in a separate location, and at the conclusion of the build job, alters its attributes and either destroys it or gives it back to you, while the (newly created) BPO+normalized_data gets destroyed, never to have actually been held by the player.

This would mean that you could do all sorts of stuff on BPCs in inventory because they're a different TypeID, without significantly increasing database queries that display inventory; your database and CPU hits would all only be when jobs are installed in the Science/Technology tab, which is used far less often than the inventory tab.

Meh?

X

To clarify:

Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2.

You can build a Raven from TypeID 1, but TypeID 2 is useless to the system.

So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally.

When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)".

Thus, all the code changes are in the build interface, not in the inventory interface.

Possible?
--

Sig under construction.

Make BPOs and BPCs distinguishable - by Xiaodown

Tue, 9 Sep 2009 19:23:00 +0000

Originally by: CCP Lingorm
Originally by: Raynar Alcohol
Edited by: Raynar Alcohol on 03/09/2008 14:22:08
I have already posted my idea, however it was probably expressed too complicated/wrong

Current situation:
same TypeId for BPO/BPC and this information is stored in the normalized table.
The problem is the very expensive table join to output that data.

Solution:
make one TypeId for the BPO and one for the BPC.

A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC.

This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup.

Is this too simple?

Except as stated before, in the current normalized db structure, an object can not have 2 creator Blueprints. So we could not tie the output of the new bpc type to an object so they would not produce anything while consuming minerals.

Just tossing ideas out here - what about this:
An object can't have 2 creator blueprints, so this limits the ability of some otherwise seemingly workable ideas...
What if - when you produce a BPC, it gets a separate TypeID, and then the code for the actual production is tweaked to account for it?

I.e. essentially when you build something from a BPC, the build system would recognize that it's not the right TypeID of Y to build X item, but it would intercept this, send the BPC to a subroutine whereby your BPC is altered or destroyed (based on how many runs you build) before returning it to you (or not), and what actually gets installed in the job system is a standard [BPO + normalization code to turn it into essentially a BPC as they work now].

So, basically, when you create a BPC, you would create an item with a different TypeID that is (as the code stands now) worthless and incapable of actually doing anything, and then the code changes would all be on the science/technology tab to correctly interpret them.

So, you want to build something from a BPC, but it's the wrong TypeID. The build system accepts your BPC of different type, reads its attributes, and creates a BPO with the normalized data to make it a [BPC with X, Y, and Z specs], and installs that into the actual job. Meanwhile, it keeps your (worthless, wrong TypeID) BPC in a separate location, and at the conclusion of the build job, alters its attributes and either destroys it or gives it back to you, while the (newly created) BPO+normalized_data gets destroyed, never to have actually been held by the player.

This would mean that you could do all sorts of stuff on BPCs in inventory because they're a different TypeID, without significantly increasing database queries that display inventory; your database and CPU hits would all only be when jobs are installed in the Science/Technology tab, which is used far less often than the inventory tab.

Meh?

X
--

Sig under construction.

Make BPOs and BPCs distinguishable - by Imhothar Xarodit

Thu, 4 Sep 2009 11:17:00 +0000

Edited by: Imhothar Xarodit on 04/09/2008 11:21:39
Lingorm, thanks for al the clarification on how the EVE DB works.

If I remember correctly, every BPC is initially ALWAYS unpackaged (if this is not always the case, time to change it), meaning the singleton entry is 1 or true or whatever. Now a singleton item has no quantity (well implyed 1).

So, what do you think about re-using the quantity field and instead store the number of runs left on a BPC there, as the quantity field does not have any other function for singleton items.

Yes, it would create a redundancy to the attributes table, but seeing as this field is already present, it wouldn't take up more storage. You would only have to update the field when a BPC is created/used (which you have to do anyway when it is retrieved from a job and placed into the inventory).

If the client encounters a blueprint typeID it checks if it is a singleton, and if its quantity is
!= -1 (or simply different from what a BPO would have), the client can distinguish between BPO and BPC and could even display the number of runs left on the blueprint icon (like in the top right corner instead of bottom right, so it cannot be confused with a stack of repackaged BPOs).

Is this a possible solution?
If the DB is layed out as I understood it, there shouldn't be any issues with implementing it.

Pros:
No access to the attributes table on inventory lookups.
The ability to display the number of runs left on the blueprint icon without having to open the info dialog would be a mega plus!
The existence of the number of runs on a blueprint icon would automatically distinguish it from a BPO!

Cons:
It must be guaranteed that all BPCs are created as singleton, without exceptions.
The quantity field must be kept up-to-date with the correct numberOfRuns (every time it is used in a job and put back into the hangar).
The client has to treat a special case.
When the patch is applied you have to run a rather lengthy DB job to update all the quantity fields.

This would be a total win for everyone working with BPCs!

Make BPOs and BPCs distinguishable - by CCP Lingorm

Wed, 3 Sep 2009 16:16:00 +0000

Originally by: Jarne
Edited by: Jarne on 03/09/2008 14:19:33
All nice and good, but PLEASE make us at least use the science&industry interface to move our BPs from where they are.

Right now I can

a.) look into the science&industry interface and nicely distinguish my BPOs and BPCs (but not move them!)

OR

b.) look into the inventory and separate BPOs from BPCs by clicking on EACH AND EVERY one, looking if it's original or copy, and then moving it (or not)

That's totally stupid. On the one hand I have all needed information, but can't do anything with it, on the other hand I don't have ANY information without awkwardly clicking me to death, but at least I can use it?!

Edit: Haven't used the science&industry interface for ages... was just too depressing. maybe it's already implemented in some way, then just ignore me :).

This is what we are looking into. Improving the usability of the S&I interface rather than the Inventory system.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by CCP Lingorm

Wed, 3 Sep 2009 16:15:00 +0000

Originally by: Raynar Alcohol
Edited by: Raynar Alcohol on 03/09/2008 14:22:08
I have already posted my idea, however it was probably expressed too complicated/wrong

Current situation:
same TypeId for BPO/BPC and this information is stored in the normalized table.
The problem is the very expensive table join to output that data.

Solution:
make one TypeId for the BPO and one for the BPC.

A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC.

This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup.

Is this too simple?

Except as stated before, in the current normalized db structure, an object can not have 2 creator Blueprints. So we could not tie the output of the new bpc type to an object so they would not produce anything while consuming minerals.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Raynar Alcohol

Wed, 3 Sep 2009 14:17:00 +0000

Edited by: Raynar Alcohol on 03/09/2008 14:22:08

Originally by: CCP Lingorm
itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity (this is in the staticDB dump we provide)

Basically what you get out of the inventory API (which has some names added for ease).

If you are really interested in the detail then have a look at the static data dump as it has all the tables and structures.

I have already posted my idea, however it was probably expressed too complicated/wrong

Current situation:
same TypeId for BPO/BPC and this information is stored in the normalized table.
The problem is the very expensive table join to output that data.

Solution:
make one TypeId for the BPO and one for the BPC.

A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC.

This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup.

Is this too simple?

Make BPOs and BPCs distinguishable - by Jarne

Wed, 3 Sep 2009 14:15:00 +0000

Edited by: Jarne on 03/09/2008 14:19:33
All nice and good, but PLEASE make us at least use the science&industry interface to move our BPs from where they are.

Right now I can

a.) look into the science&industry interface and nicely distinguish my BPOs and BPCs (but not move them!)

OR

b.) look into the inventory and separate BPOs from BPCs by clicking on EACH AND EVERY one, looking if it's original or copy, and then moving it (or not)

That's totally stupid. On the one hand I have all needed information, but can't do anything with it, on the other hand I don't have ANY information without awkwardly clicking me to death, but at least I can use it?!

Edit: Haven't used the science&industry interface for ages... was just too depressing. maybe it's already implemented in some way, then just ignore me :).
-
Success=Achievements/Expectations

Make BPOs and BPCs distinguishable - by CCP Lingorm

Wed, 3 Sep 2009 13:01:00 +0000

To reiterate things.

When you get an asset listing sent to your client the resulting data has NO entries for, if it is an original or a copy, it does not know how many runs are on it so sorting or flaging by that information is not possible.

To show you the change that would be need (in psuedo SQL not the full SQL) look below.

Current get asset listing.

Select itemID, graphicID, singular, amount From inventory Where characterID = and locationID =

Nice and simple.

The change would be to something like this.

Select i.itemID, i.graphicID, i.singular, i.amount, ia.invAttri as runCount from inventory i right outer join inventoryAttributes ia (right outer join attributes a on ia.attribute = a.attribute) on i.itemID = ia.itemID where a.attribute = 1234 and i.characterID = and i.locationID =

As you can see this is ORDERS of magnitude larger than the current system. and this would have to be run EVERYTIME you wanted you inventory list. This would have a significant impact on the performance of the db and therefore will not be implemented.

We have identified that using the more targeted returns from the Science and Industry interface returns the required information and are looking at ways to make this more usable to overcome this issue. But a change to show the difference in your hanger inventory is not going to happen.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Make BPOs and BPCs distinguishable - by Saffin

Wed, 3 Sep 2009 12:43:00 +0000

Have to admit i havent read the entire thread. So ignore me if this is said earlier and answered.

But if changing the icon is no no, is it possible (without adding signicant load) to make sort by type sort by type then number of runs ascending, that way there would be no visual clue, but the bpos would always be first in the list of their type.

Saf

Make BPOs and BPCs distinguishable - by db Deckard

Tue, 2 Sep 2009 21:31:00 +0000

Originally by: Thevlyn
Edited by: Thevlyn on 29/08/2008 03:17:45
why not just change the color of all BPO's, while i understand the idea of a blue blueprint is based on actual BPs, it would be a whole lot easier if all BPO's were a different color, like red.

This whole discussion devolved into a SQL and Database discussion. The bottom line is that the UI has no ojective way for a player to determine if a blueprint is a copy or an original.

If assettype = "Original" then color red else color blue

This really should not be that hard to do

db