Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Uncle Mo
Raddick Explorations
|
Posted - 2008.06.17 20:31:00 -
[1]
Telling the T1 BPO's apart from the BPC's is kind of a pain. Is there anyway we could change the background color or add an icon in the corner of a BPO to differentiate them? --------------------------------------------- Official US ambassador to the UK.
|
Arous Drephius
|
Posted - 2008.06.17 20:40:00 -
[2]
Apparently it will cause too much lag because your client would need to constantly ask the server whether a BP is an O or a C.
|
shady trader
|
Posted - 2008.06.17 21:44:00 -
[3]
Look in the features forum there is a sticky tread descussing with dev responces.
Basicly BPO and BPC are the same item as the database is concerned till you check the details. 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. |
Cyndial
|
Posted - 2008.06.19 00:22:00 -
[4]
Still wouldn't be a bad idea to have the BPC's a second color and hence an second item in the database. From my understanding the station is on a different server then the space in a given system and station lag will not effect the lag in the systems themselves, but I could be wrong. If the lag would increase then I'm against it, but if the lag would be station side only then it would be a great addition.
|
RaTTuS
BIG
|
Posted - 2008.06.19 11:08:00 -
[5]
just make bpc's pink -- BIG Lottery, BIG Deal, InEve,
|
Shintai
Balad Naran Orbital Shipyards
|
Posted - 2008.06.19 11:55:00 -
[6]
How hard can it be...just put BPCs in a new grp if needed and assign a pink/green/yellow/red/whatever colour to it. No extra DB load. Abstraction and Transcendence: Nature, Shintai, and Geometry |
RaTTuS
BIG
|
Posted - 2008.06.19 12:28:00 -
[7]
/me summons PrismX [not that that works really as he has his own pet Cthulhu] -- BIG Lottery, BIG Deal, InEve,
|
Xonox Galatorg
Pulsar Combat Supplies Alternative Realities
|
Posted - 2008.06.19 13:09:00 -
[8]
Please read this thread
It's the one that was mentioned above. You'd probably have to have a good understanding about DBs in order to fully understand, but it's basically because it definately would cause lag. To make them different colors would mean having to perform extra DB operations in turn slowing down their 'normalized' database. Some info from that thread:
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.
When it comes down to it, I would guess that it is possible to do it, but they would need to rework the database and that would take a ton of work to do.
-Xonox Pulsar Combat Supplies, Director of Production and POS |
Baron Aethon
Ostium Orci
|
Posted - 2008.06.19 13:25:00 -
[9]
Please change the color, Please
|
Arous Drephius
|
Posted - 2008.06.19 13:29:00 -
[10]
Originally by: Baron Aethon Please change the color, Please
Are you stupid? The devs have said no.
|
|
Selari
|
Posted - 2008.06.19 13:56:00 -
[11]
Originally by: Xonox Galatorg Please read this thread
It's the one that was mentioned above. You'd probably have to have a good understanding about DBs in order to fully understand, but it's basically because it definately would cause lag. To make them different colors would mean having to perform extra DB operations in turn slowing down their 'normalized' database. Some info from that thread:
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.
When it comes down to it, I would guess that it is possible to do it, but they would need to rework the database and that would take a ton of work to do.
That... makes very little sense.
I am going to presume for the moment that BPO's and BPC's are the same 'itemtype' in the database. I also know that I have no actual knowledge of the database structure.
The table must ALREADY be able to tell the difference between a BPO and a BPC... since... it has to pull the difference when it checks to see if you can make copies.
The logic should be something along the lines of.. "IF NumberOfCopiesAvailable = -1, This = Original. ELSE This = Copy." (where I assume -1 = Infinite, a semi-standard convention for gaming). As this information is ALREADY being stored for every blueprint in existance, and would require no database modifications. It would, however, require the client to query for that NumberOfCopiesAvailable *every* time you had to render the icon...
Alternately, if a BPC and a BPO were seperate itemtypes in the database, it would be rather easy to have this, since you'd just put different icons for them. (Hence why i make my original assumption that they are not.)
|
Xonox Galatorg
Pulsar Combat Supplies Alternative Realities
|
Posted - 2008.06.19 14:51:00 -
[12]
Originally by: Selari It would, however, require the client to query for that NumberOfCopiesAvailable *every* time you had to render the icon...
I believe this is where the problem lies. And when you go through a hangar with hundereds of copies this is a bunch of extra queries that slow things down. I'd suggest posting to that other thread since a dev seems to have been watching it and is listening to ideas. Your idea has come up on that thread as well.
-Xonox Pulsar Combat Supplies, Director of Production and POS |
Firvain
|
Posted - 2008.06.19 15:18:00 -
[13]
Originally by: Selari
Originally by: Xonox Galatorg Please read this thread
It's the one that was mentioned above. You'd probably have to have a good understanding about DBs in order to fully understand, but it's basically because it definately would cause lag. To make them different colors would mean having to perform extra DB operations in turn slowing down their 'normalized' database. Some info from that thread:
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.
When it comes down to it, I would guess that it is possible to do it, but they would need to rework the database and that would take a ton of work to do.
That... makes very little sense.
I am going to presume for the moment that BPO's and BPC's are the same 'itemtype' in the database. I also know that I have no actual knowledge of the database structure.
The table must ALREADY be able to tell the difference between a BPO and a BPC... since... it has to pull the difference when it checks to see if you can make copies.
The logic should be something along the lines of.. "IF NumberOfCopiesAvailable = -1, This = Original. ELSE This = Copy." (where I assume -1 = Infinite, a semi-standard convention for gaming). As this information is ALREADY being stored for every blueprint in existance, and would require no database modifications. It would, however, require the client to query for that NumberOfCopiesAvailable *every* time you had to render the icon...
Alternately, if a BPC and a BPO were seperate itemtypes in the database, it would be rather easy to have this, since you'd just put different icons for them. (Hence why i make my original assumption that they are not.)
it makes sense, and databases arent that easy like that(And i know, i studied them). And as stated befor, the inventory items are in a diffrent table then the items themself. So it only stores basic stuff(like name and what it is). and as soon as you click on it, you load a new table with the specific info about the item. So what you want to have is to have a whole new item in the inventory table, which would make you load more(although it wont be that much, it adds up)
|
Selari
|
Posted - 2008.06.19 16:33:00 -
[14]
Originally by: Firvain it makes sense, and databases arent that easy like that(And i know, i studied them). And as stated befor, the inventory items are in a diffrent table then the items themself. So it only stores basic stuff(like name and what it is). and as soon as you click on it, you load a new table with the specific info about the item. So what you want to have is to have a whole new item in the inventory table, which would make you load more(although it wont be that much, it adds up)
Actually.. they ARE easy like that. (And I know, I design them!)
You wouldnt have to actually modify the table at all; you'd just have to change the fetch-icon function in the case of itemtype being a Blueprint.
It would, however, put a larger strain on the server, as it has to retrieve that data over and over for each and every blueprint. This may indeed be more strain than desired for the system; you'd exchange people complaining about identifying BPO/BPC for people complaining that having lots of BP's in their inventory takes forever to load.
|
Pwett
QUANT Corp. QUANT Hegemony
|
Posted - 2008.06.19 16:44:00 -
[15]
aye, it would be a significant query cache to pull the specifics for every blueprint as it displays them.
Just do yourself a favor, use the Science and Industry blueprint section to do all the sorting for you. The functionality exists; I'm surprised people actually ENJOY sorting through their hangars. _______________ Pwett CEO, Founder, & Executor <Q> QUANT Hegemony
|
Xonox Galatorg
Pulsar Combat Supplies Alternative Realities
|
Posted - 2008.06.19 16:51:00 -
[16]
I just use cans to keep my BPOs and BPCs sorted. Although this has it's flaws too. -Xonox Pulsar Combat Supplies, Director of Production and POS |
Lord Fitz
Antares Fleet Yards SMASH Alliance
|
Posted - 2008.06.19 17:01:00 -
[17]
Originally by: Pwett use the Science and Industry blueprint section
This.
We've been over this 100 times (although not for the last few months)
It's not possible for them to do this for items because 1 item = 1 icon. A BPC is the SAME item as a BPO but with different attributes.
It is possible however to do this in the S&I window where they already show you if it's a copy anyway. Increased functionality in the S&I window is what you want (drag and drop etc).
|
Bambi
Existentialist Collective
|
Posted - 2008.06.20 13:17:00 -
[18]
Surely if all icons are stored locally within the client, and the client has already received the copy/original flag from the server, then the lag would not be server side?
EVE is dead, long live EVE!
|
Xonox Galatorg
Pulsar Combat Supplies Alternative Realities
|
Posted - 2008.06.20 13:31:00 -
[19]
The icons are cached locally I believe. Look in:
C:\Program Files\CCP\EVE\cache\Pictures\Blueprints
When it request the blueprint info it sends the icon along with it. I could be wrong on this so don't take it as a fact.
-Xonox Pulsar Combat Supplies, Director of Production and POS |
Talaan Stardrifter
|
Posted - 2008.06.20 15:21:00 -
[20]
Originally by: Lord Fitz
Originally by: Pwett use the Science and Industry blueprint section
This.
We've been over this 100 times (although not for the last few months)
It's not possible for them to do this for items because 1 item = 1 icon. A BPC is the SAME item as a BPO but with different attributes.
It is possible however to do this in the S&I window where they already show you if it's a copy anyway. Increased functionality in the S&I window is what you want (drag and drop etc).
I've seen the static dumps, I am aware of the minimum levels of normalisation apparent in them. (I''m also aware they may only be views and not necessarily tables)
First: I agree with the S&I usage and functionality, but lets fix other things first (Overview Bug).
Second: If "1 item[type] = 1 icon", then 2 itemtypes would = 2 icons. The issue at hand is that A BPC need not be the same item type as a BPO. Adding another itemtype wouldn't break the database, wouldn't require ANY table manipulation (database redesign), and shouldn't require exhaustive processing power to evaluate. It would mean that a single item type was virtually identical to a second item type, and would require another similar icon (Green is good ).
The side effect of this is that "Sort by Type" in your assets list will group BPOs together in one section, and BPCs together in another section and not having them randomly interspersed as is now the case.
|
|
Selari
|
Posted - 2008.06.20 15:23:00 -
[21]
Originally by: Lord Fitz
It's not possible for them to do this for items because 1 item = 1 icon. A BPC is the SAME item as a BPO but with different attributes.
It is possible however to do this in the S&I window where they already show you if it's a copy anyway. Increased functionality in the S&I window is what you want (drag and drop etc).
It is never 'impossible' for a coder to do something with the code he has control over.
I'll include this little snippet in PHP form.
Quote: (Inside the Icon fetch code) if($this->itemtype == #BLUEPRINTITEMTYPE#) { $this->details = get_item_details($this->uniqueid); if($this->details['copysavailable'] == -1) { $this->icon = 'bpo'.$this->icon; } else { $this->icon = 'bpc'.$this->icon; } }
Even if the icons are stored locally, however, this would STILL require a call to the server (because get_item_details would need data that is only stored on the server, for anti-hacking purposes), which would make this code undesirable. Doable, but undesirable.
|
Xonox Galatorg
Pulsar Combat Supplies Alternative Realities
|
Posted - 2008.06.20 15:33:00 -
[22]
Originally by: Talaan Stardrifter
... lets fix other things first (Overview Bug). ... The side effect of this is that "Sort by Type" in your assets list will group BPOs together in one section, and BPCs together in another section and not having them randomly interspersed as is now the case. ...
First part: I really wish/hope this is #1 on their list.
Second part: That would be nice -Xonox Pulsar Combat Supplies, Director of Production and POS |
Pwett
QUANT Corp. QUANT Hegemony
|
Posted - 2008.06.20 16:56:00 -
[23]
There's a reason that bpos and bpcs are the same itemtype - if they weren't there would either need to be another layer for data retrieval - i.e. a bpcID and parentID table, or there would need to be duplicates of all the data in the bpotypes or even tl2materials table.
One is a database no-no and the other one would quickly add up to being an extensive amount of additional processing and retrieval time. _______________ Pwett CEO, Founder, & Executor <Q> QUANT Hegemony
|
Matthew
BloodStar Technologies
|
Posted - 2008.06.20 18:20:00 -
[24]
Originally by: Talaan Stardrifter Second: If "1 item[type] = 1 icon", then 2 itemtypes would = 2 icons. The issue at hand is that A BPC need not be the same item type as a BPO.
Actually, dev responses in the linked thread have specifically stated that, given the current implementation, this must be the case:
Originally by: CCP Lingorm 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).
Note that they also say that they want to change this limitation, but this is likely to be a significant coding change, that is not a high priority currently (I suspect things like the HPC project are sucking up most of the server code development time).
Originally by: CCP Lingorm Adding another itemtype wouldn't break the database, wouldn't require ANY table manipulation (database redesign), and shouldn't require exhaustive processing power to evaluate. It would mean that a single item type was virtually identical to a second item type, and would require another similar icon (Green is good ).
What it would require is additional QA to ensure that the copy and original shared the same properties. By having two different item types, you open up the potential for additional bugs (e.g. a Raven BPC producing a Megathron, or just having a different production time etc).
Also, as Pwett mentions, double the amount of item types in bpotypes and tl2materials tables is going to increase the computational cost of queries using those tables.
Originally by: Bambi Surely if all icons are stored locally within the client, and the client has already received the copy/original flag from the server, then the lag would not be server side?
The problem is that the client does not normally receive the copy/original flag when you load your hangar. Finding out that flag is a separate look-up, and one that generates much greater load.
For the people unfamiliar with databases, joins, normalization etc, lets try to make a similar example in a paper filing system.
Most paper filing systems will have an index card. This will tell you what each file is, where it is stored, and maybe how many files there are. If you just want to know what's in the filing system, you can get it quickly and easily from the index card. This is equivalent to the look-up performed to load your hangar in Eve.
Now, imagine in your paper filing system, you are asked which files have an X99 form in them. That isn't recorded on the index card, so you have to physically look through every file to check. Clearly, this is going to be very time-consuming, and not practical to do every time you check the index card. That is the sort of question you're asking when you want to know whether a blueprint is a copy or original.
Yes, the check can be done, and is done in appropriate circumstances (e.g the S&I window). However it is not practical to do every single time someone looks at their hangar.
And yes, you could flag the presence of the X99 form as an extra column on the index card. But that makes the index card bigger, and more difficult to use for it's intended rapid-lookup purpose, especially when most checks do not care about the X99 form.
Oh, and for the tech pedants, yes I know the analogy is not an exact match to what a Join really does, but I feel it is a useful tool for those seeking to understand the problem without learning lots of database theory.
Given the database structure issues, I think that trying to get the desired flagging into the main hangars is not worth the effort it would take. Instead, enhancing the existing S&I screen into a full-blown BP management tool would be the way to go. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
Lord Fitz
Antares Fleet Yards SMASH Alliance
|
Posted - 2008.06.20 18:45:00 -
[25]
Originally by: Bambi Surely if all icons are stored locally within the client, and the client has already received the copy/original flag from the server, then the lag would not be server side?
The server when you open your items window, tells the client it has a blueprint of type x . The client then picks out the icon for the BP. The client is NOT sent the attributes (which determine if it's a BPC) unless you do a show info. At this point the client sends a request to the server, and this causes the lag. To give different icons to BPCs the server would need to send that request for EVERY item in your hangar. Thus the lag.
It already does this when you open the S&I window but only for BPOs etc. It doesn't do it every time everyone opens their items window.
|
Slanty McGarglefist
University of Caille
|
Posted - 2008.06.20 19:15:00 -
[26]
Wait! So you're telling me that its impossible to add three letters before the name of the Blueprint like;
BPC Raven Blueprint BPO Heavy Neutron Blaster BPO Arbitrator BPC Large EMP Smartbomb
Etc and so on!?!!? __________________________________________________
Originally by: CCP Wrangler No
Doh! |
Matthew
BloodStar Technologies
|
Posted - 2008.06.20 19:31:00 -
[27]
Originally by: Slanty McGarglefist Wait! So you're telling me that its impossible to add three letters before the name of the Blueprint like;
BPC Raven Blueprint BPO Heavy Neutron Blaster BPO Arbitrator BPC Large EMP Smartbomb
Etc and so on!?!!?
Hmm, depends on exactly how the unique item names are handled. I remember from discussions around the space clean-up blog that not all items have all fields, so it depends if blueprints have, or can be given, a unique name field. It would probably use the same naming system as ships and containers. Though you would have to special-case the item creation routine to set the unique item name to the correct value, and to prevent the user manually changing the name. Though the name is unique to each item, there must be a way to load this in the hangar, as it is already done.
Though from a design point of view, flagging via a prefix in a text field is a fairly dirty hack.
I'd suggest posting the idea in the thread others have linked to, that one more likely to get dev attention. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
Slanty McGarglefist
University of Caille
|
Posted - 2008.06.20 19:35:00 -
[28]
Originally by: Matthew I'd suggest posting the idea in the thread others have linked to, that one more likely to get dev attention.
Done as requested. __________________________________________________
Originally by: CCP Wrangler No
Doh! |
Uncle Mo
Raddick Explorations
|
Posted - 2008.06.20 21:49:00 -
[29]
Thanks for the link to the other thread and the S&I tip. Sorry to open up an old can of worms. --------------------------------------------- Official US ambassador to the UK.
|
quickshot89
|
Posted - 2008.06.21 18:57:00 -
[30]
its called a BLUE print
why would a blueprint be pink, it would be a pinkprint then, regardless if its a copy
|
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |