Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Aineko Macx
Royal Amarr Institute Amarr Empire
93
|
Posted - 2012.01.08 12:32:00 -
[1] - Quote
As stated by subject.
CCP once stated they weren't looking into it because BPCs can have varying stats (runs, ME, PE). In practice, however, the people that have the most BPCs are the ones making copies, which usually have identical stats and would thus be very stackable. The benefits are less cluttered hangars, which would make players and CCPs DB guys happy. |
CynoNet Two
GoonWaffe Goonswarm Federation
413
|
Posted - 2012.01.08 20:20:00 -
[2] - Quote
Aineko Macx wrote:As stated by subject.
CCP once stated they weren't looking into it because BPCs can have varying stats (runs, ME, PE). In practice, however, the people that have the most BPCs are the ones making copies, which usually have identical stats and would thus be very stackable. The benefits are less cluttered hangars, which would make players and CCPs DB guys happy.
This is technically very difficult to do. BPC's (like used BPOs) are a singleton*. Put simply they are unique items and so cannot have a quantity value other than 1. Far from making the DB guys happy, any attempt to work around this would likely make them miserable.
While it may be possible to have some client-side filter than makes them appear as a single stack, this could be very resource-intensive as soon as you start dealing with large numbers of prints. A much simpler solution is to just keep similar prints in a can or hangar division. Perhaps CCP could allow use of blueprints out of cans instead?
*apparently we can't use URL tags anymore - http://en.wikipedia.org/wiki/Singleton_%28mathematics%29 |
Aineko Macx
Royal Amarr Institute Amarr Empire
93
|
Posted - 2012.01.08 23:57:00 -
[3] - Quote
Ok, you want to go technical: I know that with the update to differentiated BPOs and BPCs CCP merged the semantics of the singleton and quantity column into a single column (where quantity == -1 equals singleton). That change is basically a crutch to get the easy differentiation client side done that now hinders further improvements to BPs. The better solution would have been to give BPOs and BPCs a different type id. Further, the singleton design is not really needed. In the cases where you want to set a foreign key to a "singleton" BP you could just as well use the auto stack splitting that is used in many other parts of the game and set the FK to that newly created 1 unit stack. In fact the solution I propose requires the singleton concept to be abolished, as the BP stats come from another table that are joined to the actual inventory row. The only slightly trickier part is to avoid stacking BPs with different stats or which are part of a pseudo singleton FK (for instance BPOs in research). |
Xander Hunt
17
|
Posted - 2012.01.14 22:32:00 -
[4] - Quote
Overall +0.8 for this proposal.
Just my thoughts (I only skimmed) if CCP were to give another ItemID (As mentioned) for the BPC then allow for merging BPC runs together so long they have the same ME/PE values would pretty much solve the problem. This would save having several T2 BPCs kicking around, since most of them never have a range outside of -4/-4 to +4/+4.
The only trick for CCP would be to have a SQL transaction happen that'd look for a currently defined BPC, create a new itemID with the old BPC settings, then delete the old BPC. I know there are millions of BPCs out there, and doing something like this would be SERIOUSLY IO intensive. The other thing that could be done is instead of doing bulk transactions like this would be to not make any more BPCs the existing way, just create the items the new way. It MIGHT cause some UI grief as to why two seemingly similar BPCs won't merge, but, that'd be just a small thing until all the old BPCs are consumed. |
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |