EVE Search - Poll- BPO's should stay blue and BPC's should be Green

All Channels

Test Server Feedback

Poll- BPO's should stay blue and BPC's should be Green

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

Monitor this thread via RSS [?]

Pages: [1] :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Dsltnangel	Posted - 2005.11.22 14:29:00 - [1] Edited by: Dsltnangel on 22/11/2005 14:29:46 I think that it is so confusing to have almost a thousand BPO's and BPC's mixed together and not know which is which. I suggest that the BPO's stay the traditional blue and the BPC's Start off Green and progressivly turn red as the runs are depleted. How's that for an idea. Or if that isnt possible. Then a different color is in order. Whatcha think!!!??!! A:) Yes, I agree B:) STFU Dont change the game!!!
Dsltnangel	Posted - 2005.11.22 14:34:00 - [2] didnt notice there was an ideas channel. can we move this there?
Elissen	Posted - 2005.11.22 15:02:00 - [3] It has been stated a couple of times by the devs that making a difference of bpo's and bpc's in your hangar would cause quite a lot of load on the servers. My bet is that bpo's and bpc's have the same TypeID's in the database and are just seperated from each other by other properties of the item. If you look at t20's data export you'll notice there is no "Maller Blueprint Copy" in it; just the "Maller" and "Maller Blueprint". Still, this is quite high on the wish-list of many people ----- ICSC Member New: Jumpplanner tool - Plan your dreadnought travelroute!
Scetrov	Posted - 2005.11.22 15:10:00 - [4] Yes, Elissen, that is exactly why implementing a different icon for BPCs and BPOs causes more load. A BPC has the number of runs remaining set to a number (i.e. 1500), where as a BPO has the number of runs remaining set to "Infinite". Thus to differentiate between a BPO and a BPC would require first to query what is in the hanger, and second to query if "number of runs remaining" is equal to "Infinite". Why, they are not implemented as seperate Items I don't fully know, I imagine it was a design decision taken way back when to avoid data duplication.
Cyperinn	Posted - 2005.11.22 16:38:00 - [5] It does indeed add more load to the server, sending the bp type along with the inital data should not cause too much more load. Doing two differnt queries would be wasteful imo. I'd move to say that as we need to manually check what are bpo and bpc en mass some times thats going to cause alot more load..
Kurren	Posted - 2005.11.22 16:42:00 - [6] I refuse to believe that, with all the thousands of items in Eve, that changing the colors of BPCs would cause screwballs with the servers. This doesn't mean that it doesn't, or wouldn't, cause screwballs, but I would like to think that this game runs on servers strong enough to handle one thing blue and one thing green. Granted, it wouldn't be just one... but for most people it would be... 10 or less. Corporate hangars would be the exception to that. But, even with the thousands of BPOs and BPCs that some corps have... it' only a difference in color. I'm for the idea! ************************************************ My sig is too big...
Oz Draconis	Posted - 2005.11.22 22:26:00 - [7] Originally by: Scetrov Yes, Elissen, that is exactly why implementing a different icon for BPCs and BPOs causes more load. A BPC has the number of runs remaining set to a number (i.e. 1500), where as a BPO has the number of runs remaining set to "Infinite". Thus to differentiate between a BPO and a BPC would require first to query what is in the hanger, and second to query if "number of runs remaining" is equal to "Infinite". Why, they are not implemented as seperate Items I don't fully know, I imagine it was a design decision taken way back when to avoid data duplication. Of course all your sorting could be done with bubble sorts, but only a retard would do that! Yes, you could use the double access method mentioned above, but only.... The run count could be embedded in the icon id. This would require either a sub field or a range of IDs for each BPC type. To bring the size of each range into reason (i.e. max run ammo BPCc) the max run count should be decreased while increasing the lot size. When a job is finished and the BPC is ejected from the factory, the icon ID would have to be adjusted. Since they are doing an overhaul of manufacturing anyway, now would be the perfect time to slip that code in to be tested along with the rest of the manufacturing code. --- Natural Selection Works.
elFarto	Posted - 2005.11.23 10:24:00 - [8] Oh god not again. Read This Regards elFarto Stratego > 2005.10.22 14:15:17 combat Imperium Alliance petitions you, glancing off causing no real damage.
Nexus1972	Posted - 2005.11.23 12:52:00 - [9] As someone has pointed out, if i cannot tell what bpo/bpc is what, then i will right click and do properties of every bpo/bpc. Now imagine around the world say 500 ppl doing this simultaneously, and the load that retrieving all the info for each bpc generates. Now imagine an SQL query that retrives item id, name, and runs vs a query that returns item id,name,type,calculating research time based on current skills, calculating min requirements based on skills (plus the others). If they were blue/green then ultimatley it would be more efficient, its just down to them not _WANTING_ to do it, not being _UNABLE_ to do it.
Trak Cranker	Posted - 2005.11.23 13:00:00 - [10] Pretty sure they would like to do this. If they figured the win/loss ratio to be the right size. Someone has to use the time to eeffectuate this difference down through the code - with all the errors in blueprint production that might bring with it. Right now a BPO and a BPC is the same thing when the system loads your hangar/container content. It CANNOT tell the difference - so it CANNOT _just_ paint it blue and green respectively. Bad design choice? I would say so. Something they would not like to change, even given the issues we all know we have? I think not. Please resize your signature so that it is within the forum rule size limits - Jacques
John Blackthorn	Posted - 2005.11.23 14:29:00 - [11] Well, it might be a feature that would cause server load but it's a feature that needs to be added. Back when the labs were rare and my corp wanted to keep the labs busy so they just didn't unrent themselfs we just stuck anything in and started making copies. We have more than 10,000 copies in our corp hangers.. probibly more. I refuse to sit there for a week and click info to see which ones are the orginal bpo's and which are the bpc's. If I could pick the bpos out I'd just delete the rest. -BT
Sirilonwe	Posted - 2005.11.23 14:42:00 - [12] Originally by: Elissen It has been stated a couple of times by the devs that making a difference of bpo's and bpc's in your hangar would cause quite a lot of load on the servers. Warning, geek post ;). I guess the load would be caused by each BP loading it's properties each time you open your hangar. Currently, you have to do the check manually: SQL: SELECT properties FROM item WHERE item.id = 'this_id' One result. A fast player can do this request on time every 2 or 3 seconds. Imagine now the player has 1000 BPC's in his hangar. The request would be like: SQL: SELECT properties FROM item WHERE item.owner_id = 'this_player' AND item.hangar_id = 'this_hangar' This request would send every properties for each BP in the hangar, eating up much more bandwidth. _______________________ Forums DSU
Elissen	Posted - 2005.11.23 15:18:00 - [13] Originally by: Sirilonwe ... Imagine now the player has 1000 BPC's in his hangar. The request would be like: SQL: SELECT properties FROM item WHERE item.owner_id = 'this_player' AND item.hangar_id = 'this_hangar' This request would send every properties for each BP in the hangar, eating up much more bandwidth. I know how a 'bit' about programming and SQL (points at signature ) If you do something like that your gonna make damn sure that you only pull in the information that you actually need. My first approach (without knowing their datastructure) would be SELECT typeID, quantity, propertyValue AS isCopy FROM items LEFT JOIN itemproperties ON (items.itemID = itemproperties.itemID AND itemproperties.properyName = 'isCopy' AND itemproperties.propertyValue = true) WHERE locationID = :location Note that I don't know if this query works in MSSQL, has been a while since I worked with MSSQL. Main point here is that you don't query more information that you actually need. However, the biggest problem of this will be the number of items in the entire database. Almost a year ago they passed itemID 2.000.000.000. On the other hand, perhaps it will be possible now with the RamSan. What might be interesting to read is this PDF: "One table alone gets 8 million records added per day plus a huge amount of selects and updates." Last second addition: I just started to wonder how they do it with names of bookmarks and containers??? ----- ICSC Member New: Jumpplanner tool - Plan your dreadnought travelroute!
Rafaello Cruel	Posted - 2005.11.23 15:23:00 - [14] A:) Yes, I agree ------------------------------------- best regards Rafaello Cruel
John Blackthorn	Posted - 2005.11.23 15:42:00 - [15] But just think if this option was avalable how many bps' would simply get the right click delete? Because I'm fairly certain many corps did the same thing as we did in order to keep the labs from unrenting. So that we could have a lab when we actually needed to use one. -BT
Sinari Galdrin	Posted - 2005.11.23 15:47:00 - [16] ISTM that it wouldn't be very hard to do with a bit of thinking outside the box. The problem is that we mere mortals don't know the data structures.. I'd guess that when the client gets the item list, it will make the server do a query like: SELECT items.itemid, items.qty, itemdefinitions.icon, itemdefinitions.name, itemdefinitions.group FROM items INNER JOIN itemdefinitions ON items.typeid=itemdefinitions.typeid WHERE location='here' AND user='fred' There's two ways I could see to change this: The 'least programming changes' way would be to do something like: SELECT items.itemid, items.qty, CASE ISNULL(itemproperties.value, 'infinite') WHEN 'infinite' THEN itemdefinitions.icon ELSE itemdefinitions.icon + 10000 ENDCASE AS icon, itemdefinitions.name, itemdefinitions.group FROM items INNER JOIN itemdefinitions ON items.typeid=itemdefinitions.typeid LEFT OUTER JOIN itemproperties ON items.itemid=itemproperties.itemid WHERE location='here' AND user='fred' AND itemproperties.name='runsleft' But, this requires another join on another table, which would probably be too DB intensive, and wouldn't be the way I'd want to do it on a well populated game like Eve. The other way would be to add an 'icon' column to the 'items' table, and use SELECT items.itemid, items.qty, COALESCE(items.item, itemdefinitions.icon) as icon, itemdefinitions.name, itemdefinitions.group FROM items INNER JOIN itemdefinitions ON items.typeid=itemdefinitions.typeid WHERE location='here' AND user='fred' That way if the 'icon' column in the items table in NULL, then it works as before, but it allows the 'items' table entries to have different icons from the norm. Then, the bit of code making a BPC could set the items column, but no other code would need changing as long as the items.icon column had a default value of NULL. This way doesn't require another join, and just gets one more column from a table it's already accessing, and performs a simple expression. I wouldn't expect this method to have a big impact on performance. (Doing it this way is pretty flexible, as it allows any item to have any icon, if desired, so it wouldn't just apply to BPCs, it could mean that, for instance, partly worn out items could be made to have different icons from 'new' ones, by the bit of code which 'wears' out the items changing the item icon at a desired threshold)
Elissen	Posted - 2005.11.23 16:47:00 - [17] The client already has information about types and the associated icons. No need to have the server figure that out and send it to the client. AFAIK the server only send typeID's and the client looks up the name of the item and the associated icon in it's local data. Thus you only need to send down a marker that something is a copy and then the client can on its own use another icon. ----- ICSC Member New: Jumpplanner tool - Plan your dreadnought travelroute!
Macro Media	Posted - 2005.11.23 17:20:00 - [18] The Brain Dead way is this Server sends hangerlist to client. Client checks the BP If a BP has infinate runs, Colour it green.Or use a Green Icon etc. Server does nothing different, get NO extra load etc etc. Let the client do the work. ------------ Criminal EVE Guides Evil Genius 101 Guide
Karnov Darkstar	Posted - 2005.11.23 17:59:00 - [19] Eh, then the server has to still check every bp so it knows what to send to the client. __________________________ Ketchup! Everywhere! Suckers!
Sinari Galdrin	Posted - 2005.11.23 22:56:00 - [20] Originally by: Elissen Thus you only need to send down a marker that something is a copy and then the client can on its own use another icon. The problem is that, at the moment, the 'what items I own' database table doesn't say whether they are copies or not, they are just the 'type id' for BPOs. So, either it needs a table definition change (eg an 'I'm a copy' column) or an extra DB query. I guess they're reluctant to change the table definition, and a DB query is too slow. I'd agree that an extra DB query is probably too slow, but I don't see why changing the table definition would be that hard. You could either have an 'I'm a copy' definition or a 'client display type id' and have the server send a different type id to the client when the client gets the type id for display purposes, whilst the server can use the original type id for behaviour/property. However, this is potentially a much bigger change than if the server sent the icon number to the client for each item, so I can see why it would not be desirable. The other problem is stacking - a mix of BPOs and BPCs might cause a problem as you could currently stack them together (I presume), but you wouldn't want to stack them if they have different icons.
Hohenheim OfLight	Posted - 2005.11.24 09:14:00 - [21] Why carnt we just have something cliant side which says O this is a bpc, I will make th icon green after all there must be querare in the first place to see wha teh item is to draw to the icon why not just make it part of that?
Elissen	Posted - 2005.11.24 10:59:00 - [22] Originally by: Sinari Galdrin Originally by: Elissen Thus you only need to send down a marker that something is a copy and then the client can on its own use another icon. The problem is that, at the moment, the 'what items I own' database table doesn't say whether they are copies or not, they are just the 'type id' for BPOs. Thats what I am saying (read my previous posts in this topic) Originally by: Sinari Galdrin I'd agree that an extra DB query is probably too slow, but I don't see why changing the table definition would be that hard. You could either have an 'I'm a copy' definition or a 'client display type id' and have the server send a different type id to the client when the client gets the type id for display purposes, whilst the server can use the original type id for behaviour/property. Every solution to this problem has drawbacks. If you add just one column to that table, the table grows a lot. There are (possibly) more then 2 bilion rows in it. Is that worth it? And giving bpo and bpc different typeID's has the drawback that your gonna end up with duplicate data (the building requirments for example) so it will require extra time and effort to keep those in sync. Also not something I would choose for. Originally by: Hohenheim OfLight Why carnt we just have something cliant side which says O this is a bpc, I will make th icon green after all there must be querare in the first place to see wha teh item is to draw to the icon why not just make it part of that? Read the topic. We're making educated guesses as why it is so hard to do so. Basicly you need the server to determine if something is an original or copy and tell the client about it. Then the client could choose between different icons. ----- ICSC Member New: Jumpplanner tool - Plan your dreadnought travelroute!
Angelic Resolution	Posted - 2005.11.24 12:08:00 - [23] 1.
Matthew	Posted - 2005.11.24 13:05:00 - [24] Originally by: Elissen Last second addition: I just started to wonder how they do it with names of bookmarks and containers??? An interesting experiment is to create a container full of BM's, then try opening it. You should find this takes much longer than opening a container with a similar number of "normal" items. This is entirely down to the need to retrieve the names of all the BMs. Performance would be similarly hit if they got BP's to look up their "is copy" field every time. Given that they are trying to reduce the load associated with BM's, I can't see them introducing a similar load issue into BPs. Originally by: Hohenheim OfLight Why carnt we just have something cliant side which says O this is a bpc, I will make th icon green after all there must be querare in the first place to see wha teh item is to draw to the icon why not just make it part of that? That's the whole problem - the client doesn't automatically know whether it is a copy or original, it only knows that it is a blueprint. Asking the server about every BP, or having the server work it out automatically, is what generates the extra load. Originally by: Elissen Read the topic. We're making educated guesses as why it is so hard to do so. Basicly you need the server to determine if something is an original or copy and tell the client about it. Then the client could choose between different icons. Which is what it all boils down to. Only the Devs know for sure exactly what the software is doing right now, so only they know whether the change is easy or not. They have said it isn't easy, so it isn't easy. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Juno II	Posted - 2005.11.24 13:15:00 - [25] what?! Server load?! just make the client ask something like, If the BPO has Infinite runs, use blueicon, if else green. Make the rule apply to type of objekt and voila. diffrent colors without any server load. Im not a programmer or know how to code but i know the basics. I hope you get what i meant. And i do know that if it was so easy why didn't CCP do it allready?!, well yeah thats the question i want to know now. Why CCP haven't you done this? is there something im missing? /Juno Ginnungagaps Rymdfarargille
TuRtLe HeAd	Posted - 2005.11.24 13:34:00 - [26] Is this acutally an idea or is it an idea intesting already, because this thread is one of the most common threads to get resurrected. Yes we need a way to distinguish between the two. Regarless of the difficulties, We come up with solutions let the game designers put them in the game.
Lygos	Posted - 2005.11.24 20:38:00 - [27] I guess we need more personal hangars so we can keep important objects in one and print out into another. I've never managed to score a mislisted bpo off of escrow yet. Targetting Sig Variance -- "Everything I love is combustible."
Tadamitsu	Posted - 2005.11.28 08:16:00 - [28] +10000000000 yes please, make it soooo.. This drives me crazy keeping my copys straight. I do not have a good way to do it but this would be a great add. Talk is cheap, whisky costs money. you got any cash?

Pages: [1] :: one page
First page \| Previous page \| Next page \| Last page

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