open All Channels
seplocked Features and Ideas Discussion
blankseplocked Make BPOs visually distinctive from copies
 
This thread is older than 90 days and has been locked due to inactivity.


 
Author Topic

Inspiration
Posted - 2009.12.27 13:49:00 - [1]
 

This one has bothered me for an eternity now...

Simple change the border color of a BPC or do as with T2 and T3 stuff, project a stamp over the BPC (reading copy).
Then you can instantly spot if a blueprint is a copy or not.

Serge Bastana
Gallente
GWA Corp
Posted - 2009.12.27 14:11:00 - [2]
 

Been through this one countless times Commonly Proposed Ideas sticky

Inspiration
Posted - 2009.12.27 14:27:00 - [3]
 

Quoting CCP Lingorm on the issue:

"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."

Well I happen to know SQL Server quite well, and he might make a mistake here. Indeed a fixed join would be too costly, but a conditional subselect would do the trick as well and not cause overhead for EVERY item in the database as long as you know the item in question is a blueprint of some sort.

select
i.ID
, i.SomeData
, i.IsBluePrint
, case
when i.IsBluePrint = 0 then null
else ( select d.IsBPC from dbo.Differential as d where d.ID = i.ID )
end as isBPC
from
dbo.Inventory as i
;

Something like the above...the key is to know when to do the lookup, if there is anything even remotely reliable like a visual representation field in the Inventory table, just re-arrange the IDs next major patch so you can work with ID ranges and test on the range and your are set :).

So CCP please explore this avenue....you make many people happy and yourself too :)

Serge Bastana
Gallente
GWA Corp
Posted - 2009.12.27 14:32:00 - [4]
 

It would be incredibly useful to have them distinguished from each other, but 2 points:

1: When you open a hangar or can with dozens of blueprints in, it will be similar to opening your bookmarks list in P&P, a fair bit of lag as the client has to drag the information required for each blueprint to be able to mark it as original or copy.

2: The reason I posted the commonly proposed sticky was so you could post in that thread instead of keeping yet another one on this subject going Razz

If it can be done with minimum drag on the client/server data communication then perhaps its time to update the DB and give us a little more info on our blueprints.

Inspiration
Posted - 2009.12.27 14:37:00 - [5]
 

Edited by: Inspiration on 27/12/2009 14:40:52
Edited by: Inspiration on 27/12/2009 14:36:55
Originally by: Serge Bastana
It would be incredibly useful to have them distinguished from each other, but 2 points:

1: When you open a hangar or can with dozens of blueprints in, it will be similar to opening your bookmarks list in P&P, a fair bit of lag as the client has to drag the information required for each blueprint to be able to mark it as original or copy.

2: The reason I posted the commonly proposed sticky was so you could post in that thread instead of keeping yet another one on this subject going Razz

If it can be done with minimum drag on the client/server data communication then perhaps its time to update the DB and give us a little more info on our blueprints.


I wish I could post there m8, but it is locked...it seems they given up...stuck in the mindset of having to join for every item in the Inventory table where in fact that is not the case if you know your SQL a bit more. I can only hope he dev guys read this one and get a eureka moment :)

As for lag in P&P..it is not the client that would need to so that. Some of the normalized away attributes in the Inventory table can standard be returned by sub-selects as I have shown with some example SQL. The client would not know any better then these attributes were stored in the Inventory table as it gets them always. It is SQL Servers end the DEVs job to get the data as efficiently as possible. BPCs are quite rare among the total inventory of every player (even a researcher). The sub-select should have no noticeable performance impact whatsoever for the end user.

Pan Dora
Caldari
Organization for Nuclear Research
Posted - 2009.12.27 15:25:00 - [6]
 

Originally by: Inspiration

Well I happen to know SQL Server quite well, and he might make a mistake here. Indeed a fixed join would be too costly, but a conditional subselect would do the trick as well and not cause overhead for EVERY item in the database as long as you know the item in question is a blueprint of some sort.

[example]




Sorry, but this look to me like posting "hello word" and say that programing its simple.


Breaker77
Gallente
Reclamation Industries
Posted - 2009.12.27 15:28:00 - [7]
 

Originally by: Inspiration
BPCs are quite rare among the total inventory of every player (even a researcher). The sub-select should have no noticeable performance impact whatsoever for the end user.


I blow through upwards of 300 to 400 BPCs on an average day and my BPO collection is somewhere about 500 to 600. It's bad enough waiting for my corp hangers to load now and I keep everything seperated out all nice and neat.

Serge Bastana
Gallente
GWA Corp
Posted - 2009.12.27 15:36:00 - [8]
 

Edited by: Serge Bastana on 27/12/2009 15:37:31
Knowing something about SQL I have some idea how much data a join would need to sift through just for a few dozen blueprints, when you get into a situation like Breaker's where you are opening a hangar with hundreds of them, then that amount of information that would cause the client to lag quite a bit.

At the moment CCP uses a template for all blueprints and the item specific information is only fed to the client for each individual blueprint that you show info for. A similar join would be required just for the one fragment of data that specifies if it's a copy or original, and considering that you could be looking at several hundred, if not thousands when opening a hangar or can, it's just not efficient data wise using the current normalisation methods.

Think how the client stalls when opening the market or getting show info on characters sometimes and consider how long you would want to wait for your client while it was communicating with the server for the stored procedure to finish executing. One simple join could cause a lot of lag in its execution.

Inspiration
Posted - 2009.12.27 17:00:00 - [9]
 

Originally by: Pan Dora
Originally by: Inspiration

Well I happen to know SQL Server quite well, and he might make a mistake here. Indeed a fixed join would be too costly, but a conditional subselect would do the trick as well and not cause overhead for EVERY item in the database as long as you know the item in question is a blueprint of some sort.

[example]




Sorry, but this look to me like posting "hello word" and say that programing its simple.




Then you don't understand a word of it...know your tools, there can be huge differences in efficiency (magnified by data volume) between different SQL statements that are seemingly functional identical and give the desired result. But are in fact slightly different in what you demand from the server and as such you get different execution plans. A join is always made....a sub-select is an expression, not a statement and is governed by different rules.

For example...if you have a view with a sub-select that produces attribute x, and the select that operates on that view does not request attribute x, it will have SQL Server generate a plan completely without that sub-select.
Do the same with a join and the join is made regardless.

Similarly for a sub-select in an conditional expression, it is only executed when it is needed (unlike a join). I gave the example for a purpose, sorry you did not understand it. If you have access to a test case or you can provide scripts to me that generate a test case with sufficient data, I will demonstrate the differences. It can sometimes reduce minutes of execution time in a seemingly perfect statement to just a few milliseconds. There are more related tricks that can have a similar impact, but those only work in some rare cases.

The reason i picked up on this, is the way the DEV formulated his statements, referring them as join repeatedly. And since the finer details of SQL behavior are not well known among developers in general, nor many DBA's in fact, I pointed the above facts out, hoping that CCP spends some time testing it on their data and architecture.

I would do it for free if I had a script that generates a good test case..meaning representative test data, correct table structure and the same indexes and statistics.

Inspiration
Posted - 2009.12.27 17:13:00 - [10]
 

Edited by: Inspiration on 27/12/2009 17:17:02
Originally by: Serge Bastana
Edited by: Serge Bastana on 27/12/2009 15:37:31
Knowing something about SQL I have some idea how much data a join would need to sift through just for a few dozen blueprints, when you get into a situation like Breaker's where you are opening a hangar with hundreds of them, then that amount of information that would cause the client to lag quite a bit.

At the moment CCP uses a template for all blueprints and the item specific information is only fed to the client for each individual blueprint that you show info for. A similar join would be required just for the one fragment of data that specifies if it's a copy or original, and considering that you could be looking at several hundred, if not thousands when opening a hangar or can, it's just not efficient data wise using the current normalisation methods.

Think how the client stalls when opening the market or getting show info on characters sometimes and consider how long you would want to wait for your client while it was communicating with the server for the stored procedure to finish executing. One simple join could cause a lot of lag in its execution.



Think set based when you deal with SQL, execution delay for one item has some lookup costs, but if you do it for 20 or 30 or more in one statement, that costs does increase only slightly...it does not go up linearly. I know this as I deal with these things on a daily basis myself. Just stop thinking of SQL like it is a loop like you do in regular programming. And what I propose doesn't even involve a join in the regular sense...it is free as long as you don't have blueprints to begin with. If you do, it provides additional useful data at low cost.

A client would not lag more then it does now, it might get the data a few ms later but then its just as fast as it is today and saves you the hassle of checking blueprints manually.
Graphics wise they can project an image over current graphics, just like they do for the T2 and T3 corners of items (as is sometimes obvious when scrolling).

Yarik Mendel
Amarr
Red Horizon Inc
Cascade Imminent
Posted - 2009.12.27 17:23:00 - [11]
 

Edited by: Yarik Mendel on 27/12/2009 17:24:33
How about just get rid of BPC and voila problem solved, and higher risk and profit in manufacturing sector.

edit: invention; you need bpo but can't lose bpo if process fail.

Inspiration
Posted - 2009.12.27 17:27:00 - [12]
 

Originally by: Yarik Mendel
Edited by: Yarik Mendel on 27/12/2009 17:24:33
How about just get rid of BPC and voila problem solved, and higher risk and profit in manufacturing sector.

edit: invention; you need bpo but can't lose bpo if process fail.


I seriously doubt CCP will even consider that suggestion :).
They just added invention and T3 stuff that heavily depends on copies!

Czert ElPrezidente
Caldari
Posted - 2009.12.27 17:42:00 - [13]
 

Here is one think I dont understand - if adding copy to bueprints is that server-demanding, which way CCP did it for distinqusing tech2/3 ships ? Same highly demanding from server way ?

Pan Dora
Caldari
Organization for Nuclear Research
Posted - 2009.12.27 17:45:00 - [14]
 

Originally by: Inspiration
Then you don't understand a word of it...


Exactly! My programing knowledge dont include much else than "hello world" in pseudo-code. Laughing

But Im curious and accepting you said 'dev is wrong because technobable' its not enough for me.

Thank you for the further explanation. (No, I didint get it 100%, just enough to calm me down a bit ugh)


Enkilil
Minmatar
Thirteen Ninety Three
Posted - 2009.12.27 18:04:00 - [15]
 

Originally by: Yarik Mendel
Edited by: Yarik Mendel on 27/12/2009 17:24:33
How about just get rid of BPC and voila problem solved, and higher risk and profit in manufacturing sector.



Please stop posting.

Nova Fox
Gallente
Novafox Shipyards
Posted - 2009.12.27 19:02:00 - [16]
 

Edited by: Nova Fox on 27/12/2009 19:05:03
Had somone explain it to me before but I just find it funny that every entity in the game does have a blue print. not just items you get in your hangerbay, but even those little dead corpses afloat and arent able to be picked up. It wouldnt surprise me if the planets had thier own blue prints.

BTW let me add to this, the last solution I overheard to this problem is to get rid of the blue print as an noraml everyday item for you to operate with and have it part of a pulldown menu under SnI interface of blueprints you aquired and have them in your research 'database' vai Wow Crafter Recepie Listing if you will. Differences is that you can yank out the blue print out of this database and make it the physical item again to be trades sold or even stolen. Advantages this will allow your blue prints to become available to your corp and prevent them from doing certain things to them like submitting them to research or making copies.

Misanthra
Posted - 2009.12.28 06:24:00 - [17]
 

Edited by: Misanthra on 28/12/2009 06:27:02
Originally by: Czert ElPrezidente
Here is one think I dont understand - if adding copy to bueprints is that server-demanding, which way CCP did it for distinqusing tech2/3 ships ? Same highly demanding from server way ?



No, factor in number of t2/t3 varieties for ships vice number of bpo's. Just look at t2 ship bp's, each set has 9 component bp's, so you have 36 right there. That's 72 items if bp's looked different.


Virtually everything in this game has a bpo from which it is made. BPO's with an invention path can fork out to bpc copies of t2 (remembering some lead to 2 possibilities which in turn may have a bpo in the system), and bpc's all having their own pics....Be aaaaalot of entries for this.


Nova Fox
Gallente
Novafox Shipyards
Posted - 2009.12.28 08:33:00 - [18]
 

Edited by: Nova Fox on 28/12/2009 08:34:59
there are about close to about a million different items in eve, only 2% are available to players though, NPC entities have thier own blueprints too and there are alot of different kinds of those.

Inspiration
Posted - 2009.12.28 09:42:00 - [19]
 

Originally by: Misanthra
Edited by: Misanthra on 28/12/2009 06:27:02
Originally by: Czert ElPrezidente
Here is one think I dont understand - if adding copy to bueprints is that server-demanding, which way CCP did it for distinqusing tech2/3 ships ? Same highly demanding from server way ?



No, factor in number of t2/t3 varieties for ships vice number of bpo's. Just look at t2 ship bp's, each set has 9 component bp's, so you have 36 right there. That's 72 items if bp's looked different.


Virtually everything in this game has a bpo from which it is made. BPO's with an invention path can fork out to bpc copies of t2 (remembering some lead to 2 possibilities which in turn may have a bpo in the system), and bpc's all having their own pics....Be aaaaalot of entries for this.




Just to make sure you understand...no new pictures are needed! All that is required is some meta data which by a regular join is too costly to get. Once this meta data reaches the client the client can put a "Copy" stamp on it, no need for variations of any sort!

Misanthra
Posted - 2009.12.28 09:58:00 - [20]
 

CCP can't get 200 players on grid lag free at this point with current system of server db call loads eve wide...last thing eve needs is to have any extra server calls tbh. This small db call sadly is an extra one we don't need atm. I run an indy with a small mixed collection of bp's so not a pvp or death type but have met death head on and he had lag inscribed on his scythe lol (insert here's a lag death weak excuse tissue like statement here). Rather get on grid faster and have to take the 4 seconds to see if a bpo or bpc to be honest. 4 seconds of right click don't cost me 40 mil isk...death by lag does.

Inspiration
Posted - 2009.12.28 11:12:00 - [21]
 

Edited by: Inspiration on 28/12/2009 11:16:25
Originally by: Misanthra
CCP can't get 200 players on grid lag free at this point with current system of server db call loads eve wide...last thing eve needs is to have any extra server calls tbh. This small db call sadly is an extra one we don't need atm. I run an indy with a small mixed collection of bp's so not a pvp or death type but have met death head on and he had lag inscribed on his scythe lol (insert here's a lag death weak excuse tissue like statement here). Rather get on grid faster and have to take the 4 seconds to see if a bpo or bpc to be honest. 4 seconds of right click don't cost me 40 mil isk...death by lag does.


You are missing the point...completely (and hijacking a thread I might add), you discount human behavior with the current system that causes extra calls to check blueprints and double check them before selling etc. But when it is instantly clear without additional calls, you get rid of that extra load. Instead of adding extra calls, it removes them as what the system delivers better matches that what players need. The sole question remains what are the added execution cost is in CCPs case. I can only say from my own experience and have honestly never worked with a database as huge and heavily loaded as theirs, I doubt anyone here does.

So please people stop say no, because...lag this, lag that....no we can't...my issues first, etc. Let CCP take a closer look at this, maybe they have explored it already, maybe not...I just felt that by their explanations they did not even tho they want this feature in as badly as many of us do. It will take them only a few minutes to see if the approach has potential and needs to be investigated further, if they get stuck at it, they know were to find me and provide a test case to me which I can try to optimize further. And if it doesnt work out, well it doesn't work out...then we have to wait on a remodeled system at some point, which they arent going to do just for this feature and will by default be more comprehensive.

Ardetia
Caldari
Killer Koalas
Posted - 2009.12.28 11:29:00 - [22]
 

sounds to me like inspiration has come up with a sloppy fix that the devs maybe (just maybe) hasnt bothered to check
but then again, this presumes that they dont use a heavily optimized SQL system of their own
i doubt they havent looked at different ways of doing even this

it is, however, possible :)

Venkul Mul
Gallente
Posted - 2009.12.28 12:16:00 - [23]
 

Originally by: Czert ElPrezidente
Here is one think I dont understand - if adding copy to bueprints is that server-demanding, which way CCP did it for distinqusing tech2/3 ships ? Same highly demanding from server way ?


Because a T2 or T3 BP is a different item from a T1 BP, so the normalized template for that specific T2 or T3 blueprint is loaded, including a T2/T3 symbol.

A T2 BPO and a T2 BPC of the same item are identical, like a T1 BPO or T2 BPC of the same item.

A T2 BPC of a Golem instead is a different item from a T1 BPO/BPC of a Raven, exactly like the BPC of a faction item is different from the T1 version of the same item and point to a different finished item.

PaulTheWise
Posted - 2009.12.28 13:25:00 - [24]
 

Originally by: Inspiration
select
i.ID
, i.SomeData
, i.IsBluePrint
, case
when i.IsBluePrint = 0 then null
else ( select d.IsBPC from dbo.Differential as d where d.ID = i.ID )
end as isBPC
from
dbo.Inventory as i
;
Hmm, you'd stick a bit onto each and every item (ok, maybe less for stacked items) in the universe. Lets hope there's already (flags mod 8) <> 0 bits in the table, just how many rows are there in that table?

I was going to propose a container of sorts that could only hold blueprints, so every time you opened that the game could fetch the number of runs remaining (-1 or a natural number if I followed past topics correctly) but that would not really help, as you can't build, research or sell out of them, and you'd still have the right-click game in POS labs or hangars.

Kleranna
Minmatar
Hitodama Industrial Cooperative Operations
Manifest Destiny.
Posted - 2009.12.28 15:08:00 - [25]
 

Edited by: Kleranna on 28/12/2009 15:10:30
Edited by: Kleranna on 28/12/2009 15:09:53
Edited by: Kleranna on 28/12/2009 15:08:29
The two most commonly proposed solutions to this are:

1. Change the DB lookup for blueprints to something more complicated so they can be displayed differently.

The devs response to this one is that such complex SQL queries would lag the server too much if they were used for normal inventory display.

2. One counter to this is ... ok, make copies of blueprints into separate item types with their own icons -- one for the original and a completely different one for a copy.

The CCP answer here is that the build system does not allow for more than one blueprint type to build a given item, so it would require remaking part of the SQL database schema and the code associated with it, and that (apparently) doesn't have very high priority.

That's why it's still the way it is, not because CCP doesn't know it's annoying as hell. :-)


 

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only