EVE Search - Make BPOs and BPCs distinguishable

Check My IP Information

All Channels

Player Features and Ideas Discussion

Make BPOs and BPCs distinguishable

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 3 4 5 6 7 8 9 :: [one page]

Author	Thread Statistics \| Show CCP posts - 29 post(s)
Joe Starbreaker	Posted - 2008.05.16 16:51:00 - [1] CCP, it's really hard to tell BPOs and BPCs apart. Right-clicking to "show info" on every single blueprint is a pain in the backside, especially when you've got hundreds of blueprints. I am here to request a color change. Let BPO icons be blue on white and BPC be white on blue, or something like that. ---------------- [insert signature here]
Jinx Barker GFB Scientific	Posted - 2008.05.16 16:57:00 - [2] They cant. CCP Devs posted about it before, something to do with the way Database process the BPOs/BPCs - would be impossible, or rather Lag Causing - to do the delineation between them in color. I think because it will have to treat each BPC as a unique DB item, and create each additional entry in the system for each BPC and so forth and so on, basically lagging EVE to hell and back.
Joe Zalt	Posted - 2008.05.16 17:01:00 - [3] Edited by: Joe Zalt on 16/05/2008 17:01:43 Funny, they can show locked/unlocked BPCs in a different color. I don't buy the excuse. EDIT: Oops alt post.
Jinx Barker GFB Scientific	Posted - 2008.05.16 17:21:00 - [4] Originally by: Joe Zalt Funny, they can show locked/unlocked BPCs in a different color. I don't buy the excuse. EDIT: Oops alt post. Well, thats what CCP told us. But, by all means... I am certainly not against more clarity when it comes to things...
Somatic Neuron	Posted - 2008.05.17 11:41:00 - [5] You'd think that they could add a TypeAttribute to the local cache that would provide a BPC graphicID and the item could be looked at to see if it has a number of runs associated with it and then set the state of the item, much like they do with locked items, and change the graphic to indicate its BPC status based on that indicator. ----------

CCP Lingorm C C P	Posted - 2008.05.17 13:21:00 - [6] The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. 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.

Raven Timoshenko Flying While Intoxicated The Threshold	Posted - 2008.05.17 16:35:00 - [7] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. Just slightlly off track, but if we can get an export to CSV / XML option for all the BPs in the Corp R&D Section through the S&I interface, it would really help matters. Removable Implants and Money Sinks
Somatic Neuron	Posted - 2008.05.17 17:04:00 - [8] Edited by: Somatic Neuron on 17/05/2008 17:04:34 Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. It would seem obvious to me, that the BPC marker is stored by itemID at some point in the database, otherwise how could we see that it was a copy when we viewed its info? Here would be a very simple workaround to make everyone happy. When you display any item of a type that is a blueprint, you look at the local cache. If that local cache shows that itemID has ever had the appropriate information downloaded, you display a BPC icon. If not, you show a BPO icon. That way the database doesn't get any more calls than it currently does, and when people need to tell at a glance which BP is a copy and which is an original, it is simple matter to view that info in the S&I window once, and then the local cache is updated to store that BPC indicator for that itemID....and tada, everyone is happy. Database guys because no additional hits on the database, Devs because people stop *****ing at them about this issue, and players because we get what we have been begging for since day 1. ----------
Danton Marcellus Nebula Rasa Holdings	Posted - 2008.05.17 17:13:00 - [9] Can you just sticky this thread? This gets asked every other day. Should/would/could have, HAVE you chav! Also Known As
Zarch AlDain Hematite Rose Bionic Dawn	Posted - 2008.05.17 19:15:00 - [10] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. Except that the S&I interface doesn't work for blueprints in containers or in labs. It doesn't allow you to multi-select...etc etc The excuse doesn't wash either. Simply split the blueprint originals and copies into different types. The copy operation can generate the new type and a downtime script can convert the existing ones. Yes I know it's a bit of extra work than that since you need to adjust the manufacturing slots to take both types etc but fundamentally it's not a huge job and it would save all industrialists a lot of hassle. Zarch AlDain ---- My corp is recruiting. See the recruitment thread here.

Joe Starbreaker	Posted - 2008.05.17 19:37:00 - [11] Maybe database design is the issue here. I can't see why you couldn't alter the design a bit so that it wouldn't have to be so much work to distinguish blueprints. I don't think this is a minor issue -- industrialists, researchers, and traders look at dozens to hundreds of blueprints on a regular basis. Not knowing what you're seeing is a huge hassle and probably leads to a lot of mistakes made, fraudulent contracts, and confusion for newbies. ---------------- [insert signature here]
xena zena Catalyst Corporation Dominatus Phasmatis	Posted - 2008.05.17 21:04:00 - [12] of course the change would be kinda drastic, but instead of one item type/code for a blueprint, why not two, bpo code and bpc code... I presume each inventory item has a code that determines item type for display of icons and such. Instead of one type for a blueprint, why not two? Then convert the existing database during some extended downtime or whatever.. problem solved, no additional joins and database overhead... just another type. (which should of been done from the start, imho). Just a thought.. you could fix the problem, it would of course require a little work.
Nova Fox Gallente	Posted - 2008.05.17 22:22:00 - [13] the only i see this being possible if they make it so that bpos are unresearchable. New Ship Idea: Tender Supply Ship, The Logistics Sister
xena zena Catalyst Corporation Dominatus Phasmatis	Posted - 2008.05.17 22:34:00 - [14] Originally by: Nova Fox the only i see this being possible if they make it so that bpos are unresearchable. how in what universe does that even remotely make sense? problem is: items in your inventory is displayed from an query of a table that doesn't contain the data of if a blueprint is a copy or original, to get that info you have to query another table that contains the details/stats of the item. Also that a blueprint "type code" is the same regardless if it's original or copy, so the only way to tell is to get info from the item details table, and that takes far more server resources then they want to commit for the small gain of seeing which type a blueprint is. researchability of a blueprint has absolutely no link to the stated problem, ergo, your comment makes no sense. Option is to increase server load to display this (more lag) or to change the way blueprints are stored in the inventory table (my suggestion to give bpo's and bpc's different item "codes")
Somatic Neuron	Posted - 2008.05.17 23:09:00 - [15] Originally by: xena zena problem is: items in your inventory is displayed from an query of a table that doesn't contain the data of if a blueprint is a copy or original, to get that info you have to query another table that contains the details/stats of the item. Also that a blueprint "type code" is the same regardless if it's original or copy, so the only way to tell is to get info from the item details table, and that takes far more server resources then they want to commit for the small gain of seeing which type a blueprint is. Option is to increase server load to display this (more lag) or to change the way blueprints are stored in the inventory table (my suggestion to give bpo's and bpc's different item "codes") The solution has already been posted....requires no more server resources, nor does it cause addition lag. For the solution, click here ----------
Kazuo Ishiguro House of Marbles Zzz	Posted - 2008.05.18 00:01:00 - [16] I forget - does the API tell people whether blueprints are originals or not? My research services Spreadsheets: Top speed calculation - Halo Implant stats
Nova Fox Gallente	Posted - 2008.05.18 00:52:00 - [17] let me put it like this a packaged ship has no extra info on it, it has no modules no rigs no damage unpack it take it out for a ride and get ti beat up and fit some stuff on it its entirely different item now. the packaged ship would still be possible for i to be a 'different' item form the unpackaged ship but soon as you can package it back up it becomes uniform to the original item. Unless there was a way to give bpos a ship like treatment unresearched bpos behave the same way its possible to repackage them and stack them. However once researched its gone. it may be very possible for them to make icons for an unresearched bpo and a researched bpo different, but to constantly check which it is would be lag inducing. But that would be like having modules turn red if they where damaged or something it eats up bandwidth and if you have like 4000 bpos you can imagine the amount of calls have to be made. But basically they would have to rewrite the entire area of the database to deal with bpo/bpcs in order to have this feature, and im afraid that if they do this all of our previous bpo research could get nullified. New Ship Idea: Tender Supply Ship, The Logistics Sister
Kuroshiro	Posted - 2008.05.18 02:07:00 - [18] Originally by: CCP Lingorm A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. This would be a more practical workaround if the entries in this list were not gigantic and if the list did not reset to the top every time you start a job on one of your blueprints. Currently as it is, you scroll down through a hundred blueprints, start a job on the first blueprint you want to work with, then have your position reset to the top of the list so you have to scroll down again to find the next blueprint. All of this assumes also that your blueprints are located in your top level hangar, which is an organizational disaster. Could we get 'hangar tabs' like you get for corporate hangars?
Jurgen Cartis Caldari Interstellar Corporation of Exploration Nex Eternus	Posted - 2008.05.18 07:22:00 - [19] Originally by: Nova Fox <stuff> BPOs ARE like ships, they all start the same, but once researched they're JUST LIKE that damaged Raven, except you cannot repackage a BPO. They have some base values in the DB (Skills needed, materials, etc.) and some that differ from print to print and ship to ship (ME, Runs/IsCopy) The idea most frequently put forward is for two SEPARATE itemIDs, each with pretty much the same set of parameters, one for BPO, one for BPC With the current inventory system, we can see that Blueprint A is, say, an Ibis BP, but we can't see ME/PE/Runs unless we get info on it. Okay, lets make two new item types, Ibis BPO and Ibis BPC. If it's a BPO, then the client can tell that from the itemID, no need to call for any more specific data unless I specifically query that. Ditto for the BPC, all its info isn't queried until asked for, but the item type itself is enough to tell the client it's a BPC and stick a little 'C' in the top left corner. The idea is to make it so they don't need to query specific data about a print to tell if its BPC or BPO, the type alone would contain it. -------------------- ICE Blueprint Sales FIRST!! -Yipsilanti Pfft. Never such a thing as a "last chance". ;) -Rauth
Kirov VIII	Posted - 2008.05.18 11:24:00 - [20] I'm sorry but if we can't have this information, the database isn't correctly designed for this game and you need to work on that ... Take the time for important things (all days problems on EvE) not add an another owerpowered ships not really needed ... Create a 5th Amarr OOMPH because they are always crap actually and stop to boost race already correctly balanced (like the caldari and em missile), review a little the contract for take less time to create multiple contract and select more than one item its for the player and for the DB, make something for the EvE logs on our HDD because it's really not good for actual and future HDD, rework on your source code for share load between ALL servers ... You have a LOT of WORK CCP, stop to create new useless contents. THX

Schani Kratnorr x13	Posted - 2008.05.18 11:51:00 - [21] Green for BPCs and Blue for BPOs. redesign databse, go go go (Or do we need to remind you who pays your bills?)
Elisa Day Koshaku Brutally Clever Empire	Posted - 2008.05.18 15:25:00 - [22] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. I'm not an expert DB programmmer, but from my experience with the data export shouldn't this work and be (relatively) painless: 1. In invtypes, make a copy of each blueprint type so that there is now one "pwn module blueprint" and one "pwn module blueprint copy". Use a different color BG for the icon rendering on this type. 2. When you make a BPC, instead of returning a "blueprint" type item, return a "blueprint copy" type icon. 3. On DT when the patch is applied, run a script that converts all current copies that are the "old" type to the new "copy" type. This would double the amount of BP types in the database but I don't see that as a big problem. In short, make the distinction happen when the BP is copied, so that it doesn't need to be "looked up" every time you view a BP.
Doc Iridium Amarr Viziam	Posted - 2008.05.18 16:49:00 - [23] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. Simple solution: Two new types of containers. BPO books and BPC books, perhaps BPO and BPC books for different types and teirs of modules. If you try to put a BPO into a BPC book, it won't go. If you try to put a BPC into a BPO book, it won't go. Just like the way weapon modules work today. You can only put certain types of ammo in certain types of weapons, why not a container that works like a weapon module? I imagine the database manipulation would be similar. Additionally you might even create a new station tab specifically for blueprints and blueprint books. There is already one for ships, and another for everything else. Well, I've said my piece - wait, is that Veldspar over there? Woot!
Somatic Neuron	Posted - 2008.05.18 18:33:00 - [24] Come on people, the answer isn't "Adding more types to the database"...the information is already out there, and there is no reason to change the database structures or calls at all. Check here for the solution....we just need to get a Dev to see it. ----------
Joe Starbreaker	Posted - 2008.05.19 00:09:00 - [25] Originally by: Schani Kratnorr Green for BPCs and Blue for BPOs. redesign databse, go go go (Or do we need to remind you who pays your bills?) See I was thinking it'd be white lines on blue for the original (like an old-time 'master' for a ditto machine) and blue lines on white for the copy. ---------------- [insert signature here]
Gina Torelli	Posted - 2008.05.19 09:38:00 - [26] Edited by: Gina Torelli on 19/05/2008 09:38:51 ... how about this. All BPO's id's are stored in a specific interval, assuming you are referencing the items by their primary key (Because if your not, im not sure how you are doing it? ;) ). Then all BPC are stored in a different interval of ID's. Let the UI destinguish between icons based on ID's. Same number of queries, but with an UI change. ... ???

CCP Lingorm C C P	Posted - 2008.05.19 10:04:00 - [27] 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. As for the S&I interface not allowing you to filter the view, the Corp one allows you to filter by individual hanger and you can filter by Original or Copy. The 'Personal view allows you to filter by Original/Copy. As for the list resetting to the top, I will have a chat with the UI dude, and see what we can do about it (I hate it too), I will also ask about getting a list of BP's in labs or Factories in a useable manner. This will not make the next expansion, but hopefully in one of the 'point' releases we can get it in. 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.

Zarch AlDain Hematite Rose Bionic Dawn	Posted - 2008.05.19 10:34:00 - [28] Thanks for the replies on this Lingorm...it sounds like you might be an industrialist yourself since you seem to know the pain :) My alt's invention corporation usually has somewhere between one and two thousand blueprints, of which around 3/4 are BPCs at any time. We are a dedicated corp so we use multiple hangars to sort them and yet we still end up needing containers to sort more. As soon as they go in containers or we take them out to the pos labs then we can't use the S&I screen. The big things that would make a HUGE difference are: Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing). S&I screen working in labs and containers. The list not jumping back up to the top. I understand something is being done to overhaul the whole S&I process in a coming patch so hopefully we will see improvements in this area at the same time. Zarch AlDain ---- My corp is recruiting. See the recruitment thread here.
Raynar Alcohol Omega Fleet Enterprises Executive Outcomes	Posted - 2008.05.19 11:06:00 - [29] Edited by: Raynar Alcohol on 19/05/2008 11:08:32 Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A simple solution would be to clone the item, just create two different items, one BPO and one BPC. If you copy a BPO, a BPC with a different itemId should be created. This should solve the join problem quite easily and it allows the use of another icon. -- Computer games donÆt affect kids. I mean if Pac-Man affected us as kids, weÆd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music.
Sunbird Huy Yarrtards With Epeen	Posted - 2008.05.19 11:13:00 - [30] one question, how the hell would u be able to make difference between the ME and PE on the bpc's on market? u would still have to check the info anyway.

Doc Iridium Amarr Viziam	Posted - 2008.05.19 12:14:00 - [31] 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. As for the S&I interface not allowing you to filter the view, the Corp one allows you to filter by individual hanger and you can filter by Original or Copy. The 'Personal view allows you to filter by Original/Copy. As for the list resetting to the top, I will have a chat with the UI dude, and see what we can do about it (I hate it too), I will also ask about getting a list of BP's in labs or Factories in a useable manner. This will not make the next expansion, but hopefully in one of the 'point' releases we can get it in. Honestly, I think the entire blueprint system needs to be scrapped and rebuilt if it's this much effort to make it sanely functional. If it used more database space, so what. Right now the blueprint dysfunction is as maddening for me as the PVP broken-ness :P Well, I've said my piece - wait, is that Veldspar over there? Woot!
Somatic Neuron	Posted - 2008.05.19 13:36:00 - [32] 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. As for the S&I interface not allowing you to filter the view, the Corp one allows you to filter by individual hanger and you can filter by Original or Copy. The 'Personal view allows you to filter by Original/Copy. As for the list resetting to the top, I will have a chat with the UI dude, and see what we can do about it (I hate it too), I will also ask about getting a list of BP's in labs or Factories in a useable manner. This will not make the next expansion, but hopefully in one of the 'point' releases we can get it in. So is my local cache idea not doable then? It wouldn't require any database changes or additional calls to the database... ----------

CCP Lingorm C C P	Posted - 2008.05.19 14:16:00 - [33] The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. The issue with making a BPO and BPC base item are that at the moment each item can only have 1 blue print associated with it. This is a limitation we have looked at and would like to change (we could then implement alternate builds for items, so that you could build it from 2x, 3y, 1z or 2u, 3y, 1z for example). The rest of the blue print structure is actually very good and works perfectly. As stated before would could do the 'different' marker (icon overlay or such) but the db query overhead is not acceptable at this time for general inventory lookups. As for the number of items in a hanger and not being able to use containers, I know that pain (Looks into his Corporate hanger to see cans called "Caldari Battleship BPC's", "Gallente Battleship BPC's" ... "Caldari Cruiser BPC's", etc etc). I am not sure that anything can be done about this because of the recursion routines but it is something that I would like ... or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it. Yes, I am an industrial player .... so I can understand your pain ... I do some pvp as well though grin. 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.

Somatic Neuron	Posted - 2008.05.19 15:06:00 - [34] Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. To be honest, I think that is something we could live with...as it is much much better than the options available to us today. Anyone else agree with me on that sentiment? As an add-on suggestion to this, would it be possible to make that local cache file a seperate, shareable, file for each corp, so that we could then transfer the file between computers? ----------
shady trader	Posted - 2008.05.19 20:29:00 - [35] Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. The issue with making a BPO and BPC base item are that at the moment each item can only have 1 blue print associated with it. This is a limitation we have looked at and would like to change (we could then implement alternate builds for items, so that you could build it from 2x, 3y, 1z or 2u, 3y, 1z for example). The rest of the blue print structure is actually very good and works perfectly. As stated before would could do the 'different' marker (icon overlay or such) but the db query overhead is not acceptable at this time for general inventory lookups. As for the number of items in a hanger and not being able to use containers, I know that pain (Looks into his Corporate hanger to see cans called "Caldari Battleship BPC's", "Gallente Battleship BPC's" ... "Caldari Cruiser BPC's", etc etc). I am not sure that anything can be done about this because of the recursion routines but it is something that I would like ... or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it. Yes, I am an industrial player .... so I can understand your pain ... I do some pvp as well though grin. One way could be to have say Yellow for known BPC's and say green for known BPO's and if a BP is not known due to it not being in the cache leave it blue. This way people can see the difference if they have accessed as well as knowing if they have not looked at it. Macrointel, the place were the nature order of the universe does not hold sway. Pirates and ore thief's are congrated by carebears for the actions.
Jurgen Cartis Caldari Interstellar Corporation of Exploration Nex Eternus	Posted - 2008.05.19 20:31:00 - [36] Originally by: Somatic Neuron Originally by: CCP Lingorm <Dev Communication> To be honest, I think that is something we could live with...as it is much much better than the options available to us today. Anyone else agree with me on that sentiment? As an add-on suggestion to this, would it be possible to make that local cache file a seperate, shareable, file for each corp, so that we could then transfer the file between computers? Most of us only play Eve on one computer, while this idea would blow for those who play at cybercafes, for example, those who simply play from a home computer could make full use of it. -------------------- ICE Blueprint Sales FIRST!! -Yipsilanti Pfft. Never such a thing as a "last chance". ;) -Rauth
Doc Iridium Amarr Viziam	Posted - 2008.05.20 08:52:00 - [37] Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. I do not believe it would create any more confusion than losing all the data that is already stored locally on the client. It's a sub-optimal solution, but better than no solution. If the BPO/BPC organizational process is simple to start, then it could be processing while the player sets up their preferences on the new machine, or with the new build. I still think the creation of containers that are restricted to holding only BPO's or BPC's is a optimal situation, offering a high level of organization, depending on how many book types are created. Perhaps books based on what POS assembly modules can build? Small ship Book does frigs, dessies, and fighters. Depending on how modular your database is, you could then strip acceptable BPO types from the POS module build allowability tables to generate tables of what BPO's will fit in which books, and compare infinite to non-infinite builds for full determination of where each BPO might go. Even if these books are local storage only, and would revert to unassembled containers with loose blueprints in open inventory after moving to a new computer, or reinstalling a new client, it would be _very_ much worth it. Allowing a select-all-and-drop onto a book, while allowing the appropriate items to drop into the book without non-appropriate types stopping the process would be very fast sorting compared to bpo sorting methods used today, and could be done with a low priority so as to not overburden the servers if they are operating under heavy load. and finally, what would stop the client from making a determination as to status of BPC's then requesting permission to sort and color them? "It seems that you have blueprint copies that are not visually different from your blueprint originals. Shall I adjust the color of blueprints so you can tell copies from originals?" I suppose my biggest confusion is that there are already two colors of BP. There are some that are an odd shade of purple, and then there are the common blue ones. The colors are apparently not associated with any meaning. However the fact that there are already two colors of BPO seems to indicate that at least some of the work required to organize BPO's by image is already coded. Well, I've said my piece - wait, is that Veldspar over there? Woot!
J'Mkarr Soban Amarr Proxenetae Invicti	Posted - 2008.05.20 13:43:00 - [38] Lingorm: Why not have an extremely simple method that the first time a BP is loaded from the DB to the local cache, an easy if (productionRunsRemaining > -1) then BPImage.setColourFilter("green"); is run? As one who works with databases, the idea of storing derived data is abhorrent to me, but this is usually how things work when taking data out in the first place. Combined with type filtering by tabs in hangers (hint hint) this wouldn't add much overhead, especially given the cap of 1000(?) item types in a hanger. -- These are my personal views and in no way represent the views of Proxenetae Invicti, which maintains a neutral stance stemming from the strong ethics demanded of its work.
Zirconium Blade Ass Pounding Space Monkeys	Posted - 2008.05.20 20:05:00 - [39] Bumpin this, cause its got a Dev response and if its on the front page we might get less of these threads created.
Ki Tarra Caldari Ki Tech Industries	Posted - 2008.05.20 22:11:00 - [40] Originally by: CCP Lingorm Stuff So basicly this comes down to the fact that BPO's and BPC's both used the same typeID. The only way that we could see seperate icons for BPO's and BPC's is if they were given different typeID's. However, doing that creates a bunch of extra work as you would need to duplicate all of the typeID's for blueprints. This could potentially lead to weird bugs if for example the copy time of the BPO's typeID was updated but the copy time for the BPC's was not. It would also require an additional attribute of BPO's indicating what the typeID is of the BPC it will produce. All in all, another mess that causes more problems than it fixes?

Guvante GALAXIAN	Posted - 2008.05.20 23:57:00 - [41] Originally by: J'Mkarr Soban Lingorm: Why not have an extremely simple method that the first time a BP is loaded from the DB to the local cache, an easy if (productionRunsRemaining > -1) then BPImage.setColourFilter("green"); is run? As one who works with databases, the idea of storing derived data is abhorrent to me, but this is usually how things work when taking data out in the first place. Combined with type filtering by tabs in hangers (hint hint) this wouldn't add much overhead, especially given the cap of 1000(?) item types in a hanger. You failed to read his note, there is no such thing as productionRunsRemaining attached to an item. That is contained in a separate DB, that is what he has said twice now >< Remember, when you open your hangar, it only gets information for what items you have and the generic properties of that item (ie its Icon). Any more specific properties require an additional look up. And about your comment of only 1000 item types, sure it is only 1000 item types, per user, and EVE has a lot of users online at once, all hitting the same DB. This is especially painful since no distributed system out there is really designed to handle extremely rapidly changing data.
Zirconium Blade Ass Pounding Space Monkeys	Posted - 2008.05.21 13:43:00 - [42] Sticky, perhaps?
TornSoul BIG	Posted - 2008.05.22 01:17:00 - [43] Edited by: TornSoul on 22/05/2008 01:19:17 Originally by: Zarch AlDain The big things that would make a HUGE difference are: Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing). Oh God yes... Pretty please with sugar on the top... Originally by: CCP Lingorm or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it. Once more - Oh God yes!
Seth Ruin Galactic Exploration and Mining Corporation	Posted - 2008.05.22 04:41:00 - [44] Originally by: Doc Iridium Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. I do not believe it would create any more confusion than losing all the data that is already stored locally on the client. It's a sub-optimal solution, but better than no solution. I agree. A sort-of "hack" like this as a hold-over until such a BPO overhaul that has been hinted at emerges would be better than having to query the DB every time one checks a BP to see if it is a BPO or BPC. Is it just me or does it seem like the design of the Blueprint system didn't expect there to be such a market for BPCs? Seems like BPCs have evolved beyond their original design, perhaps.
Wren Alterana The Baros Syndicate Kissaki Republic	Posted - 2008.05.22 06:03:00 - [45] not really a big computer person but what about having the database query for the # of runs, it doesn't have to know how many runs are remaining, just the fact that it contains that category, if it does it recolors it. or would that cause too much lag? I wouldn't think one additional factor when querying the database would cause too much strain. _________ Dynamic Maps

CCP Lingorm C C P	Posted - 2008.05.22 09:48:00 - [46] Because the numberOfRuns attribute is still present on a BPO it just contains -1 which means unlimited runs. 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.

Kuroshiro	Posted - 2008.05.22 15:46:00 - [47] Originally by: CCP Lingorm Because the numberOfRuns attribute is still present on a BPO it just contains -1 which means unlimited runs. If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
procurement specialist	Posted - 2008.05.22 17:38:00 - [48] Edited by: procurement specialist on 22/05/2008 17:38:36 Originally by: TornSoul Edited by: TornSoul on 22/05/2008 01:19:17 Originally by: Zarch AlDain The big things that would make a HUGE difference are: Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing). Oh God yes... Pretty please with sugar on the top... Originally by: CCP Lingorm or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it. Once more - Oh God yes! someone is excited :D

CCP Lingorm C C P	Posted - 2008.05.22 17:56:00 - [49] Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not? Did you read the thread? This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory. This is not acceptable from a performance perspective so we do not do 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.

Zarch AlDain Hematite Rose Bionic Dawn	Posted - 2008.05.22 19:01:00 - [50] Originally by: CCP Lingorm Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not? Did you read the thread? This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory. This is not acceptable from a performance perspective so we do not do it. Please don't give up on the rest of us because of one or two idiots :( Most of us are reading and understanding. Zarch AlDain ---- My corp is recruiting. See the recruitment thread here.

Helison Times of Ancar Pure.	Posted - 2008.05.22 20:32:00 - [51] Edited by: Helison on 22/05/2008 20:32:53 no new info
Kuroshiro	Posted - 2008.05.22 20:39:00 - [52] Originally by: CCP Lingorm Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not? Did you read the thread? This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory. This is not acceptable from a performance perspective so we do not do it. Honestly? No I didn't. I'm like 99% of the customers on this planet in that I'm really not interested in what limitations poor planning in your database have created in your product, I just would like to see a solution engineered to correct or work around this deficiency in your interface. This should not be the least bit of a shock to any experienced engineer. Also, if I were to talk to my company's customers the way you just spoke to me -- well, I'm not 100% sure what would happen, but I would certainly never be allowed to talk to customers again and it would definitely show up the next time I was up for a raise. There's just no excuse for it that lack of professionalism, no matter how stupid you think the question is.
Joe Starbreaker	Posted - 2008.05.22 21:59:00 - [53] Originally by: CCP Lingorm Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not? Did you read the thread? This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory. This is not acceptable from a performance perspective so we do not do it. I'm starting to get a mental picture of your database now, and I can see the trouble. I guess that the color changes you apply to locked blueprints in containers, and blueprints in lockdown, are identified by fields in teh Inventory table, then? Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work... ---------------- [insert signature here]
Joe Starbreaker	Posted - 2008.05.22 22:01:00 - [54] Originally by: Kuroshiro There's just no excuse for it that lack of class, no matter how stupid you think the answer is. Fixed that for you... ---------------- [insert signature here]
Cutie Chaser Federal Navy Academy	Posted - 2008.05.23 04:03:00 - [55] Originally by: Joe Starbreaker Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work... To do anything along those lines I think what would be needed instead is a new set of entries into the Inventroy DB for blueprint copies, thus having 2 entries into the table for each Blue Print so that a BPC can be a distinct entity. This would be undesireable. They always said EVE is a harsh game, I didn't start to realize until recently how much of this is due to technological restrictions; 1. Lag killed your ship? Our logs show nothing! 2. Can't tell the difference between BPC and BPO? Can't be helped! In exchange for being in a world with 50k other players you make some sacrifices; thats alright by most people. The people who are not ok with it are the people who accidentally sell a BPO as a BPC. Or people who lose an expensive ship to desync and are denied a claim due to a insufficiently verbose server logging system(I would bet likely also a performance choice). *** Thats a Templar, the amarr fighter. Its a combat drone used by carriers.
Astral Water	Posted - 2008.05.23 05:09:00 - [56] Signed. Make them a different color.
Esiel	Posted - 2008.05.23 07:28:00 - [57] Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable. I would be perfectly fine with this local machine only. Its no different to me than the bookmarks I have for places. When I switch to a different machine I loose all my folders. (same goes for my buddy list) We will know that it is local machine only and so we will still organize our stuff but it will make life a bit easier. Off with your head

CCP Lingorm C C P	Posted - 2008.05.23 09:11:00 - [58] Adding fields to the inventory table is not an option. EVERY object in EVE has an entry in this table, it (along with the locations table) creates the structure for EVE. By adding fields to this table add fields to millions of items they do not apply to. Hence the normalization. We could of put every type of iten into their own table, but then the query to get your 'inventory' would have been insanely bad. 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.


CCP Lingorm C C P	Posted - 2008.05.23 09:21:00 - [59] Originally by: Kuroshiro Honestly? No I didn't. I'm like 99% of the customers on this planet in that I'm really not interested in what limitations poor planning in your database have created in your product, I just would like to see a solution engineered to correct or work around this deficiency in your interface. This should not be the least bit of a shock to any experienced engineer. Also, if I were to talk to my company's customers the way you just spoke to me -- well, I'm not 100% sure what would happen, but I would certainly never be allowed to talk to customers again and it would definitely show up the next time I was up for a raise. There's just no excuse for it that lack of professionalism, no matter how stupid you think the question is. Honestly, I was not trying to pick on you. I got this tread stickied so that we do not have to keep repeating the answers every couple of months. The answer to your question was already in the thread. As for a solution to the problem, that is what we are trying to work out? But I bet if you walked up to your db supplier and said "Your DB is badly limited because of your poor planning" they would have some choice things to say to you. We are trying to find solutions. Our DB structure is the only practicable one that will support our needs, that means we have to accept some "limitations" to be able to do what we do. We have come up with some suggestions her for possible work arounds (Remote Moves of items from Containers to Hangers, the Local cache - not fond of this myself but I will still present it to game design and programming, and some others. If you have a suggestion that might help we are all listening. 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.


CCP Lingorm C C P	Posted - 2008.05.23 09:24:00 - [60] Edited by: CCP Lingorm on 23/05/2008 09:25:59 Originally by: Joe Starbreaker I'm starting to get a mental picture of your database now, and I can see the trouble. I guess that the color changes you apply to locked blueprints in containers, and blueprints in lockdown, are identified by fields in teh Inventory table, then? Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work... Locked is one of the flags that can be set in the Inventory Table. So yes we get that on the return. The issue is that the kludge would have to be put into the query that return your inventory list, and would have to be run for EVERY single item in your Inventory, and I know I have lots of stuff other than blue prints in my inventory and this would add significant overhead to retrieving that data. 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.


Siigari Kitawa The Aduro Protocol	Posted - 2008.05.23 12:09:00 - [61] Edited by: Siigari Kitawa on 23/05/2008 12:18:17 I don't get it. There is a tag that says whether or not the blueprint is an original or not (which is at the very top of every blueprint) so why don't you make a little sticker on the right side of the blueprint similar to the tech 2 sticker, only this was says "O". I dunno, use a sticker. Seems simple to me. www.siigarikitawa.com
xttz GoonFleet GoonSwarm	Posted - 2008.05.23 13:05:00 - [62] Originally by: CCP Lingorm Locked is one of the flags that can be set in the Inventory Table. So yes we get that on the return. Out of interest, what columns are used in the Inventory table?

CCP Lingorm C C P	Posted - 2008.05.23 14:00:00 - [63] 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. 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.

Arrs Grazznic Poena Executive Solutions	Posted - 2008.05.23 14:59:00 - [64] Interesting threadà Rather than looking to see if this could be solved by a one-pass operation, would it be possible to do this in two steps? Let me explain a littleà For the purpose of BP differentiation, BPs effectively have three states or tags: 'Unknown', 'Original' and 'Copy'. The first time you view a group of BPs you would have no information on their state, so they would all be displayed as state unknown and could look exactly as they do now. This is where the second step comes in. By right clicking you could select a new option such as "Retrieve Blueprint Info". Selecting this would effectively run an optimised 'show info' query for each of the BPs in the container. The UI would use the returned data to add a small icon or tag to each BP to indicate if it was either an original or copy. The retrieved data could also be stored in the cache thus allowing the client to quickly tag the BPs when they are viewed in the future. By having the 3 states for BPs, you would get past the problem of what to display if there is no information for a BP present in the cache -- it would not have any stored state and would therefore be displayed as state unknown with no original or copy tag. Taking this one step further, the "Retrieve Blueprint Info" option could also return other info, such as ME, PE and number of runs. This information could be superimposed on the base BP image and stored in the cache as well. This would allow quite a bit of information to be displayed for BPs and would be very useful when looking through your BP lists. There would of course be quite a network and processing overhead for this operation. This could be limited in a number of ways, for example limiting a client to only be able to run the option every hour or a maximum number of times in a day, or to have the client send queries through on a BP by BP basis, but a one request every 10 seconds or so. Anyway, my 2p for the day! Cheers, Arrs
Raven Timoshenko Flying While Intoxicated The Threshold	Posted - 2008.05.23 15:20:00 - [65] Maybe this has already been said and done ( I am not 100% sure), but how about then allowing the BPs in the corp be exported via an XML or CVS file, which can then be read off an external program. It is not the perfect solution, but atleast this way we can easily run an inventory of the corporate BPs, which IMO will generally exceed the number of pilot owned BPs. Secondly how about a separate BP tab in the hangar, so the same export system can be used? This way you don't have to rewrite the db for now, until a more complete solution can be found. Just a thought. Removable Implants and Money Sinks
Kuroshiro	Posted - 2008.05.23 18:04:00 - [66] Originally by: CCP Lingorm As for a solution to the problem, that is what we are trying to work out? But I bet if you walked up to your db supplier and said "Your DB is badly limited because of your poor planning" they would have some choice things to say to you. Then they're taking their work too personally. I was merely stating that the current design has limitations that need to be worked around and would have been better to plan for from the start. There was not, encapsulated within that, the implication that the database designers are poor at their jobs or that the database is a complete failure (it clearly is not). Quote: We are trying to find solutions. Our DB structure is the only practicable one that will support our needs, that means we have to accept some "limitations" to be able to do what we do. Can you add a flag for 'bpo/bpc' to the 'flags' field? You'd need a job to set this bit for existing blueprints, but that could be run during downtime. Otherwise, when a blueprint is created, the bit is set in the appropriate inventory entry and otherwise it is copied from the source inventory entry when the item is moved. That may create additional overhead, but otherwise it's not too terrible. It's a bit annoying because that's object data being carried along with the inventory entry instead of just state data, but meh, sometimes you have to kludge to make things work. Of course, even once you get this fixed, countdown to people wanting number of runs/ME/PE on the inventory tab. A more generally useful workaround might be to provide corp hangar-style 'tabs' to invidual hangars, allowing individuals to at least keep their BPOs and BPCs separated. Of course, that may be even more complicated.
Joe Starbreaker	Posted - 2008.05.24 05:00:00 - [67] Originally by: Arrs Grazznic 3 states for BPs Yes, I really like this idea! Deliver them as obviously unknown, then let the user right-click and "check all BP types" or something, which checks and caches the blueprint types locally. From then on they should show up with differentiated icons. ---------------- [insert signature here]
Helison Times of Ancar Pure.	Posted - 2008.05.24 11:06:00 - [68] 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¦ve checked the API and the DB dump, but was not successful in locating the location of the locked-Flag (or whatever). Items within a container have an own flag for locked/unlocked, but locked BPOs within the corp-hangar only have the flag of the hangar-section. I hoped, that it could be possible to use the locked-flag for differentiating BPOs from BPCs, but this depends on how the flag is really stored. Is it an additional value in the inventory table? Have I missed any info?
ninjaholic Aliastra	Posted - 2008.05.24 21:54:00 - [69] I don't think it's a good idea, as it would only make high-sec gankers jobs easier. The ability to tell BPO's and BPC's apart would just increase their accuracy and frequency. Hell no for this idea. Nothing personal, but you're just gonna have to keep things organised. LAG-FREE fight-record tool!
Cheopis Imperial Shipment	Posted - 2008.05.25 12:11:00 - [70] 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. Do you store your flag as a single bit, or a byte? If stored as a byte, how many bits do you use for the flag?

Sha'Aryn	Posted - 2008.05.25 13:54:00 - [71] I confess I haven't read the entire thread, so please forgive me if this has already been suggested. I keep my blueprints organized by storing BPO's in one small secure container and the BPC's in another SSC - and each containter named accordingly. There's still a manual search aspect, but you only have to do it once per copy run.
Cheopis Imperial Shipment	Posted - 2008.05.27 04:57:00 - [72] Originally by: Sha'Aryn I confess I haven't read the entire thread, so please forgive me if this has already been suggested. I keep my blueprints organized by storing BPO's in one small secure container and the BPC's in another SSC - and each containter named accordingly. There's still a manual search aspect, but you only have to do it once per copy run. Most people actually do this. But when you have three accounts doing research, and you have 25x 10-max-run ammo BPC runs coming out at a time, sorting through those 260 blueprints is a serious pain.
Hawk TT Bulgarian Experienced Crackers	Posted - 2008.05.27 22:42:00 - [73] Originally by: Zarch AlDain Thanks for the replies on this Lingorm...it sounds like you might be an industrialist yourself since you seem to know the pain :) My alt's invention corporation usually has somewhere between one and two thousand blueprints, of which around 3/4 are BPCs at any time. We are a dedicated corp so we use multiple hangars to sort them and yet we still end up needing containers to sort more. As soon as they go in containers or we take them out to the pos labs then we can't use the S&I screen. The big things that would make a HUGE difference are: Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing). S&I screen working in labs and containers. The list not jumping back up to the top. I understand something is being done to overhaul the whole S&I process in a coming patch so hopefully we will see improvements in this area at the same time. Sign me in - implementing the suggestions above would solve the current issues completely. The S&I interface is the only usable option if you have to manage hundreds of BPOs / BPCs anyway.. ___________________________________ Science & Diplomacy Manager @ BECKS Sons of Tangra Alliance (SOT)
Kerdrak 3B Legio IX Atlas Alliance	Posted - 2008.05.28 13:10:00 - [74] Client side change factible? ________________________________________
Guns nButter The Nietzian Way Hydra Alliance	Posted - 2008.05.29 07:43:00 - [75] Edited by: Guns nButter on 29/05/2008 07:45:34 Edited by: Guns nButter on 29/05/2008 07:44:04 Originally by: Kerdrak Client side change factible? i believe the term you are looking for is feasible. and i was about to ask the same question until i read your post. i took basic (the language) programming in high school, and i can tell that python is waaaay over my head...(based on what i have read so far, an if/then statement wouldnt work here would it? :P) so i hope my questions aren't too dumb. when your inventory is being displayed on your screen, where is it reading from (if i may ask that)? based on that answer, is there something that could simply be put in our client that can change the appearance of BPOs compared to BPCs, based on what is read differently between them? or, possibly simply change where they are displayed in your items? (ie instead of behind unrefined minerals, in front of them, or at the very end of your items list?)
Mr Krosis The humble Crew	Posted - 2008.05.29 18:36:00 - [76] Originally by: Arrs Grazznic Rather than looking to see if this could be solved by a one-pass operation, would it be possible to do this in two steps? This is a really good idea. What do you think Lingorm, would this be acceptable as far as performance? My personal preference would be to make "unknown" blueprints a greyed out or faded color, BPCs the normal color, and add a gold border or something for BPOs. I like the idea of displaying ME and PE as well. Might need to add some new columns to the list view so people who can't see the large icon or any icon can still access it. -- Mr Krosis The greatest obstacle to discovery is not ignorance; it is the illusion of knowledge.
Kolwrath Imperial Shipment	Posted - 2008.05.30 15:37:00 - [77] Edited by: Kolwrath on 30/05/2008 15:51:23 Originally by: Kuroshiro Honestly? No I didn't. I'm like 99% of the customers on this planet in that I'm really not interested in what limitations poor planning in your database have created in your product, I just would like to see a solution engineered to correct or work around this deficiency in your interface. This should not be the least bit of a shock to any experienced engineer. Also, if I were to talk to my company's customers the way you just spoke to me -- well, I'm not 100% sure what would happen, but I would certainly never be allowed to talk to customers again and it would definitely show up the next time I was up for a raise. There's just no excuse for it that lack of professionalism, no matter how stupid you think the question is. Wow you way out of line here. You do not know what your talking about. Please read up on database normalization. Way, way out of line. To CCP: I originally thought you guys could do a simple join to the attributes table in order to read that data, but then I realized that it would add alot of overhead. What about simply creating a new ItemID for BPOs that is different from BPCs? This would solve the BPC contract scams, and also fix this BPC/ BPO identification issue. Yes its kinda clunky, and goes almost completly against the ideas of a heavily normalised DB (reduced data replication) ... but it would work. <edit> Originally by: Kuroshiro Then they're taking their work too personally. I was merely stating that the current design has limitations that need to be worked around and would have been better to plan for from the start. There was not, encapsulated within that, the implication that the database designers are poor at their jobs or that the database is a complete failure (it clearly is not). You need to word your replies better. You essentially said that CCP DB's did a crap job. That may not have been your intent, but that is how it came across. Walking up to anyone and saying that thier work is crap is not going to go over well. I doubt you will, but apologizing might be a good idea. Yes this is an item that was probably looked at in the design stage, but they chose to heavily normalize the DB for performance and size reasons, and the trade off was the removal of the ability to differentiate BPOs from BPCs without a second DB lookup (or a JOIN) in the process. </edit> Originally by: Chaos Space Marines Do you hear the voices, too?!?!
Dr Cedric The Nietzian Way Hydra Alliance	Posted - 2008.05.30 21:14:00 - [78] Originally by: Guns nButter Edited by: Guns nButter on 29/05/2008 07:45:34 Edited by: Guns nButter on 29/05/2008 07:44:04 Originally by: Kerdrak Client side change factible? i believe the term you are looking for is feasible. and i was about to ask the same question until i read your post. i took basic (the language) programming in high school, and i can tell that python is waaaay over my head...(based on what i have read so far, an if/then statement wouldnt work here would it? :P) so i hope my questions aren't too dumb. when your inventory is being displayed on your screen, where is it reading from (if i may ask that)? based on that answer, is there something that could simply be put in our client that can change the appearance of BPOs compared to BPCs, based on what is read differently between them? or, possibly simply change where they are displayed in your items? (ie instead of behind unrefined minerals, in front of them, or at the very end of your items list?) Another Database noob here, but this really does seem to make sense. You wouldn't have any more overhead on the Database, and it would be a one time thing on the player-side of the client. This way, no crazy reprogramming in the DB, and you can put a clicky button on it, just like turning on/off the upgraded graphics. This is easy and doable....right? Dr Cedric Dipolmatic Liason; Industrial Logistics Technician - The Nietzian Way -My opinions and ideas do not necessarily represent those of my corporation or alliance-
Cheopis Imperial Shipment	Posted - 2008.06.01 07:54:00 - [79] I personally would be emphatically supportive of any sort of system to differentiate between BPO's and BPC's A Client side system might actually be preferable because that would mean you could move BPO's and BPC's around, and an aggressor scanning your ship would tell exactly what it does now - only the owner would be able to see the difference between the two types. I would be unconditionally supportive of a client side database to differentiate bpos. In fact, if you really wanted to crush the CCP database some more, you could use the same technique to process ammunition, ores, etcetera. The database at CCP would store primary data on ores, say, as simply "ore" and then as the client builds the database it would query the server for what types of ores each stack really is. You might do the same for "trade goods / passengers", "Ammo, projectile", Ice products, minerals... However the differences between nonstackable items and stackable items would be a likely issue here. I have training in older computer languages, and understand logic and binary math reasonably well, but I do not fully understand your database structure - it's almost certain that stackables are stored in a different way than non-stackables. There are, however, certain items that are not stackable, that people might own in significant number. Two types off the top of my head are faction / t2 laser crystals and mining crystals. Unfortunately these items change at a much faster pace than blueprints as they degrade during use, it may be that updating them between client and server might not work so well. What about stored bookmarks? I'd be extremely suprised if there aren't still enough of those around to be a significant load on the database. If CCP is truly concerned about client side database storage for reference being something that players won't want, then make it an option like the fancy graphics.
Allen Ramses Typo Corp	Posted - 2008.06.01 23:50:00 - [80] I don't know if this is viable or not, but what about to make a near identical copy of the parent BPO to parent BPC? That way, whenever a blueprint is copied, the resulting BPC can contrast from the parent BPC, instead of the parent BPO? The only differences in it would be name, ID, and icon. For example, I have a rifter blueprint that has a ME of 20 and a PE of 10. It points to the parent rifter BPO (lets pretend it's item type 12000). I copy my rifter blueprint, and this new rifter BPC copies over all differential data from my personal BPO, but instead points to the parent rifter BPC (lets pretend it's item type 12001). It shows up in inventory as a blueprint copy, because that's what it is identified as. I know this would literally double the database space for parents required to differentiate between an original and a copy, but it's the only way I think it could be practical. ____________________ Pimped out Raven to run level 4 missions quickly: 210 Mil ISK. Realizing your 120 Mil ISK Drake gets the job done faster: Priceless.

Frecator Dementa	Posted - 2008.06.02 18:25:00 - [81] I suppose you couldn't automatically transform every bought BPO into an unique item, then use the "packaged/unpackaged" flag to mean "BPO/BPC" if the item is a blueprint? ----------------------- forum ate my post again
Koti Resci Knighthawk Light Industries	Posted - 2008.06.02 22:52:00 - [82] Edited by: Koti Resci on 02/06/2008 22:52:30 Everyone thinks it's a pain in the Dairy-aire to distinguish between BPOs and BPCs. Many are right, for their needs. But I digress! For me, it is easy. You see, I use something that not everyone knows how to use: the Science & Industry window. I've never had to move a significant number of BPCs and BPOs, or even separate the two. When I need something, I just open up the Science & Industry window and get it done. That is, until recently. I've created a large number of copies of my blueprints, more than I will need in the immediate period, and I found someone that was willing to purchase them... for a fair price, of course. But you see, now I find out that while I can use the blueprints in the Science & Industry window, I cannot move them. I'm slightly confused. The Science & Industry blueprint list looks only slightly more complicated that the Assets window's list, as compared here. In the Assets window, I can move things fairly easily. When I find an item, I can drag it to my current ship, and it will place that item in my cargohold (assuming I have enough cargo space available; if not, I will get an error message stating such). I can open a cargo container and then drag items from the Assets window to that cargo container, and the item will be placed there. Now when I accidentally created 3000 copies instead of 30 (hey, I was drunk...), I thought it wouldn't be a problem. I'd simply open up the Science & Industry window and drag all of the non-origional blueprints into a special can for them. But alas, it turns out that I cannot drag any entry from the blueprint lists in the Science & Industry window. This is rather distressful. OK, no problem... I'll just shift-click to select multiple blueprints and just contract them over from there. Oh wait, that won't work either! It turns out that I can only select one blueprint at a time. That kind've makes sense, since you aren't able to use multiple blueprints at a time. But that does prevent me from contracting them over without sorting them first. Suffice to say that the interface is already there, the client already pulls the data regarding whether or not the blueprint is a copy or not. All it needs to do is create a draggable item.
happy Dawn of a new Empire Pure.	Posted - 2008.06.04 22:56:00 - [83] how abought a filtered qurie mostly a ui quiry like sort order or somthing to off load it to the client side as a preferance the only reason i would want to distinguish a bpc is so i can move it to a container it does not need to be stored permantly on the server just a way to sort the prints so you can manualy seperate them also on a off note what hapend to being able to compare items every tim,e i open a info on a print or item it reuses the item window i like being able to compare differnt prints or item info between prints If your happy and you know it clap your hands...... and if your not happy and you know it, .....its probaly because i just podded you
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.05 16:08:00 - [84] Originally by: CCP Lingorm ... flag, contraband, singleton, quantity ... flag (bool? [locked/unlocked?]), contraband (list probably?), singleton (bool?), quantity (int?). Researched BPO's/BPC's will always have a quantity of 1 right? What does singleton mean? Does it mean an item that is unpackaged? All researched BPO's BPC's are 'unpackaged', so couldn't you use the quantity field to store what type of BPO/BPC it is, if it is researched (and thus unstackable) Essentially Researched BPO = Singleton 1, Quantity 2 (UI knows its only 1 item however) BPC = Singleton 1, Quantity 1 Unresearched BPO = Singleton 0, Quantity X Sure it would take a bit of rewriting of the inventory code, and probably a lot of testing but in the end it would be worth it. --
Chi Quan Perkone	Posted - 2008.06.05 19:29:00 - [85] let me get this straight here a bit: 1) researched bpos and bpcs have a unique id (the aforementioned itemID i persume?) 2) itemID is sent every time the inventory is requested by the client, along with typeID if both statements are correct, is it possible to give bpos an odd number in itemID and pcs an even one and that let the client do the differentiation? ---- You don't have to like it - I don't blame you for not liking it.
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.05 23:40:00 - [86] I assume based on dev responses BPC's and BPO's have the same itemID, otherwise it would be really simple fix because then you could simply change the graphic for the itemID. --
Cyberman Mastermind	Posted - 2008.06.06 07:46:00 - [87] Originally by: Draygo Korvan I assume based on dev responses BPC's and BPO's have the same itemID, otherwise it would be really simple fix because then you could simply change the graphic for the itemID. AFAIK, they have the same typeID, but the itemID is the actual unique item. So both are blueprints of type 123 but one has itemID ABC and the other DEF.
Jason Edwards	Posted - 2008.06.06 22:40:00 - [88] I know this idea might be kind of annoying... but why not just make it so when you "copy" the blueprint. It's actually creating a new type of item in of itself. So that it can essentially have at least a different picture just as any other items have different pictures. Or a sort of O or C in the top right corner like others have proposed? I just figure have a completely new item created is doable because invention creates a completely new item. ------------------------ "There was this bright flash of light - and now this egg shaped thing is on my screen - did I level up?"
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.07 04:48:00 - [89] Originally by: Jason Edwards I know this idea might be kind of annoying... but why not just make it so when you "copy" the blueprint. It's actually creating a new type of item in of itself. So that it can essentially have at least a different picture just as any other items have different pictures. Or a sort of O or C in the top right corner like others have proposed? I just figure have a completely new item created is doable because invention creates a completely new item. I don't think the devs are interested in doubling the size of their item database. --
Allen Ramses Typo Corp	Posted - 2008.06.08 09:24:00 - [90] Well, the thing is, we don't actually happen to know how much of an impact doubling the host blueprints will have on the database. It could have a significant impact on the database, but then again, it could have a trivial impact upon it. That's why it was brought up as an option, to determine the feasibility of it. I think this is a question Sharkbait might have to answer. ____________________ Pimped out Raven to run level 4 missions quickly: 210 Mil ISK. Realizing your 120 Mil ISK Drake gets the job done faster: Priceless.

Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.08 16:16:00 - [91] The reason I say that because while that would be a simple and easy 'fix', they obviously have not done it for some reason. --
Aran Aldamar	Posted - 2008.06.08 16:22:00 - [92] Originally by: CCP Lingorm This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Oh noes1!! A join! You aren't serious are you? I can see resisting a database structure change, but resisting adding a join to a query is pretty laughable. Why not just add a new item type? You have Blueprint now, just add Blueprint Copy. Sure, new set of icons to download. Not a big deal. At least it would be really obvious which BPs are copies. The S&I interface is awful. No search, resets every time. I can't tell you how many times I've gone through the exact same set of selections to get a manufacturing job started.
Aran Aldamar	Posted - 2008.06.08 16:32:00 - [93] Originally by: Draygo Korvan The reason I say that because while that would be a simple and easy 'fix', they obviously have not done it for some reason. I suspect that 1% of the suggestions they get are simple and easy. 10's of thousands of players who will all complain loudly if something gets broken. Still, this seems pretty small compared to say, faction warfare, which no one I know is excited about. The issue here is that not enough people have complained about this. Squeaky wheel!
Femaref Armageddon Day	Posted - 2008.06.10 23:09:00 - [94] Originally by: Aran Aldamar Originally by: CCP Lingorm This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Oh noes1!! A join! You aren't serious are you? I can see resisting a database structure change, but resisting adding a join to a query is pretty laughable. Why not just add a new item type? You have Blueprint now, just add Blueprint Copy. Sure, new set of icons to download. Not a big deal. At least it would be really obvious which BPs are copies. The S&I interface is awful. No search, resets every time. I can't tell you how many times I've gone through the exact same set of selections to get a manufacturing job started. A join on a table that contains millions of entries. I don't want to be the hamster responseable for it...
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.11 18:45:00 - [95] Lingorm has been very good at communicating with us so far. I'm waiting to see his response to posts made after his last one. I'm interested in what he sees the potential problems might be to the new set of suggestions (besides "it's a lot of work"). --

CCP Lingorm C C P	Posted - 2008.06.12 10:26:00 - [96] Originally by: Draygo Korvan flag (bool? [locked/unlocked?]), contraband (list probably?), singleton (bool?), quantity (int?). Researched BPO's/BPC's will always have a quantity of 1 right? What does singleton mean? Does it mean an item that is unpackaged? All researched BPO's BPC's are 'unpackaged', so couldn't you use the quantity field to store what type of BPO/BPC it is, if it is researched (and thus unstackable) Essentially Researched BPO = Singleton 1, Quantity 2 (UI knows its only 1 item however) BPC = Singleton 1, Quantity 1 Unresearched BPO = Singleton 0, Quantity X Sure it would take a bit of rewriting of the inventory code, and probably a lot of testing but in the end it would be worth it. Singleton means that it is 'unpackages and hence can have different dogma attributes from its type dogma values. A Singleton ALWAYS has a quantity of 1, but quantity of 1 does not mean an item is a singleton (singleton is a bit/bool field). We could do this but that means adding special code to the inventory system and teh UI system which is not idea. I will note the idea down and mention it, but I don't think it will go anywhere. Nice idea though. 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.


CCP Lingorm C C P	Posted - 2008.06.12 10:28:00 - [97] Originally by: Chi Quan let me get this straight here a bit: 1) researched bpos and bpcs have a unique id (the aforementioned itemID i persume?) 2) itemID is sent every time the inventory is requested by the client, along with typeID if both statements are correct, is it possible to give bpos an odd number in itemID and pcs an even one and that let the client do the differentiation? We can not control what itemID is given to an item. ItemID's are recycled and it is a function that is called to fetch a free itemID for use. 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.


CCP Lingorm C C P	Posted - 2008.06.12 10:36:00 - [98] Originally by: Jason Edwards I know this idea might be kind of annoying... but why not just make it so when you "copy" the blueprint. It's actually creating a new type of item in of itself. So that it can essentially have at least a different picture just as any other items have different pictures. Or a sort of O or C in the top right corner like others have proposed? I just figure have a completely new item created is doable because invention creates a completely new item. I thought I had explained that this is not doable as the Raven (for example) can not have 2 associated Blueprints that produce it (this is a limitation that we would like to change but other things are higher on the backlog). So there would be no way to link the BPC version of a Raven Blueprint to the Raven item. We have fixed this limitation in other parts of the code it has just not be refactored back into this part of the code yet. 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.


CCP Lingorm C C P	Posted - 2008.06.12 10:41:00 - [99] Originally by: Aran Aldamar Originally by: CCP Lingorm This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Oh noes1!! A join! You aren't serious are you? I can see resisting a database structure change, but resisting adding a join to a query is pretty laughable. Why not just add a new item type? You have Blueprint now, just add Blueprint Copy. Sure, new set of icons to download. Not a big deal. At least it would be really obvious which BPs are copies. The S&I interface is awful. No search, resets every time. I can't tell you how many times I've gone through the exact same set of selections to get a manufacturing job started. Not a "Join" because by default a Join is an "Inner Left Join", which means that if the item in the left table (inventory) does not have an entry in the right table (dogma attribs) then it will not be included in the result table. What we actually need is and "Outer Left Join" which is All entries in the left table (inventory) and if they have the appropriate Dogma attribute then also include the stuff from the Right table, if they do not have the attributes then put in either NULL or some specified value. While this may actually seem like less work because of the way indexes work it is acutally more work to do an outer join than it is to do an inner join. 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.


CCP Lingorm C C P	Posted - 2008.06.12 10:47:00 - [100] Hope that answers all the questions and brings this thread upto date with a wall of black and blue. 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.


Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.12 21:30:00 - [101] Edited by: Draygo Korvan on 12/06/2008 21:30:43 Originally by: CCP Lingorm Singleton means that it is 'unpackages and hence can have different dogma attributes from its type dogma values. A Singleton ALWAYS has a quantity of 1, but quantity of 1 does not mean an item is a singleton (singleton is a bit/bool field). We could do this but that means adding special code to the inventory system and teh UI system which is not idea. I will note the idea down and mention it, but I don't think it will go anywhere. Nice idea though. I look forward to what they have to say about it. Yea it would obviously require some UI changes such that singleton 1 is always treated as a single item regardless what the quantity value is, so you can use the quantity value to determine if its a BPO or BPC. Thanks for your input, I look forward to any further information that might come out of this. --
Lenus Daragio coracao ardente	Posted - 2008.06.12 22:54:00 - [102] Originally by: CCP Lingorm I thought I had explained that this is not doable as the Raven (for example) can not have 2 associated Blueprints that produce it (this is a limitation that we would like to change but other things are higher on the backlog). So there would be no way to link the BPC version of a Raven Blueprint to the Raven item. We have fixed this limitation in other parts of the code it has just not be refactored back into this part of the code yet. I'd say we have to wait until this is done, since really BPCs and BPOs should be two different items, and not the same. I base this on the item value, a BPO is worth tons more than a BPC, and people obviously know that. Also, players refer to BPCs and BPOs as if they were entirely two different items. Making them different items should really become more of a priority here, since it reflects both the players and the devs view on how this works. This would also probably prove useful when programming future expansions, etc, or special items that can be used to produce other items.
Danton Marcellus Nebula Rasa Holdings	Posted - 2008.06.13 12:35:00 - [103] Just let us tag things after the fact clientside, that'll clear up a good portion of the problems.
Raven Timoshenko Flying While Intoxicated The Threshold	Posted - 2008.06.14 02:28:00 - [104] Originally by: Danton Marcellus Just let us tag things after the fact clientside, that'll clear up a good portion of the problems. hmmm, you know this would be a good compromise, we can "star" objects like in say GMail, or apply tags, client side. What would be needed however is an export / import function for the client cache so we can take it with us to another PC if need be.
Sophie Malaster Equitus Nosferatum Praetorians	Posted - 2008.06.16 12:13:00 - [105] Much easy, in the past the blue prints was blue or cuttlefish, at color. Well, the BPO blue, the BPC cuttlefish. Easy.
Arthor Dark N.A.S.A. Skunk-Works	Posted - 2008.06.18 19:02:00 - [106] Is there any reason why we can't control / shift select a group of blueprints from the S&I Blueprint window so as to move them around or contract them all at once? I find myself having to contract one blueprint at a time otherwise.
Talaan Stardrifter	Posted - 2008.06.20 16:01:00 - [107] Originally by: CCP Lingorm ... I thought I had explained that this is not doable as the Raven (for example) can not have 2 associated Blueprints that produce it (this is a limitation that we would like to change but other things are higher on the backlog). So there would be no way to link the BPC version of a Raven Blueprint to the Raven item. We have fixed this limitation in other parts of the code it has just not be refactored back into this part of the code yet. Sounds like a double-linked list when only a single-link is necessary. How I read this is that the Blueprint knows what it builds, and the item knows what builds it. correct? I'm guessing it's to do with finding the reprocessing values? I can understand how this could take some time to unravel. IF we were to take up the two-item-type technique, would it not be possible for the 'BPC' type to reference the 'BPO' type using a Dogma attribute? It's after midnight here and I'm headed for bed. I'll extrapolate this idea onto paper tomorrow and come back with what I've got.
Falcyon G-Man Industries	Posted - 2008.06.20 16:53:00 - [108] Edited by: Falcyon on 20/06/2008 16:56:01 I hear what you're saying about the current structure, in that no item can have two BPs associated with it. Still, is there a possibility that BPCs could technically not exist? They could be separate types of items in the database that simply make reference to their BPO parents for all their functions, making them psuedo-items or wrappers or some such. I'm not sure how your DB works, but I'm just throwing it out there. --------------------------------------------- Thread on idea for Ship/Module Customization, Depreciation, and Towing
Slanty McGarglefist University of Caille	Posted - 2008.06.20 19:34:00 - [109] 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. _______________________ __________________________________________________ Originally by: CCP Wrangler No Doh!
procurement specialist	Posted - 2008.06.20 21:29:00 - [110] yes because the bpc and bpo cannot both be used to make the item. therefore the bpc or bpo would be incapable of making said item. pick one.

Lord Fitz Antares Fleet Yards SMASH Alliance	Posted - 2008.06.21 02:42:00 - [111] Originally by: Arthor Dark Is there any reason why we can't control / shift select a group of blueprints from the S&I Blueprint window so as to move them around or contract them all at once? I find myself having to contract one blueprint at a time otherwise. This. This is what we need. Something that means that people don't have to use the items window to move things around (though deliver to from the S&I window works, it still feels like a workaround). It would mean that the attributes are already fetched here, and is merely more functionality.

CCP Lingorm C C P	Posted - 2008.06.22 17:03:00 - [112] 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. 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.


CCP Lingorm C C P	Posted - 2008.06.22 17:04:00 - [113] Originally by: Arthor Dark Is there any reason why we can't control / shift select a group of blueprints from the S&I Blueprint window so as to move them around or contract them all at once? I find myself having to contract one blueprint at a time otherwise. This has been added to the list of changes for the UI group to look into. 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.

Kuroshiro	Posted - 2008.06.22 18:49:00 - [114] How hard would it be to give personal hangars 'division' tabs like corp hangars? That could go a long way towards solving some of the 'BPC/BPO' distinguishing and 'make containers searchable' requests less necessary.
Falcyon G-Man Industries	Posted - 2008.06.22 18:58:00 - [115] Originally by: CCP Lingorm 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. Would it be possible to make BPs Locations, then? It could be a first step towards customizable BPs. :) --------------------------------------------- Thread on idea for Ship/Module Customization, Depreciation, and Towing
Jiggardin	Posted - 2008.06.23 18:39:00 - [116] [stupid on] probably a stupid answer but: get some Sun V890 with enough ram and oracle RAC. you wont have performance issues anymore. i know you use mssql, maybe that is the real problem. [/stupid off] i am quite sure that ccp looks into those issue. since the db is normalized, its really hard to implement something like that. at least not without raising the load on the servers. i have no idea of ms products, but are there features in mssql to route special queries onto another machine? -jigga
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.23 20:47:00 - [117] Originally by: CCP Lingorm Originally by: Draygo Korvan All researched BPO's BPC's are 'unpackaged', so couldn't you use the quantity field to store what type of BPO/BPC it is, if it is researched (and thus unstackable) Essentially Researched BPO = Singleton 1, Quantity 2 (UI knows its only 1 item however) BPC = Singleton 1, Quantity 1 Unresearched BPO = Singleton 0, Quantity X (BPC's are always singleton 1, due to the blueprint copy metadata) We could do this but that means adding special code to the inventory system and the UI system which is not (a bad?) idea. I will note the idea down and mention it, but I don't think it will go anywhere. Nice idea though. Did it go anywhere? --
Falcyon G-Man Industries	Posted - 2008.06.23 23:39:00 - [118] Edited by: Falcyon on 23/06/2008 23:39:52 That's not a bad idea at all, I would think. A little snippet of code with an IF-ELSE and you've got discernible icons. Still kind of a hack, but it works, right? No harm done. --------------------------------------------- Thread on idea for Ship/Module Customization, Depreciation, and Towing
Fallorn GoonFleet GoonSwarm	Posted - 2008.06.24 03:40:00 - [119] CCP Lingorm's the best for actually explaining stuff so we understand the game better. Sig removed. If you would like further details please mail [email protected] with a link to your signature. - Elmo Pug
Icome4u Interstellar Planetary KIA Alliance	Posted - 2008.06.25 03:14:00 - [120] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. Their you go guys, directly from a Dev why EVE fails (and lags)! ~~~ My posts are just that, MINE. They do not represent my Corp or Alliance.

Ricdic Corporate Research And Production Pty Ltd Zzz	Posted - 2008.06.25 18:27:00 - [121] I like the idea about being able to tag your items client side. It allows us to utilise not just blueprints but also things like tagging of items used for a ship etc. Maybe even enhance that a little with an option to select all tagged items Seems it would be simple enough to implement and would bypass the issues expressed here. http://oldforums.eveonline.com/?a=topic&threadID=500043 Largest Empire Research Alliance in EVE!
Mar'Dur Taren The Copernicus Institute	Posted - 2008.06.26 15:03:00 - [122] I'd like to post my support for making the BPOs and BPCs visually distinguishable. There is no good reason for them not to be and it would improve usability a lot.
Captain Counterpart GALNET Company Limited	Posted - 2008.06.26 20:03:00 - [123] BPC background turn to RED.
Gwendion Gallente Bladed Moon Zzz	Posted - 2008.06.27 10:06:00 - [124] I know you've said its not possible but uh.. You have ways to control visual displays of the images right? Possible to change the RGB hues or add another icon overlay? (like T2 for example) So.. how about just a visual change, a quick change where it calls the function to display the icon like... (I used -1 as the BPO difference, cause if its greater than 1, then its a BPC, thats just how Im thinking about it) if (item->runs != -1) { addBPCIcon(item); } or whatever, similar to say T2 how the T2 icon is just a small visual change ontop of the base icon. It would work! You have the ability! :P A copy stamp over the icon would look cool.. (bottom up orientation) -----------------------------------
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.06.28 04:04:00 - [125] Originally by: Gwendion I know you've said its not possible but uh.. You have ways to control visual displays of the images right? Possible to change the RGB hues or add another icon overlay? (like T2 for example) So.. how about just a visual change, a quick change where it calls the function to display the icon like... (I used -1 as the BPO difference, cause if its greater than 1, then its a BPC, thats just how Im thinking about it) if (item->runs != -1) { addBPCIcon(item); } or whatever, similar to say T2 how the T2 icon is just a small visual change ontop of the base icon. It would work! You have the ability! :P A copy stamp over the icon would look cool.. (bottom up orientation) It wont work because Eve does not query the meta data on an item on opening the inventory window, only when you 'show info' for that item. Read the thread. --
Rodanine Caldari School of Applied Knowledge	Posted - 2008.07.04 13:46:00 - [126] since Blueprints take up basically little to no actual space why can't we manufacture them from inside containers so i can keep my inventory floor space neat and tide by using 2 small containers one labeled bpc the other labeled bpo's. i have almost everything else in my hanger floor broken down into containers weather they are station containers or gsc. i suppose i could continue to have to manually pull the prints from their respective containers so i can manufacture but thats becomes a tad tedious after a while of having to pull them out and put them back when one is done. not a perfect solution but i am a tad of neat freak and hate seeing my hanger floor cluttered with all the stuff i currently have. yes this is an alt get over it
Luzz Bightyear	Posted - 2008.07.05 11:49:00 - [127] Having the client query the number of runs, PE, etc automatically when it encounters BPs is ideal IMO. This crap about additional database overhead is bullshit, everyone with a brain has to hit the Info page and query it ANYWAY. :P Off topic: a button in the Create Job window next to the Runs box that sets the number of runs to the max you can produce with the materials you currently have would be nice.
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.07.07 01:33:00 - [128] Originally by: Luzz Bightyear Having the client query the number of runs, PE, etc automatically when it encounters BPs is ideal IMO. This crap about additional database overhead is bullshit, everyone with a brain has to hit the Info page and query it ANYWAY. :P Off topic: a button in the Create Job window next to the Runs box that sets the number of runs to the max you can produce with the materials you currently have would be nice. I don't know about you, but I don't click show info on every single BPO/BPC every single time I open my inventory hanger in a station. I only really do it when I want to use a BPO/BPC. So yes, it is added overhead to the database to have it run tens to hundreds of extra queries all at once. --
Mika Meroko Minmatar Crayon Posting Inc	Posted - 2008.07.09 08:08:00 - [129] here to add/share the pain of dropping a single cap recharger bpo into 400 copies of bpcs... and spending an hour to find it... in the 21 to last item...
HenkieBoy Enrave Ethereal Dawn	Posted - 2008.07.09 21:20:00 - [130] First of all, find it great a dev talks alot about an issue :) I have done SQL modeling for some time now, and I understand the problem at hand. The only real option is to rethink and rebuild the whole item part in EVE. This annoying problem is just something small. But this same DB design does not allow 'customized build' items, thats why we got so much 'named' stuff. While this system worked for years, I really think it due for a major overhaul. One big problem though.. an 'Industrial expansion' just isn't a selling point. Thats why we get expansions only covering missions, wars, pvp and battles.. because those themes sell to the big public.

Yohanes Flame Burning Sky Labs	Posted - 2008.07.13 14:44:00 - [131] Edited by: Yohanes Flame on 13/07/2008 14:45:27 per the dev reasoning. why not put a graphical tag on copies then. especially if they are user db local. any why is it not possible to have the original/copy/all drop down in hanger view. ____________________________ Point Zero Corp
Khlitouris RegusII	Posted - 2008.07.13 20:01:00 - [132] Originally by: Jinx Barker They cant. CCP Devs posted about it before, something to do with the way Database process the BPOs/BPCs - would be impossible, or rather Lag Causing - to do the delineation between them in color. I think because it will have to treat each BPC as a unique DB item, and create each additional entry in the system for each BPC and so forth and so on, basically lagging EVE to hell and back. Yet some bpo's and bpc's come in different colours already
Matthew Caldari BloodStar Technologies	Posted - 2008.07.15 18:16:00 - [133] Originally by: Ricdic I like the idea about being able to tag your items client side. It allows us to utilise not just blueprints but also things like tagging of items used for a ship etc. Maybe even enhance that a little with an option to select all tagged items One of the main issues with that would be around customer understanding. You and I may know my repackaging, merging or splitting stacks etc would break the tagging on what most users see as the same item. But a lot of players won't, and would spam the GM's and Bughunters when the tagging didn't behave as they expected. Any client hack to migrate the tag from one ItemID to another when performing such an item would rely on you only ever using one client, and only one char ever accessing that hangar/can/whatever. Otherwise you'd have to maintain an ItemID history for each item on the server, which would be horrendous. There's also the issue of how to clear out "dead" tags - e.g. if you tag an item and one of your corp-mates trashes it, how does your client know to remove that ItemID from your local tagging list? Bearing in mind that ItemID's get re-used, so it's not reliable to just check whether that ItemID has been trashed, as it could already have been assigned to a new, completely unrelated, item. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
BigWhale Gallente Three WiseMen Association	Posted - 2008.07.15 19:36:00 - [134] Edited by: BigWhale on 15/07/2008 19:37:29 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. Flags and contraband? Bits? Bytes? If bytes, then a solution could be to use bitfields for storing those binary values. You know, (1 << 0) - Normal Item (1 << 1) - Contraband (1 << 2) - BPO (1 << 3) - BPC If those are bits already, then you could combine the two of them? 0 0 - Normal Item 0 1 - Contraband 1 0 - BPC 1 1 - Flag It wouldn't work without UI changes. Edit: It seems others already suggested similar approach. :) -- R, U & Y are letters, not words...
Skolima	Posted - 2008.07.18 17:01:00 - [135] Bump, I just had to locate 2 BPO between 300 BPC :-( Seeing any of the ideas implemented would be nice, all would be awesome: - local cache of the BPC/BPO status (with ME/PE/runs?) with the option to select multiple items and request "query details" - ability to drag&drop items from the Science And Industry view - single-character version of corporate hangars - DB changes (we all know this won't happen...) - perform operations on multiple BPC/BPO at once (say, select 10, push Invent, select 10 available slots and have them run) Man can dream...
Anton Zuber Minmatar Brutor tribe	Posted - 2008.07.18 19:39:00 - [136] Edited by: Anton Zuber on 18/07/2008 19:39:30 You have got to be kidding me.... The entire reason you have NOT added an easy way to distinguish BPOs from BPCs is that you don't want to add ONE SINGLE BIT of data to your item indexing database? How many BPOs/BPCs are out there now? I know there's a lot. So that must mean you've got to already be running 16, probably 32 bit indexing anyhow? And you're whining about adding ONE louzy bit of data to that? It's not that hard. one binary bit, 0 or 1. original or copy. Oh my. Worse, you add invention to the mix. Now Invention is encouraging us to make MANY more unique items in your data base. So you are in effect encouraging us to add undoubtedly much more than one bit of data to your indexing. But what do you expect? We need the copies to do invention runs. As an added feature for us users that are running copies, the batch spits the Original out in a RANDOM ORDER so we get to sit here and show info on every single BP in the hangar until we can find the ONE that is an original and set it aside in a can or something so we can find the bloody thing later. gods.... CCP is so dumb some days.... "Oh it is the eyeball one." -Erfworld " ... I was looking forward to flinging an angry housecat in someone's soft and unprotected face." -Order of the Stick
BigWhale Gallente Three WiseMen Association	Posted - 2008.07.19 06:13:00 - [137] Actually adding a single bit to a database table might be a little difficult. You can't just add a bit. How will you store a single bit on a disk? Or even in memory? To add a single bit, you have to add one column to a database table. That would be (at least) one byte per every item. The idea is to find a solution in existing DB schema. Can they recycle a bit here and there in one of the existing columns? -- R, U & Y are letters, not words...
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.07.21 02:15:00 - [138] Edited by: Draygo Korvan on 21/07/2008 02:15:48 Edited by: Draygo Korvan on 21/07/2008 02:15:30 Originally by: BigWhale Actually adding a single bit to a database table might be a little difficult. You can't just add a bit. How will you store a single bit on a disk? Or even in memory? To add a single bit, you have to add one column to a database table. That would be (at least) one byte per every item. The idea is to find a solution in existing DB schema. Can they recycle a bit here and there in one of the existing columns? http://oldforums.eveonline.com/?a=topic&threadID=772921&page=4#96 --
Wardo21 The Arcanum	Posted - 2008.07.22 22:11:00 - [139] I think the general consensus is that you should be able to do this with some recoding and adjusting with the data you already retrieve for inventory lists. There is really 3 states for prints: original untouched - can still be sold on the normal market and stacked. original used/researched - can't stack or sell on the normal market. copy - no stacks, no further research, not sold on normal market. When I run a production job, you already remove the "1" from the stack size of the original untouched print as it converts to a used original. Even if I haven't done any research on that print. (I think, but I haven't used a virgin print in a long time.) Researched originals clearly lose their stack size attribute from the list already returned. This is one option I can think of. It's technically a violation of strict normalization by using the same attribute from the query for different purposes, but it should work. Yes, you will likely have to create more types to be "copies" and used originals (but perhaps not), and alter the code that produces copies from a lab/mfg facilities (for sure). You will also have to resolve the issue of multiple prints being able to produce the same item (if multiple types are needed). If so, rethink the FK declaration between prints and produced objects. Reuse the field that determines the size of a gun, or the slot for a module, to indicate the type of print. Also, store the number of runs for a copy in the same place as the number of items in a stack. (Or however it is that you mark a print as used, stack size for used originals is null or empty.) This would also be a nice indicator of how many runs a copy has right on the icon. Color would be nice when it's in an icon view, but at the very least, the detail view will show the print type (like gun size or slot). If the client reacts to that field and alters the color or overlays another icon, all the better. These can be left to the client side to reduce bandwidth and server requirements. Bonus points to disable this coloring/overlay feature for low resource clients.
Ackuula	Posted - 2008.07.25 14:00:00 - [140] Get rid of BPO's and turn them into something like skills that you learn forever, in other words it's not in your inventory anymore and is non-transferable. Standard research facilities or say cashing in research points can be used to optimize them. If you want to make something or sell copies you crank out a BPC hardcopy and there you go no more confusion. It wouldn't take away all the corp theft/pirate nastiness since BPC's would still be expensive to make and a risk to transport.

Rogen DarHeel Caldari Rogen's Heroes THORN Alliance	Posted - 2008.07.25 19:43:00 - [141] BPO's aren't going anywhere...
Xelios Xarxes	Posted - 2008.07.28 03:01:00 - [142] I would also like to be able to see the ME/PE/Runs of a BPC without having to show info. (Is there a way already?) When you create a contract you can see all those details on the contract list, but before creating it there's no way I know of. It's really annoying; make detail view in the item hangar show the same BPC details as contract or something.
Ava Santiago Minmatar	Posted - 2008.07.30 04:54:00 - [143] I'm hoping we get a search option for originals in the updated contract system. I can figure out how to deal with my copies, but buying researched BPO's would be a LOT easier if I could find them in the stacks of copies. It's also nice to know at least one developer understands industrial issues. Concord doesn't provide consequences. Concord provides insurance payouts.
suicide Caldari Synergy.	Posted - 2008.07.30 06:08:00 - [144] Color them different. Done. Yay
Lieutenant Isis Gristle Industries	Posted - 2008.07.31 18:48:00 - [145] Lingorm, this thread is the most informative sources of information I have seen from any Dev. Most devs, if they offer an explanation at all, are general esoteric or of the, "no we cannot do that" style. I must thank you and hope that the informations continues! Originally by: Roc Wieler I enhance my RP experience by filling my bathtub with red jello, balancing a wooden plank across it, then play EVE naked on my laptop.
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.07.31 20:09:00 - [146] Originally by: Wardo21 Reuse the field that determines the size of a gun, or the slot for a module, to indicate the type of print. Also, store the number of runs for a copy in the same place as the number of items in a stack. (Or however it is that you mark a print as used, stack size for used originals is null or empty.) This would also be a nice indicator of how many runs a copy has right on the icon. That field is in the itemid for the item which is shared between BPC and BPO, so that wouldn't work at all. --
DorXtar The Hull Miners Union The Red Skull	Posted - 2008.08.03 22:35:00 - [147] Originally by: suicide Color them different. Done. Yay BPC's should be brown. ________________________________ It never hurts to help!
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.08.05 17:45:00 - [148] Edited by: Draygo Korvan on 05/08/2008 17:45:47 Originally by: Mika Meroko here to add/share the pain of dropping a single cap recharger bpo into 400 copies of bpcs... and spending an hour to find it... in the 21 to last item... Use the science and industry window if you accidentally drop it in 200 bpc's. You can throw the bpo back into production then move all your BPC's to a container, and then cancel the S&I job. --
Ammon Skycloud Caldari Matari Research Foundation	Posted - 2008.08.08 10:35:00 - [149] Ok I've not read the entire thread so someone may have said some of this before. I noticed that one of the devs stated that the database is heavily normalised, and that adding the ability to identify a BPO would require an additional relationship to exist which will affect performance. as a developer who has been responsible for optimising and normalising transactional databases for stock exchanges, banks it occurs to me that either the dev who made that statement is basing it on incomplete understanding of the data structure, or that the data structure is horribly over normalised, something that can lead to serious performance degradation, the old adage of too much of a good thing might apply here. Be that as it may, there is something I have noticed in the game, the fact that BPOÆs can already be distinguished from BPCÆs, the first reason is BPOÆs can be stacked (when packaged) BPCÆs cannot, unless the game is checking the database every time you tell it to repackage or stack items that information is already available on the client. Secondly and more importantly, when viewing your inventory in detail list mode, BPOÆs have a qty value and BPCÆs do not, this alone should be enough to identify a BPO from a BPC graphically since it is obvious that the information that the client has about a BPO is different from that of a BPC, IÆll admit using the qty flag/field/parameter as a way to identify a BPO is a bit of a hack, but if the database is truly normalised to the extent that you cannot add a parameter field to the BPO database record without an additional table join then it may be a viable option. But in all seriousness as someone who has specialised in database and system performance optimisation for a long time the description given of the database although limited makes me want to say only one thing /facepalm
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.08.08 14:43:00 - [150] Originally by: Ammon Skycloud Ok I've not read the entire thread so someone may have said some of this before. yea it has been suggested. BPO's do not have a quantity value once researched or used in manufacturing. --

Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.15 01:25:00 - [151] "itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity" Can you use the typeID to sort them differently in the hanger? Right now if you sort BP's by type, the BPO's end up at the end or beginning of the BPO/C's you have. If I have 10 Atron BPC's and 1 Atron BPO plus 10 Tristan BPC's and 1 Tristan BPO, it'll be 10 Atron copies, then the Atron orginal followed by 10 tristan copies and 1 original. If the type sort works this way, is there any way to sort BPO's first then BPC's so you have Atron BPO then Tristan BPO then the copies? It seems that BPO's and BPC's are handled differently by the type sort, so is there any way to use that even if the icons are the same? Also, I think someone said it earlier, ME and PE in the assets window would be nice. I don't have the database files on this computer atm but I'm downloading them to take a look at what you described. Not sure if my question above is doable but I'll edit it if not :p
Rashmika Clavain Gallente Revelation Space	Posted - 2008.08.18 10:01:00 - [152] Edited by: Rashmika Clavain on 18/08/2008 10:05:16 Jesus what part of "heavily normalised" database are people missing? Listing the BPO's status in the database as either BPO or BPC fracks the normalisation. At a very basic level, normalisation works to remove duplicated entries, ie: 001 Chimera BPO 002 Thorax BPO 003 Catalyst BPO 004 Vexor BPC 005 Enyo BPC to: 001 Chimera 002 Thorax 003 Catalyst 004 Vexor 005 Enyo With possibly a link to another table for BPO/BPC status via the ID. It's not about the ease of adding a new database tag/column or whatever. It's about adding duplicated data thus breaking the normalised model. Even if you add item tags such as "A" for BPO and "B" for BPC, you're still adding duplicated data which needs to be normalised. That said, a query window would be helpful, but I doubt the effort needed would be worth it. Personally I store my BPO's in can1, my single run BPC's in can2 and my max run BPC's in can3. It's not hard, but as with most things in EVE, people see fit to whine until CCP takes them away from the fire because they're burning. /rant off Removed. Please keep your EVE signature related to your EVE persona and not that of a real life politician. Navigator
Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.18 11:48:00 - [153] While you have a great can method that works for you, there are about 5 other instances where I have issues with not being able to determine BPC's and BPO's visually or by some identifier. I think the problem here though is not the icon, it's having some way to identify the BPC's and BPO's. You can't do it in the asset window and the functionality of the science and technology interface doesn't allow you to select multiples or transfer the BP's to another container or something else. I think the best solution to the problem here is not to change the icon, because by CCP's database structure doesn't allow that to happen easily, but to change the way we can view them in the UI. Then it seems that there is a solution that can be reached. The information is already there, it is shown on the UI now in some areas so it can be used to help distinguish the BP's apart. The areas I can think for UI support that I would find useful are to have a designator in the asset window for BPC or BPO, possibly with ME and PE, and the ability to select multiple BP's from the sci/tech window for contacting purposes. Also a sorting function that puts all BPO's first, then BPC's would helpful if it's possible (I think my earlier post on this wasn't correct).
Matthew Caldari BloodStar Technologies	Posted - 2008.08.18 22:09:00 - [154] Originally by: Zifrian Can you use the typeID to sort them differently in the hanger? Right now if you sort BP's by type, the BPO's end up at the end or beginning of the BPO/C's you have. If I have 10 Atron BPC's and 1 Atron BPO plus 10 Tristan BPC's and 1 Tristan BPO, it'll be 10 Atron copies, then the Atron orginal followed by 10 tristan copies and 1 original. Copies and originals have the same typeID. The effect you are describing probably occurs because of the secondary sorting criteria. i.e. when you sort by Type, how does it decide the order of items that are the same Type? My guess would be that it falls back on the itemID, as that is the only value guaranteed to be unique. So it will sort by typeID first, but then sort by itemID within each typeID. Now, assuming that all the copies present have been produced in one batch, they are likely (but not guaranteed) to have itemID's in a similar range. It is more likely for a BPO to have an itemID outside that range than within it, hence why the BPO is likely to graviate to one end of the sort or the other. While this happens often enough to be an observable pattern, it is not something the system is designed specifically to do, and not something that it is guaranteed to do every time. In order to guarantee it happening, you would have to special-case a reserved range of itemID's for BPO's either at the top or bottom of the range, to ensure the BPC's could not be given itemID's on both sides of the BPO values. Which would be a horrible dirty hack, and potentially cause problems with the itemID capacity management and recycling.
Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.18 22:42:00 - [155] Yeah, I don't think the sort thing worked right. Sometimes it does, other times it doesn't.
Xailia Unsteady Corporation	Posted - 2008.08.24 06:06:00 - [156] The only solutions that seem viable are either a local cache (single machine), a workaround (ugly), or a switch from a RDBMS to an ORDBMS (major code overhaul). In the short term the first two are nice. But in the long term, the system needs to fit how the data is used. "The sky above the port was the color of a television, tuned to a dead channel."

CCP Lingorm C C P	Posted - 2008.08.26 10:16:00 - [157] I have written up the suggestions for changes to the Science and Industry Interface so that you have the option to Right Click and Move them to a Corp or Personal Hanger. This has now been handed to the UI Group and they will prioritise and organise getting it into game. No Promises on when this will happen but this is now a feature on out Backlog. 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.

Thevlyn	Posted - 2008.08.29 03:17:00 - [158] 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.
Lu'Pa Caldari	Posted - 2008.08.29 19:02:00 - [159] Originally by: CCP Lingorm Not a "Join" because by default a Join is an "Inner Left Join", which means that if the item in the left table (inventory) does not have an entry in the right table (dogma attribs) then it will not be included in the result table. What we actually need is and "Outer Left Join" which is All entries in the left table (inventory) and if they have the appropriate Dogma attribute then also include the stuff from the Right table, if they do not have the attributes then put in either NULL or some specified value. While this may actually seem like less work because of the way indexes work it is acutally more work to do an outer join than it is to do an inner join. Hmmm... Don't shoot me down, as I don't know everything about your database structure, but I sometimes use a kind of multi-pass SQL to overcome these outer left joins for specific cases. Basically you split the query on two queries with inner joins, and join them using union or concatenate, whatever the operator in SQLServer. The first for blueprints, and the second for everything else. If I understand correctly, blueprints have always have a row in the second table, hence you could do an inner join in that query too. If you have indexes favouring access by item type... i don't know... might work. Just my .02 isk
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.09.01 04:05:00 - [160] Originally by: CCP Lingorm I have written up the suggestions for changes to the Science and Industry Interface so that you have the option to Right Click and Move them to a Corp or Personal Hanger. This has now been handed to the UI Group and they will prioritise and organise getting it into game. No Promises on when this will happen but this is now a feature on out Backlog. Please add an option to move to your active ships cargohold, there are cases when a player may not have a corp or personal hanger and having a 'catch all' option would mitigate that problem. If you dont have an active ship or your ship cannot store the item in its cargohold have it just pass an error.

db Deckard	Posted - 2008.09.02 21:31:00 - [161] 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
Saffin	Posted - 2008.09.03 12:43:00 - [162] 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

CCP Lingorm C C P	Posted - 2008.09.03 13:01:00 - [163] 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 = <you> and locationID = <station> 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 = <you> and i.locationID = <station> 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.

Jarne Increasing Success by Lowering Expectations Vanguard.	Posted - 2008.09.03 14:15:00 - [164] 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
Raynar Alcohol Omega Fleet Enterprises Executive Outcomes	Posted - 2008.09.03 14:17:00 - [165] 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?

CCP Lingorm C C P	Posted - 2008.09.03 16:15:00 - [166] 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.


CCP Lingorm C C P	Posted - 2008.09.03 16:16:00 - [167] 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.

Imhothar Xarodit Minmatar Wolverine Solutions Interstellar Alcohol Conglomerate	Posted - 2008.09.04 11:17:00 - [168] 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!
Xiaodown coracao ardente Triumvirate.	Posted - 2008.09.09 19:23:00 - [169] 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.
Xiaodown coracao ardente Triumvirate.	Posted - 2008.09.09 19:35:00 - [170] 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.


CCP Lingorm C C P	Posted - 2008.09.11 16:11:00 - [171] 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.

Shnitz	Posted - 2008.09.13 05:25:00 - [172] 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.
Detes cald Caldari	Posted - 2008.09.15 16:08:00 - [173] 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 :)
MailDeadDrop Archon Industries	Posted - 2008.09.16 20:42:00 - [174] 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
cuncannon freelancers inc	Posted - 2008.09.17 16:36:00 - [175] 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)
MailDeadDrop Archon Industries	Posted - 2008.09.18 16:45:00 - [176] 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
Lothendra Gallente	Posted - 2008.09.21 18:04:00 - [177] 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.
Bob Farsenbruck	Posted - 2008.09.21 19:50:00 - [178] 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
Jarna Civire	Posted - 2008.09.24 14:48:00 - [179] 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.

CCP Lingorm C C P	Posted - 2008.09.24 16:22:00 - [180] 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.


Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2008.09.26 19:37:00 - [181] 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.
Zinnn	Posted - 2008.09.27 05:16:00 - [182] 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.

CCP Lingorm C C P	Posted - 2008.09.27 10:48:00 - [183] 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.


CCP Lingorm C C P	Posted - 2008.09.27 10:49:00 - [184] 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.

Nova Fox Gallente Novafox Shipyards	Posted - 2008.09.28 06:57:00 - [185] 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!!!
Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2008.09.28 11:24:00 - [186] 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
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.09.28 21:03:00 - [187] 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. --

CCP Lingorm C C P	Posted - 2008.09.29 09:49:00 - [188] 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.


CCP Lingorm C C P	Posted - 2008.09.29 09:53:00 - [189] 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.

Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2008.09.29 16:48:00 - [190] 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.


CCP Lingorm C C P	Posted - 2008.09.29 17:12:00 - [191] 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.

Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2008.09.29 21:20:00 - [192] 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.
Nova Fox Gallente Novafox Shipyards	Posted - 2008.09.30 00:26:00 - [193] 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!!!
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.09.30 06:24:00 - [194] 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. --
Katana Seiko Gallente	Posted - 2008.10.02 08:23:00 - [195] 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
Tobin Shalim Vulcan Foundry	Posted - 2008.10.04 20:23:00 - [196] 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

CCP Lingorm C C P	Posted - 2008.10.06 09:46:00 - [197] 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.

Tobin Shalim Vulcan Foundry	Posted - 2008.10.06 15:42:00 - [198] 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

CCP Lingorm C C P	Posted - 2008.10.06 16:53:00 - [199] 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.

Nova Fox Gallente Novafox Shipyards	Posted - 2008.10.10 16:47:00 - [200] 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!!!

Zifrian Gallente Chapter Black TRUST Coalition	Posted - 2008.10.11 22:05:00 - [201] 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.
Lothendra Gallente	Posted - 2008.10.12 13:44:00 - [202] On a related note, is there any particular reason why we can't repackage an unresearched BPO?
Jed Clampett	Posted - 2008.10.15 08:12:00 - [203] 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....
Jed Clampett	Posted - 2008.10.15 08:20:00 - [204] 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.
Malik Mantille Minmatar Dark Sun Collective	Posted - 2008.10.17 08:40:00 - [205] 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 ------
Rev Russ	Posted - 2008.10.17 21:37:00 - [206] 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.
Molishero	Posted - 2008.10.31 20:04:00 - [207] 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?
ChaoticDemon	Posted - 2008.11.02 19:43:00 - [208] 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
Mister Xerox	Posted - 2008.11.06 11:07:00 - [209] 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.
Shin Hu	Posted - 2008.11.06 15:41:00 - [210] 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").

Cheopis Ardishapur Ammunition and More	Posted - 2008.11.06 20:29:00 - [211] 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.
Mister Xerox	Posted - 2008.11.07 14:57:00 - [212] 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.
FLT BoB Caldari Reefer Madness Inc	Posted - 2008.11.09 00:11:00 - [213] 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)
Sigras	Posted - 2008.11.13 23:10:00 - [214] ummmm . . . cant we just make the blueprints tab of the science and industry window drag-able? it already sorts by copy and original
Cheopis Ardishapur Ammunition and More	Posted - 2008.11.14 11:53:00 - [215] 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.
Coltane Di-Tron Heavy Industries Atlas Alliance	Posted - 2008.11.21 19:34:00 - [216] 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.
wert668	Posted - 2008.11.26 18:06:00 - [217] 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.
Cheopis One Stop Mining Shop	Posted - 2008.11.30 04:33:00 - [218] 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
Arama Bishop	Posted - 2008.12.04 12:40:00 - [219] 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.
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 22:28:00 - [220] 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 !

Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 22:55:00 - [221] 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 !
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 23:09:00 - [222] 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 !
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 23:16:00 - [223] 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 !
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 23:21:00 - [224] 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 !
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.08 23:57:00 - [225] 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 !
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.10 23:53:00 - [226] 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 !
Cheopis Amarr One Stop Mining Shop One Stop Research	Posted - 2008.12.11 09:31:00 - [227] 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.
Gotrek65 Caldari Brimstone Order CryoGenesis Mining Syndicate	Posted - 2008.12.15 06:09:00 - [228] Will any of these options be viable when the eve servers are upgraded to HPC and/or microsoft sql server 2008?
Kweel Nakashyn Minmatar Brutor tribe	Posted - 2008.12.17 00:02:00 - [229] 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 !
Cheopis Amarr One Stop Mining Shop One Stop Research	Posted - 2008.12.18 07:38:00 - [230] 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.

Mister Xerox	Posted - 2009.01.07 00:50:00 - [231] This topic has been stickied, so it has been deemed important... yet not a single comment from the dev side?? blueprint sorting, and an ME/PE/runs remaining layer mask is something I'd like to see implemented before half of the 'crap' currently on the drawing board.
Turgun	Posted - 2009.01.10 14:35:00 - [232] bpo - blue bpc - green prolly already mentioned, as for distinguishing dif me/pe... bit much? maybe you could rename them or simply just have the numbers on the end? (me/pe)
Ravenal The Fated	Posted - 2009.01.14 21:37:00 - [233] Would an easy fix for this be: - Add #Runs column to the details and list view of hangars ... i mean, the number of runs clearly distinguishes bpcs from bpos .
Emporors Champian	Posted - 2009.01.15 11:06:00 - [234] it can be done! if it has to lag up the computer so you get still frames for 3 hours then so be it i want gold trim on my bpo
Doorsdown Minmatar hirr Morsus Mihi	Posted - 2009.01.16 18:23:00 - [235] 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 ? idea is good but to find out what to put into the data field you would still need to do another db call or another join which is what they are trying to get around. love the idea though
darkst0rm Insidious Existence RAZOR Alliance	Posted - 2009.01.19 02:19:00 - [236] 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.
Lord Fitz Project Amargosa	Posted - 2009.01.23 17:27:00 - [237] I think some people are not getting it. Blueprint Originals and Copies are EXACTLY the same item, except for the attributes. Getting the attributes on an item requires a database join. One of these, not so intensive. One every single player does every time they open their hangars, is very very very bad. The only sensible fix for this is to upgrade the functionality within the S&I window, which has a limited performance hit because it a) is only opened when you are specifically looking for blueprints (limits the number of joins) b) is limited to the current region You will notice that this window is much slower than the items window. If the functionality was added to the items window that the S&I window has, the items window itself, would go even slower. This is very bad. Adding it so you could see in the assets window would probably grind the whole game to a halt. The simple and only real fix, is to allow drag and drop from the S&I window, and upgrade the views you can get with the window etc etc. Basically focus all the attention on that, because you're not ever going to get a solution that will work for the items window, no matter how much people suggest what colours they should be.
Lord Fitz Project Amargosa	Posted - 2009.01.23 17:32:00 - [238] 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. The attributes could have changed since you last opened the screen. But anyway. Colouring on the client side is possible after you have opened that window, only for the items that your client knows about. (so not the others in your assets / other regions etc). Of course, I don't see the point in adding this to the items window itself, because again you will suffer some performance penalties. You just do as suggested and upgrade the S&I window functionality. The window unfortunately needs a performance boost already. Not to mention usability.
Shaka Quatuic	Posted - 2009.01.23 19:52:00 - [239] 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.
Wardo21	Posted - 2009.01.26 18:43:00 - [240] 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. If I understand the mechanics correctly, only ships and other containers can be renamed. So in order to rename a BPO/C you would have to make it a "container" in the game, which doesn't make much sense.

Ethilia Freelance Excavation and Resistance	Posted - 2009.01.26 22:06:00 - [241] 1. How about creating a function such that hovering the mouse pointer over a BPO/BPC pops up a window showing the details. There is a similar function used for mining crystals when they are installed in a T2 strip miner. You can see how much damage the crystal has by hovering over it (that would require an 'intensive' DB call just like the blueprints if it were shown by default and not using the popup window). 2. Add an option in the contract GUI where you can unselect items just before creating the contract, but after the DB calls have been made and the information is displayed. This would create nice method for sorting items and limit the DB calls. -I think the above methods avoid the problem with calling the database everytime a hanger/container is opened and has a lot of blueprints. It should not be too much of a problem to code since nothing new is being created really.
Dawnstar Gallente Kiroshi Group	Posted - 2009.01.27 05:22:00 - [242] So, having just noticed this fascinating topic and waded through the various notions and wonderful comments by Lingorm (thank you for all the info and effort you've shown us on this topic)... If I understand the problem correctly, the biggest issue is coming up with a way of flagging BPCs vs BPOs in the information returned by the query for the current asset listing, without significantly bogging down the query or adding significant overhead to the db. So to that end... I have a few questions and thoughts about the graphic ID. Might I inquire about the size of the graphic ID? I'm assuming that it is a standard SQL int, which I'm guessing is probably 2^32 in size (could be wrong there, but the line of reasoning to follow can probably still stand, albeit scaled down). That's a few more bits than I suspect will ever be needed for graphic IDs. (That's -2,147,483,648 through 2,147,483,647 for those who care). Suppose only 24 bytes worth of numbers were used for the actual graphics IDs. That would still leave 16,777,216 possible graphics IDs. I suspect that this would be adequate for a long, long time. The unused 8 bits could then be used as flags (or even ids) of effects to be applied to the base graphics Id (such as giving the image a tint). The graphics id in the database retrieved by the query would become a bitwise or of the actual graphics id and the effects flag/id. Client software could simply use a bitwise and to mask out the special bits and use the id as normal and also use a bitwise and to determine any effects to apply to the image. Both are fairly cheap operations. Any joins currently in the database using the graphics id in the table would need to apply a bitwise and to the id before joining as well, but that is relatively inexpensive as far as operations go (usually). This of course, assumes that its a 32 bit int we're talking about. If it is a smaller size, it might still be feasible to use a scaled down version of this scheme (with fewer bits for both). Hope the suggestion is helpful. -D
Morux	Posted - 2009.01.28 11:45:00 - [243] Never gave this much thought until a few days ago (after I made a system move) when I accidentally did a "repackage all" on all hangar items, forgetting that I just moved all of my small containers which had every owned BPO/BPC sorted out. After the client hung, I restarted it with the worst fears realized - over 4,000 BPOs / BPCs had just been thrown out into my hangar. I don't need to explain to those in this thread what a nightmare this has caused... it is going to take several days (and over 4,000 database queries) to sort this out. There has to be a better solution somewhere... for those of us who invent reguarlarly, this is a real headache! /signed on getting a solution built in the future. Cheers, ~Morux
Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2009.02.02 17:55:00 - [244] Originally by: CCP Lingorm 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 ... Any news/progress on this front?
wert668	Posted - 2009.02.05 19:20:00 - [245] I post this last time: Originally by: wert668 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. Can anyone tell me why this can't be done? It looks pretty simple to me. Yes, you will need replay from hundreds of items, bud how often users sort theirs BPO/BPC? Thanks
Fwuffy Wabbit	Posted - 2009.02.15 03:20:00 - [246] Let us manually tag items, then we can tag all our own BPOs and not have to keep looking them up.
SXYGeeK Gallente Interstellar Planetary KIA Alliance	Posted - 2009.02.20 20:52:00 - [247] Edited by: SXYGeeK on 20/02/2009 20:57:16 add an additional query for the client to run if there are any unidentified blueprints in the inventory container it is querying. It could gather the ItemId's and BPO/BPC flag for these blueprints and cache them. this cached data would allow the blueprints in any inventory to be identified as BPO/BPC and would prevent this data from needing to be queried more than once, or for all inventory items. I can't imagine that this will signifigantly increase client cache for most players, at worst it will be caching a few thousand BP itemID's and a bit flag for thier type, should total no more than a 100k of cache for the vast majority of players. this coming, with respect, from a guy who works with ASP.Net web form applications running against a very large MS-SQL 2005 database, I know a bit about the importance af optimizing queries and limiting round trips to DB. Thanks for everything guys, the Xpack is shaping up even if it's a little rough on sisi ATM. -We So SeXy
Rookie Info	Posted - 2009.02.20 23:44:00 - [248] Edited by: Rookie Info on 20/02/2009 23:45:58 Originally by: CCP Lingorm Edited by: CCP Lingorm on 23/05/2008 09:25:59 Originally by: Joe Starbreaker I'm starting to get a mental picture of your database now, and I can see the trouble. I guess that the color changes you apply to locked blueprints in containers, and blueprints in lockdown, are identified by fields in teh Inventory table, then? Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work... Locked is one of the flags that can be set in the Inventory Table. So yes we get that on the return. The issue is that the kludge would have to be put into the query that return your inventory list, and would have to be run for EVERY single item in your Inventory, and I know I have lots of stuff other than blue prints in my inventory and this would add significant overhead to retrieving that data. What about enabling players to set a local (on their installed instance) single-character alphanumeric tag on objects, like in the overview? We could sort by that within our ship, container, and dock inventories. We should be able to group-assign/clear/re-assign those tags.
Kyra Felann Gallente Noctis Fleet Technologies	Posted - 2009.02.23 23:07:00 - [249] Originally by: Joe Zalt Funny, they can show locked/unlocked BPCs in a different color. I don't buy the excuse. It's easy to not buy the excuse when you have no clue how databases work.
Imhothar Xarodit Minmatar Wolverine Solutions Dead Mans Hand	Posted - 2009.02.26 15:13:00 - [250] 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 ... So, the thread has been unstickied, moved back some pages now, and there is no mentioning about this anymore. There is a big potential here, don't just throw it away.

Precurseur Gallente	Posted - 2009.02.27 00:02:00 - [251] Originally by: CCP Lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views. I take it the database isn't actually queried to determine if it's a BPO or BPC when you open your assets, but only when you "Show Info" on the item? It then retrieves the item details from the database and fetches the corresponding data from another table to ascertain if it's a copy/original? If I'm correct there, and can further assume that every asset which belongs to a player has some sort of asset/inventory ID? That being the case, could the CLIENT then cache the details on the local machine once a print has been queried to figure out if it's a BPO/BPC. This way the database is never re-queried about print details (from that client/machine anyway). A few assumptions there, rightly or wrongly but if the client could at least tell the difference AFTER an initial query that would ease some frustration and give someone a quick visual reference for the future after a one-time query. The cache could be checked for integrity on startup/asset open, and if the data is more than X days old refreshed where/when needed - if at all. A BPO will never become a BPC and vice versa (except in the case of copying, which probably generates a new asset/invetory id anyway). Just my take on it
Mara Rinn	Posted - 2009.02.27 04:47:00 - [252] Originally by: Precurseur The cache could be checked for integrity on startup/asset open, and if the data is more than X days old refreshed where/when needed - if at all. A BPO will never become a BPC and vice versa (except in the case of copying, which probably generates a new asset/invetory id anyway). Incorrect assumption. The itemID can be reused later. As a pathological example, it could be possible to lose a BPC, then some other BPO that you find tomorrow will have that itemID. But I do agree that a lot of "display preferences" stuff could be handled on the client more efficiently than on the server. User opens inventory -> it's up to the client to trawl through the local database (aka "cache") and produce the right display based on item time and specific details. I'm amused by the number of people reading this thread who seem to have gone as far as the "Employee -> Role" example from many SQL tutorials and assumed that kilo-transactions-per-second databases with millions of records and tens of thousands of simultaneous clients follow the same rules as two-queries-a-day tutorials :)
Leigh Crusio	Posted - 2009.04.10 02:12:00 - [253] I would not mind if i had to click a sort or download button and wait 5 minutes to get all my BPO/C's different colours. Surley the client could pause a second before each request to the server and cache the results until they need to be updated. Its also a pain in the ass when copying BPO's, having to search through all the copies to find the original :( Lag however you dress it up is not a feature it is an issue, a very BIG ISSUE. Fleet warfare / blobbing is the only real way to win in 0.0 combat eg. 1 side brings 20 peeps the other brings 200 both a
skulled	Posted - 2009.04.11 13:08:00 - [254] *Make BPOs and BPCs distinguishable* signed
NightF0x Gallente Intergalactic League of Terrorists	Posted - 2009.04.11 15:37:00 - [255] Originally by: skulled *Make BPOs and BPCs distinguishable* signed Read the Dev post on page 1 and you will find your answer ------------------------------------
cpu939 Gallente OffBeat Creations The Elders Alliance	Posted - 2009.04.11 17:02:00 - [256] i know that the devs have stated that they can't change the icon,how ever when you look in to the science and industry tab you can see what bpc you have and the runs they have this is ok but you can't drag and drop you can do every thing else i.e. sell make contract build research. so atm we can use this for building but what about adding the data in to the hangar/corp hangar when in a list from that would allow us to drag and drop the bpcs it would also make sure that we finish of all the runs on a bpc before starting on the next one. devs could this be done and if not why not? 01101111 01100110 01100110 01100010 01100101 01100001 01110100 00100000 01100011 01110010 01100101 01100001 01110100 01101001 01101111 01101110
ShadowDraqon The Quantum Company	Posted - 2009.05.06 17:12:00 - [257] I think this would be a good thing. Simply having BPC's a separate item might work. Or, since there's a line in the info window of blueprints, that stats "yes" or "no" to whether it's an original or not, add a function that puts a little logo on the item thumbnail, it you select it (click on it). Anyway, thread supported. ~ MED-SEC ~ AND The Blatantly Obvious
Solostrom	Posted - 2009.05.06 17:15:00 - [258] Shadow did u even read the third post where the Dev says... it is not possible? Training Reading comprehension L1 plz.
ShadowDraqon The Quantum Company	Posted - 2009.05.06 17:22:00 - [259] Edited by: ShadowDraqon on 06/05/2009 17:22:46 Originally by: Solostrom Shadow did u even read the third post where the Dev says... it is not possible? Training Reading comprehension L1 plz. I believe nothing is impossible. Let me rephrase it: This feature would be very nice, if it were implemented (whenever it becomes possible). ~ MED-SEC ~ AND The Blatantly Obvious
nardaq Wolverine Solutions	Posted - 2009.05.22 21:33:00 - [260] Edited by: nardaq on 22/05/2009 21:33:56 because almost "everything" is serverside can't the client "see" if it's a copy or orginal? And if so add a "C" in the right botom corner (like ammo, even better to add run PE and ME also in all the corners?) _______________________________________________ whining to CCP, Yarrrr!!111 until EVE is working properly =] will it ever be??

Le Ming	Posted - 2009.07.01 18:51:00 - [261] how about a client-side "hack": - whenever there is a icon to display for an item with a given itemid, check local cache for item details. - if cache returns nothing, query server for item details and store them in cache. - use that data to label the blueprint icon... or add an scripting interface, so we can do it on our own. :D that'd actually be even cooler. ;) Best, Le Ming
Marcus Gideon Gallente The NightClub	Posted - 2009.07.01 19:59:00 - [262] Since they just redid their database, can the new and improved one handle associating a different icon with the same value that determines whether it says "Original" or "Copy" in the Info page? There are several key differences between the stats on an BPO and a BPC. Why can't the icon simply look to one of those differences and adjust?
ollobrains THORN Syndicate Mostly Harmless	Posted - 2009.07.03 23:16:00 - [263] Yes i think the redone database could be used to tweak the bpo-bpc
ollobrains THORN Syndicate Mostly Harmless	Posted - 2009.07.03 23:21:00 - [264] Yes i think the redone database could be used to tweak the bpo-bpc
Gavin McStine Gallente M.A.G.E.C	Posted - 2009.07.04 12:06:00 - [265] Its my understanding that there are layers of graphics, couldnt the icon for the blueprint have 2 layers? Have one as the current icon, then have another one ontop of it thats transparent that only shows BPO or BPC over it?
Venkul Mul Gallente	Posted - 2009.07.04 13:25:00 - [266] Originally by: Le Ming how about a client-side "hack": - whenever there is a icon to display for an item with a given itemid, check local cache for item details. - if cache returns nothing, query server for item details and store them in cache. - use that data to label the blueprint icon... or add an scripting interface, so we can do it on our own. :D that'd actually be even cooler. ;) Best, Le Ming Even better "hack": after doing that change the stat of the BPC on your PC so it say BPO and sell it. Or see if you can get the server to accept it as real and research it/produce from it. There is a reason why those stat are not on the player PC side.


Pages: 1 2 3 4 5 6 7 8 9 :: [one page]

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.