Pages: [1] 2 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 6 post(s) |
zeus78
|
Posted - 2006.02.01 15:53:00 -
[1]
Not sure if this is the place on the forum to do this but how about putting a C in the left hand corner of a BPC. The T2 stuff has the "II" in the right hand corner. I think this would help to figure out what is what when you are looking in your BPOs and BPCs.
|
dodge2005
|
Posted - 2006.02.01 19:26:00 -
[2]
Its been sudgested many many times before and CCP have said its not possible to do it. Something about how a BPO/BPC's are linked. Its just the item info thats different in the number of runs, so its impossible to have 2 images for the same item... atleast thats my understanding
|
|
Mephysto
|
Posted - 2006.02.02 10:23:00 -
[3]
Originally by: dodge2005 Its been sudgested many many times before and CCP have said its not possible to do it. Something about how a BPO/BPC's are linked. Its just the item info thats different in the number of runs, so its impossible to have 2 images for the same item... atleast thats my understanding
This is indeed the problem.
|
|
Extreme
|
Posted - 2006.02.02 11:31:00 -
[4]
Just change the color of a copy
Blue- original Pink - copy
. .
|
|
Mephysto
|
Posted - 2006.02.02 17:49:00 -
[5]
Originally by: Extreme Just change the color of a copy
Blue- original Pink - copy
Which part of "cant do this" did you miss? If we could differntiate between BPc's and BPo's we would have done this already.
|
|
Wyke Mossari
|
Posted - 2006.02.02 18:07:00 -
[6]
If you sort a bunch of mix BPO/BPC by type the BPO is always the last item.
|
Lygos
|
Posted - 2006.02.02 18:33:00 -
[7]
Isn't the tII symbol a transparent gif that overlays the normal img? This seems like a very odd problem. How does the server recognize the difference? If the BPC and BPO were connected, what happens to the BPC if the original is destroyed?
It's always peculiar how the most innocuous seeming of problems can be the most fiendishly contingent. First rule of other people's problems: If it was simple, they'd have done it already.
I'm glad it's not my problem. And now, back to idling on the escrow market watching for misentered products..
Eunoia: The persistent suspicion that the universe is secretly conspiring to quietly improve one's life. |
Extreme
|
Posted - 2006.02.02 19:49:00 -
[8]
Edited by: Extreme on 02/02/2006 19:49:26
Originally by: Mephysto
Originally by: Extreme Just change the color of a copy
Blue- original Pink - copy
Which part of "cant do this" did you miss? If we could differntiate between BPc's and BPo's we would have done this already.
Well, i am no devellopper/programmer, but changing a color seems different to me than creating an extra image into the bpc.
Anyways, in my simple non professional thoughts, an original BPO says 'infinate'. Maybe in all my simpleness a script can detect that 'infinate' and when detected change a color ?
Just a thought here, forgive me for allmost being 100% wrong here. . .
|
Lokimon
|
Posted - 2006.02.02 21:53:00 -
[9]
Originally by: Mephysto
Originally by: Extreme Just change the color of a copy
Blue- original Pink - copy
Which part of "cant do this" did you miss? If we could differntiate between BPc's and BPo's we would have done this already.
Since you are coming up short in the ideas or talent area then may we as players collectively request CCP hire more talented developers or convice the current team to stretch a little and think outside the box.
The real problem here is that to some of the dev team, half-assed is a job well done and is much quicker perhaps than doing it right.
It isn't just the BPO/BPC issue, which by the way could have been FIXED when you did a rewrite of the research and manufacturing code in the game.
Lets take the new research and manufacturing as a prime example of half-assed CRAP. What is the most common way a researcher or manufacturer would use a BPO? It is RIGHT NOW and IN THE CURRENT STATION. Why isn't that the default?? But hey, what do you devs care about us poor carebears. It has nothing to do with PvP and hey it gets the job done. Right?
If a manufacturer has filled all of the assembly lines his skill allows, why is that check at the end of the job setup and not in the beginning?
Lets take the market. How many people put up sales orders or buy orders for ONE DAY? Yet, it is the default. When a producer uses the market to sell stuff, why doesn't the client remember that they ALWAYS use the advanced selling tab for that? I know, I know. It gets the job done and if half-assed is good enough for CCP it is good enough for their customers.
How about the font in Eve? How many over qualified devs are working on that one?
If CCP really cared about the BPO/BPC issue and was willing to spend some time on such a boring endeavor, we would already have a "Select All BPOs" option in the right click menu.
In reality making the BPO/BPC change requires two things: Brains and willingness to put in the effort. In this regard, the dev lack at least one of those.
|
|
Valar
|
Posted - 2006.02.03 00:13:00 -
[10]
Originally by: Extreme Edited by: Extreme on 02/02/2006 19:49:26
Originally by: Mephysto
Originally by: Extreme Just change the color of a copy
Blue- original Pink - copy
Which part of "cant do this" did you miss? If we could differntiate between BPc's and BPo's we would have done this already.
Well, i am no devellopper/programmer, but changing a color seems different to me than creating an extra image into the bpc.
Anyways, in my simple non professional thoughts, an original BPO says 'infinate'. Maybe in all my simpleness a script can detect that 'infinate' and when detected change a color ?
Just a thought here, forgive me for allmost being 100% wrong here.
Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar.
This *can* be done.. easily even... however, it will cause extreme load on the database.
So, to be able to properly do this, we'd need an inventory system rewrite or a wrapper around it. The inventory system in EVE is fragile, and one of the most critical system since everything is an item. Changes to the inventory system are always risky and a small oversight can cause database corruption.
Belive me, we want to do this. We also play the game. We also manufacture and research. We've discussed this back and forth, but this is a project that need alot of work and a huge amount of testing effort if we are to avoid lagging EVE to hell. ------ Valar Quality assurance department CCP games How to write a good bugreport |
|
|
j0sephine
|
Posted - 2006.02.03 06:38:00 -
[11]
"Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar.
This *can* be done.. easily even... however, it will cause extreme load on the database."
If (and this is big if, but likely) each item has its own distinct id which is visible to the client, could there be some sort of client-side caching system introduced... that does this sort of lookup for each 'new' blueprint it encounters, then writes the result of query down for future reference, something like "item 102300001023 is blueprint copy" ... so then each time after that when this particular item is encountered again, the client can easily tell the nature of BP without having to bother the server about it? Since blueprints never change into copies and vice versa to my knowledge, there's no worry about that particular attribute of item ever changing. ^^;;
|
Gigi Barbagrigia
|
Posted - 2006.02.03 06:58:00 -
[12]
Originally by: Valar Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar. ...
Huh? infinite flag is just a field in items table, no? You now make one joined select which gets you item properties from items table and type properties from types (including graphicID). So if you included infinite in fields list pulled how would that require additional DB call?
You could argue additional server-client traffic, yes. Specially since most of items don't use infinite flag but cmon, 1 bit sized field? ----- 42 |
|
Valar
|
Posted - 2006.02.03 10:34:00 -
[13]
Originally by: Gigi Barbagrigia
Originally by: Valar Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar. ...
Huh? infinite flag is just a field in items table, no? You now make one joined select which gets you item properties from items table and type properties from types (including graphicID). So if you included infinite in fields list pulled how would that require additional DB call?
You could argue additional server-client traffic, yes. Specially since most of items don't use infinite flag but cmon, 1 bit sized field?
There is the problem, BP info is not kept in the items table, and the join with the table its kept in is too costly. ------ Valar Quality assurance department CCP games How to write a good bugreport |
|
|
Valar
|
Posted - 2006.02.03 10:35:00 -
[14]
Originally by: j0sephine "Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar.
This *can* be done.. easily even... however, it will cause extreme load on the database."
If (and this is big if, but likely) each item has its own distinct id which is visible to the client, could there be some sort of client-side caching system introduced... that does this sort of lookup for each 'new' blueprint it encounters, then writes the result of query down for future reference, something like "item 102300001023 is blueprint copy" ... so then each time after that when this particular item is encountered again, the client can easily tell the nature of BP without having to bother the server about it? Since blueprints never change into copies and vice versa to my knowledge, there's no worry about that particular attribute of item ever changing. ^^;;
Of course its possible to cache the info, however, imagine opening "Show info" on all BPs in your corp hangar at once. Imagine hundreds of people doing that. Imagine the lag.
Really, we have put loads of time into trying to find a good way to do this. ------ Valar Quality assurance department CCP games How to write a good bugreport |
|
Dark Shikari
|
Posted - 2006.02.03 11:03:00 -
[15]
Originally by: Valar
Originally by: j0sephine "Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I. Thus, adding this change of color or image overlay would require an extra database call for each and every blueprint in your hangar.
This *can* be done.. easily even... however, it will cause extreme load on the database."
If (and this is big if, but likely) each item has its own distinct id which is visible to the client, could there be some sort of client-side caching system introduced... that does this sort of lookup for each 'new' blueprint it encounters, then writes the result of query down for future reference, something like "item 102300001023 is blueprint copy" ... so then each time after that when this particular item is encountered again, the client can easily tell the nature of BP without having to bother the server about it? Since blueprints never change into copies and vice versa to my knowledge, there's no worry about that particular attribute of item ever changing. ^^;;
Of course its possible to cache the info, however, imagine opening "Show info" on all BPs in your corp hangar at once. Imagine hundreds of people doing that. Imagine the lag.
Really, we have put loads of time into trying to find a good way to do this.
Question, Valar.
Before the manufacturing changes, when you opened your lab screen, it would show a WHOLE LIST of all your BPOs (in my case a few hundred), with their runs, ME, and PE. This would happen in a fraction of a second even in a lagged hub like Oursulaert.
How is it that you can say "we can't do it" when you did it for 2 years on one interface but not another? -- Proud member of the [23].
The Tachikomas are DEAD! Click sig for video.
|
Halo Jones
|
Posted - 2006.02.03 11:28:00 -
[16]
I thought that why they changed the system, wasn't that blueprint thing taking up 2% of the cluster or something massive? And it certainly wasn't instant when you had a large BPO hangar, I remember sitting with very long load times opening that thing, for every slot you needed to install to.
Oberon Carrier and Dreadnought Sales! |
dodge2005
|
Posted - 2006.02.03 11:57:00 -
[17]
Our corp has 100's of bps (in cans all be it) but everytime someone opens up the corp bp hanger an extra call is made to the database for EVERY blueprint there,
Opening a can/hanger with 100+ blueprints in it is bad for lag atm, now doing this would double the load efectivly???, one call for the blueprint one call for the picture? Think about it, its like opening a shuttle with 600 bm;s in it. That seriously laggs your client.
LAG TASTIC!
CCP are doing what they can, give them a break.
|
ArchenTheGreat
|
Posted - 2006.02.03 12:21:00 -
[18]
Originally by: Valar
Of course its possible to cache the info, however, imagine opening "Show info" on all BPs in your corp hangar at once. Imagine hundreds of people doing that. Imagine the lag.
Really, we have put loads of time into trying to find a good way to do this.
BTW can you cache MORE on the client side? I am talking about evemails and container items. Most of my killmail folders doesn't change too often. The same is with my containers. Make a flag (sent by server when checking mail) if mail folder is changed so client can get folder contents from cache. Even containers in corp hangars can be effectively cached in most cases. The flag can be a last change time or something similar.
|
Lothendra
|
Posted - 2006.02.03 13:53:00 -
[19]
Originally by: Valar Of course its possible to cache the info, however, imagine opening "Show info" on all BPs in your corp hangar at once. Imagine hundreds of people doing that. Imagine the lag.
So, stop them running a show-info on a hangar-full of items. Make them do it one-by-one. Oh, wait, they already do this when they need to find the single BPO out from their hangar full of copies... only this time, the client will keep the result cached for future use.
|
Ricky Baby
|
Posted - 2006.02.03 15:27:00 -
[20]
you have to query the bpc/bpo type (what it is 150mm rail bpo or a geddon bpc) to choose the image already so why dont you pull the infomation in the same go so instead of just bp_type you get bp_type and BP_runs and run some code like this:
if ( BP_RUNS == 'infinate' ) { $image == bp_pink_geddon; } else { $image == bp_blue_geddon }
or something
|
|
Selak Zorander
|
Posted - 2006.02.03 15:58:00 -
[21]
Originally by: Ricky Baby you have to query the bpc/bpo type (what it is 150mm rail bpo or a geddon bpc) to choose the image already so why dont you pull the infomation in the same go so instead of just bp_type you get bp_type and BP_runs and run some code like this:
if ( BP_RUNS == 'infinate' ) { $image == bp_pink_geddon; } else { $image == bp_blue_geddon }
or something
While i do not know exactly how the CCP database is set up, most Databases are not that simple. I work with a rather large one for work (but not nearly as large as the one for eve i bet). There are 70k items in the database i work with, and each item could have information in more than 40 different tables.
I bet the items table contains very little information like:
Unique item number Item name Item description Item icon
If the item then happens to be a blueprint for instance then there is prolly a table for research needs, a table for build needs, a table for skills required to build it, original stats (like build time, research time, base wastage, productivity lvl). There is probably yet another table that contains information on any research done to the print or maybe if its a copy and whether or not there are any runs remaining.
AS you can tell, databases can get very confusing very quick and depending on how they are linked, the so called simple check of the number of runs remaining may actually involve search through 5 or more tables and getting info off each table.
Even then I am prolly short on a bunch of the different tables and it is likely to be even more complex than i have described it.
|
Lothendra
|
Posted - 2006.02.03 16:07:00 -
[22]
Caching the number of runs left, ME and PE level would be a waste of time, since that information could change without the cache being updated.
The status of a blueprint, being an original or a copy, will never change and so is a perfect candidate to be cached on the client.
|
Zarch AlDain
|
Posted - 2006.02.03 16:16:00 -
[23]
Guys, this is embarissing.
The devs know basic code, and SQL. Probably better than most of you. Please stop making us all look foolish.
What is probably happening is that there is a generic engine which pulls back details of an item and then displays it. That engine pulls back the info that is common to all items. Asking it to pull back extra info would require an extra query. Yes stuff could be done with outer joins and suchlike but it would add complexity and specifics to a generic engine - this is a bad thing.
The suggestion of caching the data in the client is a new, and very good, one - everyone else is suggesting something that the devs will have already considered. I do this sort of thing for a living and it's not as simple as you seem to think to add something like this to an already large and complex system.
|
j0sephine
|
Posted - 2006.02.03 19:06:00 -
[24]
"Of course its possible to cache the info, however, imagine opening "Show info" on all BPs in your corp hangar at once. Imagine hundreds of people doing that. Imagine the lag.
Really, we have put loads of time into trying to find a good way to do this."
Probably doesn't have much relevance, but the way i dealt with similar issue was to put a sort of scheduler in the system. That is, instead of sending all requests and trying to load everything at once, there's a sort of client-side queue which registers list of requests that need to be made ... and then performs them at rate that's considered 'suitable' at the moment.
The advantage of it is, the user opens their hangar once and doesn't get immediate benefit of seeing difference between copies and originals... but while they keep playing, the client can update info on the nature of BPO at slow rate (say, one query a minute or even less) ... and then next time the hangar is opened, chances are the info shown to player will be more accurate. That without bogging down the database too much (especially if matching, global scheduler is on the server end to throttle global flow of such queries as well) ... since it's not critical to get this kind of info immediately, this kind of delayed update doesn't matter much. ^^;;
|
Dutarro
|
Posted - 2006.02.03 20:11:00 -
[25]
The EVE client cannot easily peek at item attributes, therefore it cannot distinguish between BPO and BPC because they are the same item type. Assuming that paraphrase is accurate...
OK then, why not make BPO's and BPC's separate item types? For example take a manufacturable item type like Small Shield Booster I. You end up with 3 item types for it:
1) the shield booster itself 2) a shield booster BPO 3) a shield booster BPC
Existing BPC's could be converted to the new item type during downtime in one sweep. Two BP item types = two images and you're done.
Yes you end up with twice as many blueprint entries in the item-type table, but is that really such a bad thing? That table is still teeny-tiny compared to the table of actual blueprints.
|
Trak Cranker
|
Posted - 2006.02.04 10:34:00 -
[26]
Yeah, what is needed is of course that copies become separate types.
I would not like to guess what kind of code needs to be changed in order to handle that blueprints can now be two different types. Although I should think that in OO based code and with the already established groupIDs, that should be somewhat straightforward. Not saying fast. But managable.
As Valar says; It comes at the risk of item corruption. But thats what tests are for, I would assume.
If it WAS super easy, then I am _pretty_ sure they would have done it by now. But its something that needs to be brought up now and again, so they keep thinking about it subconciously at least. :) Who knows? The solution might just come up. Please resize your signature so that it is within the forum rule size limits - Jacques |
elFarto
|
Posted - 2006.02.05 18:46:00 -
[27]
Originally by: Valar Its the scan for the "infinite" flag thats the problem. Your EVE client doesn't know about the infinite flag until you do a show info on the blueprint or try to use it in S&I.
In the table that holds all the items, what columns are there? I'm guessing something like itemId, typeId, stackSize, damage...?
Could you 'hi-jack' the damage column to hold the amount of runs left, or -1 if it's a BPO?
Regards elFarto
npc.elfarto.com > Ingame NPC database T2 Mod Resistant SigÖ |
Joerd Toastius
|
Posted - 2006.02.05 19:14:00 -
[28]
That does nothing to help - it just means it has to query a different value in the same table.
|
K Shara
|
Posted - 2006.02.06 12:22:00 -
[29]
of course you could make new items for every BPO and just do a system scan and mass replace every bp with the infinate flag with a new item BPO
or allow people to trade the infinate BPC for the new BPO
|
Ayla Vanir
|
Posted - 2006.02.07 01:28:00 -
[30]
Edited by: Ayla Vanir on 07/02/2006 01:29:52 [Posted to the wrong thread
Escrow Market Revamp
|
|
|
|
|
Pages: [1] 2 3 :: one page |
First page | Previous page | Next page | Last page |