EVE Search - let us distinguish between BPC and BPO finally!!!

All Channels

Science and Industry

let us distinguish between BPC and BPO finally!!!

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

Monitor this thread via RSS [?]

Pages: 1 2 3 4 5 6 :: [one page]
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Robert Caldera	Posted - 2010.03.17 17:12:00 - [1] I'm getting mad every time I have to sort the fuggin BPO out of a bunch of BPC in hangars and POS divisions!!!! I dont care about technical backgrounds and explanations why things are broken currently, if you did it wrong, then simply fix it!
Jokiller Gerius Gallente	Posted - 2010.03.17 17:53:00 - [2] Edited by: Jokiller Gerius on 17/03/2010 17:54:02 not broken see below for why it can't be done as posted by ccp lingorm The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. A good workaround is to actually use the S&I interface and then use the Blueprints and Corp blueprints tabs on there, they have a different query that does include this information as the query is filtered to blueprints only. It will also show the ME and PE values in the columns on these views.
Evilbeero	Posted - 2010.03.17 18:16:00 - [3] Edited by: Evilbeero on 17/03/2010 18:23:16 I use 2 containers, and throw in a bookmark called BPO in one, and BPC in the 2nd, always clear for me which blueprints i am looking at. I know it doesnt solve the problem, which won't be solved most likely as the poster above me states, but its a great work around.
Joe SMASH You Got A Purty Mouth	Posted - 2010.03.17 18:23:00 - [4] Originally by: Evilbeero I use 2 containers, and throw in a bookmark called BPO in one, and BPC in the 2nd, always clear for me which blueprints i am looking at. Exactly what I do. And the corp hanger has separate tabs for BPOs and BPCs. As long as you put the right print in the right place, there is no problems. When the server is less laggy and there is more overhead in the db, then we can talk about making them look different. ----------------------------------- Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
Robert Caldera	Posted - 2010.03.17 18:43:00 - [5] Edited by: Robert Caldera on 17/03/2010 18:44:51 Originally by: Jokiller Gerius The database is heavily 'normalised' (a method of removing duplicate data) this means that the marker for BPO/BPC is not actually in the Inventory table, it is a table that stores specific differential data. This means that to add this field to the inventory return we would need to do an addition join to the differential data table to look up this field for EVERY item in the inventory regardless of whether or not this is a blueprint of not. stop quoting bullsht. btw Originally by:* Robert Caldera I dont care about technical backgrounds and explanations why things are broken currently, if you did it wrong, then simply fix it! Originally by: Jokiller Gerius Trust me if we could do it I would love it ... but from a DB point of view the extra load is not wanted for the amount of gain. bull**! Stop quoting bull*! A simple flag cant be that hard to realize, the information is behind the BPC anyways if you look into item info. STOP QUOTING BULLSHT A CLUELESS DEV SAID ONCE OVER AND OVER AGAIN!! Originally by: Jokiller Gerius A good workaround ... I dont want pesky workarounds, I want a FIX!
Joe SMASH You Got A Purty Mouth	Posted - 2010.03.17 18:46:00 - [6] Originally by: Robert Caldera bull**! Stop quoting bull*! A simple flag cant be that hard to realize, the information is behind the BPC anyways if you look into item info. STOP QUOTING BULLSHT A CLUELESS DEV SAID ONCE!! Originally by: Jokiller Gerius A good workaround ... I dont want pesky workarounds, I want a FIX! Oooo... You must be one of those, 'If you do not agree with me, you are wrong' type of people.... ----------------------------------- Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
Robert Caldera	Posted - 2010.03.17 18:48:00 - [7] Edited by: Robert Caldera on 17/03/2010 18:48:39 Originally by: Joe SMASH Oooo... You must be one of those, 'If you do not agree with me, you are wrong' type of people.... no I just dont want fukking workarounds pain in the ass anymore and please stop repeating bull**** like a parrot, it doesnt get more true from that.
SurrenderMonkey	Posted - 2010.03.17 18:50:00 - [8] Originally by: Robert Caldera I dont care about technical backgrounds and explanations why things are broken currently, if you did it wrong, then simply fix it! They didn't do it wrong, so there's nothing to fix. It's designed that way on purpose. Read up on the subject of database normalization. They COULD differentiate between the two. What they are saying is that it's not worth the performance hit of adding an additional join (which is a logical connection between two tables in a database) to the query that is called when you view an inventory. This would likely affect EVERY instance in which that query is called, too - not just the ones involving blueprints. The answer to your question is not, "We can't," but rather, "We can, we're just not going to." --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Joe SMASH You Got A Purty Mouth	Posted - 2010.03.17 18:53:00 - [9] Well, since you cannot be bothered to look it up apparently, here is the previously quoted thread: LINK. It has been discussed, at great length. It will not be changed anytime soon. Can I have your stuff? ----------------------------------- Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
Robert Caldera	Posted - 2010.03.17 18:55:00 - [10] Originally by: SurrenderMonkey They didn't do it wrong, so there's nothing to fix. It's designed that way on purpose. Read up on the subject of database normalization. stfu I graduated in computer science and databases are my daily business, so please stfu teaching me stuff I'm messing aroung for years! Originally by: SurrenderMonkey They COULD differentiate between the two. What they are saying is that it's not worth the performance hit of adding an additional join (which is a logical connection between two tables in a database) not worth? NOT WORTH?? WE LIKE FUKKING OUR CUSTOMERS MUCH MUCH MORE, is it what you're going to tell me?? How many threads were there in the past regarding this painly issue??? Every producer/inventer is arguing about this WRONG IMPROPER implementation! If you cant joing a simple fukkin BOOLEAN FLAG into your join, either fire your database designer or JUST DENORMALIZE THE FUKKIN BOOLEAN into the parent table!!
SurrenderMonkey	Posted - 2010.03.17 18:59:00 - [11] Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 18:57:04 Originally by: SurrenderMonkey They didn't do it wrong, so there's nothing to fix. It's designed that way on purpose. Read up on the subject of database normalization. stfu I graduated in computer science and databases are my daily business, so please stfu teaching me stuff I'm messing aroung for years! Originally by: SurrenderMonkey They COULD differentiate between the two. What they are saying is that it's not worth the performance hit of adding an additional join (which is a logical connection between two tables in a database) not worth? NOT WORTH?? WE LIKE FUKKING OUR CUSTOMERS MUCH MUCH MORE, is it what you're going to tell me?? How many threads were there in the past regarding this painly issue??? Every producer/inventer is arguing about this WRONG IMPROPER implementation! If you cant joing a simple fukkin BOOLEAN FLAG into your join, either fire your database designer or JUST DENORMALIZE THE FUKKIN BOOLEAN into the parent table, whatever, rendering the life of the half eve population much easier!! Yes. Not worth. Glad I could clear this up for you. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.17 19:06:00 - [12] Originally by: Robert Caldera Technical excuses for MAJOR GAMEPLAY flaws are always a really really dumb idea! Gameplay defines the backend usually! IT'S NOT REALLY A MAJOR GAME PLAY FLAW, BUT I ADMIRE YOUR ABILITY TO COMPLAIN ABOUT THE LITTLE ****. Typed in caps so you could hear me.
Robert Caldera	Posted - 2010.03.17 19:11:00 - [13] Originally by: Tellenta Originally by: Robert Caldera Technical excuses for MAJOR GAMEPLAY flaws are always a really really dumb idea! Gameplay defines the backend usually! IT'S NOT REALLY A MAJOR GAME PLAY FLAW, BUT I ADMIRE YOUR ABILITY TO COMPLAIN ABOUT THE LITTLE ****. Typed in caps so you could hear me. it IS! FIX IT
Sir Waka	Posted - 2010.03.17 19:12:00 - [14] grrrr bull******* ****** BPO/BPC distinction **** grrr ra ra ** not worth*** NOT WORTH!!!! *** bull&**** Sorry, I wasn't sure how else to respond to a post when all I see is this. Seriously, grow up. If you want it fixed that bad, apply for a job at CCP. They have said it will not happen. I THINK that means they aren't going to make the change. Do the work around, stop being ignorant, you are NOT the only person that is ever right, and please, stop crying.
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.17 19:24:00 - [15] Originally by: Robert Caldera Originally by: Tellenta Originally by: Robert Caldera Technical excuses for MAJOR GAMEPLAY flaws are always a really really dumb idea! Gameplay defines the backend usually! IT'S NOT REALLY A MAJOR GAME PLAY FLAW, BUT I ADMIRE YOUR ABILITY TO COMPLAIN ABOUT THE LITTLE ****. Typed in caps so you could hear me. it IS! FIX IT I JUST REALIZED I CAN ADD A TIDBIT OF HELPFUL INFORMATION!!!!!! WHEN YOU SORT BY TYPE WHEN YOU MESS UP AND PUT YOUR BPO IN WITH THE BPC'S THE BPO WILL BE EITHER THE FIRST OR LAST ONE DEPENDING ON WHAT BPO IT IS, NO I DON'T KNOW WHY ONE BPO ENDS UP FIRST ON THE LIST AND ANOTHER ENDS UP BEING LAST!!!!!!! I KNOW YOU WERE NOT INTERESTED IN WORKAROUNDS, BUT I DON'T HAVE THE SAME INTERESTS AS YOU!!!! typed in caps to show I was serious.
Sir Waka	Posted - 2010.03.17 19:26:00 - [16] Originally by: Tellenta typed in caps to show I was serious. THIS ISN'T IN CAPS. YOU MAY WANT TO EDIT SO THAT WE KNOW YOU ARE BEING SERIOUS ABOUT BEING SERIOUS!
Chainsaw Plankton IDLE GUNS IDLE EMPIRE	Posted - 2010.03.17 19:43:00 - [17] I only deal in bpos, yay!
Robert Caldera	Posted - 2010.03.17 19:46:00 - [18] Originally by: Tellenta I KNOW YOU WERE NOT INTERESTED IN WORKAROUNDS, BUT I DON'T HAVE THE SAME INTERESTS AS YOU!!!! then stop trolling if you're not interested in a fix and stfu.
Robert Caldera	Posted - 2010.03.17 19:51:00 - [19] Edited by: Robert Caldera on 17/03/2010 19:52:42 Originally by: Tellenta IT'S NOT REALLY A MAJOR GAME PLAY FLAW being unable to distinguish 2 main groups of blueprint items easily and having a lot of annoying work sorting the sht out, once mixed accidentally, is a major flaw for me. Originally by:* Tellenta Typed in caps so you could hear me. FU
Emporer Norton	Posted - 2010.03.17 19:58:00 - [20] Is easy use divison for bpo another for bpc or 2 containers or if in hanger s&i to sort thru quickly
Joe SMASH You Got A Purty Mouth	Posted - 2010.03.17 19:59:00 - [21] I am feeling nice, so I will help ya out. If you send me all your BPOs and BPCs, I will sort them into containers for you and contract them back. I will be online tonight. ----------------------------------- Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
FunzzeR Death of Virtue MeatSausage EXPRESS	Posted - 2010.03.17 20:05:00 - [22] Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 17:22:40 I'm getting mad every time I have to sort the fuggin BPO out of a bunch of BPC in hangars and POS divisions!!!! I dont care about technical backgrounds and explanations why things are broken currently, if you did it wrong, then simply fix it! Just use only bpos like I do But I digress, I have been hearing about this quibble for years. And CCP has been pretty clear on why they won't change it. And honestly, they have bigger fish to fry anyways.. PRAISE THE SCOTTISH FOLD!! THEIR WILL SHALL BE DONE!!
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.17 20:16:00 - [23] Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 19:52:42 Originally by: Tellenta IT'S NOT REALLY A MAJOR GAME PLAY FLAW being unable to distinguish 2 main groups of blueprint items easily and having a lot of annoying work sorting the sht out, once mixed accidentally, is a major flaw for me. Originally by:* Tellenta Typed in caps so you could hear me. FU All right, sorry about that I had just gotten back from work and was working (I know right) on something that required caps-lock to be engaged, deal with it. I will stand by your assertion that having an at-a-glance ability to distinguish BPO's from BPC's would be rather nice, however as a previous poster provided CCP is either unable, or haven't gotten around to making that a reality. I can accept that, considering that if I lose my BPO amongst my BPC's all I have to do is show info on the first or last BPO/C of that bunch to find it again, it really is not that hard, annoying? sure but hardily something that breaks your back in effort. Quote: being unable to distinguish 2 main groups of blueprint items easily This is a fine example of a false statement, commonly used to try to up the importance of a rather banal subject. also, FU2
Robert Caldera	Posted - 2010.03.17 20:16:00 - [24] Edited by: Robert Caldera on 17/03/2010 20:23:43 Originally by: Emporer Norton Is easy use divison for bpo another for bpc or 2 containers or if in hanger s&i to sort thru quickly I do too, but sometimes, they accidentally get together, which suddenly causes a lot of annoying work. I know the workarounds, but like I said before, these are only workarounds for a FLAW, which I'd like to see fixed soon! Originally by: Tellenta I can accept that, considering that if I lose my BPO amongst my BPC's all I have to do is show info on the first or last BPO/C of that bunch to find it again if it was that easy, this tactic never worked for me - I had to look infos of each single one of 60 BPs to find my lost 2 BPOs again 2 hours ago.
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.17 21:21:00 - [25] Edited by: Tellenta on 17/03/2010 21:21:49 Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 20:23:43 Originally by: Emporer Norton Is easy use divison for bpo another for bpc or 2 containers or if in hanger s&i to sort thru quickly I do too, but sometimes, they accidentally get together, which suddenly causes a lot of annoying work. I know the workarounds, but like I said before, these are only workarounds for a FLAW, which I'd like to see fixed soon! Originally by: Tellenta I can accept that, considering that if I lose my BPO amongst my BPC's all I have to do is show info on the first or last BPO/C of that bunch to find it again if it was that easy, this tactic never worked for me - I had to look infos of each single one of 60 BPs to find my lost 2 BPOs again 2 hours ago. This puzzled me so I did an experiment. It turns out I was mistaken (kinda). I decided to run an experiment to see if I could get a BPO not at the beginning or end of the stack. I had success when I had BPC's from two BPO's however when I had 3 BPO's amongst 60 BPC's something different happened two where where I expected them to be, however the third was not to be found. http://img253.imageshack.us/img253/5760/20100317210222.jpg Crap he is right I thought to myself, but there has to be an easier way than looking through all of them! Then I thought to myself, maybe the BPO is somehow attached to the batch of BPC's went up 40 from the bottom (out of 60 similar BPC's) and selected the 41st one http://img12.imageshack.us/img12/8504/20100317210346.jpg There it was, great victory! I hope this helps in your future endeavors.
Ruziel Minmatar Twilight Military Industrial Complex	Posted - 2010.03.17 21:26:00 - [26] Originally by: Tellenta d CCP is either unable, or haven't gotten around to making that a reality. It's not that they can't. It's the fact that doing so would add crippling load to the database servers. You are asking to add a table join for a single column that is only relevant to blueprints to the lookup any time a container (be it a station hangar, a ship hold, a cargo container) is opened. The reason they do this on the S&I blueprint tabs, is because they are doing it for only blueprints, and they aren't doing it for a single column, but the ME and PE levels as well.
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.17 21:39:00 - [27] Originally by: Ruziel Originally by: Tellenta d CCP is either unable, or haven't gotten around to making that a reality. It's not that they can't. It's the fact that doing so would add crippling load to the database servers. You are asking to add a table join for a single column that is only relevant to blueprints to the lookup any time a container (be it a station hangar, a ship hold, a cargo container) is opened. The reason they do this on the S&I blueprint tabs, is because they are doing it for only blueprints, and they aren't doing it for a single column, but the ME and PE levels as well. Minor correction, I'm not asking CCP to change anything. I am a happy clam regardless of whether they decide to find a way to determine BPO from BPC from an at a glance way. I fear the repercussions if CCP decides to try fixing some old code like that, jump gates won't work, guns won't fire, dogs and cats living together, MASS HYSTERIA!!!
Ruziel Minmatar Twilight Military Industrial Complex	Posted - 2010.03.17 22:28:00 - [28] Originally by: Tellenta Minor correction, I'm not asking CCP to change anything. I am a happy clam regardless of whether they decide to find a way to determine BPO from BPC from an at a glance way. I fear the repercussions if CCP decides to try fixing some old code like that, jump gates won't work, guns won't fire, dogs and cats living together, MASS HYSTERIA!!! My second point was aimed at the OP more than yourself, but I could see the confusion. You are correct that a proper fix to this that does not involve adding a massive DB load, thereby increasing lag, would require a change to the DB structure. Which in turn require rewriting every bit of inventory code that touches it. As anyone familiar with multi-thread and database transaction programming, they have to be extremely careful with the inventory code to prevent item duplication and other exploits. One would hope that a refactoring or optimization of this core code is on the schedule, as with all the other code optimization they have been doing over the last few releases. But to demand that they drop everything and fix it NAO is ill-advised.
ZeeOhSix Blackwater Manufacturing and Logistics	Posted - 2010.03.17 23:40:00 - [29] Note to self; do not hire RC as a DBA :) I would offer that if you have the expertise you claim to, you'd recognize that until you see the schema, you really don't know what's possible and what's not. It may have been a short-sighted design, but we don't really know. It sounds like in the end they treat it as an attribute of an existing object, rather than a seperate object, and I can see why that would be attractive from a system design perspective. OTOH, they did buy one of these for their database ;) http://www.ramsan.com/products/ramsan-400.htm The business of EVE is business!
Robert Caldera	Posted - 2010.03.18 08:53:00 - [30] absolute normalization is a curse if it comes to performance considerations, its general knowledge - so I cant understand why CCP still sticks to it by all means. Functionality should form the backend, not the other way around, the complaints about this terrible game flaw are there since I've started playing eve.
Charles Park	Posted - 2010.03.18 09:24:00 - [31] I honestly have no problem keeping my bp's straight in my carebear alt corp. The only reason I'd like BPO's to be different from BPC's is so I can know how many tears I caused when I popped someone and their cargo of BP's didn't survive. Was that a covetor bpc or bpo in their hold?
Tereliss Verr	Posted - 2010.03.18 09:52:00 - [32] I am by no means a computer guru in any way, but would it be possible just to have a different colour for BPO's and a different one for a BPC? Just a thought.
NeoFusion Caldari Freelancer Union Unaffiliated	Posted - 2010.03.18 14:45:00 - [33] Edited by: NeoFusion on 18/03/2010 14:49:44 For those that don't understand the problem, there are two types of BPO, a 'type' and an 'instance'. A type would be 'Megathron Blueprint' which would be generic. An instance would be a 'Megathron BPC, ME20 PE20, copies 2' which is of type 'Megathron Blueprint'. When you ask EVE to give you a listing of items in your hangar it grabs all the types of thing you have in there, guns, ships, blueprints etc. It only ever gets the type of these things, not the instance. If you open a ship, then it opens the instance of the ship or blueprint, which can then do a second request for all the information and to obtain the instance, including information about ME, PE, copies, number of guns fitted etc. For EVE to display all the data about a blueprint in the item hangar it would need to say "give me all the types and instances of these types in my hangar" which would be an exponentially bigger query, given the size of EVE and the amount of queries going on. Imagine that multiplied by the number of players currently online querying their hangars and you've got a major problem. It is simply not feasible. And to those who say "Why can't you just do a flag" in order to do the flag you would need to get the instance in order to determine if 'Megathron BPO' is a copy or a blueprint, which involves the same query and same problems associated with it. Giving the blueprint a different colour still requires your client to find whether the blueprint is a BPO or an instance BPC, in order to determine what colour to give it, same problem. There are two ways CCP could do this, the first would be to have two queries for every hangar/container access, the first would say "give me all the types that aren't blueprints" then the second would be "give me all the blueprints and their instances" which would be smaller queries, but in that problem you've just doubled the total amount of queries for every viewing of a hangar across the whole of EVE (which is bad mkay?) The second way would be to create a separate 'type' of blueprint, one for the original, one for the copy so they would be completely different. I.e. this is of type 'Megathron BPO' and this is of type 'Megathron BPC', but CCP have already stated that this would need a complete rewrite of the scientific and industrial portion of the game, a massive undertaking probably taking months and months, just to get a blueprint a specific colour. There are more important things I'm afraid. - Neo
Hallingen Caldari SWARTA	Posted - 2010.03.18 14:46:00 - [34] Edited by: Hallingen on 18/03/2010 14:49:27 Originally by: Robert Caldera absolute normalization is a curse if it comes to performance considerations, its general knowledge - so I cant understand why CCP still sticks to it by all means. Functionality should form the backend, not the other way around, the complaints about this terrible game flaw are there since I've started playing eve. Yes, but this is not just a DB-issue. Had it been it would've been easy. The problem, as stated in other threads, appears to be that there's a unique-constraint on the "manufactured-by" column on the items table. This means that a ship for instance can only be produced by one itemtype, that is the BP for that item. If they made BPOs and BPCs different item-types they would have to lift this constraint, or a BPO and a BPC wouldn't be able to manufacture the same item! And that means also messing with the application code for the entire manufacturing system. So it's not just a denormalization, but a major rewrite involving both the DB and some legacy application-code. This is very much nontrivial and is probably (rightly) ranked quite low on CCPs lists of feature requests. Major overhead for minor tweak. Edit: spelling. Also what the last guy said.
ExplicitViolence	Posted - 2010.03.18 14:56:00 - [35] I'm calling BS on this. And I don't mean 'battleship'. If CCP's elite database is really so completely and thoroughly normalized (a terrible idea) then adding an attribute to distinguish between original and copy would be trivial. Trivial I say.
Robert Caldera	Posted - 2010.03.18 15:24:00 - [36] Originally by: NeoFusion ... [a lot of speculations about eve implementation internas] ... For EVE to display all the data about a blueprint in the item hangar it would need to say "give me all the types and instances of these types in my hangar" which would be an exponentially bigger query there is nothing exponential. If a query for a set of blueprints is O(n), then an expanded query which would check the exact type would still result in O(n), assuming the access to the type is O(1), if you know what I'm talking about. Originally by: NeoFusion There are more important things I'm afraid. yes, new ship paints for example.
Breaker77 Gallente Reclamation Industries	Posted - 2010.03.18 15:31:00 - [37] Originally by: Robert Caldera there is nothing exponential. If a query for a set of blueprints is O(n), then an expanded query which would check the exact type would still result in O(n), assuming the access to the type is O(1), if you know what I'm talking about. Btw. before querying for types of objects, you need the objects themselves, here is your mistake assuming types exist independently of objects they're assigned to. It's bad enough waiting for my hangar to load several hundred blueprints. I don't want to add anymore time. Use containers, or seperate corp hangar divisons to keep everything seperate. It's really simple unless you're an idiot.
Robert Caldera	Posted - 2010.03.18 15:35:00 - [38] Originally by: Breaker77 It's bad enough waiting for my hangar to load several hundred blueprints. I don't want to add anymore time. Use containers, or seperate corp hangar divisons to keep everything seperate. It's really simple unless you're an idiot. poor you... I have several thousands blueprint copies in a pos hangar division. I wouldnt like to imagine if I drop a BPO there by accident.
Breaker77 Gallente Reclamation Industries	Posted - 2010.03.18 15:41:00 - [39] Originally by: Robert Caldera poor you... I have several thousands blueprint copies in a pos hangar division. I wouldnt like to imagine if I drop a BPO there by accident. If only there was a screen that shows you the types of blueprints you have in your hangar. You know maybe somewhere in the science and industry screen, oh and would be nice if you could sort it. If only it existed All the tools are present for you to determine what blueprints you have already, just requires a little brainpower to use them.
Robert Caldera	Posted - 2010.03.18 15:56:00 - [40] so, how does the stupid Science&Industry window help me separating them, since you cant move them anywhere within that window!
Sir Bonkers Caldari Innovations and Research	Posted - 2010.03.18 16:51:00 - [41] Originally by: Robert Caldera so, how does the stupid Science&Industry window help me separating them, since you cant move them anywhere within that window! I am at work atm, but I believe there is a drop down menu at the top of the window. Should have options; "Show all Blueprints", "Show Only Originals", "Show only Copies". That is from memory, so do not take it as 100% fact.
Robert Caldera	Posted - 2010.03.18 18:01:00 - [42] Edited by: Robert Caldera on 18/03/2010 18:03:16 Originally by: Sir Bonkers I am at work atm, but I believe there is a drop down menu at the top of the window. Should have options; "Show all Blueprints", "Show Only Originals", "Show only Copies". That is from memory, so do not take it as 100% fact. yeah you're right but this does not help since there is no option to move the prints across divisions or see in which division they exactly are. the use of Science&Industry is of very limited use in this concern.
Sir Bonkers Caldari Innovations and Research	Posted - 2010.03.18 18:28:00 - [43] Edited by: Sir Bonkers on 18/03/2010 18:31:33 Edited by: Sir Bonkers on 18/03/2010 18:30:22 Originally by: Robert Caldera Edited by: Robert Caldera on 18/03/2010 18:03:16 Originally by: Sir Bonkers I am at work atm, but I believe there is a drop down menu at the top of the window. Should have options; "Show all Blueprints", "Show Only Originals", "Show only Copies". That is from memory, so do not take it as 100% fact. yeah you're right but this does not help since there is no option to move the prints across divisions or see in which division they exactly are. the use of Science&Industry is of very limited use in this concern. It is limited, yes. But how often are you moving blueprints? If they are all in one place (lets say a corp tab called Blueprints), then you can use Sci&Indy to start research, manufacturing, etc. That would eliminate the need to have them sorted in the first place. I use one tab for everything and the Sci&Indy button to launch all my production and research from there. Not a great way to do it, but it is what is easiest for me. Good luck! EDIT: I just realized that the method I describe assumes you have the skills to remotely start jobs. Not sure if you do or not, but it is highly recommended.
Robert Caldera	Posted - 2010.03.18 18:52:00 - [44] Edited by: Robert Caldera on 18/03/2010 18:52:12 the point of this thread was not talking about useless workarounds but about easier handling of blueprints, so sorry, the S&I is useless and there is no other way to find BPOs among many prints for sorting them out, which is the main issue.
Mad Constructor Mad Industrys	Posted - 2010.03.18 20:46:00 - [45] Originally by: Robert Caldera Edited by: Robert Caldera on 18/03/2010 18:52:12 the point of this thread was not talking about useless workarounds but about easier handling of blueprints, so sorry, the S&I is useless and there is no other way to find BPOs among many prints for sorting them out, which is the main issue. I have about 100 BPOs and over 1300 BPCs at any given time. I've never had BPOs and BPCs get mixed. Even if I had 10x that many BPs they still wouldn't mix. Learn to be better. Oh, and a quick trip to the S&I window will help sort out your mixed BPs.
ZeeOhSix Blackwater Manufacturing and Logistics	Posted - 2010.03.18 21:08:00 - [46] Originally by: Robert Caldera absolute normalization is a curse if it comes to performance considerations Goodness, but you're confused regarding the benefits of nomalization for high-transaction databases But it is entertaining reading
Robert Caldera	Posted - 2010.03.18 23:38:00 - [47] Originally by: Mad Constructor I have about 100 BPOs and over 1300 BPCs at any given time. I've never had BPOs and BPCs get mixed. Even if I had 10x that many BPs they still wouldn't mix. Learn to be better. this thread is not about personal habits handling the prints Originally by: Mad Constructor Oh, and a quick trip to the S&I window will help sort out your mixed BPs. you suck at reading and undestanding. S&I does not help me locating and sorting the prints, this is the thread all about actually. Originally by: ZeeOhSix Goodness, but you're confused regarding the benefits of nomalization for high-transaction databases says who? go trolling somewhere else if you have no clue
Seurimas	Posted - 2010.03.19 00:03:00 - [48] Originally by: Robert Caldera this thread is not about personal habits handling the prints This thread is actually about whatever people post in this thread. That's the whole point of a thread. It's not a venue for your personal tirade on the workings of BPC/BPO sorting and picturing. It's a place for discussion. And frankly, I'm surprised it hasn't taken a serious derail into discussion about the way you handle this poor, scream-deafened thread of yours. You should take better care of your things.
Paknac Queltel Standards and Practices	Posted - 2010.03.19 00:11:00 - [49] I'd seriously recommend unlearning the theoretical college stuff and get a nice dose of realism. The database server is constrained in memory and CPU. Guess what? Joins burn extra of both. Say we added this extra join on a query that runs every single hangar load (which there are a lot of every second). All's fine and dandy, and you've got your nice and shiny BPC marker. The cost? Now EVE is laggier than before. Your little join is causing extra server CPU cycles to burn, and is increasing memory usage, which means more data has to flow into swap. Also, every single hangar load will now cause more data to be sent to the server node, which has to pass on extra info to the end client (even if it's a single byte indicating that there is no extra info), causing extra congestion on CCP's internal network. All these things, seperately, increase lag. Now, could this problem be fixed by throwing more processing power, more memory and faster network equipment against it? Yes, of course. Guess what? Now there's more hardware, which means more chance of something failing. Is a simple mark on your blueprint, when the information is already available, worth the chance of all that trouble?
Emporer Norton	Posted - 2010.03.19 01:14:00 - [50] There are other ways it could be done also just make a duplicate type with a diff pic have a script run during an extended dt check all bp's all copies changed to new type would be extra work once then is just loading like always
SurrenderMonkey	Posted - 2010.03.19 02:26:00 - [51] Edited by: SurrenderMonkey on 19/03/2010 02:26:29 Originally by: Emporer Norton There are other ways it could be done also just make a duplicate type with a diff pic have a script run during an extended dt check all bp's all copies changed to new type would be extra work once then is just loading like always Originally by: Hallingen Edited by: Hallingen on 18/03/2010 14:49:27 Originally by: Robert Caldera absolute normalization is a curse if it comes to performance considerations, its general knowledge - so I cant understand why CCP still sticks to it by all means. Functionality should form the backend, not the other way around, the complaints about this terrible game flaw are there since I've started playing eve. Yes, but this is not just a DB-issue. Had it been it would've been easy. The problem, as stated in other threads, appears to be that there's a unique-constraint on the "manufactured-by" column on the items table. This means that a ship for instance can only be produced by one itemtype, that is the BP for that item. If they made BPOs and BPCs different item-types they would have to lift this constraint, or a BPO and a BPC wouldn't be able to manufacture the same item! And that means also messing with the application code for the entire manufacturing system. So it's not just a denormalization, but a major rewrite involving both the DB and some legacy application-code. This is very much nontrivial and is probably (rightly) ranked quite low on CCPs lists of feature requests. Major overhead for minor tweak. Edit: spelling. Also what the last guy said. Assuming what the above poster said is true, your idea would violate that constraint, which is likely there for a variety of very good reasons.
ChrisIsherwood	Posted - 2010.03.19 02:55:00 - [52] If we accept that 1) it would be too inconvenient to distinguish between BPO & BPC all dialog boxes 2) the SI& dialog box has the info you need then what is wrong with just adding drag&drop functionality to that S&I dialog box? E.g. drag from this dialog box to cargoholds, containers, hangars, mail etc. It could not possibly add any more database accesses, since the info is already being shown. TBH, drag & drop and object manipulation have been a common user interface paradigm since before the Mac shipped in 1984. i.e. it should be in the UI regardless. N.B., you do not have to use the S&I dialog; you just need a way for current things like items and cargohold to open without wasting precious nanoseconds of computing power while allowing in those situations when the user cares about the information, allow them to see and use it.
Angus McSpork Caldari	Posted - 2010.03.19 04:34:00 - [53] NERD FIGHT!
Sukoz	Posted - 2010.03.19 05:58:00 - [54] The solution is actually pretty simple. Reading the dev posts I've come to this understand about the process. When the inventory is queried, you get a result of an itemID, and a parentID. How the system works is BPOs and BPCs both have the same parentID, the original un-researched BPO. In a separate table, the difference between the items you have and the original un-researched BPO are stored. So the ME/PE/etc for the BPO and the BPC. It also stores either a -1 for the maxruns, for a BPO, or a positive number for a BPC. So the problem is that the data differentiating the BPO and BPC are in a separate table, and to access it would require a second query on a much larger table every single time an inventory is queried. Which is unacceptable. A solution suggested is to simply add a flag to the inventory table to differentiate without having to query. CCP say they won't do this and I don't blame them, as it would add a field that would only be used for blueprints, and simply be empty space for every single other item in every single inventory. Ideally the solution should not change the setup of the database, or if it must be changed, to do so in a table specific to blueprints, which would be very small compared to the table containing every inventory. Fortunately theres a way to do so. For each blueprint, create 2 "parent" items. The un-researched BPO, with the base ME/PE/etc values and a maxrun of -1, and a un-researched BPC, same attributes but the maxrun being 0. When a copy is created it uses the same system, but instead setting the item parent as the un-researched BPC, using the same deltas. Load added to the system: Doubles the count of blueprint item types, by adding an item type for the BPC as well. 17% increase in table size of item types, from 18k to 21k records. This is static table and nowhere near the size of the table holding inventories, size increase is likely negligible. Double the size of the blueprint type table to near 7k records. Would also need to add a flag to this database of whether the blueprint is a copy or original. Again, static table, small size. Possibly the parentBlueprintTypeID field could be re-purposed to link the copy to the original and vice versa, as I guess it is not actually used currently? If not, would need to add another field simply linking the 2 items together. The table size would likely increase to 2.5x the size of the original, but it is still small. This could cause an issue depending on how these static tables are cached, hopefully not. When a blueprint copy is created, there would need to be a query lookup to find the itemID for the copy from the blueprint type table. I'd like to believe this would be an easy operation based on the fact its a small static table. Then instead of setting the parent id for the new copy instance as the un-researched BPO, it would be the un-researched BPC. The rest of the system would be interchangeable, using the same delta attributes and such, no change needed. All current BPCs would need to be found, and their parent id's changed. Also the delta database records for these BPCs would need to be changed if the parent id is also stored in those(don't know the exact setup of these internal databases). This would be a very large operation. Would need to be done during an update or extended downtown. Likely other small changes as well. As far as the fix, there would be separate parentIDs for a BPO and BPC, which is returned in the inventory without the query being changed. Could have a different group id, for sorting, or a different icon, etc. The only runtime changes are the item type table size increase and when copies are created to find the copy typeID from the original typeID, which I hope are minor performance hits for what the change provides. I really hope a change like this could be implemented. It skirts around the performance issues of other suggestions and should not require major changes done to the blueprint logic.
Celia Therone	Posted - 2010.03.19 07:09:00 - [55] Client side cache blueprint id's and bpo status in a hash table?
Venkul Mul Gallente	Posted - 2010.03.19 07:40:00 - [56] Originally by: Celia Therone Client side cache blueprint id's and bpo status in a hash table? How many seconds before someone find how to change that T2 BPC to: 10.000 runs ME +1.000 PE +1.000? It is the same reason why all our stuff is listed on the server side: too easy to cheat otherwise.
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 08:30:00 - [57] Edited by: Vaerah Vahrokha on 19/03/2010 08:32:04 Quote: I graduated in computer science and databases are my daily business, so please stfu teaching me stuff I'm messing aroung for years! Possibly 90% of the EvE players are nerds that can easily talk about database normalization. Titles would apply only for breakthru findings, but yours aren't. You don't seem even to have the practice in the field to know what happens in a C software written with the ass (original EvE code tends to be like that). Nothing prevents EvE to be like the 10 man years C++ software I had to maintain for some years, where the SQL retrieved cursors were loaded directly in RAM thru a memcopy >_< and changing / adding 1 field would overwrite beyond the allocated structures and cause nasty-to-butt to debug access violations. EvE is that bad, where you could change 1 bit of the dinosaur code and suddenly have ships unable to warp, gates stopping to work and worse. This is why nowadays that they use agile programming but still have to keep the game running, they use and build over the ancient code as a read only nucleus to touch with care. Quote: Functionality should form the backend, not the other way around, the complaints about this terrible game flaw are there since I've started playing eve. Functionality should begin with a decent backend. The initial choices made years ago were to pick LOLMSQLServer and anything from 2003 onwards will forever be affected by that and not going to change. Quote: then what is wrong with just adding drag&drop functionality to that S&I dialog box? Ever wondered why that box, the POS management box and the LP store box are different and yet totally UGLY in their own and unique ways? Made by different people who were probably more suited at designing Chinese torture devices, they are implanted under layers of years old code that will crash our very plane of existence only at looking funny at them. Quote: So the problem is that the data differentiating the BPO and BPC are in a separate table, and to access it would require a second query on a much larger table every single time an inventory is queried. Which is unacceptable. Add the fact that in theory the tables could (years ago) be made to reside on different speed media depending on their intended workload and you'll have the situation to join and slow down the quick access table(s) at the turtle speed of the slower ones. Quote: Client side cache blueprint id's and bpo status in a hash table? Check what happens in butt made "partial client side optimization" popular MMOs, with the incessant hacks and exploits. Unlike those games, in EvE items matter, are not even "soul bound". The consequences could be dire. - Auditing & consulting When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
Robert Caldera	Posted - 2010.03.19 09:32:00 - [58] just STFU being idiots teaching me why 1 bit flag cant be retrieved from the database, all you can do is being parrots repeating excuses some dev did one day.
Killahchick	Posted - 2010.03.19 10:59:00 - [59] Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 18:46:49 stop quoting bullsht. highly normalized blaaaahhhhh... improperly/too much normalized if the database table definition does miss the purpose and makes basic things impossible!! So what you're saying is they need to remake a big part of a DB just because you say so. Yeah I should stop quoting bull*... like I did above. Quote:** I dont want pesky workarounds, I want a FIX! Didn't mom tell you? The "I want" herb doesn't grow anymore.
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 11:18:00 - [60] Quote: just STFU being idiots teaching me why 1 bit flag cant be retrieved from the database, all you can do is being parrots repeating excuses some dev did one day. Then let me talk not like a parrot: learn to fuking deal with it and play like everyone else do without so much crying. The game is harsh and badly usable for the same reason it won't accept external LUA player made add ins nor will implement autoloot and similar. Now, use your graduation to find out the banal reason why it's like that and why it's better it stays like that than not.
wakalaka Information And Entropy	Posted - 2010.03.19 11:21:00 - [61] Do you want to know how I made my first 1.5 billion ISK ingame? Someone set up a contract for a capital ship part BPC. Only it wasn't a BPC, it was the BPO. In fact, that poor soul set up his whole capital BPO library on contracts while confusing them with BPC, but I was only in time to get hold of one of them. Which is to say, there are quite some people who profit and make a career into looking for contracts like that. Unfortunately the contracts were corporate ones, so I don't know who did it, but what a bad day, guy! This is EvE. What OP proposes is logical and necessary to avoid stupid mistakes. There are many things (most UI related). But it's not EvE, a game that encourages scamming and suicides induced by the UI, without any safeguards. So, here you have the two faces of my dime.
Newtonius Rex Triturus Logistics and Exploration Support Harmonious Ascent	Posted - 2010.03.19 12:07:00 - [62] Originally by: Tellenta ..... I fear the repercussions if CCP decides to try fixing some old code like that, jump gates won't work, guns won't fire, dogs and cats living together, MASS HYSTERIA!!! Best post in this thread - Live to Fly - Fly to Live - Power is Nothing Without Control
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 12:24:00 - [63] Quote: Someone set up a contract for a capital ship part BPC. Only it wasn't a BPC, it was the BPO. Now, now! you are spoiling my riddle: Quote: Now, use your graduation to find out the banal reason why it's like that and why it's better it stays like that than not. Eve is made and lives and is special because it got SO MANY ripples, so many mini games, so many opportunities, so many styles. Thanks to the clumsy UI a guy just made a billion: he knows how to play the contracts minigame and find out for hidden riches like the mistaken BPC that in reality were BPOs. Thanks to the missing flag, the suicide ganker has the thrill and suspension when scanning incoming ships. No "bah, 95% are carrying worthless BPCs, I give up" but: "this dude got 4 different cap ship construction components blueprints. Pop him? Risk? Maybe it's a wagon of money. Maybe it's a toss. Thanks to the dubious interface, a guy just bought a missile launcher for 120000000 isk, another outplayed a bidder by putting an "8" in a long series of "9"... Thanks to the UI quirks, no one is super-safe. "Dammit, forgot to pay" => POS offlined and possibly wasted. Sov drops. It's BAD things... that make EvE multi-dimensional, rich, unique. No super-streamlined, tard proof smooth perfection where you have a wizard that drives you to find your wily. Boring perfection. The marvel is in diversity, in unforeseeable events, in NOT knowing what's next. In the journey. Only the zero benefits UI misfeatures (IE the LP store) should be really fixed, as they don't give opportunities and tears. - Auditing & consulting When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
Tasty Bit Gallente UNITED STAR SYNDICATE	Posted - 2010.03.19 12:35:00 - [64] Please don't question anything ever. Everything is fine.
Robert Caldera	Posted - 2010.03.19 12:38:00 - [65] Just fix it.
Paknac Queltel Standards and Practices	Posted - 2010.03.19 13:15:00 - [66] Originally by: Vaerah Vahrokha It's BAD things... that make EvE multi-dimensional, rich, unique. No super-streamlined, tard proof smooth perfection where you have a wizard that drives you to find your wily. Boring perfection. The marvel is in diversity, in unforeseeable events, in NOT knowing what's next. In the journey. Mind if I steal this excuse for next time someone asks me why my GUI's are terribad? Originally by: Robert Caldera Just fix it. Ah, so you're mid-level management. Figures.
Robert Caldera	Posted - 2010.03.19 13:19:00 - [67] Edited by: Robert Caldera on 19/03/2010 13:20:53 Originally by: Paknac Queltel Originally by: Robert Caldera Just fix it. Ah, so you're mid-level management. Figures. at least I'm honest I dont give a **** how eve ticks internally... I am a customer after all. All I can tell from my perspective is that such a thing is not a big business usually and even more not unrealizable at all as many parrots try to tell me. Many people in this thread remind me of a bunch of nerds standing in front of a machine and quarrel about its abilities and how its probably working.
Sarina Berghil Minmatar New Zion Judge Advocate Chained Reactions	Posted - 2010.03.19 13:49:00 - [68] Or they could just improve on the science and industry interface so that essential actions like moving the blueprints was possible, making it a viable workaround instead of a useless window. Of course since any action on the science window results in a full scale query that might take several minutes, its usually faster to just look through 100 identical blueprints anyway. Want to invent 'refresh' button, 'move_to' button, useful filter options. Or have the default hangar show just blueprints by default but provide a show 'bluerint details' button for those that actually need them, wouldn't cause more lag than opening each blueprint individually anyway. There's no lack of useful workarounds.
Paknac Queltel Standards and Practices	Posted - 2010.03.19 13:50:00 - [69] Originally by: Robert Caldera Edited by: Robert Caldera on 19/03/2010 13:20:53 Originally by: Paknac Queltel Originally by: Robert Caldera Just fix it. Ah, so you're mid-level management. Figures. at least I'm honest I dont give a **** how eve ticks internally... I am a customer after all. All I can tell from my perspective is that such a thing is not a big business usually and even more not unrealizable at all as many parrots try to tell me. Many people in this thread remind me of a bunch of nerds standing in front of a machine and quarrel about its abilities and how its probably working. Sure, it can be done. It's simply unwise to do so, for so little gain. While risking being called a parrot, let me explain again: The BPO is always the first or last of the sorted list of items. That's only two item detail pages you need to check, max. Most often, though, you don't even need to check for it, if you separated your blueprints properly. However, the check whether it's a BPC or not would still need to be done, every time anyone loads a container, anywhere. It's a heavy cost compared to the tiny benefit.
cough cough	Posted - 2010.03.19 14:01:00 - [70] Edited by: cough cough on 19/03/2010 14:09:17 Let me give you a ***** clue for good... On the science & industry window: Right click on your desired BPO, deliver to, corp hangar, BPO division or whatever you call that division. Next time, please use your brain before you start crying about missing features. Edit: of course this only work if you have your own corp / have BP access rights on your corp. Wich should be a requirement if you have such a huge number os BPOs an BPCs
Sarina Berghil Minmatar New Zion Judge Advocate Chained Reactions	Posted - 2010.03.19 14:31:00 - [71] Originally by: cough cough Edited by: cough cough on 19/03/2010 14:09:17 Let me give you a ***** clue for good... On the science & industry window: Right click on your desired BPO, deliver to, corp hangar, BPO division or whatever you call that division. Next time, please use your brain before you start crying about missing features. Edit: of course this only work if you have your own corp / have BP access rights on your corp. Wich should be a requirement if you have such a huge number os BPOs an BPCs Of course none of those features work in a POS that is the only practical place to do research anyway, just having a way to open a container inside a hangar would be awesome. Because then unusued blueprints could be put inside for safekeeping. Or simply letting us define more hangars than the global one-size fits all divisions of hangars across the known and unknown universe. There are tons of little changes that could make science and industry tolerable, but the only excuse seems to be that changing the database structure isnt viable. And if someone is going to tell me to solve UI bugs, by moving all POS'es to hi-sec and setup offices there, I am going to literally explode. Its ridiculous the amount of workarounds players go through, to fix IU issues that are trivial to improve upon.
ChrisIsherwood	Posted - 2010.03.19 14:34:00 - [72] Originally by: Vaerah Vahrokha The game is harsh and badly usable for the same reason it won't accept external LUA player made add ins nor will implement autoloot and similar. Now, use your graduation to find out the banal reason why it's like that and why it's better it stays like that than not. I think you explained it very well 3 posts ago: they made some poor choices in the past (LOLMSQLServer) as well as having a bad, ancient codebase that they are trying to make minimal changes to. Which is sort of depressing for the future of EVE; oh well, no game is for ever. Now that you mention it, CCP's last two corporate acquisitions have been for console gaming which allows them to avoid having to make these and other changes to the legacy code in EVE.
Susurrous	Posted - 2010.03.19 15:17:00 - [73] 1. When I go to Science & Industry -> Corp Blueprints, I see a list of hundreds of corp blueprints, all with a tag COPY stating YES or NO. Clearly this tag is immediately available without any major overhaul. 2. What it sounds like is the primary problem is that CCP can't at the moment have two different itemtypes produce the same item without a major overhaul. Is there, however, a reason why we couldn't have two different graphics on the same itemtype, based on that flag? e.g., overlay BPC onto the blueprint icon if it's a copy, or put a number with the runs remaining on it.
Tallaran Kouros Caldari	Posted - 2010.03.19 15:18:00 - [74] Originally by: Robert Caldera I graduated in computer science and databases are my daily business, so please stfu teaching me stuff I'm messing aroung for years! I'm going to stop you here. No matter how smart you think you are or how good you are, CCP are smarter and know more. I'm normally one of the first people to slag CCP when it's justified, but their DBAs know their stuff. CCP's database structure is nearly enough unique in the world and when companies have problems to solve or new database hardware to test CCP is one of the few companies in the world that they go to in order to do this. Let me repeat - you are wrong and CCP are right. Now leave the keyboard alone - your posts are just a fountain of fail.
SurrenderMonkey	Posted - 2010.03.19 15:31:00 - [75] Edited by: SurrenderMonkey on 19/03/2010 15:35:51 Originally by: Susurrous 1. When I go to Science & Industry -> Corp Blueprints, I see a list of hundreds of corp blueprints, all with a tag COPY stating YES or NO. Clearly this tag is immediately available without any major overhaul. 2. What it sounds like is the primary problem is that CCP can't at the moment have two different itemtypes produce the same item without a major overhaul. Is there, however, a reason why we couldn't have two different graphics on the same itemtype, based on that flag? e.g., overlay BPC onto the blueprint icon if it's a copy, or put a number with the runs remaining on it. Yes - because it would require an additional join. That information does not exist in the table(s) responsible for managing inventory, nor in the table(s) for managing the base item type - it only exists in a table that stores certain specific information about specific instances of an item. That table is not referenced when you open your hangar (or a container). So, to get that information, a join to that table would be required. Every time EVERY player opened their hangar, it would be calling the specific instance information of EVERY item contained within. So, in conclusion: 1. They can't (won't) make a separate itemtype because of that previously mentioned builtby constraint (assuming that's true). 2. They won't link to the item instance information for just looking in a container because it would represent a substantial performance hit due to the inclusion of at least one additional join and the metric asston of information that would come with it. There almost certainly IS a way to do it that wouldn't be terribly detrimental, however. It might be a little bit "hackish", but as other people have pointed out, when sorted the BPOs are always either first or last, which means there is probably some tiny piece of information in there that somehow differentiates them. It is probably not something that most right-minded designers would use for such a purpose, but... --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Sarina Berghil Minmatar New Zion Judge Advocate Chained Reactions	Posted - 2010.03.19 15:36:00 - [76] Originally by: Susurrous 1. When I go to Science & Industry -> Corp Blueprints, I see a list of hundreds of corp blueprints, all with a tag COPY stating YES or NO. Clearly this tag is immediately available without any major overhaul. 2. What it sounds like is the primary problem is that CCP can't at the moment have two different itemtypes produce the same item without a major overhaul. Is there, however, a reason why we couldn't have two different graphics on the same itemtype, based on that flag? e.g., overlay BPC onto the blueprint icon if it's a copy, or put a number with the runs remaining on it. The result from the science and industry window is probably an advanced query taking up quite a bit of server time, while the result from a normal hangar is much simpler. So the yes/no tag is not immediately available. The main issue is not to show the graphic, but for the client to know what kind of graphic to show. Since people as a whole probably open many more hangar windows, than they open science and industry windows, it makes sense to make a simpler query for the hangars. However giving us the use to customize queries to some extent, and decide how to organize and sort items, could reduce the limitations a lot. And possible even be lighter on server load. I see no reason why the game needs to make a new database query just because I choose to sort the items on a different attribute, it might as well be cached client side as long as the data didn't change.
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 15:53:00 - [77] Quote: Many people in this thread remind me of a bunch of nerds standing in front of a machine and quarrel about its abilities and how its probably working. Apply to the whole game, and you are getting the grasp about EvE is about Quote: Of course none of those features work in a POS that is the only practical place to do research anyway, Do you realize that anyone will locate your POS and come attack it ASAP now? Quote: for console gaming which allows them to avoid having to make these and other changes to the legacy code in EVE. That's quite sad indeed, but that's how software was made in the early days and there's no way back. Furthermore, EvE is not one of those games with limited lifespan where you can expect a "version 2" in few years that will bring in a complete re-engineering. Quote: There almost certainly IS a way to do it that wouldn't be terribly detrimental, however. It might be a little bit "hackish", but as other people have pointed out, when sorted the BPOs are always either first or last, which means there is probably some tiny piece of information in there that somehow differentiates them. If I can toss some garbage guesstimate, the BPO unique IDs have a lower value than the BPCs derived from them or they just appear in the physical database table before the BPCs (existing before they were created). Thus, when sorting the items, the criteria are applied to other properties like name etc and the creation ID just permeates and "survives" the sort so that the BPO ends up top in the sort sub-category. To see if this is true or false, you have to buy 1 BPO, make 1-2 BPCs, then buy another of the same BPO and sort them. If the second BPO appears after the BPCs, then the physical creation order or the unique IDs are playing a role. Quote: I see no reason why the game needs to make a new database query just because I choose to sort the items on a different attribute, it might as well be cached client side as long as the data didn't change Many operations are cached. Others must be flushed anyway at every warp, and that includes inventories / slots / jobs etc. - Auditing & consulting When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
Sarina Berghil Minmatar New Zion Judge Advocate Chained Reactions	Posted - 2010.03.19 16:14:00 - [78] Originally by: Vaerah Vahrokha Do you realize that anyone will locate your POS and come attack it ASAP now? Sounds like fun, can't wait. :P On the matter of database queries, it does not make sense to repeat the same query every time a minor change in the user interface happens, which is the case in the science and industry window. This is much more evident when a query takes several minutes to complete.
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 16:47:00 - [79] The common times I see such a query redone are when you warp in a new system. In that case the stuff needs recalculation. If you know of other cases... petition CCP, they love to remove uneeded database load on their servers. - Auditing & consulting When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
Celia Therone	Posted - 2010.03.19 18:02:00 - [80] Originally by: Venkul Mul Originally by: Celia Therone Client side cache blueprint id's and bpo status in a hash table? How many seconds before someone find how to change that T2 BPC to: 10.000 runs ME +1.000 PE +1.000? It is the same reason why all our stuff is listed on the server side: too easy to cheat otherwise. A client side cache would only effect the display of BPO/BPC (e.g. showing the bpo as green and the bpc as blue or adding an 'o' to the top right corner for bpos). The server side logic for using them would remain identical. Things like runs and ME probably wouldn't even be part of the cache to avoid client/server de-synch as much as possible.
Dasola Minmatar	Posted - 2010.03.19 19:25:00 - [81] Originally by: Robert Caldera Edited by: Robert Caldera on 17/03/2010 17:22:40 I'm getting mad every time I have to sort the fuggin BPO out of a bunch of BPC in hangars and POS divisions!!!! I dont care about technical backgrounds and explanations why things are broken currently, if you did it wrong, then simply fix it! Then why did you get them mixed in first place? It does ask when you copy the damn blueprint where you want copy to go to. As far as i have read how database at ccp works, its not really broken. Its just not impelemented becouse server load. Yes try imagine Microsoft SQL database handle even 5-10% more load. We even currently manage to get it all jammed up. What my alt corp does is, keep originals in one corp hanger, copies in another (where they are put immediatle after retrieved from lab site).
Robert Caldera	Posted - 2010.03.19 20:51:00 - [82] Edited by: Robert Caldera on 19/03/2010 20:52:06 Originally by: Sarina Berghil Of course none of those features work in a POS that is the only practical place to do research anyway, oh, wondered what he's talking about. Oh my.. Originally by: Susurrous 1. When I go to Science & Industry -> Corp Blueprints, I see a list of hundreds of corp blueprints, all with a tag COPY stating YES or NO. Clearly this tag is immediately available without any major overhaul. read the whole thread. It has been mentioned several times but S&I is useless for the main issue entirely Originally by: Tallaran Kouros I'm going to stop you here. No matter how smart you think you are or how good you are, CCP are smarter and know more. another CCP's advocate?? fck off Originally by:* SurrenderMonkey Yes - because it would require an additional join. one of how many thousands? so what? Do it... joining indexed tables is not that an issue actually. Or if you dont like joins for particular reasons, you introduce an redundant attribute, a common approach to mitigate consequences of heavily normalized schemas. Originally by: Vaerah Vahrokha Do you realize that anyone will locate your POS and come attack it ASAP now? you're kidding, arent you? POS is the easiest and actually the only practical way to research/invent. Originally by: Dasola Then why did you get them mixed in first place? It does ask when you copy the damn blueprint where you want copy to go to. by accident rolling eyes Its not the question WHY either...
SurrenderMonkey	Posted - 2010.03.19 21:08:00 - [83] Originally by: Robert Caldera Originally by: SurrenderMonkey Yes - because it would require an additional join. one of how many thousands? so what? Do it... joining indexed tables is not that an issue actually. Or if you dont like joins for particular reasons, you introduce an redundant attribute, a common approach to mitigate consequences of heavily normalized schemas. Lolwut? I sincerely doubt the query that's called for getting the inventory of anything in Eve involves more than a handful of joins. Certainly not thousands, or even hundreds, probably not even tens. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Darkaene	Posted - 2010.03.19 23:40:00 - [84] Originally by: Tellenta I fear the repercussions if CCP decides to try fixing some old code like that, jump gates won't work, guns won't fire, dogs and cats living together, MASS HYSTERIA!!! Yes it's true. The OP has no *****.
Vaerah Vahrokha Minmatar Vahrokh Consulting	Posted - 2010.03.19 23:48:00 - [85] Quote: you're kidding, arent you? POS is the easiest and actually the only practical way to research/invent. YOU are kidding, aren't you? The person admits using BPOs at a POS >_< - Auditing & consulting When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
Robert Caldera	Posted - 2010.03.20 10:06:00 - [86] Originally by: Vaerah Vahrokha YOU are kidding, aren't you? The person admits using BPOs at a POS >_< so what should happen in a high sec pos? Originally by: SurrenderMonkey Lolwut? I sincerely doubt the query that's called for getting the inventory of anything in Eve involves more than a handful of joins. Certainly not thousands, or even hundreds, probably not even tens. I meant overall joins in eve.
Sarina Berghil Minmatar New Zion Judge Advocate Chained Reactions	Posted - 2010.03.20 12:25:00 - [87] It seems this is a very controversial issue, some players' game experience will obviously be affected adversely by better user interface. Since Eve is a game of making workarounds when faced with user-unfriendly interface elements, the balance issues are so severe that having ancient and outdated dialogs, is an essential feature of the game. Just look at the LP store, if that was streamlined macro missioners would rule the Eve world, now they are forced to buy the crappy implants at the start of the list. For the same reason improving UI elements related to science and industry is out of the question, industrialists are of course carebears anyway who should burn in hell. /me Heads back to 'show info' on 200 BPCs...
Ishikari Gallente Duct Tape Inc.	Posted - 2010.03.20 14:26:00 - [88] Originally by: Robert Caldera Edited by: Robert Caldera on 18/03/2010 18:03:16 Originally by: Sir Bonkers I am at work atm, but I believe there is a drop down menu at the top of the window. Should have options; "Show all Blueprints", "Show Only Originals", "Show only Copies". That is from memory, so do not take it as 100% fact. yeah you're right but this does not help since there is no option to move the prints across divisions or see in which division they exactly are. the use of Science&Industry is of very limited use in this concern. hmm, try right clicking your print, it gives you the option of delivering to a different division or player.. been there for years.
Tyranus vonCarstein Bella Vista Holdings Corp	Posted - 2010.03.20 21:46:00 - [89] Originally by: Joe SMASH Originally by: Robert Caldera bull**! Stop quoting bull*! A simple flag cant be that hard to realize, the information is behind the BPC anyways if you look into item info. STOP QUOTING BULLSHT A CLUELESS DEV SAID ONCE!! Originally by: Jokiller Gerius A good workaround ... I dont want pesky workarounds, I want a FIX! Oooo... You must be one of those, 'If you do not agree with me, you are wrong' type of people.... /thread You may all stop posting now.
ZeeOhSix Blackwater Manufacturing and Logistics	Posted - 2010.03.20 22:48:00 - [90] Originally by: Robert Caldera Originally by: ZeeOhSix Goodness, but you're confused regarding the benefits of nomalization for high-transaction databases says who? go trolling somewhere else if you have no clue Says a 25 year DBA that's designed more high-transaction, large-scale databases than you've had zits - and that's saying something. You noted you were a DBA - what's your experience in designing large-scale transactional databases? Just name one. The troll, sir, is you claiming something is "simple" and making consistent mis-statements about how databases actually work. I suggest you go back to your Microsoft Access playtime and leave real database work to professionals The business of EVE is business!
Tellenta Gallente Invicta. Cry Havoc.	Posted - 2010.03.20 23:02:00 - [91] Originally by: Sarina Berghil Of course none of those features work in a POS that is the only practical place to do research anyway, just having a way to open a container inside a hangar would be awesome. Because then unusued blueprints could be put inside for safekeeping. Or simply letting us define more hangars than the global one-size fits all divisions of hangars across the known and unknown universe. There are tons of little changes that could make science and industry tolerable, but the only excuse seems to be that changing the database structure isnt viable. And if someone is going to tell me to solve UI bugs, by moving all POS'es to hi-sec and setup offices there, I am going to literally explode. Its ridiculous the amount of workarounds players go through, to fix IU issues that are trivial to improve upon. Doesn't have to be in hi-sec any region with a station will do. Quote: Scientific Networking Scientific Networking Skill at running research operations remotely. Each level increases the distance at which research projects can be started. Level 1 allows for range within the same solar system, Level 2 extends that range to systems within 5 jumps, and each subsequent level then doubles it. Level 5 allows for full regional range. If you want to continue being a full on idiot with your BPO's only to lose them all because you accidentily had a real life for a week and your POS ran out of fuel that is fine by me. Your counter-point about not having the BPO's in a station makes me think you are either uneducated on the lines of skills you can train, or just one more idiot like the OP that enjoys making blanket statements and crying like a baby when someone says "no". Quote: There are tons of little changes that could make science and industry tolerable, but the only excuse seems to be that changing the database structure isn't viable. your definition of excuse seems rather closer to the definition of a reason in this aspect. Of course I'll just be called a parrot or a troll because I am not toeing the OP's line. So in summary with a realists point of view. person: Hey CCP could you make a way to differentiate BPO's and BPC's CCP: we'd love to but it won't work with the way we have it coded, the only way to do it is if we re-wrote the code from scratch person: welp, Other person: OMG THAT IS NOT ACCEPTABLE I WANT A REFUND FOR THE TIME SPENT BECAUSE I SUCK AT ORGANIZATION OH GOD OH GOD CCP THIS IS ALL YOUR FAULT FIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOWFIXITNOW ANYONE THAT DISSAGREES WITH ANYTHING I SAY IS A STUPID DUMBHEAD BAWWWWWWWWW. I think I got it right.
Robert Caldera	Posted - 2010.03.21 11:22:00 - [92] Edited by: Robert Caldera on 21/03/2010 11:25:25 Originally by: ZeeOhSix Says a 25 year DBA that's designed more high-transaction, large-scale databases than you've had zits - and that's saying something. You noted you were a DBA - what's your experience in designing large-scale transactional databases? Just name one. yeah, and I am santa claus, c'mon, on an internet spaceships forum everybody can write what he likes to. I wont do it. Your 25 year DBA experience saying there is no way to get a simple attribute from a joined table lets look you like an idiot, tbh Originally by: ZeeOhSix The troll, sir, is you claiming something is "simple" and making consistent mis-statements about how databases actually work. so, what mis-statement? show me one. Originally by: ZeeOhSix I suggest you go back to your Microsoft Access playtime and leave real database work to professionals yeah, my master.
trollerii Mostly Harmless	Posted - 2010.03.21 11:34:00 - [93] what about coloring the BPC/BPO different? Or put a little tag on the image just like t2 loot has, with a small b or a c depending on what it is? -{Signature}- OvO -orly? hoot hoot m m
Paknac Queltel Standards and Practices	Posted - 2010.03.21 11:58:00 - [94] Originally by: Robert Caldera yeah, and I am santa claus, c'mon, on an internet spaceships forum everybody can write what he likes to. I wont do it. Your 25 year DBA experience saying there is no way to get a simple attribute from a joined table lets look you like an idiot, tbh Your lack of understanding the impact such a change has on a complex system like the EVE server infastructure makes you look like an idiot, tbh. All of us can explain, and explain again, but you knowing how to write a query on that MySQL you installed on your home PC blocks you from understanding the scaling problems somehow. I give up. Enjoy your ignorance.
Robert Caldera	Posted - 2010.03.21 12:04:00 - [95] Edited by: Robert Caldera on 21/03/2010 12:05:09 Originally by: Paknac Queltel Your lack of understanding the impact such a change has on a complex system like the EVE server infastructure makes you look like an idiot, tbh. yeah, actually eve couldnt work at all because its that complex, right? Its a miracle. Originally by: Paknac Queltel All of us can explain, and explain again, but you knowing how to write a query on that MySQL you installed on your home PC blocks you from understanding the scaling problems somehow. I give up. Enjoy your ignorance. lol you cant "explain" anything because you know a sh*t about the eve implementation as me too... so all we can do is discuss basics
Paknac Queltel Standards and Practices	Posted - 2010.03.21 12:38:00 - [96] Originally by: Robert Caldera Edited by: Robert Caldera on 21/03/2010 12:14:30 Originally by: Paknac Queltel Your lack of understanding the impact such a change has on a complex system like the EVE server infastructure makes you look like an idiot, tbh. yeah, actually eve couldnt work at all because its that complex, right? Its a miracle. Funny how people believe the BPO thing would be the last pinch pushing eve off the cliff into complete failure because of 0.00003% database load increase. Originally by: Paknac Queltel All of us can explain, and explain again, but you knowing how to write a query on that MySQL you installed on your home PC blocks you from understanding the scaling problems somehow. I give up. Enjoy your ignorance. sigh another dude guessing other peoples RL activities... you cant "explain" anything because you know a sh*t about the eve implementation as me too... so all we can do is discuss basics Hey, if you don't know anything about how EVE is implemented, that's your problem. Go read up on dev blogs and CCP Dev forum posts if you want to know. There's a thread with dev responses on why this is not all that simple linked on the first page. What's that? You don't want to know? HTFU and accept that it's not worth the trouble to implement this, then.
Dasola Minmatar	Posted - 2010.03.21 13:28:00 - [97] Originally by: Robert Caldera Funny how people believe the BPO thing would be the last pinch pushing eve off the cliff into complete failure because of 0.00003% database load increase. Hmm if you can estimate that eves database would be effect that much then you must be ccp database designer, go and fix what you broke. Seriously, its dangerous to make claims like that without knowing actyall stats about ccp's database. Are you sure it would be that minuscule effect? My bet is it would suddenly show guite a bit bigger effect then you are willing to admit. So can we kill you ingame if ccp makes change requested and it pushes database to unstable again?
Lord Fitz Project Amargosa	Posted - 2010.03.21 15:16:00 - [98] Edited by: Lord Fitz on 21/03/2010 15:17:49 If you think it's 0.00003%, you're just proving you have no idea. The load would be several orders of magnitude higher. The game would be unplayable, completely. On the other hand, there are already a multitude of solutions to the 'actual' rather than perceived problem, some that would work fine for you, and others that would work better for us. Quote: you cant "explain" anything because you know a sh*t about the eve implementation as me too... so all we can do is discuss basics CCP Provide a database export, it gives you a very good idea about the Eve implementation, assuming you understand what you're looking at.
Ghoest	Posted - 2010.03.21 15:52:00 - [99] BPOs/BPCs are just one aspect of how industry is broken with respect to corporations operating. The amount of meta-game organization required for a modest sized corp to allow many of its members to use corp industry/science facilities is insane. Its terrible game game design. Wherever you went - Here you are.
ZeeOhSix Blackwater Manufacturing and Logistics	Posted - 2010.03.21 18:59:00 - [100] sigh I guess I'll take one pass, haul ass for fun, but this really isn't very interesting. Just another wanna-be dev telling the pros they're stupid. Originally by: Robert Caldera saying there is no way to get a simple attribute from a joined table lets look you like an idiot, tbh This was not my statement, and the issue in question is not based on an attribute. Once again, you demonstrate that you simply don't understand high TPS relational databases. Originally by: Robert Caldera so, what mis-statement? show me one. highly normalized blaaaahhhhh... improperly/too much normalized if the database table definition does miss the purpose and makes basic things impossible!! This is just one, and the one that caught my eye initially as it demonstrates clearly you haven't done transactional DB work. Simple normalization, First normal form, is based on making "basic things" (queries) easy and avoiding data duplication. For high-transaction databases, this isn't enough as we need to be very aware of log overhead and dataset sizes. The purpose of this high level of normalization is performance, not ease of query. But this is all well beyond your ken; suffice to say that in terms of looking like an idiot - you're doing it right...just keep posting on the thread. Originally by: Robert Caldera yeah, my master. Outstanding; with that acknowledgement and recognition, my work here is done. The business of EVE is business!
Komi Toran	Posted - 2010.03.22 09:13:00 - [101] Database issues may prevent us from changing the icon on a BPC versus a BPO, but it doesn't mean that we cannot distinguish them in other ways. Allowing drag and drop from the S&I window would be a start, but S&I doesn't let you look in cans. What I think we need is a cross between an inventory tab and the S&I interface. Just as assembled ships are kept separate from a player's inventory, so would blueprints. Copies and BPOs would get their own separate playgrounds within this structure, so they'd be instantly distinguishable based on their location. I'd even like to see a way to consolidate those thousands of identical BPCs into a single entity for storage. This would mean that players would basically be allowed to merge and split BPCs at will, which probably breaks some balance I'm not that aware of (T2 production off invented BPCs, perhaps? Can't see that as being too major, really, as dedicated inventors have their production slots filled 24/7 anyway), and the system would be more complicated to accommodate variations in me/pe. Anyway, 'tis a dream I have, and will probably stay a dream for as long as I play Eve.
Matthew Caldari BloodStar Technologies	Posted - 2010.03.22 19:07:00 - [102] Originally by: Susurrous 1. When I go to Science & Industry -> Corp Blueprints, I see a list of hundreds of corp blueprints, all with a tag COPY stating YES or NO. Clearly this tag is immediately available without any major overhaul. You are right in that it can be retrieved, no-one is disputing that. The question is can it be retrieved in a way that generates a reasonably low load on the server? For the S&I window, the answer is yes for 2 reasons: 1) The S&I window is accessed much less frequently than hangar windows, lessening the impact of using a more complex query 2) My experience of the S&I window (especially on the corp blueprint side of things) is that the results are cached, which again limits the impact of using a more complex query. For the general hangar windows, the answer is no because neither of those two factors above apply. My favored solution to this whole issue would be to add full item-move capabilities into the S&I window. Yes, the caching may cause confusion on occasion, but as long as the error messages are sufficiently well-worded, this should not cause too much difficulty. Originally by: Susurrous 2. What it sounds like is the primary problem is that CCP can't at the moment have two different itemtypes produce the same item without a major overhaul. Is there, however, a reason why we couldn't have two different graphics on the same itemtype, based on that flag? e.g., overlay BPC onto the blueprint icon if it's a copy, or put a number with the runs remaining on it. The problem is that you would need some way of knowing whether the blueprint is a copy or not. The Copy:Yes/No field and the Number of Runs fields are both in the separate table that would be required to be joined in, which is what causes the problem with every idea along these lines. To boil it down: Hangars only know about the Item Type, and making separate Item Types for copies and originals breaks the S&I system. Any other way of differentiating copies and originals in the hangar would mean retrieving data from the separate item-instance-specific table, which generates too much load given how frequently hangars are queried. Originally by: Vaerah Vahrokha If I can toss some garbage guesstimate, the BPO unique IDs have a lower value than the BPCs derived from them or they just appear in the physical database table before the BPCs (existing before they were created). Thus, when sorting the items, the criteria are applied to other properties like name etc and the creation ID just permeates and "survives" the sort so that the BPO ends up top in the sort sub-category. You're kinda right, the only downside is that Item unique ID's do not last forever. Once an item is trashed and gone the ID will eventually get recycled (otherwise you'd just see insane bloat in the ItemUniqueID field). At least that's how it worked several years ago when TQ crashed because they hadn't freed up enough IDs. What this means is that your BPO is not guaranteed to have a lower ItemUniqueID than any copies made from it. However, working the probabilities, it is highly likely that a single job of copies (i.e. all delivered at the same time) will get ItemUniqueID values in a fairly similar range. Therefore, it is also highly likely that the ItemUniqueID of the BPO will be outside of that range. When you sort your hangar, ItemUniqueID is used to resolve ties in the sorting, hence, it is highly likely that your BPO will end up as either the first or the last blueprint. The problem is that while it is highly likely, it is not guaranteed, therefore you cannot base blueprint-flagging logic on it. It also tends to break down when you have copies of the same blueprint type from multiple different jobs. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Matthew Caldari BloodStar Technologies	Posted - 2010.03.22 19:15:00 - [103] Incidentally, if you find yourself in a position where the first/last trick doesn't work and you have a very large number of copies to cull, there is a way of using the S&I window to assist your search: 1) Take half of the blueprints and put them in a can (so they don't show in the S&I window) 2) View the remaining blueprints in the S&I window to quickly determine if the original is in the can or on your hangar floor. 3) Eliminate the half of your blueprints that you now know do not contain the original 4) Split the remaining blueprints half-and-half between the can and the hangar again 5) View in the S&I window (remembering to allow for the caching to update) 6).... Repeat until you've narrowed it down to a small number of potentials, then show info on each to find the original. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Paknac Queltel Standards and Practices	Posted - 2010.03.22 22:16:00 - [104] Originally by: Matthew Words proving that this guy knows his stuff. Excellent explanation. Here's hoping it won't fall on deaf ears. /me sits back and waits for the "idc CCP fix nao" crowd.
Robert Caldera	Posted - 2010.03.23 11:18:00 - [105] like I wrote before, i am not interested in workarounds but in a proper fix. - the S&I window is delayed - the S&I window is cached - the S&I window shows me sometimes nothing even if I am at 0 to the lab -> the S&I window is a pain to use and I have to do a lot of work only for differentiating what I actually have in my fuggin hangar! This is a broken game design. FIX IT! thxbai
Di Mulle	Posted - 2010.03.23 13:13:00 - [106] Thanks for good thoughts and explanations in this thread. As for the op, your constant attitude: Originally by: Robert Caldera like I wrote before, i am not interested in workarounds but in a proper fix. This is a broken game design. FIX IT! thxbai deserves the same attitude. Nobody is interested in your interests, thxbai.
SurrenderMonkey	Posted - 2010.03.23 14:32:00 - [107] Edited by: SurrenderMonkey on 23/03/2010 14:32:03 Originally by: Robert Caldera like I wrote before, i am not interested in workarounds but in a proper fix. - the S&I window is delayed - the S&I window is cached - the S&I window shows me sometimes nothing even if I am at 0 to the lab -> the S&I window is a pain to use and I have to do a lot of work only for differentiating what I actually have in my fuggin hangar! This is a broken game design. FIX IT! thxbai I want a score of large breasted swedish prostitutes to show up at my door bearing coffers full of gold. Looks like neither of us are going to get what we want. thxbai --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Lord Helghast	Posted - 2010.03.23 14:54:00 - [108] i never understood why original BP's dont send an extra octet "IM A ORIGINAL" and if that ssent it shows the original icon, if thats missing it shows copy icon, i mean honestly, is 1 boolean really going to kill the ccp servers?
Joe SMASH You Got A Purty Mouth	Posted - 2010.03.23 14:59:00 - [109] Quote: like I wrote before, i am not interested in workarounds but in a proper fix. - the S&I window is delayed - the S&I window is cached - the S&I window shows me sometimes nothing even if I am at 0 to the lab -> the S&I window is a pain to use and I have to do a lot of work only for differentiating what I actually have in my fuggin hangar! This is a broken game design. FIX IT! thxbai The mechanic is fine the way it is. If you refuse to use the tools CCP put into the game then why would CCP help you? Your constant whining is akin to complaining that you have no access to mass transit when there is a bus stop outside your door. Just because you refuse to use the bus, does not mean you do not have access to mass transit. Sure, the bus might be less glamorous and a bit smelly compared to the train, but it'll get you to where you need to go. Just like the S&I window (or even separate cans) will solve your problem. But you are too ignorant to use the tools given to you, so you whine incessantly about it like a 2 year old. Grow up. You will not always get your way. ----------------------------------- Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
SurrenderMonkey	Posted - 2010.03.23 15:06:00 - [110] Originally by: Lord Helghast i never understood why original BP's dont send an extra octet "IM A ORIGINAL" Really? Four pages later and you still don't? --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Linaeon	Posted - 2010.03.25 17:08:00 - [111] this discusion is going no where if u guys talking about ur databases bla bla bla, just find another solution. IF ur server is not strong enough buy a new one. 1 year double subscription fee :P BPC and BPO in same place is a headache.
Legende Two Brothers Mining Corp. R.A.G.E	Posted - 2010.03.25 19:15:00 - [112] I don't see why this is so hard for people to understand, databases are simple stuff. Currently, you open a station items/can/whatever and it runs a query that contains no item information, besides it's instanceID and typeID. What you are asking for is that a JOIN be added that will cause the query for those items to take more time and resources. This may be a small impact per user but could be a very very large impact on EVE as a whole with 30k+ users online at any given time. The real solution here is to create a new typeID for BPOs, give them a different icon background, and change all BPO items to use their new typeID ... this would be a rather large change but IMO would be well worth it to avoid the current issues at hand. Yes there are workarounds, but I too would prefer a fix.
Flitterby	Posted - 2010.03.25 22:05:00 - [113] I am hesitant to enter into this discussion, but I do know a bit about databases. I completely understand why CCP doesn't want to fetch instances for every inventory listing. However, they could make two special inventory tabs (hidden by default) that when accessed fetch either BPO or BPC. These queries are already being done in S&I interface... the OP just wants to be able to run them occasionally on containers. No one needs to run these queries allthetime on every container.
Di Mulle	Posted - 2010.03.25 23:40:00 - [114] Originally by: Legende The real solution here is to create a new typeID for BPOs, give them a different icon background, and change all BPO items to use their new typeID ... this would be a rather large change but IMO would be well worth it to avoid the current issues at hand. Yes there are workarounds, but I too would prefer a fix. Either i do no understand what you propose, or it should not work... As I understand, BPO's and BPC's are essentially the same thing. Only difference are their attributes, stored in separate table. Do you mean giving unique typeID for every possible BPC ? Think about possible number of combinations of ME, PE and runs... it would increase database thousands of times.
Psychotic Maniac Caldari Head Shrinkers	Posted - 2010.03.26 02:13:00 - [115] This problem made me regret even training an indy char. Even though I had 4 chars. doing research and selling the researched bpo and bpc for a 800m profit per month. I just hate having to lookup info. on hundreds of bp's that I gave it up. Took down my pos' and labs and sold them all. Will be selling my indy char. soon if I can't find a good corp./alliance to untilize his t2/cap building skills to the fullest.
Token Prophets	Posted - 2010.03.26 03:41:00 - [116] It's a pity the description could not be used to give the originals a gold glow or something similar.
Cyberman Mastermind	Posted - 2010.03.26 07:44:00 - [117] Originally by: Di Mulle Do you mean giving unique typeID for every possible BPC ? Other way around. Would probably double the disc storage blueprints require. And I suppose it won't work with the current system of making copies. Any way you look at it, the blueprint system isn't suited for how they are used in-game. Perhaps they thought BPCs wouldn't really be used, or that only a handful of people ever built stuff. I'm certain they never expected there to be that many BPOs and BPCs floating around. Still using this system would be stupid beyond belief.
Venkul Mul Gallente	Posted - 2010.03.26 10:48:00 - [118] Originally by: Legende I don't see why this is so hard for people to understand, databases are simple stuff. Currently, you open a station items/can/whatever and it runs a query that contains no item information, besides it's instanceID and typeID. What you are asking for is that a JOIN be added that will cause the query for those items to take more time and resources. This may be a small impact per user but could be a very very large impact on EVE as a whole with 30k+ users online at any given time. The real solution here is to create a new typeID for BPOs, give them a different icon background, and change all BPO items to use their new typeID ... this would be a rather large change but IMO would be well worth it to avoid the current issues at hand. Yes there are workarounds, but I too would prefer a fix. The problem is that it would require to change how production is made, as 2 different items could be used to produce the same item. That would require changes to the industry interface. Mess with reprocessing. And probably touch things like POS operations, invention, reverse engineering and stuff that has apparently nothing to do with BPO/BPC. Would be splendid if implemented, but apparently CCP opinion is that it would not be cost effective or that the risk of serious bugs is too high. We can only hope for a real industrial patch where all the issues about industry, research and so on would be addressed (for example the inability to share POS facilities within an alliance).
Sader Rykane Amarr Midnight Sentinels Midnight Space Syndicate	Posted - 2010.03.26 13:47:00 - [119] OP: Fix BPO's so they can be different from BPC. CCP: We can fix it but it will cause lag. OP: Fix it! This is the jist of your argument. So you WANT lag, so you can tell the difference between a BPO and a BPC easier? Sig Gallery is currently down: Contact me ingame for prices.
Dav Varan	Posted - 2010.03.26 15:03:00 - [120] The fix is so simple. Find the flaw in this logic if you can , I double dog dare you :) When a bpc copy is created , copy the value of number of runs from the attributes table to the stack size of the item in the inventory table. Stack size is currently always 0 for singleton items. So now do the following. Fetch the inventory table. No joins required. no change in table size of returned query. Item 1 ..... singleton [yes] stacksize[0] < this is a instanced object or BPO Item 2 ..... singleton [yes] stacksize[15] < this is a instanced bpc copy with 15 runs remaining Item 3 ..... singleton [no] stacksize[20] < this is 20 units of an item ( non instanced ) Item 4 ..... singleton [no] stacksize[0] < NOT USED ATM. My client can now add a Copy corner identifier ( similar to a t2 identifier ) to the corner of bpc's icon. Problem solved. No extra lag whatsoever. Because the query returning the inventory table does not need to change. The only things that need to change are the code on the client that interprets the returned query , Fairly trivial tbh. Of course I am not saying that there might not be bugs that need looking at.
Dav Varan	Posted - 2010.03.26 15:26:00 - [121] In fact I'm gonna go further and say this. If you do away with the number of runs attribute record and use the stack size in the inventory table exclusivelly for the number of runs. ^^ a bit more dev time for this, rewritting manufacturing queries etc. You get the following benifit. Currently query to insert a bpc require at a minimum 4 records returned from the db. Inventory Item. .. runs remaining attribute .. me attribute .. pe attribute This can be changed to returning only 3 records. Inventory Item with runs remaining stored in stacksize. .. me attribute .. pe attribute So not only does this fix fix the bpc/bpo issue it makes industry queries 25% faster too :) BPO/BPC issue resolved and less lag. Goddam I am good.
Matthew Caldari BloodStar Technologies	Posted - 2010.03.26 16:10:00 - [122] Originally by: Dav Varan Item 1 ..... singleton [yes] stacksize[0] < this is a instanced object or BPO Item 2 ..... singleton [yes] stacksize[15] < this is a instanced bpc copy with 15 runs remaining Item 3 ..... singleton [no] stacksize[20] < this is 20 units of an item ( non instanced ) Item 4 ..... singleton [no] stacksize[0] < NOT USED ATM. The main problem with this is that you are special-casing things into the inventory system, which is pretty much the most fundamental underlying system within the eve codebase. As such, it is high-risk to make any changes to it, as any change to the inventory system could potentially break any aspect of eve that uses it (i.e. everything). You would also have to revise all systems that require interfacing with blueprint copies (i.e. pretty much the entire S&I system, the Loyalty Point stores, loot drops...). Does it work? In theory and assuming the current table layout is as you assume, then yes. However, once you've looked at the work required to add the special-casing into the inventory system, re-do the entire S&I system to cope, and checked that neither of these have broken anything else, it should be obvious that this is not a trivial change to implement. It would probably be at least as much work as simply re-doing the S&I system to support multiple blueprint types producing the same item type. And that option has much less of a whiff of "dirty hack" about it. Originally by: Dav Varan So not only does this fix fix the bpc/bpo issue it makes industry queries 25% faster too Actually not. You are still having to retrieve me and pe in these queries, which means you still need to join the inventory table to the item-instance table. Performing this join is probably the majority of work involved in running the query. Whether you pull back 2 fields from the item-instance table or 3 will make very little difference. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Panjho	Posted - 2010.03.26 16:33:00 - [123] So, in order to differentiate between BPOs and BPCs we need two pieces of information: Type information, which is automatically retrieved when you look in your hangar, and Instance information, which is never retrieved by the hangar but can be retrieved by the S&I. Do I understand the problem correctly? If I have the facts wrong then don't bother reading the rest of the post. Well, from a computer scientist point of view, I don't see any need to modify any server code or change any database. The client has the capability to retrieve the information it needs to properly display BPOs and BPCs in the hangar. This is a fact. We can see that information in the S&I screen. So the information transfer from the server side to the client side is complete and functional. Thus, we can exclude the server side from any potential solution to the problem. Since it's just a client problem it should be trivial to solve using normal programming methods. Just off the top of my head I can see two obvious ways to do this. I'll share these ideas only to enforce my point that the server has nothing to do with the problem. I would expect that the actual solution would be more complicated due to legacy code issues. The simple solution would be to add a button to the hangar interface to fetch blueprint Instance information. Most of the code can be recycled from the S&I. This would require some screen real estate. If you can't free up the screen real estate then add the button to the right-click menu. The more technically complex solution would be to create a client side data structure that shares the Instance information retrieved by the S&I interface with the rest of the interface. This could be pretty nasty if the interface is multithreaded. But even in that case, it's certainly not in the realm of impossible.
Dav Varan	Posted - 2010.03.26 18:28:00 - [124] Originally by: Matthew The main problem with this is that you are special-casing things into the inventory system, which is pretty much the most fundamental underlying system within the eve codebase. As such, it is high-risk to make any changes to it, as any change to the inventory system could potentially break any aspect of eve that uses it (i.e. everything). The only routines that could be affected would be those routines that use the stacksize field. Other routine that use the inventory table but do not make use of the stacksize field would not be affected. We are not altering the database structure , we are mearly extending the usage of a currently existing field. It is an entirelly trivial process to identify those routines that require developer attention. Simply do a search of the sourcecode for the affected field. e.g. search all source files for invTypes.stacksize or whatever the field is called. If the devs ADE does not provide this functionallity then there are text editors available which do and cost $15 per licence. You only consider this fix a "Dirty Hack" because you are taking the meaning of the field in question far too literally. All values held by databases are entirelly arbitary. They only gain meaning through usage via programing. If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No one is saying it would not require work by devs to make it work. However it is allways less work to rewrite a few routines than to make major changes to database structure and then rewrite a few or possible every routine. Originally by: Matthew Performing this join is probably the majority of work involved in running the query. Whether you pull back 2 fields from the item-instance table or 3 will make very little difference. The me/pe/runs are held in seperate attributes records each with a specific attributetypeID not in a single attributes record Assuming well indexed records ( which they are ). Returning 3 records from a join takes 3/2 x longer than returning 2 records from a join.
Dav Varan	Posted - 2010.03.26 18:52:00 - [125] Originally by: Panjho So, in order to differentiate between BPOs and BPCs we need two pieces of information: Type information, which is automatically retrieved when you look in your hangar, and Instance information, which is never retrieved by the hangar but can be retrieved by the S&I. Do I understand the problem correctly? If I have the facts wrong then don't bother reading the rest of the post. Well, from a computer scientist point of view, I don't see any need to modify any server code or change any database. The client has the capability to retrieve the information it needs to properly display BPOs and BPCs in the hangar. This is a fact. We can see that information in the S&I screen. So the information transfer from the server side to the client side is complete and functional. Thus, we can exclude the server side from any potential solution to the problem. Since it's just a client problem it should be trivial to solve using normal programming methods. Just off the top of my head I can see two obvious ways to do this. I'll share these ideas only to enforce my point that the server has nothing to do with the problem. I would expect that the actual solution would be more complicated due to legacy code issues. The simple solution would be to add a button to the hangar interface to fetch blueprint Instance information. Most of the code can be recycled from the S&I. This would require some screen real estate. If you can't free up the screen real estate then add the button to the right-click menu. The more technically complex solution would be to create a client side data structure that shares the Instance information retrieved by the S&I interface with the rest of the interface. This could be pretty nasty if the interface is multithreaded. But even in that case, it's certainly not in the realm of impossible. What your saying is correct. The reason why CCP dont want to do it is database load. For each Blueprint you have in a location [hangar \| can \| ship] the client would have to run a query on tranquility asking for the instance attributes. Currently this only happens in the S/I interface which reduces database load as peops use it less often and only when they need to.
Celia Therone	Posted - 2010.03.27 02:54:00 - [126] Originally by: Dav Varan What your saying is correct. The reason why CCP dont want to do it is database load. For each Blueprint you have in a location [hangar \| can \| ship] the client would have to run a query on tranquility asking for the instance attributes. Currently this only happens in the S/I interface which reduces database load as peops use it less often and only when they need to. So cache the information on the client so you don't have to repeatedly query the database.
SurrenderMonkey	Posted - 2010.03.27 05:32:00 - [127] Edited by: SurrenderMonkey on 27/03/2010 05:32:20 Quote: If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No. Stacksize is an attribute of the table controlling inventory - it tells you how many of an item you have. BPC runs are an attribute of a BPC instance. You wouldn't put that information in an inventory table - it doesn't belong there in a normalized database. Ergo, dirty hack. It is really no different than the, "Hurr just denormalize the original/copy flag onto the inventory table!" solution. You're just using an existing field to act as the flag field instead of creating a new one, which might be fine if the act of creating a new field were somehow the barrier here, but it's not - the problem is that the information just doesn't belong on that table. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Dav Varan	Posted - 2010.03.28 15:30:00 - [128] Originally by: SurrenderMonkey Edited by: SurrenderMonkey on 27/03/2010 05:44:57 Quote: If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No. Stacksize is an attribute of the table controlling inventory - it tells you how many of an item you have. BPC runs are an attribute of a BPC instance. You wouldn't put that information in an inventory table - it doesn't belong there in a normalized database. Ergo, dirty hack. Yes the current situation is the field is called stacksize. You havnt answered the retort abuot renaming the field have you!. But anyways its rather irrelevant what the field is called to the working of the database , the database doesnt understand what stacksize or stacksizenBPCruns stands for anyway. Field naming is only for the convienience of programers. Quite clearly you are wrong about the normalisation level required here. Most importantly for this particular set of information is the speed with which it can be returned from the database. And some flag or other be it bpc runs or something else to distinguish bpc from bpo needs to be in the first table so that it can be returned without using a join. This is the correct level of normalisation for this item of information. Originally by: SurrenderMonkey It would probably work, but they clearly have a hardon for normalization, and this is really no different than the, "Hurr just denormalize the original/copy flag onto the inventory table!" solution. You're just using an existing field to act as the flag field instead of creating a new one, which might be fine if the act of creating a new field were somehow the barrier here, but it's not - the problem is that the information just doesn't belong on that table. CCP have stated that they will not add an addition field to the inventory table as it would have to be returned for all items in an inventory request. This increases the bandwidth requirements between database servers and sol nodes and between sol nodes and the client. Utilising an existing field on the first table adds no bandwidth requiremnts between any of the components it also adds no extra load on the dbe by doing unnecessary joins. This solution is more computationaly efficent than other proposed solutions. In fact as stated if Stacksize were used to represent bpc runs fully and the attributetype for bpc runs were dropped. Not only would we have a solution for the BPC/BPO issue but overall load on the dbe would reduce , hence less lag. This is not a "dirty hack" this is "pure genius".
SurrenderMonkey	Posted - 2010.03.29 14:14:00 - [129] Edited by: SurrenderMonkey on 29/03/2010 14:15:35 Originally by: Dav Varan Originally by: SurrenderMonkey Edited by: SurrenderMonkey on 27/03/2010 05:44:57 Quote: If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No. Stacksize is an attribute of the table controlling inventory - it tells you how many of an item you have. BPC runs are an attribute of a BPC instance. You wouldn't put that information in an inventory table - it doesn't belong there in a normalized database. Ergo, dirty hack. Yes the current situation is the field is called stacksize. You havnt answered the retort abuot renaming the field have you!. But anyways its rather irrelevant what the field is called to the working of the database , the database doesnt understand what stacksize or stacksizenBPCruns stands for anyway. Actually, I have. What you're not grasping is that it isn't about the field name, it's about how the tables are normalized. They wouldn't put that information there - nor name the field that way - because that particular piece of information does not belong on that table in a perfectly normalized database. With regard to normalization, your solution has NO functional difference between adding a bit flag field to the inventory. So, one more time, let me bold it for you this go 'round, maybe it'll stick: It has nothing to do with the name of the field. It is a normalization issue. Quote: CCP have stated that they will not add an addition field to the inventory table as it would have to be returned for all items in an inventory request. This increases the bandwidth requirements between database servers and sol nodes and between sol nodes and the client. No. You have some wires crossed. They will not denormalize the database. It doesn't matter if they denormalize it by adding an additional field, or denormalize it by using an existing one. Functionally identical. Both solutions result in a less-normal-than-present database structure. They will ALSO not add an additional join because of the increased bandwidth and CPU load. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Dav Varan	Posted - 2010.03.29 16:17:00 - [130] Originally by: SurrenderMonkey Edited by: SurrenderMonkey on 27/03/2010 05:44:57 Quote: If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No. Stacksize is an attribute of the table controlling inventory - it tells you how many of an item you have. BPC runs are an attribute of a BPC instance. You wouldn't put that information in an inventory table - it doesn't belong there in a normalized database. Ergo, dirty hack. It would probably work, but they clearly have a hardon for normalization, and this is really no different than the, "Hurr just denormalize the original/copy flag onto the inventory table!" solution. You're just using an existing field to act as the flag field instead of creating a new one, which might be fine if the act of creating a new field were somehow the barrier here, but it's not - the problem is that the information just doesn't belong on that table. So having a Stacksize parameter sometime used and sometime not used on the Inv (first) table is what you consider "perfectly normalised" But having a bpcruns parameter sometime used and sometime not used on the Inv (first) table is what you consider "not perfectly normalised" Please explain!
SurrenderMonkey	Posted - 2010.03.29 17:41:00 - [131] Edited by: SurrenderMonkey on 29/03/2010 17:41:33 Originally by: Dav Varan Originally by: SurrenderMonkey Edited by: SurrenderMonkey on 27/03/2010 05:44:57 Quote: If the field were renamed "StackSizeOrBpcRuns" it would change from being a dirty hack to being 100% legitimate ? No. Stacksize is an attribute of the table controlling inventory - it tells you how many of an item you have. BPC runs are an attribute of a BPC instance. You wouldn't put that information in an inventory table - it doesn't belong there in a normalized database. Ergo, dirty hack. It would probably work, but they clearly have a hardon for normalization, and this is really no different than the, "Hurr just denormalize the original/copy flag onto the inventory table!" solution. You're just using an existing field to act as the flag field instead of creating a new one, which might be fine if the act of creating a new field were somehow the barrier here, but it's not - the problem is that the information just doesn't belong on that table. So having a Stacksize parameter sometime used and sometime not used on the Inv (first) table is what you consider "perfectly normalised" But having a bpcruns parameter sometime used and sometime not used on the Inv (first) table is what you consider "not perfectly normalised" Please explain! Well, let's start with the basics. First of all, you're making a lot of assumptions about their database design that, in reality, you know approximately ***-all about, but we'll nevermind that for now. Secondly... It isn't really a matter of whether or not it's "sometimes used" and "sometimes not used" (though avoiding unnecessary nulls is always good). It's a matter of where the information actually belongs. The information regarding the number of runs is a trait of a specific instance of a blueprint thus, it logically belongs in the table storing the information about that specific instance of the blueprint. Stacksize, by contrast, is a measure of a quantity of the number of instances* of an item. How many of an item you have is, obviously, a trait that belongs to the inventory table. I realize the difference is subtle, but it IS there. Runs are a quantity of runs on a SINGLE item. Stacksize is a quantity of INSTANCES of a single item TYPE. Very, very different. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Dav Varan	Posted - 2010.03.29 18:24:00 - [132] Originally by: SurrenderMonkey Well, let's start with the basics. First of all, you're making a lot of assumptions about their database design that, in reality, you know approximately copulation-all about, but we'll nevermind that for now. No assumptions are neccessary. Ccp kindly give us there database structure through the data dump and the evi api. Originally by: SurrenderMonkey Secondly... It isn't really a matter of whether or not it's "sometimes used" and "sometimes not used" (though avoiding unnecessary nulls is always good). It's a matter of where the information actually belongs. The information regarding the number of runs is a trait of a specific instance of a blueprint thus, it logically belongs in the table storing the information about that specific instance of the blueprint. Stacksize, by contrast, is a measure of a quantity of the number of instances of an item. How many of an item you have is, obviously, a trait that belongs to the inventory table. I realize the difference is subtle, but it IS there. Runs are a quantity of runs on a SINGLE item. Stacksize is a quantity of INSTANCES of a single item TYPE. Very, very different. You are becoming confused even if only in the terminolagy you are using. Stacksize is not applied against Instances ( items that have been assembled ). Stacksize is only applied to non-instanced item types. The Inventory table contains 2 types of entity. 1) An instanced entity. Flag singleton is set Stacksize = 0 Has a unique ItemID 2) non instanced entity. Flag singleton is not set Stacksize > 0 Does not have a unique ItemID. Now this is one big dirty hack as it is. A single table containing what are essentially 2 completelly different types of things. It contains singleton items with properties and it contains stacks of things of a certain type. The only field common to the two types of entity is typeID. If the EveDB followed any published form of normalisation I'm pretty sure that Invtable breaks those rules. You do not put different entity types in the same table in a normallised DB. The reason it is done like this has nothing to do with the pursuit of normalisation. The reason they do this ( have non-instanced stacks and instanced items ( constructed with parameters )) in the same table has everything to do with query performance. If invtable were a normalised table it would have to have subtables for stacks and instances. Back to your inconsistant arguements. Stacksize is a parameter of a stack of items. BPC runs is a parameter of a bpc copy. If we are to use the same form of normalisation for both. Then either both should be in the first table or both should be in a parameters subtable.
SurrenderMonkey	Posted - 2010.03.29 18:40:00 - [133] Originally by: Dav Varan I read poorly. You're toootally right, Dav. Your idea is sheer brilliance. Brilliance, I say! It's a wonder CCP hasn't hired you yet. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp
Dav Varan	Posted - 2010.03.29 18:46:00 - [134] Originally by: SurrenderMonkey Originally by: Dav Varan I read poorly. You're toootally right, Dav. Your idea is sheer brilliance. Brilliance, I say! It's a wonder CCP hasn't hired you yet. They couldn't afford me.
Namdor Amarr Section 3	Posted - 2010.03.29 18:53:00 - [135] This whole complaint seems really petty. You can do ALMOST everything you could ever want to do with a BP - including move it around - from S&I.
Robert Caldera	Posted - 2010.03.31 08:47:00 - [136] Originally by: Panjho So, in order to differentiate between BPOs and BPCs we need two pieces of information: Type information, which is automatically retrieved when you look in your hangar, and Instance information, which is never retrieved by the hangar but can be retrieved by the S&I. bla.. I cant hear this crap anymore... You always have to fetch the "instance", how would you else know if there is its type to show?? but actually, this discussion is pointless because its invaded by a bunch of nerds advocating CCPs "normalization"-excuses at all extents for some curious reasons.
Namdor Amarr Section 3	Posted - 2010.03.31 18:10:00 - [137] Originally by: Robert Caldera Originally by: Panjho So, in order to differentiate between BPOs and BPCs we need two pieces of information: Type information, which is automatically retrieved when you look in your hangar, and Instance information, which is never retrieved by the hangar but can be retrieved by the S&I. bla.. I cant hear this crap anymore... You always have to fetch the "instance", how would you else know if there is its type to show?? but actually, this discussion is pointless because its invaded by a bunch of nerds advocating CCPs "normalization"-excuses at all extents for some curious reasons. What, specifically, is it that you're trying to do that CANNOT be done with the S&I window? Things you can do with S&I: -Locate BPs -Distinguish BPOs from BPCs, both at a glance and through the use of filters -Move BPs around There's very little that one could ever need to do with regard to organizing their BPs that CANNOT be done with S&I. It would be nice if the ability to move them could be streamlined a bit (drag and drop, shift-click, etc.), but the basic functionality is all there already.
Robert Caldera	Posted - 2010.03.31 18:36:00 - [138] - you CAN'T move BPs within a POS!! - S&I window sometimes shows nothing - its delayed - its cached its just crappy!
Namdor Amarr Section 3	Posted - 2010.03.31 18:49:00 - [139] Edited by: Namdor on 31/03/2010 18:50:34 Originally by: Robert Caldera - you CAN'T move BPs within a POS!! This gets a big old "So what?" from me. On the off chance that you actually have a BPO in a POS, AND you get it mixed into the rest, it should not be hard to fix. If you do this frequently enough for it to be a nuisance, you should probably consider a less strenuous hobby, like playing with bits of string. Quote: - S&I window sometimes shows nothing I've seen this happen, but I've always been able to attribute it to some networking issue. I've had blank hangars from the same cause. Quote: - its delayed - its cached In my experience, this is pretty much bupkis, despite what the window claims. If I have S&I open to Corp BPs and I, for instance, move a BP from my corporate hanger to my private hangar, S&I immediately updates itself, even if I use the hangar interface to make the move (as opposed to the S&I interface). That aside, though, did you ever stop to think about WHY it's delayed? You do understand that it's essentially a query calling the same information that you are requesting for generic inventory displays, right? And they (supposedly) opted to put a delay on it. ...hm... ...I wonder why they did that?
Robert Caldera	Posted - 2010.04.01 13:45:00 - [140] Edited by: Robert Caldera on 01/04/2010 13:46:50 Originally by: Namdor This gets a big old "So what?" from me. "so what"? I've merely answered your question. Originally by: Namdor I've seen this happen, but I've always been able to attribute it to some networking issue. I've had blank hangars from the same cause. no, for me it was blank despite working network. Any further discussion about the broken S&I window is useless because I simply dont want it but requesting a proper implementation for all that instead, which is less pain in the a*s as it's now.
Namdor Amarr Section 3	Posted - 2010.04.01 13:56:00 - [141] Originally by: Robert Caldera Any further discussion about the broken S&I window is useless because I'm basically just throwing a tantrum. Loud and clear.
Robert Caldera	Posted - 2010.04.01 14:11:00 - [142] Edited by: Robert Caldera on 01/04/2010 14:13:33 I'm simply requesting a fix for stuff; I did not ask for tips about pesky workarounds which are nearly as much pain in the butt as the problem itself and which I've even denied explicitly multiple times already in this thread, so stop telling me 'bout it finally.
Di Mulle	Posted - 2010.04.01 15:19:00 - [143] Originally by: Robert Caldera Edited by: Robert Caldera on 01/04/2010 14:13:33 I'm simply requesting a fix for stuff; OK, you requested and that was only thing you wanted to do. Now patiently wait, this is only thing you need to do.
Token Prophets	Posted - 2010.04.01 22:23:00 - [144] Originally by: Token Prophets It's a pity the description could not be used to give the originals a gold glow or something similar. Further to the above I wonder if CCP could release in the next patch a sorta client side mod that would use the descriptions of the BPO's and BPC's to change their colour one way or another. As the server doesn't care about the difference this would only be a local change, shouldn't effect server lag as it's all local and could be a solution for many people.
Robert Caldera	Posted - 2010.04.01 22:45:00 - [145] Originally by: Token Prophets Originally by: Token Prophets It's a pity the description could not be used to give the originals a gold glow or something similar. Further to the above I wonder if CCP could release in the next patch a sorta client side mod that would use the descriptions of the BPO's and BPC's to change their colour one way or another. As the server doesn't care about the difference this would only be a local change, shouldn't effect server lag as it's all local and could be a solution for many people. you still have to get BP infos, doing it on the client will probably result in even more lag due to the network overhead for each single query as if they implement this in the cluster and transmit the data to the client once per hangar showing.
Ruziel Minmatar Twilight Military Industrial Complex	Posted - 2010.04.01 22:45:00 - [146] Originally by: Token Prophets Originally by: Token Prophets It's a pity the description could not be used to give the originals a gold glow or something similar. Further to the above I wonder if CCP could release in the next patch a sorta client side mod that would use the descriptions of the BPO's and BPC's to change their colour one way or another. As the server doesn't care about the difference this would only be a local change, shouldn't effect server lag as it's all local and could be a solution for many people. The problem with this is that the infomation to distinguish one from the other, does not exist when you open a hangar or container. As has been explained in this thread, the only information the client gets when loading a hangar or container is the item type ID, the quantity, and if it's packaged or not. The reason only this information is provided is because a) it is information common to all item types and b) all contained within the inventory table in the DB. To get any additional information about the items, you have to do more complicated queries, which incurs a additional load on the database server, which CCP has deemed unacceptable. Now, you may be thinking that additional information shows up when you do a Show Info on an item. Indeed it does. But in this case, the overhead of making more complicated queries by joining the inventory table with wherever tables they store this additional information in is deemed acceptable because it applies to a single item at a time, not the hundreds or thousands of items.
jerusik	Posted - 2010.04.02 04:02:00 - [147] Originally by: Di Mulle Now patiently wait, this is only thing you need to do. Something might freeze over before then... But think positive!
Napro Caldari Buccaneers of New Eden death from above..	Posted - 2010.04.02 11:01:00 - [148] Edited by: Napro on 02/04/2010 11:04:51 Originally by: NeoFusion Edited by: NeoFusion on 18/03/2010 14:49:44 The second way would be to create a separate 'type' of blueprint, one for the original, one for the copy so they would be completely different. I.e. this is of type 'Megathron BPO' and this is of type 'Megathron BPC', but CCP have already stated that this would need a complete rewrite of the scientific and industrial portion of the game, a massive undertaking probably taking months and months, just to get a blueprint a specific colour. There are more important things I'm afraid. - Neo How would this need a complete rewrite of code? Why cant you just have two copies of the BPO class.. BPO1 for BPOs and BPO2 (Same exact properties and methods as BPO1) for BPCs? It would function the exact same way now it'd just be labeled as a BPO2 Type and the Client would identify it as such. Class BPO; Class BPO1 inherits BPO //For Original Blueprints, exact same code we have today Class BPO2 inherits BPO //For Blueprint Copies, exact same code as above Client Side: If Type is BPO1 then Color = Blue If Type is BPO2 then Color = Green If there server code is properly OOP'd then there would be no way for it to distinguish between BPO2 and BPO1, which would mean no omg massive rewrite of server code. What am i missing?
Paknac Queltel Standards and Practices	Posted - 2010.04.02 15:09:00 - [149] Originally by: Napro Edited by: Napro on 02/04/2010 11:17:15 Edited by: Napro on 02/04/2010 11:12:34 Edited by: Napro on 02/04/2010 11:08:32 Edited by: Napro on 02/04/2010 11:04:51 Originally by: NeoFusion Edited by: NeoFusion on 18/03/2010 14:49:44 The second way would be to create a separate 'type' of blueprint, one for the original, one for the copy so they would be completely different. I.e. this is of type 'Megathron BPO' and this is of type 'Megathron BPC', but CCP have already stated that this would need a complete rewrite of the scientific and industrial portion of the game, a massive undertaking probably taking months and months, just to get a blueprint a specific colour. There are more important things I'm afraid. - Neo How would this need a complete rewrite of code? Why cant you just have two copies of the BPO class.. BPO1 for BPOs and BPO2 (Same exact properties and methods as BPO1) for BPCs? It would function the exact same way now it'd just be labeled as a BPO2 Type and the Client would identify it as such. Class BPOBase; Class BPO inherits BPOBase //For Original Blueprints, exact same code we have today Class BPC inherits BPOBase //For Blueprint Copies, exact same code as above Client Side: If Type is BPO then Color = Blue If Type is BPC then Color = Green If there server code is properly OOP'd then there would be no way for it to distinguish between BPC and BPO, which would mean no omg massive rewrite of server code. What am i missing? Edit: Nevermind, I can see the rewrite needed when Labs start outputting BPO but that does not seem like much of a massive overhaul, IMO. Inputting somewhere if # of runs <> 0 then output = BPC; doesnt seem very big at least You're missing the part where we're all talking about the database, and not about creating classes for things that don't need classes. The database structure right now requires there to be exactly one typeID for a manufacturable item. As such, to do the BPO/BPC itemID thing NeoFusion is talking about, they'd have to either add another column for BPC typeIDs or allow multiple entries into whatever table tracks manufacturable-to-BP, then walk through all the code that deals with that table to work with that. Then, all that has to be tested, reviewed for possible exploits and the works. Btw, your failing structure requires 3 classes for something that can be done in 1 class, with 1 property.
Napro Caldari Buccaneers of New Eden death from above..	Posted - 2010.04.02 23:57:00 - [150] Originally by: Paknac Queltel Btw, your failing structure requires 3 classes for something that can be done in 1 class, with 1 property. Except that your solution would require rewrites of server code.. which is what I was avoiding..
Robert Caldera	Posted - 2010.04.03 13:08:00 - [151] If the game design is bad, it has to be re-worked. The human kind has solved a lot of harder problems than coloring BPC/BPO differently.
Kerfira Audaces Fortuna Iuvat	Posted - 2010.04.03 14:12:00 - [152] Originally by: Robert Caldera If the game design is bad, it has to be re-worked. The human kind has solved a lot of harder problems than coloring BPC/BPO differently. True, and much more important ones too.... ...same with the EVE devs.... On a totally different subject, whiney brats shouldn't be allowed to post on the internet... Originally by: CCP Wrangler EVE isn't designed to just look like a cold, dark and harsh world, it's designed to be a cold, dark and harsh world.
SurrenderMonkey	Posted - 2010.04.03 17:01:00 - [153] Edited by: SurrenderMonkey on 03/04/2010 17:01:37 Originally by: Robert Caldera If the game design is bad, it has to be re-worked. The human kind has solved a lot of harder problems than coloring BPC/BPO differently. I'm pretty sure, at this point, that making you whine like a little girl with a skinned knee is a feature. --------------- Faction-Militia:Player-Alliance::Newbie-corp:Player-corp

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