| Pages: 1 [2] 3 4 5 6 7 8 :: one page |
|
|
| Author |
Topic |

Doc Iridium
Amarr Viziam
 |
Posted - 2008.05.19 12:14:00 -
[31]
Originally by: CCP Lingorm OK, to clear up a few more misconceptions.
There is a unique entry for Each generic BPO, it has some normalised attributes (Copy time, Mineral requirements etc stored in a reference table), I buy a BPO and start researching it. I now get a unique entry for my BPO and the 'parent' reference for it is the Generic Entry, the normaliased data for my BPO is now created, this consists of ONLY entries where my BPO is different from the Generic type.
I create a Copy of my BPO, this is now created in the user space and will get all the attributes of my BPO instance copied to it and a number of runs value added (not quite true the number of runs will be changed form -1 (infinite) to a positive value) but it's parent still references the generic BPO not my BPO instance.
So automatically assuming that any InvID on a blueprint in the 'user useable' ID range is false as BPO's can exist in that range.
We use this structure as it keeps the size of the database to the absolute smallest, fasted we can make it. The Inv Table only contains fields that are used by ALL types of objects in EVE, so all those differing variables are 'normalised' off into what we call the 'Dogma' Attributes. So to get access to these vaules you have to know the invID of the item (and potentially it's parentID) you then do a cross reference on the inventoryDogma attributes to find out what attributes are assigned to this item (you also add all the generic attributes of the parent if applicable and your instance only stores the changed stuff).
As you can see, it is a complicated system, but it works perfectly to reduce the stored data to the absolute minimum.
As for the S&I interface not allowing you to filter the view, the Corp one allows you to filter by individual hanger and you can filter by Original or Copy. The 'Personal view allows you to filter by Original/Copy. As for the list resetting to the top, I will have a chat with the UI dude, and see what we can do about it (I hate it too), I will also ask about getting a list of BP's in labs or Factories in a useable manner. This will not make the next expansion, but hopefully in one of the 'point' releases we can get it in.
Honestly, I think the entire blueprint system needs to be scrapped and rebuilt if it's this much effort to make it sanely functional. If it used more database space, so what. Right now the blueprint dysfunction is as maddening for me as the PVP broken-ness :P Well, I've said my piece - wait, is that Veldspar over there? Woot! |

Somatic Neuron
 |
Posted - 2008.05.19 13:36:00 -
[32]
Originally by: CCP Lingorm OK, to clear up a few more misconceptions.
There is a unique entry for Each generic BPO, it has some normalised attributes (Copy time, Mineral requirements etc stored in a reference table), I buy a BPO and start researching it. I now get a unique entry for my BPO and the 'parent' reference for it is the Generic Entry, the normaliased data for my BPO is now created, this consists of ONLY entries where my BPO is different from the Generic type.
I create a Copy of my BPO, this is now created in the user space and will get all the attributes of my BPO instance copied to it and a number of runs value added (not quite true the number of runs will be changed form -1 (infinite) to a positive value) but it's parent still references the generic BPO not my BPO instance.
So automatically assuming that any InvID on a blueprint in the 'user useable' ID range is false as BPO's can exist in that range.
We use this structure as it keeps the size of the database to the absolute smallest, fasted we can make it. The Inv Table only contains fields that are used by ALL types of objects in EVE, so all those differing variables are 'normalised' off into what we call the 'Dogma' Attributes. So to get access to these vaules you have to know the invID of the item (and potentially it's parentID) you then do a cross reference on the inventoryDogma attributes to find out what attributes are assigned to this item (you also add all the generic attributes of the parent if applicable and your instance only stores the changed stuff).
As you can see, it is a complicated system, but it works perfectly to reduce the stored data to the absolute minimum.
As for the S&I interface not allowing you to filter the view, the Corp one allows you to filter by individual hanger and you can filter by Original or Copy. The 'Personal view allows you to filter by Original/Copy. As for the list resetting to the top, I will have a chat with the UI dude, and see what we can do about it (I hate it too), I will also ask about getting a list of BP's in labs or Factories in a useable manner. This will not make the next expansion, but hopefully in one of the 'point' releases we can get it in.
So is my local cache idea not doable then? It wouldn't require any database changes or additional calls to the database... ---------- |
|

CCP Lingorm
C C P

 |
Posted - 2008.05.19 14:16:00 -
[33]
The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
The issue with making a BPO and BPC base item are that at the moment each item can only have 1 blue print associated with it. This is a limitation we have looked at and would like to change (we could then implement alternate builds for items, so that you could build it from 2x, 3y, 1z or 2u, 3y, 1z for example).
The rest of the blue print structure is actually very good and works perfectly. As stated before would could do the 'different' marker (icon overlay or such) but the db query overhead is not acceptable at this time for general inventory lookups.
As for the number of items in a hanger and not being able to use containers, I know that pain (Looks into his Corporate hanger to see cans called "Caldari Battleship BPC's", "Gallente Battleship BPC's" ... "Caldari Cruiser BPC's", etc etc).
I am not sure that anything can be done about this because of the recursion routines but it is something that I would like ... or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it.
Yes, I am an industrial player .... so I can understand your pain ... I do some pvp as well though *grin*.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|

Somatic Neuron
 |
Posted - 2008.05.19 15:06:00 -
[34]
Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
To be honest, I think that is something we could live with...as it is much much better than the options available to us today. Anyone else agree with me on that sentiment?
As an add-on suggestion to this, would it be possible to make that local cache file a seperate, shareable, file for each corp, so that we could then transfer the file between computers? ---------- |

shady trader
 |
Posted - 2008.05.19 20:29:00 -
[35]
Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
The issue with making a BPO and BPC base item are that at the moment each item can only have 1 blue print associated with it. This is a limitation we have looked at and would like to change (we could then implement alternate builds for items, so that you could build it from 2x, 3y, 1z or 2u, 3y, 1z for example).
The rest of the blue print structure is actually very good and works perfectly. As stated before would could do the 'different' marker (icon overlay or such) but the db query overhead is not acceptable at this time for general inventory lookups.
As for the number of items in a hanger and not being able to use containers, I know that pain (Looks into his Corporate hanger to see cans called "Caldari Battleship BPC's", "Gallente Battleship BPC's" ... "Caldari Cruiser BPC's", etc etc).
I am not sure that anything can be done about this because of the recursion routines but it is something that I would like ... or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it.
Yes, I am an industrial player .... so I can understand your pain ... I do some pvp as well though *grin*.
One way could be to have say Yellow for known BPC's and say green for known BPO's and if a BP is not known due to it not being in the cache leave it blue. This way people can see the difference if they have accessed as well as knowing if they have not looked at it.
Macrointel, the place were the nature order of the universe does not hold sway. Pirates and ore thief's are congrated by carebears for the actions. |

Jurgen Cartis
Caldari Interstellar Corporation of Exploration Nex Eternus
 |
Posted - 2008.05.19 20:31:00 -
[36]
Originally by: Somatic Neuron
Originally by: CCP Lingorm <Dev Communication>
To be honest, I think that is something we could live with...as it is much much better than the options available to us today. Anyone else agree with me on that sentiment?
As an add-on suggestion to this, would it be possible to make that local cache file a seperate, shareable, file for each corp, so that we could then transfer the file between computers?
Most of us only play Eve on one computer, while this idea would blow for those who play at cybercafes, for example, those who simply play from a home computer could make full use of it. -------------------- ICE Blueprint Sales FIRST!! -Yipsilanti Pfft. Never such a thing as a "last chance". ;) -Rauth |

Doc Iridium
Amarr Viziam
 |
Posted - 2008.05.20 08:52:00 -
[37]
Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
I do not believe it would create any more confusion than losing all the data that is already stored locally on the client. It's a sub-optimal solution, but better than no solution. If the BPO/BPC organizational process is simple to start, then it could be processing while the player sets up their preferences on the new machine, or with the new build.
I still think the creation of containers that are restricted to holding only BPO's or BPC's is a optimal situation, offering a high level of organization, depending on how many book types are created. Perhaps books based on what POS assembly modules can build? Small ship Book does frigs, dessies, and fighters.
Depending on how modular your database is, you could then strip acceptable BPO types from the POS module build allowability tables to generate tables of what BPO's will fit in which books, and compare infinite to non-infinite builds for full determination of where each BPO might go.
Even if these books are local storage only, and would revert to unassembled containers with loose blueprints in open inventory after moving to a new computer, or reinstalling a new client, it would be _very_ much worth it. Allowing a select-all-and-drop onto a book, while allowing the appropriate items to drop into the book without non-appropriate types stopping the process would be very fast sorting compared to bpo sorting methods used today, and could be done with a low priority so as to not overburden the servers if they are operating under heavy load.
and finally, what would stop the client from making a determination as to status of BPC's then requesting permission to sort and color them?
"It seems that you have blueprint copies that are not visually different from your blueprint originals. Shall I adjust the color of blueprints so you can tell copies from originals?"
I suppose my biggest confusion is that there are already two colors of BP. There are some that are an odd shade of purple, and then there are the common blue ones. The colors are apparently not associated with any meaning. However the fact that there are already two colors of BPO seems to indicate that at least some of the work required to organize BPO's by image is already coded. Well, I've said my piece - wait, is that Veldspar over there? Woot! |

J'Mkarr Soban
Amarr Proxenetae Invicti
 |
Posted - 2008.05.20 13:43:00 -
[38]
Lingorm:
Why not have an extremely simple method that the first time a BP is loaded from the DB to the local cache, an easy
if (productionRunsRemaining > -1) then BPImage.setColourFilter("green"); is run?
As one who works with databases, the idea of storing derived data is abhorrent to me, but this is usually how things work when taking data out in the first place.
Combined with type filtering by tabs in hangers (hint hint) this wouldn't add much overhead, especially given the cap of 1000(?) item types in a hanger.
-- These are my personal views and in no way represent the views of Proxenetae Invicti, which maintains a neutral stance stemming from the strong ethics demanded of its work. |

Zirconium Blade
Ass Pounding Space Monkeys
 |
Posted - 2008.05.20 20:05:00 -
[39]
Bumpin this, cause its got a Dev response and if its on the front page we might get less of these threads created.
|

Ki Tarra
Caldari Ki Tech Industries
 |
Posted - 2008.05.20 22:11:00 -
[40]
Originally by: CCP Lingorm Stuff
So basicly this comes down to the fact that BPO's and BPC's both used the same typeID.
The only way that we could see seperate icons for BPO's and BPC's is if they were given different typeID's.
However, doing that creates a bunch of extra work as you would need to duplicate all of the typeID's for blueprints.
This could potentially lead to weird bugs if for example the copy time of the BPO's typeID was updated but the copy time for the BPC's was not. It would also require an additional attribute of BPO's indicating what the typeID is of the BPC it will produce.
All in all, another mess that causes more problems than it fixes?
|
|

Guvante
GALAXIAN
 |
Posted - 2008.05.20 23:57:00 -
[41]
Originally by: J'Mkarr Soban Lingorm:
Why not have an extremely simple method that the first time a BP is loaded from the DB to the local cache, an easy
if (productionRunsRemaining > -1) then BPImage.setColourFilter("green"); is run?
As one who works with databases, the idea of storing derived data is abhorrent to me, but this is usually how things work when taking data out in the first place.
Combined with type filtering by tabs in hangers (hint hint) this wouldn't add much overhead, especially given the cap of 1000(?) item types in a hanger.
You failed to read his note, there is no such thing as productionRunsRemaining attached to an item. That is contained in a separate DB, that is what he has said twice now ><
Remember, when you open your hangar, it only gets information for what items you have and the generic properties of that item (ie its Icon). Any more specific properties require an additional look up.
And about your comment of only 1000 item types, sure it is only 1000 item types, per user, and EVE has a lot of users online at once, all hitting the same DB. This is especially painful since no distributed system out there is really designed to handle extremely rapidly changing data.
|

Zirconium Blade
Ass Pounding Space Monkeys
 |
Posted - 2008.05.21 13:43:00 -
[42]
Sticky, perhaps?
|

TornSoul
BIG
 |
Posted - 2008.05.22 01:17:00 -
[43]
Edited by: TornSoul on 22/05/2008 01:19:17
Originally by: Zarch AlDain The big things that would make a HUGE difference are:
Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing).
Oh God yes... Pretty please with sugar on the top...
Originally by: CCP Lingorm or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it.
Once more - Oh God yes!
|

Seth Ruin
Galactic Exploration and Mining Corporation
 |
Posted - 2008.05.22 04:41:00 -
[44]
Originally by: Doc Iridium
Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
I do not believe it would create any more confusion than losing all the data that is already stored locally on the client. It's a sub-optimal solution, but better than no solution.
I agree. A sort-of "hack" like this as a hold-over until such a BPO overhaul that has been hinted at emerges would be better than having to query the DB every time one checks a BP to see if it is a BPO or BPC.
Is it just me or does it seem like the design of the Blueprint system didn't expect there to be such a market for BPCs? Seems like BPCs have evolved beyond their original design, perhaps.
|

Wren Alterana
The Baros Syndicate Kissaki Republic
 |
Posted - 2008.05.22 06:03:00 -
[45]
not really a big computer person but what about having the database query for the # of runs, it doesn't have to know how many runs are remaining, just the fact that it contains that category, if it does it recolors it. or would that cause too much lag? I wouldn't think one additional factor when querying the database would cause too much strain. _________
 Dynamic Maps |
|

CCP Lingorm
C C P

 |
Posted - 2008.05.22 09:48:00 -
[46]
Because the numberOfRuns attribute is still present on a BPO it just contains -1 which means unlimited runs.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|

Kuroshiro
 |
Posted - 2008.05.22 15:46:00 -
[47]
Originally by: CCP Lingorm Because the numberOfRuns attribute is still present on a BPO it just contains -1 which means unlimited runs.
If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
|

procurement specialist
 |
Posted - 2008.05.22 17:38:00 -
[48]
Edited by: procurement specialist on 22/05/2008 17:38:36
Originally by: TornSoul Edited by: TornSoul on 22/05/2008 01:19:17
Originally by: Zarch AlDain The big things that would make a HUGE difference are:
Multi select on the S&I screen (so we can select a batch of BPCs for example then deliver them all to a different hangar for processing).
Oh God yes... Pretty please with sugar on the top...
Originally by: CCP Lingorm or at least a function to remotely move a bp from a container into a hanger/corp hanger would be nice. I will keep on it.
Once more - Oh God yes!
someone is excited :D
|
|

CCP Lingorm
C C P

 |
Posted - 2008.05.22 17:56:00 -
[49]
Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
Did you read the thread?
This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory.
This is not acceptable from a performance perspective so we do not do it.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|

Zarch AlDain
Hematite Rose Bionic Dawn
 |
Posted - 2008.05.22 19:01:00 -
[50]
Originally by: CCP Lingorm
Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
Did you read the thread?
This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory.
This is not acceptable from a performance perspective so we do not do it.
Please don't give up on the rest of us because of one or two idiots :( Most of us are reading and understanding.
Zarch AlDain ---- My corp is recruiting. See the recruitment thread here.
|
|

Helison
Times of Ancar Pure.
 |
Posted - 2008.05.22 20:32:00 -
[51]
Edited by: Helison on 22/05/2008 20:32:53 no new info
|

Kuroshiro
 |
Posted - 2008.05.22 20:39:00 -
[52]
Originally by: CCP Lingorm
Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
Did you read the thread?
This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory.
This is not acceptable from a performance perspective so we do not do it.
Honestly? No I didn't. I'm like 99% of the customers on this planet in that I'm really not interested in what limitations poor planning in your database have created in your product, I just would like to see a solution engineered to correct or work around this deficiency in your interface. This should not be the least bit of a shock to any experienced engineer.
Also, if I were to talk to my company's customers the way you just spoke to me -- well, I'm not 100% sure what would happen, but I would certainly never be allowed to talk to customers again and it would definitely show up the next time I was up for a raise. There's just no excuse for it that lack of professionalism, no matter how stupid you think the question is.
|

Joe Starbreaker
 |
Posted - 2008.05.22 21:59:00 -
[53]
Originally by: CCP Lingorm
Originally by: Kuroshiro If that's the case, couldn't you color based on whether numberOfRuns is '-1' or not?
Did you read the thread?
This value is NOT stored in the Inventory DB table. It is Normalized into another table that stores specifics attribute data. When we do an inventory query we return the entries in the Inventory table. We do not retrieve any data from the Normalized tables. Do do so would mean an additional db query for EVERY Item in your inventory.
This is not acceptable from a performance perspective so we do not do it.
I'm starting to get a mental picture of your database now, and I can see the trouble. I guess that the color changes you apply to locked blueprints in containers, and blueprints in lockdown, are identified by fields in teh Inventory table, then?
Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work...
---------------- [insert signature here] |

Joe Starbreaker
 |
Posted - 2008.05.22 22:01:00 -
[54]
Originally by: Kuroshiro There's just no excuse for it that lack of class, no matter how stupid you think the answer is.
Fixed that for you...
---------------- [insert signature here] |

Cutie Chaser
Federal Navy Academy
 |
Posted - 2008.05.23 04:03:00 -
[55]
Originally by: Joe Starbreaker
Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work...
To do anything along those lines I think what would be needed instead is a new set of entries into the Inventroy DB for blueprint copies, thus having 2 entries into the table for each Blue Print so that a BPC can be a distinct entity. This would be undesireable.
They always said EVE is a harsh game, I didn't start to realize until recently how much of this is due to technological restrictions;
1. Lag killed your ship? Our logs show nothing! 2. Can't tell the difference between BPC and BPO? Can't be helped!
In exchange for being in a world with 50k other players you make some sacrifices; thats alright by most people.
The people who are not ok with it are the people who accidentally sell a BPO as a BPC. Or people who lose an expensive ship to desync and are denied a claim due to a insufficiently verbose server logging system(I would bet likely also a performance choice). *** Thats a Templar, the amarr fighter. Its a combat drone used by carriers. |

Astral Water
 |
Posted - 2008.05.23 05:09:00 -
[56]
Signed. Make them a different color.
|

Esiel
 |
Posted - 2008.05.23 07:28:00 -
[57]
Originally by: CCP Lingorm The local cache idea would be doable, but would ONLY work for that machine and install of EVE, so that if you move to another machine then your BP colours would revert, which could cause confusion, so it is not really workable.
I would be perfectly fine with this local machine only. Its no different to me than the bookmarks I have for places. When I switch to a different machine I loose all my folders. (same goes for my buddy list)
We will know that it is local machine only and so we will still organize our stuff but it will make life a bit easier.

Off with your head |
|

CCP Lingorm
C C P

 |
Posted - 2008.05.23 09:11:00 -
[58]
Adding fields to the inventory table is not an option.
EVERY object in EVE has an entry in this table, it (along with the locations table) creates the structure for EVE.
By adding fields to this table add fields to millions of items they do not apply to. Hence the normalization. We could of put every type of iten into their own table, but then the query to get your 'inventory' would have been insanely bad.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
|

CCP Lingorm
C C P

 |
Posted - 2008.05.23 09:21:00 -
[59]
Originally by: Kuroshiro Honestly? No I didn't. I'm like 99% of the customers on this planet in that I'm really not interested in what limitations poor planning in your database have created in your product, I just would like to see a solution engineered to correct or work around this deficiency in your interface. This should not be the least bit of a shock to any experienced engineer.
Also, if I were to talk to my company's customers the way you just spoke to me -- well, I'm not 100% sure what would happen, but I would certainly never be allowed to talk to customers again and it would definitely show up the next time I was up for a raise. There's just no excuse for it that lack of professionalism, no matter how stupid you think the question is.
Honestly, I was not trying to pick on you. I got this tread stickied so that we do not have to keep repeating the answers every couple of months. The answer to your question was already in the thread.
As for a solution to the problem, that is what we are trying to work out? But I bet if you walked up to your db supplier and said "Your DB is badly limited because of your poor planning" they would have some choice things to say to you.
We are trying to find solutions. Our DB structure is the only practicable one that will support our needs, that means we have to accept some "limitations" to be able to do what we do. We have come up with some suggestions her for possible work arounds (Remote Moves of items from Containers to Hangers, the Local cache - not fond of this myself but I will still present it to game design and programming, and some others.
If you have a suggestion that might help we are all listening.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
|

CCP Lingorm
C C P

 |
Posted - 2008.05.23 09:24:00 -
[60]
Edited by: CCP Lingorm on 23/05/2008 09:25:59
Originally by: Joe Starbreaker
I'm starting to get a mental picture of your database now, and I can see the trouble. I guess that the color changes you apply to locked blueprints in containers, and blueprints in lockdown, are identified by fields in teh Inventory table, then?
Wouldn't it be possible to do an inelegant kludge and just un-normalize the variable that identifes a BPC? Or put a copy of it into Inventory? Ugly yes, but it would work...
Locked is one of the flags that can be set in the Inventory Table. So yes we get that on the return.
The issue is that the kludge would have to be put into the query that return your inventory list, and would have to be run for EVERY single item in your Inventory, and I know I have lots of stuff other than blue prints in my inventory and this would add significant overhead to retrieving that data.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
|
| Pages: 1 [2] 3 4 5 6 7 8 :: one page |
| First page | Previous page | Next page | Last page |