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.



Pages: [1] 2 3 4 5 6 7 8 9 :: one page
First page \| Previous page \| Next page \| Last 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.