EVE Search - Is it do difficult to have a different color for BPO / BPC ?

All Channels

EVE General Discussion

Is it do difficult to have a different color for BPO / BPC ?

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

Monitor this thread via RSS [?]

Pages: 1 2 3 4 :: [one page]
Author	Thread Statistics \| Show CCP posts - 1 post(s)
Morwagorion	Posted - 2006.12.20 22:11:00 - [1] Just change a bit color, BPC and BPO should not have the same icon
Major Stormer Caldari Red Storm Vendetta	Posted - 2006.12.20 22:14:00 - [2] Well, in fairness, it is called a "Blue"print. However a symbol on eachone saying if it was BPC or BPO, like C or O on the icon would be nice.
DukDodgerz Amarr Imperial Academy	Posted - 2006.12.20 22:22:00 - [3] bpo - gold text bpc - silver text with the number of remaining runs showing.
mindycs	Posted - 2006.12.20 22:24:00 - [4] Originally by: DukDodgerz bpo - gold text bpc - silver text with the number of remaining runs showing. Please and thank you
Terminal Entry New Fnord Industries	Posted - 2006.12.20 22:29:00 - [5] Originally by: mindycs Originally by: DukDodgerz bpo - gold text bpc - silver text with the number of remaining runs showing. Please and thank you Even if it's not with the runs remaining
x racer	Posted - 2006.12.20 22:34:00 - [6] In RL, theres only one blue blueprint, the original.....all copies of the original are gray, but still called blueprints. Not that RL has much to do with eve, hehe x
Fester Addams Minmatar	Posted - 2006.12.20 22:36:00 - [7] Sadly when the game was first coded the devs did not separate between the different types, they simply put in a number of parameters that defined what the print was. The real sad this is that the icon was hard coded and thus to change the icons the devs would have to manually go through all BP's that all the players in the game have and switch the icons. As many of us old players know there have been a number of changes to BP's but they have all been alterations where you could simply search for a specific list entry and alter it (ex unlimited BPC -> max run BPC). This is what I have gathered from dev posts. I do agree that BP's of different types should be changed, T2 BP's should have the tech II variation in the corner and there should be a visual difference between a BPC and a BPO but if making this change meens taking lots and lots of time away from more pressing issues then Im all for ignoring that.
Lucio Gallente UK Corp Lotka Volterra	Posted - 2006.12.20 22:39:00 - [8] It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! ************************************************ Yes, I know I have a negative sec. status but I'm not a pirate damnit!
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.20 22:56:00 - [9] Edited by: j0sephine on 20/12/2006 22:56:50 "Just change a bit color, BPC and BPO should not have the same icon" This was discussed at length some time ago in game development forum section... the crux of it is, because from server point of view the BPO and BPC are the same item with slightly different internal data, in order to tell apart the BPOs from BPCs the client would have to send query for each blueprint in your hangar each time you access your inventory. Multiply it by number of people in EVE playing with their inventory both while docked and in space, and the stress on server becomes enourmous. Some suggestions were made to introduce things like the client caching blueprint state to allow this kind of display without overloading the server... but in the end i guess it's just too much work and/or devs don't want to risk it with enough lag being in the system as it is o.O;
Audri Fisher Caldari The Keep THE R0CK	Posted - 2006.12.20 23:01:00 - [10] Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! I don't normaly call people idiots, and I don't think I will start now on your account. That being said, the devs have said on numerous occassions that it IS possible, but not worth it at this point, it would require so much time and effort that it would not be an effective use of manpower.
Miss Overlord Gallente Ferrum Pugnus New Eve Order	Posted - 2006.12.20 23:03:00 - [11] should be but to difficult to reprogram These posts represent my personal views and not those of my corp or alliance. These do not reflect offical alliance or corp views This is a disclaimer
Lost Penguin	Posted - 2006.12.20 23:06:00 - [12] Originally by: x racer In RL, theres only one blue blueprint, the original.....all copies of the original are gray, but still called blueprints. Not that RL has much to do with eve, hehe x in RL all the prints are black and white (including the originals), but I suppose that the color the paper that the drawings is on depends upon what company made them.
Too Kind	Posted - 2006.12.20 23:07:00 - [13] Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Not really ignored. They said it's not easy to change it, because a bpo and a bpc are technically the same or something like that. -------------------------- Post with your main !!!111
Tissaphernes	Posted - 2006.12.20 23:13:00 - [14] Originally by: Major Stormer Well, in fairness, it is called a "Blue"print. However a symbol on eachone saying if it was BPC or BPO, like C or O on the icon would be nice. I'll own up to it. I laughed when I first read this. Don't know what's wrong with me.
Shakuul Caldari The Imperial Commonwealth The Sundering	Posted - 2006.12.21 01:00:00 - [15] Maybe there would be a way to work around this...like giving players multiple hangars (just like corporations have), so you could sort BPOs into one hangar and BPCs into another.
DaveW Caldari South Park Development	Posted - 2006.12.21 03:42:00 - [16] Anything that seperated BPO's from BPC's would be a great step forward. --------------------------------------------------- "If you can't stand the heat..., stay out of the Kitchen."
Period Avenger	Posted - 2006.12.21 04:21:00 - [17] Edited by: Period Avenger on 21/12/2006 04:21:30 indeed... BPCs should be a light beige color. -Period AvengerÖ
F'nog Amarr Celestial Horizon Corp. Ascendant Frontier	Posted - 2006.12.21 06:11:00 - [18] To answer the thread title: yes, yes it is. Originally by: Lucio It can't be that hard to recolour a few hundred icons! The problem is that it's a few MILLION icons, not hundred (see above). Originally by: Troy Knight [After training Warp Drive Ops I] Still time I could have used training something else.
Shameless Avenger	Posted - 2006.12.21 06:40:00 - [19] /Signed The Blody BPCs should be different. Another tone of blue, or maybe green...anything. Just make the icons different somehow.
Tachy	Posted - 2006.12.21 07:00:00 - [20] BPO and BPC are the same item in the database. I would not be surprised when a BPC is just an entry linking to the BPO with a number of runs attached. And the BPO you research exists as a separate item in the DB - The old gets removed from your hangar and the researched one being placed in there. This would explain a couple of the problems that appear from time to time where BP kinda disappear from the research or production facilities during patches. There's no way to technically differentiate between them without accessing the full BP entry each time someone opens a container (hangar, can, ship ...) for each single BP in there - and in all containers within. You do remember the reason for removing those insta bookmarks at stations and gates? Yes, it has been done to remove the load on the database. Do you remember the reason for the revamp of the production and science system? Yes, ir has been done to remove the load on the database. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
Baleur Caldari Provisions	Posted - 2006.12.21 07:17:00 - [21] Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Hell i can set up photoshop to recolor as many icons/images as nessecary automatically, im sure they can to. They could patch this in a day if they wanted to / had 15 min to sort it out :)
Morwagorion	Posted - 2006.12.21 07:41:00 - [22] im not a BD expert, but i can imagine 2 solution: 1. a "modify query" that create a new table / new entry in a record 2. our client do the work: if BPC display icon A or add a "C" to BPC icon, if BPO display icon B any solution, even if not "elegant", is better than this situation .
Okkie2	Posted - 2006.12.21 07:58:00 - [23] Edited by: Okkie2 on 21/12/2006 08:02:21 Originally by: Baleur Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Hell i can set up photoshop to recolor as many icons/images as nessecary automatically, im sure they can to. They could patch this in a day if they wanted to / had 15 min to sort it out :) Making new icons isn't the problem, the problem is atm a BPO and a BPC are the same items but with different attrbutes. So they would have to go through all BP's (that's every single BPB/BPO that's in the game) to check whether it's attributes make it a BPO or BPC. Depending if it's a BPO or not they then change the itemnr/icon etc. So it would be possible but a lot harder then just changing some icons in Photoshop..... Do you really think they wouldn't have changed this long ago if it was only 15mins of work ? Not changing the item itself, but make the client show another icon will result in extra load on the server creating lag (as allready mentioned earlier)
Fire Hawk Destructive Influence Band of Brothers	Posted - 2006.12.21 08:03:00 - [24] The current database schema simply doesnt allow to do it. They need to change something in the DB that will need to fix a massive code correction everywhere in the game. However they can do it on the client side I think, but will generate a loading delay in the hangars where BP's appear. Imagine 150 BP's in a corp hangar that each need a server request before rendering the icon. ____________________________________ You hated ATUK and ATUK loved you for that.
Jarnau Gurgeh	Posted - 2006.12.21 08:40:00 - [25] Originally by: j0sephine Edited by: j0sephine on 20/12/2006 22:56:50 "Just change a bit color, BPC and BPO should not have the same icon" This was discussed at length some time ago in game development forum section... the crux of it is, because from server point of view the BPO and BPC are the same item with slightly different internal data, in order to tell apart the BPOs from BPCs the client would have to send query for each blueprint in your hangar each time you access your inventory. Multiply it by number of people in EVE playing with their inventory both while docked and in space, and the stress on server becomes enourmous. Some suggestions were made to introduce things like the client caching blueprint state to allow this kind of display without overloading the server... but in the end i guess it's just too much work and/or devs don't want to risk it with enough lag being in the system as it is o.O; Moreover we should not forget: usability was never a goal of CCP The run to a higher number of simultaniously players is more importent. So we will expect some more crippled functionality (but saving CPU on the Server).
UGWidowmaker Caldari Setenta Corp Xelas Alliance	Posted - 2006.12.21 08:41:00 - [26] Originally by: Audri Fisher Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! I don't normaly call people idiots, and I don't think I will start now on your account. That being said, the devs have said on numerous occassions that it IS possible, but not worth it at this point, it would require so much time and effort that it would not be an effective use of manpower. ofc its worth the manpower.. i know poeple who by mistake mixed up bpc and bpo and sold the bpo as an bpc... so who is it u call an idiot ? I will make your wife/mann a widow.
Tachy	Posted - 2006.12.21 08:42:00 - [27] Originally by: Fire Hawk The current database schema simply doesnt allow to do it. They need to change something in the DB that will need to fix a massive code correction everywhere in the game. However they can do it on the client side I think, but will generate a loading delay in the hangars where BP's appear. Imagine 150 BP's in a corp hangar that each need a server request before rendering the icon. Currently the item info itself isn't pulled. The client just gets the information that a BP of <item> is there. If the client or the server had to access the data each time and for every single BP in the ships, hangars and cans, we would not like the resulting DB based lag. Currently the BP item entry is only accessed when you look at the BP or when you're trying to install it into a lab or factory. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
Oleg K77	Posted - 2006.12.21 10:06:00 - [28] If there is problem with existing BPCs, make new BPCs as different items and leave existing ones as they are.
Tachy	Posted - 2006.12.21 10:47:00 - [29] They don't just look the same. They are the same. A change would require a complete rework of the Science&Industry and the production system, all laong the POS and relevant remote skills & features. On the bright side it would mean that the reduction in the DB complexity from removing all basic and micro BP would be counted by a long shot. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
Shameless Avenger	Posted - 2006.12.21 10:57:00 - [30] IMO, this thread is worthy of a Dev response. -------------------------------------------------- BPO/BPC Blody icons should be different
Angry Sheep Amarr Aur0ra	Posted - 2006.12.21 11:01:00 - [31] /Signed It's a Dog eat Dog World out there and I'm wearing Milky Bone underwear
Shinoobie Inversion Imperial Republic Of the North	Posted - 2006.12.21 11:11:00 - [32] People keep saying that they are the same. They are not. There is one unique factor differing between a BPO and a BPC, a BPC has a "Runs Left" attribute > 0 and < 1500. All CCP have to do is have the client read this single attribute say (X), then the rendering routine of the client will then place a "C" in the top left hand corner of the BP Picture when IF X > 0 AND X < 1501 = TRUE else it places a "O". Surely reading a single attribute of any BP Item can't be that server intensive over and beyond reading the name. Elite Scouting
Shameless Avenger	Posted - 2006.12.21 14:24:00 - [33] OK, the correct whine is that they LOOK the same. Then you have a bunch of copies and one original and have to spend a lot of time sorting out which ones are copies. A different color, a "C" or some kind of distiction is needed. We don't want to open them up one by one to find out. -------------------------------------------------- BPO/BPC Blody icons should be different
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.21 17:18:00 - [34] "Surely reading a single attribute of any BP Item can't be that server intensive over and beyond reading the name." That's precisely the point, it is. Or to put it simpler, presuming it's even possible to read single specific attribute of item rather than having to request all its data as package... you go from: request for single ID number (resolved to name client side) to: request for ID number and attribute ... that's doubling the workload -- two requests vs one for each BP, and twice as much data to lookup and send.
Tachy	Posted - 2006.12.21 17:31:00 - [35] They do not access the entry for the BPs unless you apply a 'show info' or install it into a lab or factory. Until then the BP is just a generic BP of the type. I think Valar posted about that about 1.5 years ago. I might be off on the Dev and the time here by a long shot. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20

kieron	Posted - 2006.12.21 17:33:00 - [36] Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. kieron Community Manager, EVE Online

elFarto New Order Industries	Posted - 2006.12.21 17:34:00 - [37] Oh god, not another one of these threads. runs away NPC database Mal: This is your captain speaking. We're having some technical difficulties, so we may experience some turbulence, and then explode.
Ilea Celentay Veiled Justice	Posted - 2006.12.21 17:37:00 - [38] Originally by: elFarto Oh god, not another one of these threads. runs away Firefly in your Sig, why did it get cancelled so. - Faction\|Tech1 Ship Info \|\| Rig Factory
Kamikazi BOB	Posted - 2006.12.21 17:38:00 - [39] Not very important but if it could be slipped in in one of the comming patches that be great, 1 simple solution is to change the degree of blue, just make bpo's darker and bpc's lighter? Or give bpc's a different color all together, or mebbe even just put bpc at the end, prolly dozens of easy solutions to let bpc's stand out from bpo's Anyways, would be a good improvement but not priority.
End Yourself Core Domination Big Bang Quantum	Posted - 2006.12.21 17:46:00 - [40] WORKAROUND: Lock down all bpos, voila! And it's a wise thing to do anyway. --- Fighting for peace is like screwing for virginity.
Shameless Avenger	Posted - 2006.12.21 17:54:00 - [41] Originally by: kieron ... Is this something that will be addressed in the future? Certainly. ... Thank you :)
DarkMatter Amarr Mineral Aquisition Group	Posted - 2006.12.21 17:55:00 - [42] Edited by: DarkMatter on 21/12/2006 18:04:15 So who is the "idoit" who made them the same? Probably the same "idiot" who first allowed BPC's to have unlimited runs, and the same "idiot" who came up with the T2 lottery, and the same "idiot" who came up with Invention... See a pattern here? I guess that "idiot" still works for CCP... This is what happens when the entire DEV team is PvP orientated... It shows through in all the PvE/Industrial content in this game... (PvP is great, it's what this game is about, but a robust Industrial/Market sector is sorely desired by many players, and we just don't have that...) If PvP was managed in the same way the other game content is, EVE would not be the best MMO on the market... And this topic points out one of the oversights of the DEV team, that has lead to more over the years IMO concerning these apsects of the game. (They make mistakes in PvP too, but not as blatant as these...) Newest toy for my 63 acre sandbox Building the homestead
m0jo Destructive Influence Band of Brothers	Posted - 2006.12.21 17:56:00 - [43] Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Why dont you guys just do away with bpc's?
Shameless Avenger	Posted - 2006.12.21 18:04:00 - [44] Originally by: End Yourself WORKAROUND: Lock down all bpos, voila! And it's a wise thing to do anyway. Hum, a quick "How to lock BPO's" would be nice :)
Tachy	Posted - 2006.12.21 18:10:00 - [45] Drop the BP into your corp hangar. Have the CEO or director start a vote. Have someone remove the unlocked BPC from your corp. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
Snarls McGee	Posted - 2006.12.21 18:18:00 - [46] Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Perhaps I'm just dense but didn't something like 280 million insta-bookmarks just get deleted? Surely there is some room in "the" db now as well as some free CPU cycles since, I'd dare say, more bookmarks were being loaded and used (when characters logged in, when they opened up People and Places, each time they entered a new system, etc)at any given time than BPOs/BPCs (opening up a hanger where they are kept, installing them in a factory, etc).. At the very least since we seem to be having more and more extended downtimes is there any way to implement this for all FUTURE BPCs? Over time all the existing BPCs will get used up. Even if there are worries of scams using 'old' BPCs trying to sell them off as BPOs then what kind of buyer buys a researched BPO without confirming/checking out the item? ---------- We've all heard that a million monkeys typing will eventually create something intelligent. Thanks to message forums we know that isn't true.
Jacob Holland Gallente FIRMA Interstellar Alcohol Conglomerate	Posted - 2006.12.21 18:37:00 - [47] Would it increase the load vastly if the icon were changed to add a window similar to the "number in stack", turret size or slot requirement? Perhaps in the top left hand corner the BP could simply display how many licensed runs remain on the print, with infinite runs showing as an asterisk if the mobius strip can't be used. It wouldn't show the originals from the copies absolutely as old, infinite run copies would show the same as originals; but it would make sorting easier. -- Originally by: cordy Respect to IAC .Your one of the few people who truly deserve to own and live in the space you are in.
Ramblin Man Empyreum	Posted - 2006.12.21 18:38:00 - [48] You actually want more lag for everyone now, so that you don't have to inconvience yourself with a few "show info"s?
Popsikle Caffeine Commodities Company	Posted - 2006.12.21 18:53:00 - [49] Edited by: Popsikle on 21/12/2006 18:53:43 Scamming is part of the game, and people who dont bother to read what they are selling/buying should be scammed. And the the industry whiner above: "waaaa waa waaaaa CCP hate PVE players, and they are all idiots, waaa waaa waaa" is about what you said right? __________________________________________ -= We Fly for our people =- -= I fly for Blood =-
DarkMatter Amarr Mineral Aquisition Group	Posted - 2006.12.21 19:18:00 - [50] Edited by: DarkMatter on 21/12/2006 19:20:32 Originally by: Popsikle Edited by: Popsikle on 21/12/2006 18:53:43 Scamming is part of the game, and people who dont bother to read what they are selling/buying should be scammed. And the the industry whiner above: "waaaa waa waaaaa CCP hate PVE players, and they are all idiots, waaa waaa waaa" is about what you said right? I enjoy PvP as well... But you can't deny the lack of interest CCP shows in getting the industry side of this game up to snuff... It only exists as an afterthought to support PvP in EVE. If you canÆt see that your frickin blind... Everything they touch on the Indy side seems to get **** up, and it's because of lack of interest on their part to get it right... From jet can mining to POS'. Poor vision, poor implementation due to lack of really giving a ... Now they just throw a buch of goofy ** at the industry side in the hopes to shut most of us up... Newest toy for my 63 acre sandbox Building the homestead
Popsikle Caffeine Commodities Company	Posted - 2006.12.21 20:03:00 - [51] Originally by: DarkMatter Edited by: DarkMatter on 21/12/2006 19:20:32 Originally by: Popsikle Edited by: Popsikle on 21/12/2006 18:53:43 Scamming is part of the game, and people who dont bother to read what they are selling/buying should be scammed. And the the industry whiner above: "waaaa waa waaaaa CCP hate PVE players, and they are all idiots, waaa waaa waaa" is about what you said right? I enjoy PvP as well... But you can't deny the lack of interest CCP shows in getting the industry side of this game up to snuff... It only exists as an afterthought to support PvP in EVE. If you canÆt see that your frickin blind... Everything they touch on the Indy side seems to get **** up, and it's because of lack of interest on their part to get it right... From jet can mining to POS'. Poor vision, poor implementation due to lack of really giving a ... Now they just throw a buch of goofy ** at the industry side in the hopes to shut most of us up... Hmm yes... Lets see, every ship that is blown up or hell even used, every module used, every bit of ammo is created by someone (ok, so thats only 90% true)... Thats really not saying that EVE is an industry based game now is it? Everything, including PvP is group based, thats why your in a corp, and in a group jet can mining is the most efficient way it can be done, period. Haulers cant mine the rocks, and haul, and get the volume that a group nets, POS's work wonders, they arent bad to maintain, and they save alot of cash if you are doing it right, in a group... So yea, solo industry may suck, but its supposed to, its not a solo game. And having the PvP almost 100% fueled by the industry means that the industry side HAS to work, otherwise both sides come to a halt... and Im not seing both sides come to a halt, so industry cant be that broken now can it? __________________________________________ -= We Fly for our people =- -= I fly for Blood =-
DarkMatter Amarr Mineral Aquisition Group	Posted - 2006.12.21 20:19:00 - [52] Edited by: DarkMatter on 21/12/2006 20:19:52 Originally by: Popsikle Originally by: DarkMatter Edited by: DarkMatter on 21/12/2006 19:20:32 Originally by: Popsikle Edited by: Popsikle on 21/12/2006 18:53:43 Scamming is part of the game, and people who dont bother to read what they are selling/buying should be scammed. And the the industry whiner above: "waaaa waa waaaaa CCP hate PVE players, and they are all idiots, waaa waaa waaa" is about what you said right? I enjoy PvP as well... But you can't deny the lack of interest CCP shows in getting the industry side of this game up to snuff... It only exists as an afterthought to support PvP in EVE. If you canÆt see that your frickin blind... Everything they touch on the Indy side seems to get **** up, and it's because of lack of interest on their part to get it right... From jet can mining to POS'. Poor vision, poor implementation due to lack of really giving a ... Now they just throw a buch of goofy ** at the industry side in the hopes to shut most of us up... Hmm yes... Lets see, every ship that is blown up or hell even used, every module used, every bit of ammo is created by someone (ok, so thats only 90% true)... Thats really not saying that EVE is an industry based game now is it? Everything, including PvP is group based, thats why your in a corp, and in a group jet can mining is the most efficient way it can be done, period. Haulers cant mine the rocks, and haul, and get the volume that a group nets, POS's work wonders, they arent bad to maintain, and they save alot of cash if you are doing it right, in a group... So yea, solo industry may suck, but its supposed to, its not a solo game. And having the PvP almost 100% fueled by the industry means that the industry side HAS to work, otherwise both sides come to a halt... and Im not seing both sides come to a halt, so industry cant be that broken now can it? So how is the T2 lottery not solo? Like I said, you're blind... The industry in this game functions to serve PvP only, certainly not to make the game fun for the players who engage in crafting... From day one this has been aparent, and from day one it has taken a back seat, and only made to be "good enough" Just imagine where this game would be if the DEV's lacked the vision for PvP that they do for the industry side of the game... We would not be here.. Newest toy for my 63 acre sandbox Building the homestead
Barrier Solo Solo Ventures	Posted - 2006.12.21 21:10:00 - [53] Edited by: Barrier Solo on 21/12/2006 21:10:47 Add DB tags to objects which are fetched with the object load. For any container, allow creation of logical seperators like in the Corp windows - Assets - where the hangar contents for POS are at least sorted by hangar location. With this, I could group all my BPOs BPCs Missile Launchers etc etc within a hangar, without using GSCs. Optional next step is to create permissions for those tags, so I can give access to the BPCs to builders, and BPO to directors. That part might increase load a bit, but the first part wouldn't have any significant impact server-side. Barrier Solo, CEO, INSM, ISS Join us! http://oldforums.eveonline.com/?a=topic&threadid=402528
Got b00ns	Posted - 2006.12.21 22:37:00 - [54] Edited by: Got b00ns on 21/12/2006 22:42:01 Edited by: Got b00ns on 21/12/2006 22:41:15 Edited by: Got b00ns on 21/12/2006 22:37:37 Originally by: kieron CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Please explain in layman's term to me, how the current colour gets from the databases onto the player's screen without generating that exact 5-10% performance lag you are talking about. Thank you It's just.. your statement is confussing me. Does the blue color of the BPo/c generate 5-10% lag at the moment as well? How can a simple load of a 32bit integer create 5-10% more lag?
Leilani Solaris Gallente 0utbreak	Posted - 2006.12.21 22:46:00 - [55] Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. You did it to ECM modules, why would it be so hard to do on bpo's/bpc's? Outbreak Killboard
Lucio Gallente UK Corp Lotka Volterra	Posted - 2006.12.21 23:04:00 - [56] Edited by: Lucio on 21/12/2006 23:18:42 Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. It's quite frankly appalling that no one thought of this when you were designing the game. It's got to have been one of the worst UI blunders that's still left in the game (bar things that are just plain not working!). Isn't it time to just through away the blueprint system as it stands? If your code is that bad and your database schema that limited, why not start from scratch with new ideas? What about having only BPC that you have to accquire licenses to be able to purchase or making BPC into another form of component used??? But what's the point, I'm only one person with some "crazy" ideas so I might as well leave you all to your highly educated, stupidly overpaid thinking... ************************************************ Yes, I know I have a negative sec. status but I'm not a pirate damnit!
HankMurphy Pelennor Swarm Eternal Rangers of Terror	Posted - 2006.12.21 23:05:00 - [57] Originally by: kieron I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. I would find the person that informed you and tell them how uncomfortable it is to blow smoke up there :P this just doesn't sound logical at all. If it is true, perhaps you need to re-evaluate some priorities. Simple changes like this shouldn't be as difficult as CCP often says they are. FFS, how about recon ships + cloaks + cyno gen = might as well give the ship another role as you (for whatever weak reason) cannot figure out a way to fix it. Situation Normal, AFU
hired goon Infinite Improbability Inc Dusk and Dawn	Posted - 2006.12.21 23:06:00 - [58] Edited by: hired goon on 21/12/2006 23:11:53 Originally by: kieron I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Oh. My. God. Now, I may have failed maths twice, but even I can tell what an arse-poundingly huge amount of lag we could get rid of if by this logic, we made all icons for items in the game... the same! I say, banish fleet lag! Remove all icons! -omg-
Morkus Rex Amarr Vure	Posted - 2006.12.22 07:24:00 - [59] Could it not be possible to just ad "BPO" or "BPC" to the name of the blueprints ? Most equipment is already like that, same icon but another name for named and faction stuff... ___________________________________ Remember to set long skill training EVERY time you lagout!
Lucio Gallente UK Corp Lotka Volterra	Posted - 2006.12.22 07:30:00 - [60] Originally by: Morkus Rex Could it not be possible to just ad "BPO" or "BPC" to the name of the blueprints ? Most equipment is already like that, same icon but another name for named and faction stuff... It would appear that this is beyond their abilities at this present time because they didn't think it was a needed function to be able to tell the difference.... ************************************************ Yes, I know I have a negative sec. status but I'm not a pirate damnit!
Ariel Dawn SniggWaffe	Posted - 2006.12.22 15:35:00 - [61] Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover.
Okkie2	Posted - 2006.12.22 15:48:00 - [62] Originally by: Ariel Dawn Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover. Did you read the DEV-post a page earlier ? It is possible but will introduce 5-10% extra lag, and solving this problem is certainly not worth extra lag
prsr Gallente JuBa Corp	Posted - 2006.12.22 16:25:00 - [63] Originally by: kieron Is this something that will be addressed in the future? Certainly. On behalf of all the players that have gotten their grubby hands on sweet t2 bpo's because the previous owners sold their bpo for the price of a bpc on escrow by mistake I would like to say: Nooooo!!!!!1111one, don't do it. thank you. -- .sig apathy ftw
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.22 17:03:00 - [64] Edited by: j0sephine on 22/12/2006 17:07:07 "Please explain in layman's term to me, how the current colour gets from the databases onto the player's screen without generating that exact 5-10% performance lag you are talking about. Thank you " It's currently something the client can do it on its own. All it takes is internal information to the effect "items with ID 20, 35, 40-50 ... are blueprints, use this special blue background and hue to generate their icon for the player to see" But because both BPO and BPC have the same item ID, the client cannot tell BPO from BPC just with the item ID alone... it would also have to examine content of the item to read its 'remaining copies' attribute. Which is something that normally doesn't happen until the player uses the "show info" command. It's this additional information lookup multiplied by number of players multiplied by number of BPOs and BPCs scattered in players hangars EVE-wide multiplied by number of times a day players access their inventory/assets windows etc... that would result in overall load increase of mentioned 10-15% ... something like this, anyway o.O;
Ariel Dawn SniggWaffe	Posted - 2006.12.22 17:10:00 - [65] Originally by: Okkie2 Originally by: Ariel Dawn Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover. Did you read the DEV-post a page earlier ? It is possible but will introduce 5-10% extra lag, and solving this problem is certainly not worth extra lag I know that, but my suggestion wasnt along the lines of splitting BPOs and BPCs into seperate items. Just thought if one were to hold the mouse over a BPO/BPC, it would simply say "BPO" or "BPC" in a floating text box based on the unchanged properties of the print. So as no actual changes would be made to differentiate the two, I doubt it would add any lag or stress.
spiritfa11 Vengeance of the Fallen Imperium Alliance	Posted - 2006.12.22 17:25:00 - [66] sort by type ... the first blueprint of a given type starting from left to right has "generally" (every time ive done it) been the bpo, not the bpcs, is that difficult? --------------------- I make sigs, plz evemail me ingame \| Gallery
glorious emotion Gallente Brainiacs	Posted - 2006.12.22 17:29:00 - [67] Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Thanks for the info kieron, good to hear it's something that's being looked at in the future, even if it's the distant future Which PA character are you?
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.22 17:30:00 - [68] "Just thought if one were to hold the mouse over a BPO/BPC, it would simply say "BPO" or "BPC" in a floating text box based on the unchanged properties of the print. So as no actual changes would be made to differentiate the two, I doubt it would add any lag or stress." But in order to show that information in the floater the client still has to request it from the server (it's not sent by default when you open the inventory to keep the load smaller) ... so while it'd be less stressful than automatic requests, there's some extra processing added nonetheless.
Wilfan Ret'nub Singularity.	Posted - 2006.12.22 18:36:00 - [69] Originally by: j0sephine But in order to show that information in the floater the client still has to request it from the server (it's not sent by default when you open the inventory to keep the load smaller) It could be sent by default. If they put in some effort, they could piggy-back it on something else - probably there's already a set of item flags. If not, they could find some more features (quick) item data needs and amortize that extra byte. ------ No ISK, no fun
Thor Xian Vertigo One E.A.R.T.H. Federation	Posted - 2006.12.22 18:41:00 - [70] I'd rather see the end of BPCs. ~Thor Xian, Material Defender "For all your Material Needs, Vertigo One." Corp/Alliance Services
DukDodgerz Amarr Imperial Academy	Posted - 2006.12.22 18:59:00 - [71] i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better. use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it.
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.22 20:04:00 - [72] Edited by: j0sephine on 22/12/2006 20:11:33 "It could be sent by default." Which would cause that very 10-15% server load increase kieron mentioned. There is no free lunch here -- any piece of data (at least one that isn't static) has to be looked up by the server and sent to the client in order to make it available for you. And that lookup takes time and processing power.
Uggster Caldari FinFleet Lotka Volterra	Posted - 2006.12.22 20:07:00 - [73] CBA to read the entire thread but if there was a way to easerly see the differance between BPO's and BPC's expect any decent BPO's to be scanned and then suicided. _______________________________________________ Sig removed as inappropriate- Tirg Story of my life that one :( Views expressed ARE the views of my corp and alliance, not my own.
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.22 20:09:00 - [74] "i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it." When the only information you receive from the server is item ID which is identical for BPO and BPC, how does the client tell them apart from this information alone, again? The one thing a sofware engineer should really 'know better' is to read before they post something which was suggested and explained as meaningless heap times already. "jeeeeez" indeed --;;
Snarls McGee	Posted - 2006.12.22 20:16:00 - [75] OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it). Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications? ---------- We've all heard that a million monkeys typing will eventually create something intelligent. Thanks to message forums we know that isn't true.
Gariuys Evil Strangers Inc.	Posted - 2006.12.22 21:01:00 - [76] Originally by: DukDodgerz i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better. use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it. Yeah and someone thta works with code, should know a helluvalot better then to make guesses at wild solutions without actually knowing the code they're talking about. god the only thing more tiresome then whiners, is whiners thinking they know all cause they know how to write a bat file.... get a grip
Gariuys Evil Strangers Inc.	Posted - 2006.12.22 21:03:00 - [77] Originally by: Snarls McGee OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it). Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications? Yeah, they're absolute retards, if there was a quick dirty way around this problem, for one it would have to be a priority to begin with, which is doubtful, cause it's not something critical in any way. And secondly, the dirty way around would have to exist, and be a reasonable effort considering it's priority. Conclusion, it's on their minds, and when priority, effort, and opportunity combine... we get captain planet...
Kargon	Posted - 2006.12.22 22:43:00 - [78] Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets? For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character). Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data.
Gariuys Evil Strangers Inc.	Posted - 2006.12.22 22:56:00 - [79] Originally by: Kargon Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets? For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character). Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data. Sounds simple, but isn't, this is IT, if it sounds simple, it probably won't work, will take a helluvalot longer to do then any manager could be made to understand, and it will brake atleast 10 other things that will take weeks to fix. In your example, just the problems from the top of my head. 1. It assumes the database entry you want to use for this can hold another character which is unlikely, without trouble which is even more unlikely, and no calls to the this attribute are made that will have a problem with a additional character which is highly unlikely. 2. The name is probably stored client side, and the only thing that's sent is a ID, so any client side tables that use that ID, or make a reference to it need changing. 3. You have to either make new icons, or have the icons able to switch around background colour. One requires you double all the bp entries. Other could require a rework of how icons are build, cause they're probably just standard images. 3. Doing the db update could take a while, there's a lot of bp's around. So depending on how long it takes it could mean anything from extended DT, to extending the time required to patch, cause it would probably need some client side fixes, putting it in a patch would be logical. And all that for something that's slight convenient... so probably is on the bottom of a list somewhere... ain't gonna happen.
Barthez Thed	Posted - 2006.12.22 23:46:00 - [80] Edited by: Barthez Thed on 22/12/2006 23:46:17 The resources needed are enormous. A colour has to be decided, the paint purchased and extra small paint brushed for the hamsters (custom made and very expensive). Then they gotta hire more hamsters to do the job and the Working Hamsters Union (WHO) has been giving CCP hell recently because of the new patches etc so they are not on good terms. Regards Barthez Thed
Kargon	Posted - 2006.12.23 00:32:00 - [81] Originally by: Gariuys Originally by: Kargon Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets? For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character). Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data. Sounds simple, but isn't, this is IT, if it sounds simple, it probably won't work, will take a helluvalot longer to do then any manager could be made to understand, and it will brake atleast 10 other things that will take weeks to fix. In your example, just the problems from the top of my head. 1. It assumes the database entry you want to use for this can hold another character which is unlikely, without trouble which is even more unlikely, and no calls to the this attribute are made that will have a problem with a additional character which is highly unlikely. 2. The name is probably stored client side, and the only thing that's sent is a ID, so any client side tables that use that ID, or make a reference to it need changing. 3. You have to either make new icons, or have the icons able to switch around background colour. One requires you double all the bp entries. Other could require a rework of how icons are build, cause they're probably just standard images. 3. Doing the db update could take a while, there's a lot of bp's around. So depending on how long it takes it could mean anything from extended DT, to extending the time required to patch, cause it would probably need some client side fixes, putting it in a patch would be logical. And all that for something that's slight convenient... so probably is on the bottom of a list somewhere... ain't gonna happen. 1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID. That does assume there are enough bits free, but I'm hoping they used at least 32-bit IDs, so there should be enough room. 3: Make a new icon... so what? That's art time. It's relatively free. 4: One-time DB update. I doubt it takes very long to go through the items in the DB... EVE has to have a fast DB, otherwise the game would crawl with the thousands of transactions that happen during normal play.
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.23 00:47:00 - [82] "1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID." OK, one more time, until it sinks in i guess. Currently the BPO and BPC for each item share the ID. As such you cannot encode anything in the ID that will be specifically interpreted as something reserved for either BPOs or BPCs. If the BPOs and BPCs were separate items with different IDs then yes, making change to what their icon looks like would be relatively trivial. But if i remember right, the reason they are still treated as the same item is buried somewhere deep in how the whole manufacturing process in EVE is programmed and there isn't really easy nor quick solution for changing that to a new model.
Draegario	Posted - 2006.12.23 01:19:00 - [83] Let me see if I can make a reasonable analogy for what this would take. 1) Open your window explorer and create a new folder. This represents your hanger/container. 2) Create two new text files and give them each an 8-digit number for a name. In one add the text ôOriginalö and in the other add the text ôCopyö. These represent your BPO and BPC. 3) Copy these two files as many times as you want, and each file has an 8-digit number for a name. You will probably want more BPC files than BPO files. Make enough copies so that you have 100 text files in the directory. These represent the blueprints you have in your hanger/container. 4) Close the window explorer and reboot your computer to eliminate the internal cache of the file listings. 5) Open the window explorer and go to the new folder representing your hanger/container. Note about how long it takes to display all of the file names. This is like opening your hanger/container for the first time. 6) Now, select all of the files in this folder. Right click on them and select ôopenö. This will open all of the files. A warning window may open, go ahead and click yes. Note how long it takes to open all of the files. This represents EVE looking up each blueprint to check whether it's a BPO or BPC. You can repeat this using 1,000 files. This represents the maximum number of blueprints that a hanger or container can have. Now picture thousands of players doing this several times (multiple canisters in the same hanger) all at once. Then ask yourself this. Do you really want this kind of lag to be added to playing EVE? While this is not exactly what goes on with the EVE database, I think this represents a close approximation of the delays that would be caused by the added load on the database servers. When you open a hanger or canister, all you are getting is the directory listing of what's there. To get anything more specific requires accessing the database. - Drae - - - - - - - - - - "Everyone's got one. Better to be a smart one than a dumb one." "I didn't say it was your fault. I said I was going to blame you."
Lucio Gallente UK Corp Lotka Volterra	Posted - 2006.12.23 01:47:00 - [84] Originally by: Snarls McGee OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it). Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications? That's actually a quite sensible suggestion, duplicate the BPO information and use the new ID's for BPC only and then write a querry that substitutes all BP's with runs listed for the new item ID. Sure it breaks one of the rules of good database design, never duplicate information, but it seems a good bodge until they can recode the entire way BP's work. ************************************************ Yes, I know I have a negative sec. status but I'm not a pirate damnit!
Kargon	Posted - 2006.12.23 02:14:00 - [85] Edited by: Kargon on 23/12/2006 02:19:28 Originally by: j0sephine "1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID." OK, one more time, until it sinks in i guess. Currently the BPO and BPC for each item share the ID. As such you cannot encode anything in the ID that will be specifically interpreted as something reserved for either BPOs or BPCs. If the BPOs and BPCs were separate items with different IDs then yes, making change to what their icon looks like would be relatively trivial. But if i remember right, the reason they are still treated as the same item is buried somewhere deep in how the whole manufacturing process in EVE is programmed and there isn't really easy nor quick solution for changing that to a new model. It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask... For our case, say we hijack the high bit for this extra info. The current code that checks against ID would be updated to check (ID & 0x7fffffff). Pretty simple. The client-side code that retrieves the icon for the given ID would check the high bit and change the icon as appropriate... Say our convention is to set the high bit to 1 for BPOs. Now, whenever a new BPO is created, just set that high bit. But everything else in the code will think it's exactly like the current BPO/BPC because they've been updated to check only the low order bits which remain unchanged. You would need to make one pass through the item DB to update item IDs as appropriate. It should be easy enough to automate. I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit. Then again, it could be easier than expected; one can hope that EVE used some sort of data abstraction and has a "GetID" function that could be changed and globally fix the issue. If EVE used an object-oriented language (e.g. C++), then maybe "item ID" is a private member variable that has a public accessor which could be updated simply. If you close your mind to the problem, you won't find a solution.
Kargon	Posted - 2006.12.23 02:26:00 - [86] Originally by: Draegario Let me see if I can make a reasonable analogy for what this would take. 1) Open your window explorer and create a new folder. This represents your hanger/container. 2) Create two new text files and give them each an 8-digit number for a name. In one add the text ôOriginalö and in the other add the text ôCopyö. These represent your BPO and BPC. 3) Copy these two files as many times as you want, and each file has an 8-digit number for a name. You will probably want more BPC files than BPO files. Make enough copies so that you have 100 text files in the directory. These represent the blueprints you have in your hanger/container. 4) Close the window explorer and reboot your computer to eliminate the internal cache of the file listings. 5) Open the window explorer and go to the new folder representing your hanger/container. Note about how long it takes to display all of the file names. This is like opening your hanger/container for the first time. 6) Now, select all of the files in this folder. Right click on them and select ôopenö. This will open all of the files. A warning window may open, go ahead and click yes. Note how long it takes to open all of the files. This represents EVE looking up each blueprint to check whether it's a BPO or BPC. You can repeat this using 1,000 files. This represents the maximum number of blueprints that a hanger or container can have. Now picture thousands of players doing this several times (multiple canisters in the same hanger) all at once. Then ask yourself this. Do you really want this kind of lag to be added to playing EVE? While this is not exactly what goes on with the EVE database, I think this represents a close approximation of the delays that would be caused by the added load on the database servers. When you open a hanger or canister, all you are getting is the directory listing of what's there. To get anything more specific requires accessing the database. - Drae Imagine that the "BPO or BPC" data was encoded in the filename. Now you avoid opening the file altogether. Now you can determine the "BPO or BPC" data straight from what you already have -- the filenames that you've always needed.
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.23 02:45:00 - [87] "It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask... (..) I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit." This is interesting idea, though afraid implementation would be more complicated than that. For example if you just mask off the 'original bit' everywhere, then it's possible a simple act of BPO transfer to another person or maybe even to factory/research slot can result in loss of that piece of information unless the system handling it is taught to preserve it or set again. Etc. Overall, i'd guesstimate the amount of coding work involved (given you'd need to consider all of current common game mechanics that touch assets IDs and decide in what way each of them handles this extra information) ... is likely not really much smaller from going the clean 'split BPOs and BPCs' route, if any. But then again, it's something only CCP knows -.o
Grez Minmatar The Raven Warriors	Posted - 2006.12.23 02:50:00 - [88] Originally by: Arienne Thielis Blah, Blah, Blah. Depends on how fast the hard-drive is, remember. You could have 50000 CPU's all processing data, but if the HDD isn't fast enough to load it as fast as the CPU's request it, it won't do anything, and 100 billion entries is a lot (and EVE has way more than that). --- Cache Clearer
Kargon	Posted - 2006.12.23 03:04:00 - [89] Edited by: Kargon on 23/12/2006 03:07:12 Edited by: Kargon on 23/12/2006 03:06:19 Originally by: j0sephine "It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask... (..) I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit." This is interesting idea, though afraid implementation would be more complicated than that. For example if you just mask off the 'original bit' everywhere, then it's possible a simple act of BPO transfer to another person or maybe even to factory/research slot can result in loss of that piece of information unless the system handling it is taught to preserve it or set again. Etc. Overall, i'd guesstimate the amount of coding work involved (given you'd need to consider all of current common game mechanics that touch assets IDs and decide in what way each of them handles this extra information) ... is likely not really much smaller from going the clean 'split BPOs and BPCs' route, if any. But then again, it's something only CCP knows -.o Yes, it's very possible that some code manipulating items could lose the high bit of data encoded in the ID. Code that handles copying items should copy the unmasked ID. The reverse problem -- creating a BPC that accidentally retains the high bit from the BPO ID should be limited. I can't imagine there are that many places in code that deal with making a BPC -- and specifically, transfering the BPO item ID to the BPC. It is probably cleaner to create two distinct item IDs... but then again, you could transform the item ID hack into a code feature that could be used for more "similar but different item" situations in the future.
AyeSwallow	Posted - 2006.12.23 03:06:00 - [90] Beauty Eh? Originally by: DukDodgerz bpo - gold text bpc - silver text with the number of remaining runs showing. /signed ... with extra sprinkles
Kerc Kasha Caldari Tsunami Syndicate Black Flag Alliance	Posted - 2006.12.23 03:18:00 - [91] Originally by: Leilani Solaris Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. You did it to ECM modules, why would it be so hard to do on bpo's/bpc's? Christ people its SO SIMPLE to understand. Look, every item in eve has a database entry, the ECM modules are all seperate database entries. While BPO's and BPCs are the SAME database entry but with separate variables... So to change the colour of BPC's would require a mysql query each time the BPO's and BPC's are shown on screen, which would increase lag SIGNIFICANTLY! considering how many people play eve now.
Ghoest	Posted - 2006.12.23 03:37:00 - [92] Originally by: x racer In RL, theres only one blue blueprint, the original.....all copies of the original are gray, but still called blueprints. Not that RL has much to do with eve, hehe x I dont think you know much about it. In real life they are all black and white and come off a special printer that is connected to the PC with CAD on it. Its been that way for 15 years or so now. Wherever you went - here you are.
Ghoest	Posted - 2006.12.23 03:41:00 - [93] Edited by: Ghoest on 23/12/2006 03:42:36 Originally by: kieron Originally by: Lucio It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons! Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours. CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection. Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time. No offense but some one lied to you. With respect to auctions(where this matters most) it could be done. Wherever you went - here you are.
Tachy	Posted - 2006.12.23 07:53:00 - [94] Originally by: Ghoest Edited by: Ghoest on 23/12/2006 03:42:36 Originally by: kieron Originally by: Lucio[... [...] No offense but some one lied to you. With respect to auctions(where this matters most) it could be done. Kieron is the impersonification of the travelling salesman and customer complaint guy for ccp. He'll tell you what you want he thinks you want to hear and he doesn't really like it when you tell him that you know that. He's a nice guy. Oveur does the same at another level. He's a nice guy too. Back to the topic: For client and server, a BP is a BP. There used to be only BP early in EVE. Copies came in later so pilots and corps could move around without having to fear the loss of the most valuable things in their possession. The devs did not redesign the production and later the science system. They just added some snippets here and there. That's the reason why the client and the server don't know if some BP is a copy or an original. They can't know until you explicitely ask the system to undig that the info. They can't know in advance without a complete redesign for the production and science system takes place. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
elFarto New Order Industries	Posted - 2006.12.23 11:02:00 - [95] Ok, here's another comment from a real developer who knows what they are talking about (no offence kieron ): Originally by: Traveler Seems the discussion is a bit worthless as you do not seem to know how BPs are actually handled. When the client lists a hangar or any container, it basicly only gets the itemID, the typeID and the quantity. From neither the typeID nor the itemID, the client is able to see whether this is a BPO or not. Therefore, the client would have to start a request to the server to get this special information. As you might see, asking the server for all BPs in your hangar is not a wise idea and will result in a "hangar open lag". There is currently no easy solution for this special problem. Discussing about it or adding "signed" replies will not do a change. By the way, arguing with Traveler on this subject is extremely stupid (i.e. don't do it) as he is a UI developer, he knows this sort of stuff. In terms of hacks to the current system, the one that seems to work the best, and causes the least possible load on the servers/database is for the client to load the container/hanger as normal, then build a request of all the blueprint's ID in that container (if it contains any). It then asks the server how many runs each of those have (this could be done in one database query). The server then send this to the client, and (the most important bit), the client caches it for future use. This should work perfectly if the itemID for an item never changes. Also, it only puts extra load on the server if the container contains a blueprint and it hasn't requested it before. I think this whole conversation can be summed up as, It's easy to change the colour of an icon, it's difficult/causes lots of lag to know when to change it. Regards elFarto NPC database Mal: This is your captain speaking. We're having some technical difficulties, so we may experience some turbulence, and then explode.
Delana Cantell	Posted - 2006.12.30 11:48:00 - [96] Originally by: elFarto Ok, here's another comment from a real developer who knows what they are talking about (no offence kieron ): Originally by: Traveler Seems the discussion is a bit worthless as you do not seem to know how BPs are actually handled. When the client lists a hangar or any container, it basicly only gets the itemID, the typeID and the quantity. From neither the typeID nor the itemID, the client is able to see whether this is a BPO or not. Therefore, the client would have to start a request to the server to get this special information. As you might see, asking the server for all BPs in your hangar is not a wise idea and will result in a "hangar open lag". There is currently no easy solution for this special problem. Discussing about it or adding "signed" replies will not do a change. By the way, arguing with Traveler on this subject is extremely stupid (i.e. don't do it) as he is a UI developer, he knows this sort of stuff. OK, I'm going to be stupid and argue this point. Buy a new BPO (e.g. a nice cheap shuttle BPO). Look at it in your hangar. Notice the little '1' in the corner? Start a manufacture job from the BPO, but cancel out at the quote stage. Look at it again in your hangar. Notice the little '1' has gone? If the only info passed to the UI right now is the itemID, typeID and quantity, how does the UI tell a 'used' BPO from an 'unused' BPO? It can't, it must already be receiving information about the attributes of the BP.
Kuolematon Space Perverts and Forum Warriors United Privateer Alliance	Posted - 2006.12.30 11:53:00 - [97] There is already row in blueprint table that says if its original or not. Adding an simple PYTHON CLIENT SIDE code that colours ORIGINALS with golden bracelet cannot be that hard. "It's great being Amarr, ain't it?Ö" "A world without pain"
Tachy	Posted - 2006.12.30 11:55:00 - [98] Originally by: traveller [...] only gets the itemID, the typeID and the quantity. [...] --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
Koti Resci	Posted - 2006.12.30 17:41:00 - [99] Originally by: Tachy Originally by: traveller [...] only gets the itemID, the typeID and the quantity.[...] It would not be hard to modify the "quantity" field similar to how someone wanted to modify the ID field, except that now we don't have the whole trouble of having to support 2 IDs for the same blueprint. The only trouble we'd have is if someone has the upper limit of the quantity field, but then again, if we can stack up more than 4.3 billion tritanium, I doubt anyone would have more than 4.3 billion instances of a blueprint (whether a copy or an origional).
Tachy	Posted - 2006.12.30 17:52:00 - [100] Originally by: Koti Resci Originally by: Tachy Originally by: traveller [...] only gets the itemID, the typeID and the quantity.[...] It would not be hard to modify the "quantity" field similar to how someone wanted to modify the ID field, except that now we don't have the whole trouble of having to support 2 IDs for the same blueprint. The only trouble we'd have is if someone has the upper limit of the quantity field, but then again, if we can stack up more than 4.3 billion tritanium, I doubt anyone would have more than 4.3 billion instances of a blueprint (whether a copy or an origional). Those two IDs and the quantity are used for each and every stack in your hangar. BP do not get an extra treatment. Huge amounts of minerals aren't as rare as you seem to think, and my stack of original trit changing magically into a copy of trit is beyond my understanding. Each time I have seen an implementation based on 'probably nobody ever' resulted in things like DB breakdown, hard to track client crashes and data loss. --==*-- The cause for this is not yet known, but we do have a possible fix in testing. by Sharkbait \| 2006.09.20
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.30 17:57:00 - [101] "Buy a new BPO (e.g. a nice cheap shuttle BPO). Look at it in your hangar. Notice the little '1' in the corner? Start a manufacture job from the BPO, but cancel out at the quote stage. Look at it again in your hangar. Notice the little '1' has gone? If the only info passed to the UI right now is the itemID, typeID and quantity, how does the UI tell a 'used' BPO from an 'unused' BPO? It can't, it must already be receiving information about the attributes of the BP." It's the attribute of packaged (stackable) item, not BPO-specific data. Note you get the same thing with ship modules... brand new modules show as what's essentially "module X, 1 (or more) such item(s) bundled together". When you put the module in the ship it's converted from "stack" into 'real' single item and treated as actual module with the amount number gone. The number re-appears when you repackage the module, turning it again into the "stackable item pack".
Koti Resci	Posted - 2006.12.30 20:29:00 - [102] Originally by: Tachy Originally by: Koti Resci Originally by: Tachy Originally by: traveller [...] only gets the itemID, the typeID and the quantity.[...] It would not be hard to modify the "quantity" field similar to how someone wanted to modify the ID field, except that now we don't have the whole trouble of having to support 2 IDs for the same blueprint. The only trouble we'd have is if someone has the upper limit of the quantity field, but then again, if we can stack up more than 4.3 billion tritanium, I doubt anyone would have more than 4.3 billion instances of a blueprint (whether a copy or an origional). Those two IDs and the quantity are used for each and every stack in your hangar. BP do not get an extra treatment. Huge amounts of minerals aren't as rare as you seem to think, and my stack of original trit changing magically into a copy of trit is beyond my understanding. Each time I have seen an implementation based on 'probably nobody ever' resulted in things like DB breakdown, hard to track client crashes and data loss. Find me someone that has a stack of more than 2^32 billion blueprints and I'll eat my words. The biggest problem I can forsee is an integer rollover which would make the client think it has a negative amount of BPOs instead of a positive, which I think would be something easy to spot by a GM. In any case, it IS only a hack-ish idea designed as a temporary solution until CCP eventually gets around to solving the solution in whatever REAL way they desire. Which, knowing CCP, could in fact be that they desire NO real fix.
Delana Cantell	Posted - 2006.12.30 23:30:00 - [103] Originally by: j0sephine "Buy a new BPO (e.g. a nice cheap shuttle BPO). Look at it in your hangar. Notice the little '1' in the corner? Start a manufacture job from the BPO, but cancel out at the quote stage. Look at it again in your hangar. Notice the little '1' has gone? If the only info passed to the UI right now is the itemID, typeID and quantity, how does the UI tell a 'used' BPO from an 'unused' BPO? It can't, it must already be receiving information about the attributes of the BP." It's the attribute of packaged (stackable) item, not BPO-specific data. Note you get the same thing with ship modules... brand new modules show as what's essentially "module X, 1 (or more) such item(s) bundled together". When you put the module in the ship it's converted from "stack" into 'real' single item and treated as actual module with the amount number gone. The number re-appears when you repackage the module, turning it again into the "stackable item pack". But the point is, that is information being returned from the database relating to that particular item/stack in order to generate the hangar view. This is at odds with what the dev (Traveler) was quoted as sayying. If the DB query can return specific information (used/unused) why not BPO/BPC?
Lucio Gallente UK Corp Lotka Volterra	Posted - 2006.12.30 23:40:00 - [104] Originally by: Traveler Seems the discussion is a bit worthless as you do not seem to know how BPs are actually handled. When the client lists a hangar or any container, it basicly only gets the itemID, the typeID and the quantity. From neither the typeID nor the itemID, the client is able to see whether this is a BPO or not. Therefore, the client would have to start a request to the server to get this special information. As you might see, asking the server for all BPs in your hangar is not a wise idea and will result in a "hangar open lag". Well that really does confirm it then, they'd need to make a few hundred new entires in the item database to be able to make the change, plus replace a few billion entries in the player/corp databases to pull the change of. Ya know, the feature is that annoying that I personally think it's worth doing that, even with the day of downtime that'd go with it. Of course, they could also just redesign the entire manufacturing/research system. I for one would love to see BPO's as they currently stand removed from the game and replaced with licenses to purchase BPC from the companies that actually are supposed to own the design rights, make BPC like any other manufacturing component and move all the science research to a system of "datacores" that you research and improve, then ship around as needs be. ************************************************ Yes, I know I have a negative sec. status but I'm not a pirate damnit!
j0sephine Caldari Reikoku Band of Brothers	Posted - 2006.12.31 00:00:00 - [105] Edited by: j0sephine on 31/12/2006 00:03:47 "But the point is, that is information being returned from the database relating to that particular item/stack in order to generate the hangar view. This is at odds with what the dev (Traveler) was quoted as sayying. If the DB query can return specific information (used/unused) why not BPO/BPC?" Chances are it doesn't return specific information about items but rather "a stack of items type X" is separate type itself. E.g., let's say the server sends only ever the type id, item id and amount. You open your hangar and receive from server: "damage control bp stack" (type id), "item-uuid-1" (item id), "10" (amount) ... the client draws it on your screen as "stack of 10 damage control blueprints". Now, you take single blueprint from this stack, put it in production and then it gets returned. Now when you open the hangar, the server will send you: "damage control bp stack", "item-uuid-1", "9" "damage control bp", "item-uuid-2", "1" (amount of 1 possibly gets skipped as default value) ... the client draws it on your screen as "stack of 9 damage control blueprints, and single unpacked damage control blueprint". Note, at no point it checks into attributes of specific item, it simply reports the item type, item id and the amount... without ever having to look up data linked with any specific item-uuid. Now this is all mostly guesswork of course. And note, if the blueprints had separate id for originals and copies then they could be handled in pretty much the same manner... but as long as they don't and there's supposedly limitations of production system getting in the way, we're kinda stuck :/ edit: note, this approach requires all items in the stack to have identical attributes because they don't actually exist as stacked entities... which is likely why it wasn't actually possible to stack items with different attributes like damaged modules, partially used laser lenses, assembled ships etc.

Pages: 1 2 3 4 :: [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.