| Pages: 1 2 3 [4] 5 6 :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

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 *all*the*time* 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.
|
| |
|
| Pages: 1 2 3 [4] 5 6 :: one page |
| First page | Previous page | Next page | Last page |