| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
j0sephine
Caldari
Reikoku
Band of Brothers
   |
Posted - 2006.12.20 22:56:00 -
[1]
Edited by: j0sephine on 20/12/2006 22:56:50
"Just change a bit color, BPC and BPO should not have the same icon"
This was discussed at length some time ago in game development forum section... the crux of it is, because from server point of view the BPO and BPC are the same item with slightly different internal data, in order to tell apart the BPOs from BPCs the client would have to send query for each blueprint in your hangar each time you access your inventory. Multiply it by number of people in EVE playing with their inventory both while docked and in space, and the stress on server becomes enourmous.
Some suggestions were made to introduce things like the client caching blueprint state to allow this kind of display without overloading the server... but in the end i guess it's just too much work and/or devs don't want to risk it with enough lag being in the system as it is o.O;
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.21 17:18:00 -
[2]
"Surely reading a single attribute of any BP Item can't be that server intensive over and beyond reading the name."
That's precisely the point, it is. Or to put it simpler, presuming it's even possible to read single specific attribute of item rather than having to request all its data as package... you go from:
request for single ID number (resolved to name client side)
to:
request for ID number and attribute
... that's doubling the workload -- two requests vs one for each BP, and twice as much data to lookup and send.
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.22 17:03:00 -
[3]
Edited by: j0sephine on 22/12/2006 17:07:07
"Please explain in layman's term to me, how the current colour gets from the databases
onto the player's screen without generating that exact 5-10% performance lag you are
talking about.
Thank you  "
It's currently something the client can do it on its own. All it takes is internal information to the effect "items with ID 20, 35, 40-50 ... are blueprints, use this special blue background and hue to generate their icon for the player to see"
But because both BPO and BPC have the same item ID, the client cannot tell BPO from BPC just with the item ID alone... it would also have to examine content of the item to read its 'remaining copies' attribute. Which is something that normally doesn't happen until the player uses the "show info" command.
It's this additional information lookup multiplied by number of players multiplied by number of BPOs and BPCs scattered in players hangars EVE-wide multiplied by number of times a day players access their inventory/assets windows etc... that would result in overall load increase of mentioned 10-15%
... something like this, anyway o.O;
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.22 17:30:00 -
[4]
"Just thought if one were to hold the mouse over a BPO/BPC, it would simply say "BPO" or "BPC" in a floating text box based on the unchanged properties of the print. So as no actual changes would be made to differentiate the two, I doubt it would add any lag or stress."
But in order to show that information in the floater the client still has to request it from the server (it's not sent by default when you open the inventory to keep the load smaller) ... so while it'd be less stressful than automatic requests, there's some extra processing added nonetheless.
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.22 20:04:00 -
[5]
Edited by: j0sephine on 22/12/2006 20:11:33
"It could be sent by default."
Which would cause that very 10-15% server load increase kieron mentioned. There is no free lunch here -- any piece of data (at least one that isn't static) has to be looked up by the server and sent to the client in order to make it available for you. And that lookup takes time and processing power.
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.22 20:09:00 -
[6]
"i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better
use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it."
When the only information you receive from the server is item ID which is identical for BPO and BPC, how does the client tell them apart from this information alone, again?
The one thing a sofware engineer should really 'know better' is to read before they post something which was suggested and explained as meaningless heap times already. "jeeeeez" indeed --;;
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.23 00:47:00 -
[7]
"1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID."
OK, one more time, until it sinks in i guess. Currently the BPO and BPC for each item share the ID. As such you cannot encode anything in the ID that will be specifically interpreted as something reserved for either BPOs or BPCs.
If the BPOs and BPCs were separate items with different IDs then yes, making change to what their icon looks like would be relatively trivial. But if i remember right, the reason they are still treated as the same item is buried somewhere deep in how the whole manufacturing process in EVE is programmed and there isn't really easy nor quick solution for changing that to a new model.
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.23 02:45:00 -
[8]
"It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask...
(..)
I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit."
This is interesting idea, though afraid implementation would be more complicated than that. For example if you just mask off the 'original bit' everywhere, then it's possible a simple act of BPO transfer to another person or maybe even to factory/research slot can result in loss of that piece of information unless the system handling it is taught to preserve it or set again. Etc.
Overall, i'd guesstimate the amount of coding work involved (given you'd need to consider all of current common game mechanics that touch assets IDs and decide in what way each of them handles this extra information) ... is likely not really much smaller from going the clean 'split BPOs and BPCs' route, if any. But then again, it's something only CCP knows -.o
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.30 17:57:00 -
[9]
"Buy a new BPO (e.g. a nice cheap shuttle BPO). Look at it in your hangar. Notice the little '1' in the corner? Start a manufacture job from the BPO, but cancel out at the quote stage. Look at it again in your hangar. Notice the little '1' has gone?
If the only info passed to the UI right now is the itemID, typeID and quantity, how does the UI tell a 'used' BPO from an 'unused' BPO? It can't, it must already be receiving information about the attributes of the BP."
It's the attribute of packaged (stackable) item, not BPO-specific data. Note you get the same thing with ship modules... brand new modules show as what's essentially "module X, 1 (or more) such item(s) bundled together". When you put the module in the ship it's converted from "stack" into 'real' single item and treated as actual module with the amount number gone. The number re-appears when you repackage the module, turning it again into the "stackable item pack".
|
j0sephine
Caldari
Reikoku
Band of Brothers
|
Posted - 2006.12.31 00:00:00 -
[10]
Edited by: j0sephine on 31/12/2006 00:03:47
"But the point is, that is information being returned from the database relating to that particular item/stack in order to generate the hangar view. This is at odds with what the dev (Traveler) was quoted as sayying. If the DB query can return specific information (used/unused) why not BPO/BPC?"
Chances are it doesn't return specific information about items but rather "a stack of items type X" is separate type itself.
E.g., let's say the server sends only ever the type id, item id and amount. You open your hangar and receive from server:
"damage control bp stack" (type id), "item-uuid-1" (item id), "10" (amount)
... the client draws it on your screen as "stack of 10 damage control blueprints". Now, you take single blueprint from this stack, put it in production and then it gets returned. Now when you open the hangar, the server will send you:
"damage control bp stack", "item-uuid-1", "9"
"damage control bp", "item-uuid-2", "1" (amount of 1 possibly gets skipped as default value)
... the client draws it on your screen as "stack of 9 damage control blueprints, and single unpacked damage control blueprint". Note, at no point it checks into attributes of specific item, it simply reports the item type, item id and the amount... without ever having to look up data linked with any specific item-uuid.
Now this is all mostly guesswork of course. And note, if the blueprints had separate id for originals and copies then they could be handled in pretty much the same manner... but as long as they don't and there's supposedly limitations of production system getting in the way, we're kinda stuck :/
edit: note, this approach requires all items in the stack to have identical attributes because they don't actually exist as stacked entities... which is likely why it wasn't actually possible to stack items with different attributes like damaged modules, partially used laser lenses, assembled ships etc.
|
| |
|