EVE Search - Make BPOs and BPCs distinguishable

Search EVE-Online forums for:

All Channels

Features and Ideas Discussion

Make BPOs and BPCs distinguishable

Monitor this thread via RSS [?]

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

Author	Topic
Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.15 01:25:00 - [151] "itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity" Can you use the typeID to sort them differently in the hanger? Right now if you sort BP's by type, the BPO's end up at the end or beginning of the BPO/C's you have. If I have 10 Atron BPC's and 1 Atron BPO plus 10 Tristan BPC's and 1 Tristan BPO, it'll be 10 Atron copies, then the Atron orginal followed by 10 tristan copies and 1 original. If the type sort works this way, is there any way to sort BPO's first then BPC's so you have Atron BPO then Tristan BPO then the copies? It seems that BPO's and BPC's are handled differently by the type sort, so is there any way to use that even if the icons are the same? Also, I think someone said it earlier, ME and PE in the assets window would be nice. I don't have the database files on this computer atm but I'm downloading them to take a look at what you described. Not sure if my question above is doable but I'll edit it if not :p
Rashmika Clavain Gallente Revelation Space	Posted - 2008.08.18 10:01:00 - [152] Edited by: Rashmika Clavain on 18/08/2008 10:05:16 Jesus what part of "heavily normalised" database are people missing? Listing the BPO's status in the database as either BPO or BPC fracks the normalisation. At a very basic level, normalisation works to remove duplicated entries, ie: 001 Chimera BPO 002 Thorax BPO 003 Catalyst BPO 004 Vexor BPC 005 Enyo BPC to: 001 Chimera 002 Thorax 003 Catalyst 004 Vexor 005 Enyo With possibly a link to another table for BPO/BPC status via the ID. It's not about the ease of adding a new database tag/column or whatever. It's about adding duplicated data thus breaking the normalised model. Even if you add item tags such as "A" for BPO and "B" for BPC, you're still adding duplicated data which needs to be normalised. That said, a query window would be helpful, but I doubt the effort needed would be worth it. Personally I store my BPO's in can1, my single run BPC's in can2 and my max run BPC's in can3. It's not hard, but as with most things in EVE, people see fit to whine until CCP takes them away from the fire because they're burning. /rant off Removed. Please keep your EVE signature related to your EVE persona and not that of a real life politician. Navigator
Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.18 11:48:00 - [153] While you have a great can method that works for you, there are about 5 other instances where I have issues with not being able to determine BPC's and BPO's visually or by some identifier. I think the problem here though is not the icon, it's having some way to identify the BPC's and BPO's. You can't do it in the asset window and the functionality of the science and technology interface doesn't allow you to select multiples or transfer the BP's to another container or something else. I think the best solution to the problem here is not to change the icon, because by CCP's database structure doesn't allow that to happen easily, but to change the way we can view them in the UI. Then it seems that there is a solution that can be reached. The information is already there, it is shown on the UI now in some areas so it can be used to help distinguish the BP's apart. The areas I can think for UI support that I would find useful are to have a designator in the asset window for BPC or BPO, possibly with ME and PE, and the ability to select multiple BP's from the sci/tech window for contacting purposes. Also a sorting function that puts all BPO's first, then BPC's would helpful if it's possible (I think my earlier post on this wasn't correct).
Matthew Caldari BloodStar Technologies	Posted - 2008.08.18 22:09:00 - [154] Originally by: Zifrian Can you use the typeID to sort them differently in the hanger? Right now if you sort BP's by type, the BPO's end up at the end or beginning of the BPO/C's you have. If I have 10 Atron BPC's and 1 Atron BPO plus 10 Tristan BPC's and 1 Tristan BPO, it'll be 10 Atron copies, then the Atron orginal followed by 10 tristan copies and 1 original. Copies and originals have the same typeID. The effect you are describing probably occurs because of the secondary sorting criteria. i.e. when you sort by Type, how does it decide the order of items that are the same Type? My guess would be that it falls back on the itemID, as that is the only value guaranteed to be unique. So it will sort by typeID first, but then sort by itemID within each typeID. Now, assuming that all the copies present have been produced in one batch, they are likely (but not guaranteed) to have itemID's in a similar range. It is more likely for a BPO to have an itemID outside that range than within it, hence why the BPO is likely to graviate to one end of the sort or the other. While this happens often enough to be an observable pattern, it is not something the system is designed specifically to do, and not something that it is guaranteed to do every time. In order to guarantee it happening, you would have to special-case a reserved range of itemID's for BPO's either at the top or bottom of the range, to ensure the BPC's could not be given itemID's on both sides of the BPO values. Which would be a horrible dirty hack, and potentially cause problems with the itemID capacity management and recycling.
Zifrian Gallente Blackstone Technologies Inc. Lords of the Damned	Posted - 2008.08.18 22:42:00 - [155] Yeah, I don't think the sort thing worked right. Sometimes it does, other times it doesn't.
Xailia Unsteady Corporation	Posted - 2008.08.24 06:06:00 - [156] The only solutions that seem viable are either a local cache (single machine), a workaround (ugly), or a switch from a RDBMS to an ORDBMS (major code overhaul). In the short term the first two are nice. But in the long term, the system needs to fit how the data is used. "The sky above the port was the color of a television, tuned to a dead channel."

CCP Lingorm C C P	Posted - 2008.08.26 10:16:00 - [157] I have written up the suggestions for changes to the Science and Industry Interface so that you have the option to Right Click and Move them to a Corp or Personal Hanger. This has now been handed to the UI Group and they will prioritise and organise getting it into game. No Promises on when this will happen but this is now a feature on out Backlog. 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.

Thevlyn	Posted - 2008.08.29 03:17:00 - [158] Edited by: Thevlyn on 29/08/2008 03:17:45 why not just change the color of all BPO's, while i understand the idea of a blue blueprint is based on actual BPs, it would be a whole lot easier if all BPO's were a different color, like red.
Lu'Pa Caldari	Posted - 2008.08.29 19:02:00 - [159] Originally by: CCP Lingorm Not a "Join" because by default a Join is an "Inner Left Join", which means that if the item in the left table (inventory) does not have an entry in the right table (dogma attribs) then it will not be included in the result table. What we actually need is and "Outer Left Join" which is All entries in the left table (inventory) and if they have the appropriate Dogma attribute then also include the stuff from the Right table, if they do not have the attributes then put in either NULL or some specified value. While this may actually seem like less work because of the way indexes work it is acutally more work to do an outer join than it is to do an inner join. Hmmm... Don't shoot me down, as I don't know everything about your database structure, but I sometimes use a kind of multi-pass SQL to overcome these outer left joins for specific cases. Basically you split the query on two queries with inner joins, and join them using union or concatenate, whatever the operator in SQLServer. The first for blueprints, and the second for everything else. If I understand correctly, blueprints have always have a row in the second table, hence you could do an inner join in that query too. If you have indexes favouring access by item type... i don't know... might work. Just my .02 isk
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.09.01 04:05:00 - [160] Originally by: CCP Lingorm I have written up the suggestions for changes to the Science and Industry Interface so that you have the option to Right Click and Move them to a Corp or Personal Hanger. This has now been handed to the UI Group and they will prioritise and organise getting it into game. No Promises on when this will happen but this is now a feature on out Backlog. Please add an option to move to your active ships cargohold, there are cases when a player may not have a corp or personal hanger and having a 'catch all' option would mitigate that problem. If you dont have an active ship or your ship cannot store the item in its cargohold have it just pass an error.

db Deckard	Posted - 2008.09.02 21:31:00 - [161] Originally by: Thevlyn Edited by: Thevlyn on 29/08/2008 03:17:45 why not just change the color of all BPO's, while i understand the idea of a blue blueprint is based on actual BPs, it would be a whole lot easier if all BPO's were a different color, like red. This whole discussion devolved into a SQL and Database discussion. The bottom line is that the UI has no ojective way for a player to determine if a blueprint is a copy or an original. If assettype = "Original" then color red else color blue This really should not be that hard to do db
Saffin	Posted - 2008.09.03 12:43:00 - [162] Have to admit i havent read the entire thread. So ignore me if this is said earlier and answered. But if changing the icon is no no, is it possible (without adding signicant load) to make sort by type sort by type then number of runs ascending, that way there would be no visual clue, but the bpos would always be first in the list of their type. Saf

CCP Lingorm C C P	Posted - 2008.09.03 13:01:00 - [163] To reiterate things. When you get an asset listing sent to your client the resulting data has NO entries for, if it is an original or a copy, it does not know how many runs are on it so sorting or flaging by that information is not possible. To show you the change that would be need (in psuedo SQL not the full SQL) look below. Current get asset listing. Select itemID, graphicID, singular, amount From inventory Where characterID = <you> and locationID = <station> Nice and simple. The change would be to something like this. Select i.itemID, i.graphicID, i.singular, i.amount, ia.invAttri as runCount from inventory i right outer join inventoryAttributes ia (right outer join attributes a on ia.attribute = a.attribute) on i.itemID = ia.itemID where a.attribute = 1234 and i.characterID = <you> and i.locationID = <station> As you can see this is ORDERS of magnitude larger than the current system. and this would have to be run EVERYTIME you wanted you inventory list. This would have a significant impact on the performance of the db and therefore will not be implemented. We have identified that using the more targeted returns from the Science and Industry interface returns the required information and are looking at ways to make this more usable to overcome this issue. But a change to show the difference in your hanger inventory is not going to 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.

Jarne Increasing Success by Lowering Expectations Vanguard.	Posted - 2008.09.03 14:15:00 - [164] Edited by: Jarne on 03/09/2008 14:19:33 All nice and good, but PLEASE make us at least use the science&industry interface to move our BPs from where they are. Right now I can a.) look into the science&industry interface and nicely distinguish my BPOs and BPCs (but not move them!) OR b.) look into the inventory and separate BPOs from BPCs by clicking on EACH AND EVERY one, looking if it's original or copy, and then moving it (or not) That's totally stupid. On the one hand I have all needed information, but can't do anything with it, on the other hand I don't have ANY information without awkwardly clicking me to death, but at least I can use it?! Edit: Haven't used the science&industry interface for ages... was just too depressing. maybe it's already implemented in some way, then just ignore me :). - Success=Achievements/Expectations
Raynar Alcohol Omega Fleet Enterprises Executive Outcomes	Posted - 2008.09.03 14:17:00 - [165] Edited by: Raynar Alcohol on 03/09/2008 14:22:08 Originally by: CCP Lingorm itemID, typeID, locationID, ownerID, flag, contraband, singleton, quantity (this is in the staticDB dump we provide) Basically what you get out of the inventory API (which has some names added for ease). If you are really interested in the detail then have a look at the static data dump as it has all the tables and structures. I have already posted my idea, however it was probably expressed too complicated/wrong Current situation: same TypeId for BPO/BPC and this information is stored in the normalized table. The problem is the very expensive table join to output that data. Solution: make one TypeId for the BPO and one for the BPC. A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC. This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup. Is this too simple?

CCP Lingorm C C P	Posted - 2008.09.03 16:15:00 - [166] Originally by: Raynar Alcohol Edited by: Raynar Alcohol on 03/09/2008 14:22:08 I have already posted my idea, however it was probably expressed too complicated/wrong Current situation: same TypeId for BPO/BPC and this information is stored in the normalized table. The problem is the very expensive table join to output that data. Solution: make one TypeId for the BPO and one for the BPC. A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC. This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup. Is this too simple? Except as stated before, in the current normalized db structure, an object can not have 2 creator Blueprints. So we could not tie the output of the new bpc type to an object so they would not produce anything while consuming minerals. 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.03 16:16:00 - [167] Originally by: Jarne Edited by: Jarne on 03/09/2008 14:19:33 All nice and good, but PLEASE make us at least use the science&industry interface to move our BPs from where they are. Right now I can a.) look into the science&industry interface and nicely distinguish my BPOs and BPCs (but not move them!) OR b.) look into the inventory and separate BPOs from BPCs by clicking on EACH AND EVERY one, looking if it's original or copy, and then moving it (or not) That's totally stupid. On the one hand I have all needed information, but can't do anything with it, on the other hand I don't have ANY information without awkwardly clicking me to death, but at least I can use it?! Edit: Haven't used the science&industry interface for ages... was just too depressing. maybe it's already implemented in some way, then just ignore me :). This is what we are looking into. Improving the usability of the S&I interface rather than the Inventory system. 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 Interstellar Alcohol Conglomerate	Posted - 2008.09.04 11:17:00 - [168] Edited by: Imhothar Xarodit on 04/09/2008 11:21:39 Lingorm, thanks for al the clarification on how the EVE DB works. If I remember correctly, every BPC is initially ALWAYS unpackaged (if this is not always the case, time to change it), meaning the singleton entry is 1 or true or whatever. Now a singleton item has no quantity (well implyed 1). So, what do you think about re-using the quantity field and instead store the number of runs left on a BPC there, as the quantity field does not have any other function for singleton items. Yes, it would create a redundancy to the attributes table, but seeing as this field is already present, it wouldn't take up more storage. You would only have to update the field when a BPC is created/used (which you have to do anyway when it is retrieved from a job and placed into the inventory). If the client encounters a blueprint typeID it checks if it is a singleton, and if its quantity is != -1 (or simply different from what a BPO would have), the client can distinguish between BPO and BPC and could even display the number of runs left on the blueprint icon (like in the top right corner instead of bottom right, so it cannot be confused with a stack of repackaged BPOs). Is this a possible solution? If the DB is layed out as I understood it, there shouldn't be any issues with implementing it. Pros: No access to the attributes table on inventory lookups. The ability to display the number of runs left on the blueprint icon without having to open the info dialog would be a mega plus! The existence of the number of runs on a blueprint icon would automatically distinguish it from a BPO! Cons: It must be guaranteed that all BPCs are created as singleton, without exceptions. The quantity field must be kept up-to-date with the correct numberOfRuns (every time it is used in a job and put back into the hangar). The client has to treat a special case. When the patch is applied you have to run a rather lengthy DB job to update all the quantity fields. This would be a total win for everyone working with BPCs!
Xiaodown coracao ardente Triumvirate.	Posted - 2008.09.09 19:23:00 - [169] Originally by: CCP Lingorm Originally by: Raynar Alcohol Edited by: Raynar Alcohol on 03/09/2008 14:22:08 I have already posted my idea, however it was probably expressed too complicated/wrong Current situation: same TypeId for BPO/BPC and this information is stored in the normalized table. The problem is the very expensive table join to output that data. Solution: make one TypeId for the BPO and one for the BPC. A new item is created when you create the BPC. So on item creation do a lookup on a mapping table, then copy the attributes from the BPO to the new item and change the BPO typeId to the BPC typeId. Only thing you really need is the mapping table from BPO to BPC. This enables you to display different icons for BPO/BPC without doing an expensive lookup. The only problem is, a lot of new TypeIds, but that shouldn't really matter. And the code for creating the BPC have to be altered to do the BPO2BPC lookup. Is this too simple? Except as stated before, in the current normalized db structure, an object can not have 2 creator Blueprints. So we could not tie the output of the new bpc type to an object so they would not produce anything while consuming minerals. Just tossing ideas out here - what about this: An object can't have 2 creator blueprints, so this limits the ability of some otherwise seemingly workable ideas... What if - when you produce a BPC, it gets a separate TypeID, and then the code for the actual production is tweaked to account for it? I.e. essentially when you build something from a BPC, the build system would recognize that it's not the right TypeID of Y to build X item, but it would intercept this, send the BPC to a subroutine whereby your BPC is altered or destroyed (based on how many runs you build) before returning it to you (or not), and what actually gets installed in the job system is a standard [BPO + normalization code to turn it into essentially a BPC as they work now]. So, basically, when you create a BPC, you would create an item with a different TypeID that is (as the code stands now) worthless and incapable of actually doing anything, and then the code changes would all be on the science/technology tab to correctly interpret them. So, you want to build something from a BPC, but it's the wrong TypeID. The build system accepts your BPC of different type, reads its attributes, and creates a BPO with the normalized data to make it a [BPC with X, Y, and Z specs], and installs that into the actual job. Meanwhile, it keeps your (worthless, wrong TypeID) BPC in a separate location, and at the conclusion of the build job, alters its attributes and either destroys it or gives it back to you, while the (newly created) BPO+normalized_data gets destroyed, never to have actually been held by the player. This would mean that you could do all sorts of stuff on BPCs in inventory because they're a different TypeID, without significantly increasing database queries that display inventory; your database and CPU hits would all only be when jobs are installed in the Science/Technology tab, which is used far less often than the inventory tab. Meh? ~X -- Sig under construction.
Xiaodown coracao ardente Triumvirate.	Posted - 2008.09.09 19:35:00 - [170] Originally by: Xiaodown Originally by: CCP Lingorm Originally by: Raynar Alcohol Stuff more stuff Just tossing ideas out here - what about this: An object can't have 2 creator blueprints, so this limits the ability of some otherwise seemingly workable ideas... What if - when you produce a BPC, it gets a separate TypeID, and then the code for the actual production is tweaked to account for it? I.e. essentially when you build something from a BPC, the build system would recognize that it's not the right TypeID of Y to build X item, but it would intercept this, send the BPC to a subroutine whereby your BPC is altered or destroyed (based on how many runs you build) before returning it to you (or not), and what actually gets installed in the job system is a standard [BPO + normalization code to turn it into essentially a BPC as they work now]. So, basically, when you create a BPC, you would create an item with a different TypeID that is (as the code stands now) worthless and incapable of actually doing anything, and then the code changes would all be on the science/technology tab to correctly interpret them. So, you want to build something from a BPC, but it's the wrong TypeID. The build system accepts your BPC of different type, reads its attributes, and creates a BPO with the normalized data to make it a [BPC with X, Y, and Z specs], and installs that into the actual job. Meanwhile, it keeps your (worthless, wrong TypeID) BPC in a separate location, and at the conclusion of the build job, alters its attributes and either destroys it or gives it back to you, while the (newly created) BPO+normalized_data gets destroyed, never to have actually been held by the player. This would mean that you could do all sorts of stuff on BPCs in inventory because they're a different TypeID, without significantly increasing database queries that display inventory; your database and CPU hits would all only be when jobs are installed in the Science/Technology tab, which is used far less often than the inventory tab. Meh? ~X To clarify: Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2. You can build a Raven from TypeID 1, but TypeID 2 is useless to the system. So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally. When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)". Thus, all the code changes are in the build interface, not in the inventory interface. Possible? -- Sig under construction.


CCP Lingorm C C P	Posted - 2008.09.11 16:11:00 - [171] Edited by: CCP Lingorm on 11/09/2008 16:12:10 Edited by: CCP Lingorm on 11/09/2008 16:11:23 Originally by: Xiaodown To clarify: Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2. You can build a Raven from TypeID 1, but TypeID 2 is useless to the system. So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally. When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)". Thus, all the code changes are in the build interface, not in the inventory interface. Possible? Nice idea, but what if you are not using all the 'copies' on the BPC? Also your suggestion is a lot of work, we would have to create BPC items for EVERY BPO currently in the game and then change all the code. CCP Chronotis as started a thread about Industry upgrades for the Winter expansion and one of the ideas in that is a new BluePrint Management system (so you can load you blueprints into it and them make use of them from there ... this would remove them from hangers and the standard inventory system so they would not be subject to the current normalization issues, as this system could be tailored for blueprints(. Go have a look at that. I have also put the suggestions for S&I interface changes that will help this problem into Chronotis hands so that they can be looked at in conjunction with this new feature. 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.

Shnitz	Posted - 2008.09.13 05:25:00 - [172] Because the query to distinguish between the two types is "ORDERS of magnitude larger than the current system", I propose a solution that sticks to the very foundations of the EVE UI, keep the inventory query the same, however; by Right Clicking -> Inventory -> Commands -> Science & Industry Commands -> Highlight -> BPOS would run the expensive query and highlight the BPO's yellow or something, until the inventory is refreshed again. Now the number of sub-menus is not set in stone but I think 5 or 6 is a good number.
Detes cald Caldari	Posted - 2008.09.15 16:08:00 - [173] Edited by: Detes cald on 15/09/2008 16:10:19 Olso i dont know if it's a good idea but if we got something like a book or a bookcase to put the BPO that will be easier for most industrialists to handle. Because its not so easy for someone to have tons of them to handle and find the 1 that needs. I believe that storing them all there and and a index them by titles or search it will be better and in order to take 1 or 2 from that book or bookcase you can simply extract them from there and use it as the system work now its a small addon i dont know if its easy to implement but that my opinion :)
MailDeadDrop Archon Industries	Posted - 2008.09.16 20:42:00 - [174] I believe everyone agrees that the "correct" solution would be for BPCs to have distinct typeIDs from their parent BPOs. Lingorm has said that this cannot be because a single built item may not (presently) have more than one possible blueprint. Programmaticly what this means is that somewhere in the database there's the information that "typeID X produces typeID Y" and somewhere in Eve there is the dependency that "given typeID Y, we can find typeID X which produced Y". The obvious use for this is reprocessing (presumably there's information somewhere keyed on X that lists the materials returned when Y is reprocessed). Assuming reprocessing is the stumbling block, then it seems that there should be one of two ways to crack it. Either associate the reprocessing information with typeID Y directly (i.e. associate it with "Raven" not "Raven blueprint"), or uniquely identify the entries which may be used for reprocessing (i.e. typeID X is used for reprocessing; typeID Xsub1, which is a BPC, is not used for reprocessing; both are used to build typeID Y). Once either of those changes are done, a one-time update to the database is made to detect existing BPCs and change their typeID to the new typeID for the matching BPC (e.g. if previously "typeID for Raven blueprint", then set to "typeID for Raven BPC"). The above is predicated on my assumption that the reason a built item cannot have more than one blueprint typeID associated is tangled up in the reprocessing mechanics of the game. Lingorm, if the reason is otherwise, please elaborate on why there is a 1:1 relationship. MDD Jump Clones: 8M and NO corp switching
cuncannon freelancers inc	Posted - 2008.09.17 16:36:00 - [175] When you ask to show info it then looks the bp up to see if its a bpo or not right, so why can't a line of code be added to look up the bp in question in the data base to see if it says bpo or not without having to go show info, then all it needs is to overlay the pic of the bpo with a big green O over the top. I am not sure how the data base is set up, but for instance the database has fields with the relevent info. BP Icon BPO / BPC (normally a yes / no equasion) Number runs ect ect now in access I know you can set a look up method to see if say the 3rd field says yes (then the icon could be changed or overlaid)
MailDeadDrop Archon Industries	Posted - 2008.09.18 16:45:00 - [176] Originally by: cuncannon When you ask to show info it then looks the bp up to see if its a bpo or not right, so why can't a line of code be added to look up the bp in question in the data base to see if it says bpo or not without having to go show info, then all it needs is to overlay the pic of the bpo with a big green O over the top. You can do that. But here's the rub. Ever notice how doing a show info takes a second or 2? Now imagine that you are an industrialist and that you have a container of 100 BPCs (or more). Do you really want to have to wait a minute or two just to open that container? And consider the issue from CCP's side: they're working hard to remove lag/slowness from the game. If every time someone opens their hangar, or a container, or a ship's hold, and every blueprint had that info looked up, then you've just introduced ALOT more database calls on the server, making things slower for everyone. MDD Jump Clones: 8M and NO corp switching
Lothendra Gallente	Posted - 2008.09.21 18:04:00 - [177] A client-side cache as mentioned many times before is the obvious solution. Each instance, or item_id, of a blueprint is either a copy, or an original. This NEVER changes and such its "original" or "copy" state is a perfect candidate to be cached client-side. For example, my shuttle print is "11130//1505397645" and the client would, upon first seeing this item, query its copy/orig status, find out it is an original and then store the following in its cache: 11130//1505397645 BPO it would then see my ogre print, "2445//736139074", query it, find out it is a copy, and append it to the cache: 2445//736139074 BPC so the cache would look like: 11130//1505397645 BPO 2445//736139074 BPC Thus ensuring that the next time the client sees the print in my hangar, it knows how to mark it. What the client does with the information afterwards is just a matter of taste. Personally I like the blue colour, and would prefer a small emblem on the top right stating "COPY", but the specifics don't really matter at this stage.
Bob Farsenbruck	Posted - 2008.09.21 19:50:00 - [178] Edited by: Bob Farsenbruck on 21/09/2008 19:52:36 You neednt change anything in your DB i think.... just you need make 1 other image for each blueprint. ++Are blueprints images stored in the DB??? Yes. Dont create any at the DB, just do a some image edit function for invert colours. No. Easy, create a new blueprint icon with other colour. Sure u have any function to get the number of copies of a blueprint (-1 = original, >-1 then copy) if fGetNumberCopies(blueprint) = -1 then -draw blue image (as usually) else -draw green image (new one image what colour u want) endif
Jarna Civire	Posted - 2008.09.24 14:48:00 - [179] Originally by: CCP Lingorm Edited by: CCP Lingorm on 11/09/2008 16:12:10 Edited by: CCP Lingorm on 11/09/2008 16:11:23 Originally by: Xiaodown To clarify: Say Raven BPO is TypeID 1, and Raven BPC is TypeID 2. You can build a Raven from TypeID 1, but TypeID 2 is useless to the system. So, in the Science and Technology tab, you double the number of TypeIDs that it will accept, and when it gets a "TypeID 1 object", it behaves normally. When it gets a "TypeID 2 object", some code intercepts the build job, and basically says "I can't build a raven from that, so what I'm going to do is create a TypeID 1 object with the same attributes, install the job with it, and then after the build is done, destroy the TypeID 1 object I created. I then will make changes to this TypeID 2 object that the user gave to me, and then give it back to them (or destroy it if it's all used up)". Thus, all the code changes are in the build interface, not in the inventory interface. Possible? Nice idea, but what if you are not using all the 'copies' on the BPC? Also your suggestion is a lot of work, we would have to create BPC items for EVERY BPO currently in the game and then change all the code. CCP Chronotis as started a thread about Industry upgrades for the Winter expansion and one of the ideas in that is a new BluePrint Management system (so you can load you blueprints into it and them make use of them from there ... this would remove them from hangers and the standard inventory system so they would not be subject to the current normalization issues, as this system could be tailored for blueprints(. Go have a look at that. I have also put the suggestions for S&I interface changes that will help this problem into Chronotis hands so that they can be looked at in conjunction with this new feature. Lot of work? A day tops... You would need a few SQL commands. --make new items in table INSERT INTO Items ItemName, Mass, ... (all fields in that table that needs ot be copied from the original entry) SELECT ItemName + ' BPO', Mass, ... (same list of fields as above plus any changes from the original entry) FROM Items WHERE (limit to only select blueprints, you could even filter out any BPC that never has a BPO drop) --make temp table to match oldIds to the newIDs just created CREATE TABLE #IdLookup ( OldItemId int not null, NewItemId int not null ) INSERT INTO #IdLookup SELECT A.ItemId, (SELECT B.ItemId FROM Items as B WHERE B.ItemName like A.ItemName + '%') FROM Items as A WHERE (Same as above but filter by it not having BPO in the name) --update the player invetory for currnet BPO UPDATE PlayerInventory SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId) WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently) --update the NPC drop table UPDATE NPCDropCrossRef SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId) WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently) --Missions Reward UPDATE MissionReward SET ItemId = (SELECT NewItemId FROM #IdLookup WHERE OldItemId = PlayerInventory.ItemId) WHERE ItemId in (SELECT OldItemId FROM #IdLookup) AND (limit to only BP that are actual BPOs currently) --any other tables that need to be updated should follow the same update --update all the old item names to have the BPC name UPDATE Items SET ItemName = ItemName + ' BPC' WHERE (SELECT OldItemId FROM #IdLookup) --drop the temp table DROP TABLE #IdLookup Obviously you would have to put in your real table names and fill in the missing data from the SQL and test it. You may even need to update more tables that I do not know of like for the market or what have you. On the client side there would be no change, unless you wanted to make the picture of the BPO change from the current.

CCP Lingorm C C P	Posted - 2008.09.24 16:22:00 - [180] And what about the changes to the system for creating copies, the changes to manufacturing that then needs to changed different values depending if you are building from a BPO or a BPC, 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). 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. 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. 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

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.