Pages: 1 2 3 4 5 6 [7] 8 9 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 29 post(s) |
Imhothar Xarodit
Minmatar Wolverine Solutions
|
Posted - 2008.09.26 19:37:00 -
[181]
Anything new on the topic "re-use the quantity field with number of runs on singular blueprints to distinguish from originals"?
That is a solution that from my point of view requires the least work. 1. No database table redefinitions. 2. No new item/blueprint types. 3. No additional queries on inventory lookups. 4. Works as soon as a BPC has been used. 5. Needs special treatment on the client's icon display. 6. The quantity fields needs to be up-to-date with the number of runs. 7. An automatable DB update on patch day.
It all boils down to how easy numbers 5 and 6 are implementable.
|
Zinnn
|
Posted - 2008.09.27 05:16:00 -
[182]
Edited by: Zinnn on 27/09/2008 05:20:21 Why not just add an O or a C to the top right corner of the blueprints? If you can do T1 and T2 distinguishing, why not just a simple O or a C? Doesn't have to be hugely complicated. Blue C maybe, Red O... you know, for the color blind...
Why not make that bit of code, if it's going to be extensible to make a differentiation, why not keep that coded information in cache on the local machine so you do not have to use a lookup? or does that change the entire structure of things on the server/client end?.... anyway..
Anyway, just a thought.
|
|
CCP Lingorm
C C P
|
Posted - 2008.09.27 10:48:00 -
[183]
Originally by: Imhothar Xarodit Anything new on the topic "re-use the quantity field with number of runs on singular blueprints to distinguish from originals"?
That is a solution that from my point of view requires the least work. 1. No database table redefinitions. 2. No new item/blueprint types. 3. No additional queries on inventory lookups. 4. Works as soon as a BPC has been used. 5. Needs special treatment on the client's icon display. 6. The quantity fields needs to be up-to-date with the number of runs. 7. An automatable DB update on patch day.
It all boils down to how easy numbers 5 and 6 are implementable.
See my post before yours (last post on page 6), your solution woudl involve all the same changes to all the same systems. Not really doable.
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.09.27 10:49:00 -
[184]
Originally by: Zinnn Edited by: Zinnn on 27/09/2008 05:20:21 Why not just add an O or a C to the top right corner of the blueprints? If you can do T1 and T2 distinguishing, why not just a simple O or a C? Doesn't have to be hugely complicated. Blue C maybe, Red O... you know, for the color blind...
Why not make that bit of code, if it's going to be extensible to make a differentiation, why not keep that coded information in cache on the local machine so you do not have to use a lookup? or does that change the entire structure of things on the server/client end?.... anyway..
Anyway, just a thought.
Because Tech 1 and Tech 2 items are seperate items as far as the Database is concerned (they have different item ID's and thus different Icons associated with them). They do not use the same Icon with a "II" added to 1 corner, these are seperate Icons, 1 with a "II" and 1 without.
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.
|
|
Nova Fox
Gallente Novafox Shipyards
|
Posted - 2008.09.28 06:57:00 -
[185]
So if i get this right.
All blueprint are attached to the item they make and are integeral part of its inofmration or vice versa.
Because of this copies are technically the same thing as original with one difference but it still doesnt change the fact its still a part of that item.
And from what I understand serparating the item tags to create 2 new groups (bpos and bpcs) would be an extrondinary hassel as supposivly every item has a blue print resulting in man years worth of rewriting that may ultimately drag eve down further the lab path as you have a not so slim database anymore.
as much as I slam my head on this problem I see no really good comprimise of system performance for our ease unless you manage to make copies a subitem of the same item similar to the blueprint original is /\>------------------------------V {[Blueprint Original] Item [Blueprint copy]}
Pre Order your Sisters of Eve ship today!!! |
Imhothar Xarodit
Minmatar Wolverine Solutions
|
Posted - 2008.09.28 11:24:00 -
[186]
Edited by: Imhothar Xarodit on 28/09/2008 11:24:36
Originally by: CCP Lingorm See my post before yours (last post on page 6), your solution woudl involve all the same changes to all the same systems. Not really doable.
Ok, lemme try this out.
Quote: And what about the changes to the system for creating copies,
Isn't creating copies already a special job, as you have to create a new item with number of runs on it. Would require an update to the inventory table (quantity field).
Quote: the changes to manufacturing that then needs to changed different values depending if you are building from a BPO or a BPC,
Uhm, doesn't this already have to be treated specially? Like destroy a BPC if it was a copy and its runs were used up, reduce a copies runs left as opposed to a BPO? Would need to extend this step with an update on the quantity field.
Quote: you would also need to rebuild the Invention system to now use the new BPC items not the BPO items (cos the 2 are different now).
This is not a concern with my solution as there are no new typeIDs required.
Quote: Then you need to test ALL of these changes and that would take longer than all the code changes because you have changed so many ground level systems that you would need to explicitly test the manufacture of every item from both BPO and BPC to make sure it is working properly, then test the refine to make sure that it is refining correctly (because the refine system is linked to BPO's), then test every possible invention permutation to make sure you had not changed something and invention no longer worked.
Most things you mention here are based on new/multiple blueprint typeIDs for BPO/BPC, that is again not a concern as my proposal doesn't involve any new typeIDs. As for the tests: All Blueprint types have also "Blueprint" in their name, so you can get those out with a query. Or use the invBlueprintTypes table instead. Point is, getting the list of affected typeIDs (namely blueprints) isn't an issue and could be thrown into an array on the client side to (combined with the quantity field) distinguish copy from original. Quote: Modify the loot drops for ALL entities that drop BPC's to make sure they drop the new BPC item. then all the Agent LP Store offers that offer BPC's and make sure all of these are changed.
After that you would need to test the Loot drop system and the LP store to make sure that these changes are working correctly.
And that list is just off the top of my head ... I am sure that I can come up with some more if I really put my mind to it ...
But I could be wrong ... it is JUST 1 LINE OF CODE after all. Shocked
This all doesn't seem to be related to my solution. I stil believe it is doable, with the least working overhead of all the other solutions so far. Maybe I missed some critical issue but right now I can't find any. The thing is that my proposal does not involve any database changes, and no additional queries on inventory listings. Has this be brought to the actual Coders doing this production/inventory thing? And believe me, I know that nothing is ever "JUST 1 LINE OF CODE" and never will be
|
Draygo Korvan
Merch Industrial GoonSwarm
|
Posted - 2008.09.28 21:03:00 -
[187]
Edited by: Draygo Korvan on 28/09/2008 21:03:29 I'm posting this here because its related:
Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail. --
|
|
CCP Lingorm
C C P
|
Posted - 2008.09.29 09:49:00 -
[188]
Originally by: Imhothar Xarodit Isn't creating copies already a special job, as you have to create a new item with number of runs on it. Would require an update to the inventory table (quantity field).
Yes creating copies is a special job, but rather than modify the assigned attribute in the normalised scheme you now want it to changes to 'amount' variable in the item table, so this code will have to be tested.
Quote: Uhm, doesn't this already have to be treated specially? Like destroy a BPC if it was a copy and its runs were used up, reduce a copies runs left as opposed to a BPO? Would need to extend this step with an update on the quantity field.
Yes, but we would now have to change the field that that it is checking for the amount of runs and retest it all.
Quote: This is not a concern with my solution as there are no new typeIDs required.
Not true, the available bpc list for invention needs to change it's filter to filter on the amount field rather than the normalised field. And then it needs to be retested to make sure it works in all cases.
Quote: Most things you mention here are based on new/multiple blueprint typeIDs for BPO/BPC, that is again not a concern as my proposal doesn't involve any new typeIDs. As for the tests: All Blueprint types have also "Blueprint" in their name, so you can get those out with a query. Or use the invBlueprintTypes table instead. Point is, getting the list of affected typeIDs (namely blueprints) isn't an issue and could be thrown into an array on the client side to (combined with the quantity field) distinguish copy from original. Usual singleton items would have a quantity of 1 as it is now. If a singleton blueprint, it's number of runs would be -1 (or the equivalent used with BPO number of runs) and if quantity on a blueprint typeID was >= 1 it would be a BPC with quantity as its number of runs left. Exposing this field to the EVE API as it is now would also mean one could distinguish copy from original in asset list exports.
The code changes are minimal compared to the amount of testing that would be involved. Because you are changing fundamental parts of some very low level systems, if they break then it would be a major problem for EVE. So sorry they entire thing would have to be retested rather extensively.
Quote: This all doesn't seem to be related to my solution. I stil believe it is doable, with the least working overhead of all the other solutions so far. Maybe I missed some critical issue but right now I can't find any. The thing is that my proposal does not involve any database changes, no new artifial typeIDs and no additional queries on inventory listings. Has this be brought to the actual Coders doing this production/inventory thing? And believe me, I know that nothing is ever "JUST 1 LINE OF CODE" and never will be
Yes actually it is. BPC'c dropped and bpc's created through the LP system use the same mechanics as the copy process, so they would need to be tested to make sure they are working correctly. It would not be good to drop a Machariel BPO instead of a BPC now would 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.
|
|
|
CCP Lingorm
C C P
|
Posted - 2008.09.29 09:53:00 -
[189]
Originally by: Draygo Korvan Edited by: Draygo Korvan on 28/09/2008 21:03:29 I'm posting this here because its related:
Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail.
Nope.
Speaking as a carebear I find it rather amusing when a piewat goes off and gloats about all the BPO's he has killed, when in actual fact they are all bpc's and it was a 50/50 decision to either move them and give them away to corp members or just trash them. In fact I know of a couple of instances where people tried to give them away in local first, when no one replied they loaded them in a shuttle and set of on autopilot hoping to get ganked to lump them on someone else....
All joking aside. This would add additional load to the killmail system as it would need to do an additional query to the db to get this information, exactly the same reason we do not do it for the inventory system. So my guess is that this will not happen.
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.
|
|
Imhothar Xarodit
Minmatar Wolverine Solutions
|
Posted - 2008.09.29 16:48:00 -
[190]
Originally by: CCP Lingorm Yes creating copies is a special job, but rather than modify the assigned attribute in the normalised scheme you now want it to changes to 'amount' variable in the item table, so this code will have to be tested. (...) Yes, but we would now have to change the field that that it is checking for the amount of runs and retest it all. (...) Not true, the available bpc list for invention needs to change it's filter to filter on the amount field rather than the normalised field. And then it needs to be retested to make sure it works in all cases. (...) The code changes are minimal compared to the amount of testing that would be involved. Because you are changing fundamental parts of some very low level systems, if they break then it would be a major problem for EVE. So sorry they entire thing would have to be retested rather extensively. (...) Yes actually it is. BPC'c dropped and bpc's created through the LP system use the same mechanics as the copy process, so they would need to be tested to make sure they are working correctly. It would not be good to drop a Machariel BPO instead of a BPC now would it.
Looks like there is some misunderstanding here. I was not proposing to shift the normalized field to the inventory table and let all systems deal with that, that is too much, all systems should stil work with the normalized value as that is already working fine. The suggestion merely implies giving the quantitiy field an additional meaning that is in fact only interesting for the client which does not have immediate access to the normalized table on an inventory query. As I already mentioned, this all would only work after a BPC has been assembled/used so its singleton attribute is true. As that is the key to making the quantity field rather useless (except some other services rely on it, that i don't know). So the example with the Machariel BPO can't happen as it is not a singular item (afair). But even if it was, the deal is to have the quantity field only as additional hint for the client, not be used by the server-side S&I procedures. |
|
|
CCP Lingorm
C C P
|
Posted - 2008.09.29 17:12:00 -
[191]
Originally by: Imhothar Xarodit Looks like there is some misunderstanding here. I was not proposing to shift the normalized field to the inventory table and let all systems deal with that, that is too much, all systems should stil work with the normalized value as that is already working fine. The suggestion merely implies giving the quantitiy field an additional meaning that is in fact only interesting for the client which does not have immediate access to the normalized table on an inventory query. As I already mentioned, this all would only work after a BPC has been assembled/used so its singleton attribute is true. As that is the key to making the quantity field rather useless (except some other services rely on it, that i don't know). So the example with the Machariel BPO can't happen as it is not a singular item (afair). But even if it was, the deal is to have the quantity field only as additional hint for the client, not be used by the server-side S&I procedures.
Ah I see.
So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...
I will pass it along to software ...
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.
|
|
Imhothar Xarodit
Minmatar Wolverine Solutions
|
Posted - 2008.09.29 21:20:00 -
[192]
Edited by: Imhothar Xarodit on 29/09/2008 21:20:46
Originally by: CCP Lingorm Ah I see.
So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...
I will pass it along to software ...
Exactly, thank you.
With some more tinkering you could even manage to remove the need for the client to check every item's typeID if its a blueprint typeID. If it does already, then fine, but if not the check can be removed by giving the quantity field a strict value system. Example: A singleton BPO has a quantity of -1 A singleton BPC has a quantity of > 0 Any other items have a quantity of <= 0
This way if the client encounters a singleton item with the quantity attribute larger than zero it immediately knows it must be a BPC and can take the number to for example display it on the blueprint icon in the top right corner (so it won't be confused with the quantity counter) and/or give it a different color/border/whatever.
The only problem here is for procedures that rely on the quantity field to be 1 for singleton items. How far that is stretched I can't tell. |
Nova Fox
Gallente Novafox Shipyards
|
Posted - 2008.09.30 00:26:00 -
[193]
I think the new color of the copies should be white, this contrast will be sharp enough for color blind people
Pre Order your Sisters of Eve ship today!!! |
Draygo Korvan
Merch Industrial GoonSwarm
|
Posted - 2008.09.30 06:24:00 -
[194]
Originally by: CCP Lingorm
Originally by: Draygo Korvan Edited by: Draygo Korvan on 28/09/2008 21:03:29 I'm posting this here because its related:
Can we have BPO's and BPC's distinguished in Killmails. Its not every second that a bpo/bpc is destroyed in a ship and I would find it useful to know this information in the killmail.
Nope.
Speaking as a carebear I find it rather amusing when a piewat goes off and gloats about all the BPO's he has killed, when in actual fact they are all bpc's and it was a 50/50 decision to either move them and give them away to corp members or just trash them. In fact I know of a couple of instances where people tried to give them away in local first, when no one replied they loaded them in a shuttle and set of on autopilot hoping to get ganked to lump them on someone else....
All joking aside. This would add additional load to the killmail system as it would need to do an additional query to the db to get this information, exactly the same reason we do not do it for the inventory system. So my guess is that this will not happen.
One does not bring bpo/bpc's to fleet (laggy) combat. You can always have a lag check before bothering to query. Or you can assume they are copies because that is the most likely case. I dont think people losing bpo's bpc's happens as fast as people shuffling through their inventory. The additional load should be minimal. I think the sacrifice would be worth it. --
|
Katana Seiko
Gallente
|
Posted - 2008.10.02 08:23:00 -
[195]
Originally by: Nova Fox I think the new color of the copies should be white, this contrast will be sharp enough for color blind people
Okay, that's a design question. I for my part don't like white icons. I think that BPCs should have more of a "used" look. If the icon looks like it's torn at some place or a little piece has been ripped off, that's way better (imo). You would have to be allmost blind to miss that one (and no, blind people don't play EVE, we don't need special icons for them). --- "Multiple exclamation marks are a sure sign for a diseased mind." -Terry Pratchett |
Tobin Shalim
Vulcan Foundry
|
Posted - 2008.10.04 20:23:00 -
[196]
Ok, coming from someone that has little/no DB experience aside from some very basic Access DB's I've written, I'm not so sure how well received this idea will be, but here goes....
Lingnorm, I don't see how there would be much in the way of additional DB coding that needs to be done for this, since you basically have it in there right now. Looking in my corps hanger I have a BPO, and a BPC done from that original print. I can open up the show info tab on both and see very clearly that it says the following: Original Blueprint for the BPO and: Blueprint Copy (yes, I know it's not blue, but grey doesn't work for a color on the forum).
Now, you apparently already have the DB calls in place for distinguishing the copies from the originals, so would it really be that much harder to point the DB entries that return a copy yes/no check (I'm assuming that's what you have in place, but whatever system you have would also work) to a separate icon created just for the copies? You must have something going on already for icons that are called for inventory/market queries in order for us to get the correctly displayed icons for our items, so since the distinction for originals/copies is existing, why can't you just have the copies pointed to a differently colored icon for the BPC's? -----
Originally by: Haakkon I feel a great deal of patriotism at being a part of Goonswarm. We've accomplished great things... we're just mainly jerks about it
|
|
CCP Lingorm
C C P
|
Posted - 2008.10.06 09:46:00 -
[197]
Originally by: Tobin Shalim Ok, coming from someone that has little/no DB experience aside from some very basic Access DB's I've written, I'm not so sure how well received this idea will be, but here goes....
Lingnorm, I don't see how there would be much in the way of additional DB coding that needs to be done for this, since you basically have it in there right now. Looking in my corps hanger I have a BPO, and a BPC done from that original print. I can open up the show info tab on both and see very clearly that it says the following: Original Blueprint for the BPO and: Blueprint Copy (yes, I know it's not blue, but grey doesn't work for a color on the forum).
Now, you apparently already have the DB calls in place for distinguishing the copies from the originals, so would it really be that much harder to point the DB entries that return a copy yes/no check (I'm assuming that's what you have in place, but whatever system you have would also work) to a separate icon created just for the copies? You must have something going on already for icons that are called for inventory/market queries in order for us to get the correctly displayed icons for our items, so since the distinction for originals/copies is existing, why can't you just have the copies pointed to a differently colored icon for the BPC's?
Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.
When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.
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.
|
|
Tobin Shalim
Vulcan Foundry
|
Posted - 2008.10.06 15:42:00 -
[198]
Originally by: CCP Lingorm
Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.
When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.
Couple questions:
1. Would it be too slow to use the 'Show Info' calls for blueprints only to distinguish which are copies vs. originals and then apply the correct icon? (see #1a)
1a. If there is already coding in the DB for a certain item to be assigned a certain ID for the proper icon (ex. Kestrel BPO ID: 1, it then goes through the listing of icons until it finds iconID: 1 and applies to the UI), and there is existing coding as you said for the 'Show Info' query, could it be possible to add this coding for just the blueprints so that it runs a check if it's a BPC and then finds the proper icon for that?
2. Could this coding be done for just blueprints? From what I gather, there are assigned 'categories' for each item type, so I would think the blueprints have their own group ID which would make doing this on the DB side rather easy (but I'm not a DB Admin). -----
Originally by: Haakkon I feel a great deal of patriotism at being a part of Goonswarm. We've accomplished great things... we're just mainly jerks about it
|
|
CCP Lingorm
C C P
|
Posted - 2008.10.06 16:53:00 -
[199]
Originally by: Tobin Shalim
Originally by: CCP Lingorm
Yes the information is in the Database but it is not returned with a simple asset list as the amount of work the Database would have to do is prohibitive.
When you do a 'Show Info' It goes and retrieves the information for this item only so that it can display the information.
Couple questions:
1. Would it be too slow to use the 'Show Info' calls for blueprints only to distinguish which are copies vs. originals and then apply the correct icon? (see #1a)
1a. If there is already coding in the DB for a certain item to be assigned a certain ID for the proper icon (ex. Kestrel BPO ID: 1, it then goes through the listing of icons until it finds iconID: 1 and applies to the UI), and there is existing coding as you said for the 'Show Info' query, could it be possible to add this coding for just the blueprints so that it runs a check if it's a BPC and then finds the proper icon for that?
2. Could this coding be done for just blueprints? From what I gather, there are assigned 'categories' for each item type, so I would think the blueprints have their own group ID which would make doing this on the DB side rather easy (but I'm not a DB Admin).
This has been discussed previously in this thread.
The answers are there.
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.
|
|
Nova Fox
Gallente Novafox Shipyards
|
Posted - 2008.10.10 16:47:00 -
[200]
Originally by: CCP Lingorm Ah I see.
So all that would be needed is a Server side trigger that keeps the 'runsRemaining' Normalised attribute the same as the Amount inventory attribute for Singletons ... interesting idea ...
I will pass it along to software ... [/quote
Any update on this?
Pre Order your Sisters of Eve ship today!!! |
|
Zifrian
Gallente Chapter Black TRUST Coalition
|
Posted - 2008.10.11 22:05:00 -
[201]
What about giving us the ability to right click the item and color it or something similar. Right now items in a audit container have values associated with them that makes them locked or unlocked. Is there anyway we can use this type of function to mark the item? I'm assuming it would need a new variable but this would be on the object, not the base item for the icon right?
I'm just trying to think outside of the system you have in place since it seems like changing that isn't possible, with good reason.
|
Lothendra
Gallente
|
Posted - 2008.10.12 13:44:00 -
[202]
On a related note, is there any particular reason why we can't repackage an unresearched BPO?
|
Jed Clampett
|
Posted - 2008.10.15 08:12:00 -
[203]
They could change the general inventory query by adding a couple operations to split out the Blueprints and append the blueprints at the end. That way the join for copy/original info would only need to be against blueprints.
This would minimize server loading -- particularly when their work around still involves a join with this type of information.
Code would be slightly more complex and not as elegant. And yes some work would be done for people who don't give fly crap about blueprint info....
|
Jed Clampett
|
Posted - 2008.10.15 08:20:00 -
[204]
The obvious solution is to handle Blueprints much like Ships for inventory purposes.
Add a separate inventory tab just for Blueprints which shows that BPC/BPO ME/PE info. Let people who don't care merge inventory and not show that info.
Of course you need to improve Assets windows to show this for remote locations. I am sure a similar change can be made. Such a change might even address other issues with sorting Assets.
And finally there is no reason BPCs don't have like a yellow outline in Contracts. After all the number items being shown is usually one and even when opening multiple item slections, there are seldom truly large numbers of items.
|
Malik Mantille
Minmatar Dark Sun Collective
|
Posted - 2008.10.17 08:40:00 -
[205]
Edited by: Malik Mantille on 17/10/2008 08:45:47 Currently I keep bpc and bpo seperate in cans. I seperate these based on my personal knowledge of what they are. This of course in no way effects the database. To avoid a database transaction increase, how bout we simply create user per item flags, client side of course.
I highlight all my bpcs, I label them "BPC" and have a user selectable letter overlay (not part of the actual icon) that would be placed on icon in the top left (similar to t2, but not an image, just a text overlay)
so you have
[held due to lack of ascii art in forums..hold for image]
where X is the blank area that allows for the iconic overlay. Being as it is just text, it'd not be a tax on the system.
this would also not be just for the industrialists, If you don't enjoy sorting things in station cans, you could simply enjoy being able to group these items, say your pvp fit versus mission fit items in you stations
M / P you could choose as the arbitrary upper left character and this would allow you a quick glance at what is what based on your choice factors all done client side. it would of course require some work, but there is zero db side interaction so its still a decent workaround.
In conjunction with this, it may be as well good to add a "view" option for hangers.. I wanna see all my pvp fit items, since I can name the item grouping myself (pvp tackler crow) it'll have the same P overlay that all other pvp items I've grouped have, except when it comes to my choice view. So, If i have two ship fits both pvp, one for my crow, one for my jaguar I can select pvp tackler crow and those pvp jaguar mapped items will not be shown.
the data required for this would be small client side.
data:
"Label title" "overlay character" "item number" 32 char 1char int
------
|
Rev Russ
|
Posted - 2008.10.17 21:37:00 -
[206]
Can you please add an export button within the Science & Industry window for both corp and individual Blueprints?
The export would be csv or excel and include all the fields listed in the window including bp name, station location, me, pe, runs, copy(yes or no). And as a bonus, include the material requirements :) Please!!!
This would help me greatly in creating and updating my BPC and BPO inventory.
I also think this would help reduce the frustration of BPC's not stacking, and not being able to distinguish a bpc from bpo. Lets be honest, its only frustrating when you are updating your inventory.
Also, maybe create an export for outstanding contracts as well... but thats a different topic.
|
Molishero
|
Posted - 2008.10.31 20:04:00 -
[207]
Edited by: Molishero on 31/10/2008 20:04:58 Should run client-side, outside of database. A client side fix would solve any BPO/BPC server-side network lag. This is just an example of a client side solution to this problem. If anything this would cause a slight drop in client performance but only to those who deal with 50+ blueprints at a time.
Quote:
if {blueprint.runs = "infinite"} then //Sees if the bp is a BPO bp_tex.image = 1 //If so then it changes to the BPO icon else bp_tex.image = 2 //If not then it changes to the BPC icon end if
Now I have no idea how the coding works for Eve but this is a decent example of what can be done.
Now for labs and research, why not just add an extra info slot that says how many runs are left in the BP?
|
ChaoticDemon
|
Posted - 2008.11.02 19:43:00 -
[208]
How about just making sort by type always put originals first at least then wouldn't have to search every bp just to find your original and put in a container also a pain if you accidently repack you container
|
Mister Xerox
|
Posted - 2008.11.06 11:07:00 -
[209]
Originally by: CCP Lingorm Hope that answers all the questions and brings this thread upto date with a wall of black and blue.
Hey, uh, guys... how difficult would it be to add a layer mask?
If it's a BPO (-1 runs) = Layer mask (to make it blue) If it's a BPC (+X runs) = No layer mask (it's just plain gray/white).
Yes, it would be very handy to see runs remaining as we see with ammo stacks, but if it would be to heavy on the DB then we can forgo that. But I don't see how a simple client-rendered mask/nomask would be so heavy on the engine. Note: Client rendered, so no additional server calls are required. The client querries the server and layers the items as they're parsed.
|
Shin Hu
|
Posted - 2008.11.06 15:41:00 -
[210]
Originally by: Mister Xerox
Originally by: CCP Lingorm Hope that answers all the questions and brings this thread upto date with a wall of black and blue.
Hey, uh, guys... how difficult would it be to add a layer mask?
If it's a BPO (-1 runs) = Layer mask (to make it blue) If it's a BPC (+X runs) = No layer mask (it's just plain gray/white).
Yes, it would be very handy to see runs remaining as we see with ammo stacks, but if it would be to heavy on the DB then we can forgo that. But I don't see how a simple client-rendered mask/nomask would be so heavy on the engine. Note: Client rendered, so no additional server calls are required. The client querries the server and layers the items as they're parsed.
Ok, again. The point is: There is no Run-Entry in the Inventory-list! The Inventorylist is a plain db table just with basic informations that is usefull for all itemtypes. ME/PE/Copy/Runs/... are just informations for BP's. These fields would be empty (in best case just existent with a few bytes, but as this depends on SQL EACH field would be as big as the field is, long int(16Bytes) for example), but still be loaded during query of each and every inventorylisting. Just for BP Issue there are 6 fields + on a that table which will most likely double the fields in that (and therefore double DB load).
If i understand the database correct from statement in this Topic there are 3 Tables: Genereal Inventory-Table and spezific Iteminformation. Both are connected to a third table with general Iteminformations.
So you get in general-itemtable info about the item itself. What build-requirements and materiallist etc. NO me and NO pe OR run on those. Just info what that type of item do for ME0/PE0. Now there is the 2nd Table of spezific item information. In that table are just the item-ID from the general-itemtable, ME, PE and RUN Information. Now, if you list your inventory this polls your inventory-table and this give info what item it is from the general-table, as this has a fix amount of data (just as many as items are in game) and the related information where to fin details in the spezific table. The query on the spezific table is not done in this stage as this would mean a mass overload on information and just imagine how many items are there in game!
The best solution would be the idea with just use the field where the amount of an item ist stored to be used as informationfield if this is an bpo or not. As items generaly have the ability to be repacked or not this field would be an boolean (1 bit). Just make this a 2 bit field an set states as follow: 0=Repacked 1=assembled (items like ships, modules etc) 2=BPO 3=BPC
now you could use the amount-field for whatever you want as long as you just parse this field by the client like: first 6 bit=runs, next 6=me, next6=pe. I don't know how long this field is exactly but as you can have some billion Tritanium in one stack even a field length of 8 bit each would be possible. As there are BP's with 1500 runs available the run-bit would have to be 9 bit at least. As ME/PE on smaller BP's is sometimes also >1000 3x 10bit would be fine for most cases. This way you would even be able to display that information directly in the client with just one field an nearly no extraload on DB as the parsing of the amount-field could do the client (should be simple to implement to do such parsing depending on state of "package").
|
|
|
|
|
Pages: 1 2 3 4 5 6 [7] 8 9 :: one page |
First page | Previous page | Next page | Last page |