| Author |
Topic |
Krystal Engle
Amarr
Phalanx Security Service
Psychotic Tendencies. |
Posted - 2009.07.12 06:55:00 - [ 1]
I've been a SQL admin for over 8 years now, and do know my way around a database. The malarkey that CCP is trying to shovel our way concerning the technical limitations of displaying a separate icon for BPO or BPC is just that; laziness.
Please CCP, find a solution. Your recent Inventory fixes have broken the previously hidden (albeit workable) solution to finding where the BPO was hiding.
Please, seriously. Its not hard to fix this. I will even provide you a working example in SQL and Python if you want to email me a little glimpse into how your schema is setup. I can be reached at: krystal.engle@gmail.com
Seriously. Its not hard at all. I'm willing to spend all of the development work with whomever feels brave enough to tackle the issue once and for all. |
Qual
Gallente
Cornexant Research
|
Posted - 2009.07.12 07:44:00 - [ 2]
See I am sure you solution includes actually reading from BOTH tables, and THATS the performance issue. This is not a tech issue as you say, its purely a performance issue. Any kinda of join, on disc or in memory of these datasets is too costly given thier repective sizes.
Beeing a devloper and DB admin myself I know exactly what the problem is from thier description, I find it kinda funny that you, given your 8 years experince, can't see that.
|
Qinoly
Gallente
Avib VOV |
Posted - 2009.07.12 09:16:00 - [ 3]
Not broken, unless you and me use a different method. Label 2 hangars BPO and BPC Open Science and industry > corp blueprints set TYPE to BPO Rightclick every entry on your screen > Deliver to BPO Tadaaa  |
Lord Fitz
Project Amargosa |
Posted - 2009.07.12 10:53:00 - [ 4]
Edited by: Lord Fitz on 12/07/2009 10:57:25 Originally by: Qual
I find it kinda funny that you, given your 8 years experince, can't see that.
Having some experience cleaning up other DB admins work, doesn't leave me surprised that there are DB admins out there that can't see that. If you work on databases small enough, it doesn't matter if the performance sucks. Quote:
I will even provide you a working example in SQL and Python if you want to email me a little glimpse into how your schema is setup. I can be reached at: krystal.engle@gmail.com
There's a database export readily available. It's not 'hard' to do, it's hard to do and maintain performance on a database that has to consistently serve tens of thousands of people with up to date data in a timely fashion. |
Mikal Drey
Atlas Alliance |
Posted - 2009.07.12 11:28:00 - [ 5]
hey hey didnt they also say that it would require every BPC to have a seperate database entry. currently there is only 1 entry for the bp and the details come up on show info only. to have a seperate icon or color etc they said that the database entries would plain overload (which is bad) now . . IF they had a seperate color, or outline or icon or whatever just to difrenciate BPO and BPC it would indeed be awesome but thats where they are experiencing the technical difficulty. atm im inclined to believe that ccp do want the feature but are being as cautious as possible. imagine if it bugged out and you trashed a 100ME Tempest BPO :/ Shattered Crystal - 60 day GTC |
Lord Fitz
Project Amargosa |
Posted - 2009.07.12 13:47:00 - [ 6]
The database join is already done in the Science and Industry window. It does a lookup to get the attributes on blueprints. This is so the lookup is only done when people are actually viewing blueprints. To get a different colour on the BPCs in your items hangar, you would need to do this lookup (and determine if each item is or isn't a Blueprint, then if it is or isn't an original) for every person every time they looked at an item, which would just be horrendously wasteful.
All you need is to use the S&I window and you get that 'easy' functionality you desire. Should the S&I window not give you the functionality you desire, then adding that functionality to the S&I window is what you should be asking for, not expensive database joins on every item every time it's casually viewed. |
Karentaki
Gallente
Oberon Incorporated
Morsus Mihi |
Posted - 2009.07.13 00:03:00 - [ 7]
Originally by: Krystal Engle
I've been a SQL admin for over 8 years now, and do know my way around a database. The malarkey that CCP is trying to shovel our way concerning the technical limitations of displaying a separate icon for BPO or BPC is just that; laziness.
Please CCP, find a solution. Your recent Inventory fixes have broken the previously hidden (albeit workable) solution to finding where the BPO was hiding.
Please, seriously. Its not hard to fix this. I will even provide you a working example in SQL and Python if you want to email me a little glimpse into how your schema is setup. I can be reached at: krystal.engle@gmail.com
Seriously. Its not hard at all. I'm willing to spend all of the development work with whomever feels brave enough to tackle the issue once and for all.
In just the same way there is no 'technical limitation' preventing you from brute forcing 2048 bit encryption on a pocket calculator. The algorithms exist, but they are so costly that it would take a VERY long time. Similarly, while the algorithms to display separate icons for BPC's and BPO's exist, the problem lies in the performance issues caused by the extra database processing. Changing the DB system is also practically out of the question, since in a project as large as EVE redesigning the ENTIRE item database would take at least a year and introduce far more bugs than were fixed. |
Baka Lakadaka
Gallente
Agony Unleashed
Agony Empire |
Posted - 2009.07.13 05:17:00 - [ 8]
If anyone has ever opened up a secure container with 120 odd bookmarks in it to try to copy them into your Neocom, then you'll know what lag is. It can take up to 10 minutes for this to display as each BM is looked up - all it needs to display is a unique name for each BM and it takes forever.
When I receive shared BMs from corp mates, it's a case of open the container, then go make a coffee. |
Poreuomai
Minmatar
Mirkur Draug'Tyr
Ushra'Khan |
Posted - 2009.07.13 11:05:00 - [ 9]
Edited by: Poreuomai on 13/07/2009 11:14:46Quite a lot of stuff is already stored on the player's computer, bookmark folders for example. Would it not be possible to get the icon information once and cache it on the client. It's not as if a blue print could ever change from BPO to BPC. Originally by: Krystal Engle
I've been a SQL admin for over 8 years now... I can be reached at: krystal.engle@gmail.com
You've been in software for 8 years, yet you publish you email on a public website? Enjoy the floods of spam coming your way from various web spiders. |
Steve Thomas
Minmatar
Sebiestor Tribe
|
Posted - 2009.07.13 16:24:00 - [ 10]
Originally by: Krystal Engle
I've been a SQL admin for over 8 years now, and do know my way around a database. The malarkey that CCP is trying to shovel our way concerning the technical limitations of displaying a separate icon for BPO or BPC is just that; laziness..
Originally by: Krystal Engle
I've been a SQL admin for over 8 years now, and do know my way around a database. The malarkey that CCP is trying to shovel our way concerning the technical limitations of displaying a separate icon for BPO or BPC is just that; laziness..
you obviously work for a small company, the kind that has say a couple of gas stations or is a small Mc Donalds franchise operation. the kind that does not realy need a literaly real time database. the problem is 1) is the size of the client base hitting the database at the same time. literaly everything in the game is on the database from each round of ammo to each unit of trit and veldspar. Everything is cross indexed on that database and originaly every individual item in the game had its own unique serial number and created an audit trail. (which is why being able to group weapons together was sutch a massive improvment on the database performance) 2) it has to do all of that in Literaly real time. 3) do it with hardware and software that to be blunt is specificaly not certified to do what they actualy do make it do. * The reality is that outside of MMOs theres realy not that many database systems that are required to work literaly in real time 100% of the time they are up with the goal** of also meeting the standards of recognised Accounting stadards(and to be fair most MMOs are working on trying to get there database handleing up to thoes standards, the big issue is being able to do it in real time. most mmos tend to limmit individual servers to a few thousand logins at a time and have to make due with roughly 10% of the hardware that EVE deploys per "shard" or world) * After reading an artical from Intel a while back on what EVEs hardware does I flashed on Bender saying "Lets go pick up some floozybots and void their warantys" **Note I said Goal, they would love to be able to do kind of audit trails that would allow them to pull the plug on ISK retailers that you could do so mutch easyer if you had that level of crosschecking. as the recent POS exploit shows while they can catch it after the fact, they had in the past needed to take shortcuts in order to keep the Database caught up with the game state. |
Tesal |
Posted - 2009.07.13 20:42:00 - [ 11]
I would rather have the database work for me than have me work for the database. That is a pitiful excuse. |
Steve Thomas
Minmatar
Sebiestor Tribe
|
Posted - 2009.07.13 22:59:00 - [ 12]
Originally by: Tesal
I would rather have the database work for me than have me work for the database. That is a pitiful excuse.
what are you bloody talking about, or is this just randompost number whatever for you? |
Tesal |
Posted - 2009.07.14 02:18:00 - [ 13]
Originally by: Steve Thomas
Originally by: Tesal
I would rather have the database work for me than have me work for the database. That is a pitiful excuse.
what are you bloody talking about, or is this just randompost number whatever for you?
There has to be a way to do it. We live in a world of I-phones and Youtube and Google massive data streams, and what I am hearing is that people are suffering with piles of data, having to manually sort it because CCP can't get this to work. I have a huge BPO collection, all modules pretty much, ammo, and all kinds of other ships and what not. Several times I have accidentally clicked repackage on cans with BPO and BPC in them, or accidentally sent the BPC to the wrong hangar and spent hours cleaning them up. Its a giant waste of time. |
Lord Fitz
Project Amargosa |
Posted - 2009.07.14 11:35:00 - [ 14]
Edited by: Lord Fitz on 14/07/2009 11:36:35 Originally by: Tesal
Originally by: Steve Thomas
Originally by: Tesal
I would rather have the database work for me than have me work for the database. That is a pitiful excuse.
what are you bloody talking about, or is this just randompost number whatever for you?
There has to be a way to do it. We live in a world of I-phones and Youtube and Google massive data streams, and what I am hearing is that people are suffering with piles of data, having to manually sort it because CCP can't get this to work.
I have a huge BPO collection, all modules pretty much, ammo, and all kinds of other ships and what not. Several times I have accidentally clicked repackage on cans with BPO and BPC in them, or accidentally sent the BPC to the wrong hangar and spent hours cleaning them up. Its a giant waste of time.
The iPhone, YouTube and Google are not real-time (collection and dissemination of mass data), and only Google would come onto the same complexity level. Large amounts of data are not the problem, it's operations on large amounts of data being shared between tens of thousands of users in real time. Takes a good 2 minutes to clean mixed BPCs and BPOs, put in one corp hangar, open S&I window, filter to originals, select all and deliver to another hangar. Done. Again, the way to do it is already in game, it's the S&I window, there is no problem with this, the problem would be applying such checks to every single item in game, every time it was viewed. |
Poreuomai
Minmatar
Mirkur Draug'Tyr
Ushra'Khan |
Posted - 2009.07.15 09:22:00 - [ 15]
That's why I suggested that it could be cached on the client. Is that not feasible? |
Mr Opinions |
Posted - 2009.07.15 11:41:00 - [ 16]
The crux of the problem is avoiding a lookup to the attributes tables when displaying items.  Here is a straightforward solution. For each blueprint item in the EVE universe, call this existing item an "original" blueprint and create a second item in the item database with the identical name but called "blabla (Copy)".  This avoids any need to check the attributes tables and thus the performance hit about which the devs have been concerned. Does this add a lot of items to the item database? Yes. Does that matter at all with modern databases? No, it shouldn't, since lookup times for modern databases don't scale significantly with the number of keys in the database. |
gordon861
Minmatar
PROGENITOR CORPORATION
Intrepid Crossing |
Posted - 2009.07.15 12:32:00 - [ 17]
Originally by: Mr Opinions
The crux of the problem is avoiding a lookup to the attributes tables when displaying items.
Here is a straightforward solution. For each blueprint item in the EVE universe, call this existing item an "original" blueprint and create a second item in the item database with the identical name but called "blabla (Copy)".
This avoids any need to check the attributes tables and thus the performance hit about which the devs have been concerned. Does this add a lot of items to the item database? Yes. Does that matter at all with modern databases? No, it shouldn't, since lookup times for modern databases don't scale significantly with the number of keys in the database.
I think CCP pointed out that the problem with this is to do with the way the items in the DB are set up at the base level. At the moment a BPO and a BPC are identical except for the number of runs information which is pulled from the DB on request. They can't make BPOs and BPCs different items due to the fact that the way the game is setup two different items can't both produce the same end product. So the only source of a 'Raven' is from a 'Raven BP' you can't create a second object that would lead to a 'Raven'. |
Mr Opinions |
Posted - 2009.07.15 13:21:00 - [ 18]
|
Tesal |
Posted - 2009.07.15 20:06:00 - [ 19]
Originally by: Lord Fitz
The iPhone, YouTube and Google are not real-time (collection and dissemination of mass data), and only Google would come onto the same complexity level. Large amounts of data are not the problem, it's operations on large amounts of data being shared between tens of thousands of users in real time.
Takes a good 2 minutes to clean mixed BPCs and BPOs, put in one corp hangar, open S&I window, filter to originals, select all and deliver to another hangar. Done.
Again, the way to do it is already in game, it's the S&I window, there is no problem with this, the problem would be applying such checks to every single item in game, every time it was viewed.
There is software out there for engineering projects that allows hundreds of people to work on the same project, sometimes between separate teams in separate countries. It is used in chemical plants and refinery design, aerospace, ship building, and sometimes building design as well as other fields. You may have hundreds or even thousands of users, designing with 3-D models, and adding and subtracting parts of the project in real time. They embed specifications with the products, and attach all kinds of data, cost and product information that reference a myriad of standards and quality control procedures. You can roll changes forward and backwards with each user for millions of components and thousands of systems. It is done in real time, with robust quality controls. There are also systems that track people like air traffic controls, and Blue Force in the military and can be audited. The information in EvE should be intuitive, easy to order and simple to manipulate. EvE is not nearly as complicated as those systems. I understand the tech constraints, I really don't care. They can be overcome, they have been overcome by others. This is a second rate solution. EvE is full of them, each one adds difficulty, and most of them are not documented, or are documented in a forum that cannot be properly searched. It is one of the reasons EvE has such a steep learning cliff, the interface is not that good for a lot of things. |
Tesal |
Posted - 2009.07.15 20:25:00 - [ 20]
Edited by: Tesal on 15/07/2009 21:19:43 Originally by: gordon861
At the moment a BPO and a BPC are identical except for the number of runs information which is pulled from the DB on request. They can't make BPOs and BPCs different items due to the fact that the way the game is setup two different items can't both produce the same end product. So the only source of a 'Raven' is from a 'Raven BP' you can't create a second object that would lead to a 'Raven'.
Then pull the number of runs along with the BPO name, if its any less than infinity, its a BPC. Every stack of items in the game tells you how many are there. There are far more stacks of items, then there are BPO, and they don't seem to have a problem pulling up that information for people and they don't make them look in a separate window. I see no reason why they can't pull this data for BPO. Also remember this is the same CCP that triples the number of rig BPO in one motion, who adds invention for entire classes of new ships without a problem. This can be fixed by adding a zero or a one to each item. Thats all it takes, they should do it. |
destinationunreachable
Hello Kitty Fanclub |
Posted - 2009.07.15 22:10:00 - [ 21]
I agree that with a regular RDBMS engine (MS SQL server after all...  ) there is a scaleability issue with such a DB design. If you have ever worked on a near realtime systems which needs to perform especially under high loads you need to live with such problems. (my experience comes from message queue systems, but similar issues). CCP certainly wants to avoid redesigning the DB (having a different item for a BPC) as such fundamental changes are usually connected with pain, bugs and more pain. Some people have pointed out, that systems like google (or facebook) can handle processing large datasets, you should remember: yes, it is technically solvable by writing your own custom data storage/database system. But I am sure that would be beyond CCPs technical, organisational and financial scope... |
Tagami Wasp
Caldari
Sarz'na Khumatari
Ushra'Khan |
Posted - 2009.07.16 13:10:00 - [ 22]
Edited by: Tagami Wasp on 16/07/2009 13:17:31Have you looked at the schema of the item DB? (use the Apocrypha dump) Did you notice the way the BPO/BPCs work? Since I spend 6 months analysing that dump, I can tell you that it is not set up to be used in a straightforward way, but is based on unary relationships.Using one BPO relies on a C++ program (could be Python too, I don't really know the code part) to look up the item BPO/BPC one attribute at a time and produce the item in question. That makes original and copy just another attribute, but makes the table cross-reference itself (It needs less space to store it that way, but I don't know if performance wise it is better. I feel that you get better results the more you normalise the DB, even if you end up with more tables. Space on disk these days tends to become very cheap, even if we're talking about EVE's DB). If I'd built the DB, I'd have had the BPOs in their own table, with unique ItemID fields with an attribute [copy] as "true" or "false" and the rest of the table as a bill of materials (engineering term, not game term). Then since color is just another attribute (effectID actually, if I remember correctly) then you could just do anything with it, say set it "red". Now, the S&I interface is the code that you call up to do the sorting for you, since there is no distinct table for the BPO/BPCs (all items are included in that table so don't even bother suggesting additional columns) that's the only way you have to look at it. To get more features, and discrimination between BPOs and BPCs you need to really restructure the DB. It's not easy, it already has a lot of bugs, mistakes and whatnot (well, I prefer simpler and more straightforward ways, they obviously try to save on space and reduce DB load, so they use fancy programming. I am just an Engineer, they do this for a living). IF you feel up to redesigning the DB, you should talk about hourly wages with CCP for DB restructuring and debugging. P.S. My rate is 150 Euro per hour, thank you and good luck  |
Lord Fitz
Project Amargosa |
Posted - 2009.07.16 13:59:00 - [ 23]
Edited by: Lord Fitz on 16/07/2009 14:14:10 Originally by: Tesal
There is software out there for engineering projects that allows hundreds of people to work on the same project, sometimes between separate teams in separate countries. It is used in chemical plants and refinery design, aerospace, ship building, and sometimes building design as well as other fields. You may have hundreds or even thousands of users, designing with 3-D models, and adding and subtracting parts of the project in real time. They embed specifications with the products, and attach all kinds of data, cost and product information that reference a myriad of standards and quality control procedures. You can roll changes forward and backwards with each user for millions of components and thousands of systems. It is done in real time, with robust quality controls. There are also systems that track people like air traffic controls, and Blue Force in the military and can be audited.
Again, 3-D is unimportant, that's a client issue. The lookups are attached are exactly like those Eve already has attached, and like Eve, they don't display them all at once. You are also talking of hundreds of users rather than tens of thousands and those applications are already significantly slower than Eve, also they're costing users significantly more than $15/month to dedicated CPU and disk to each user. The definition of 'real time' in a CAD system is not the same as 'real time' in Eve. They can fake a client response and update all the users when they get around to it, in Eve these inconsistencies can't be resolved, each transaction has to be atomic and performed in a timely manner on the server side. I can't honestly believe you think an air traffic control system is more complex than a system that's tracking thousands of interacting ships in a space simulation. It's like comparing a system where you have no one shooting anything, using the market etc and only a few dozen people compared with a giant fleet battle or Jita. They're not even close to the same scale. Quote:
The information in EvE should be intuitive, easy to order and simple to manipulate. EvE is not nearly as complicated as those systems. I understand the tech constraints, I really don't care. They can be overcome, they have been overcome by others. This is a second rate solution. EvE is full of them, each one adds difficulty, and most of them are not documented, or are documented in a forum that cannot be properly searched. It is one of the reasons EvE has such a steep learning cliff, the interface is not that good for a lot of things.
It is already overcome. And Eve is significantly more complicated than those systems. Eve also unlike many other applications can not cope with a client having a different view of the world than the server, in other applications such inconsistency can be resolved by the users, in Eve the server must resolve all decisions or cheating is inevitable. Items must exist once and once only, it can't 'guess'. |
Lord Fitz
Project Amargosa |
Posted - 2009.07.16 14:06:00 - [ 24]
Originally by: destinationunreachable
Some people have pointed out, that systems like google (or facebook) can handle processing large datasets, you should remember: yes, it is technically solvable by writing your own custom data storage/database system. But I am sure that would be beyond CCPs technical, organisational and financial scope...
Facebook and Google are heavily cached, if their data is old, it doesn't matter. If Eve caches data it potentially means that items can be duplicated. The reality is that what people are asking for ALREADY exists in game in the S&I window, I can't believe people are still ignoring that. It's there, it gets around the performance hit by displaying the attributes ONLY on that view, it is significantly slower than the items window, to give you an idea of what would happen if the differentiation was rolled out to every view of items in game, which would be required to give that view in the items windows. If the S&I window doesn't do what you need it to do, ask them to improve THAT ! |
Lord Fitz
Project Amargosa |
Posted - 2009.07.16 14:25:00 - [ 25]
Originally by: Tagami Wasp
Space on disk these days tends to become very cheap, even if we're talking about EVE's DB).
The thing about Eve's DB is you're not talking about 'hard' disk space as much as you're talking about memory or RAMSAN space. Yes, storing the data is cheap, storing it somewhere that performs is not quite so easy. Quote:
If I'd built the DB, I'd have had the BPOs in their own table, with unique ItemID fields with an attribute [copy] as "true" or "false" and the rest of the table as a bill of materials (engineering term, not game term). Then since color is just another attribute (effectID actually, if I remember correctly) then you could just do anything with it, say set it "red".
The main problem with this is that there is an 'items' window. The items window shows items. If you have a different table for every item, rather than one table for each item, you need to query multiple tables to form the items view, which hurts performance. If you instead just do as they're doing and store all items in one table, and then join that to a new BPOs table, you again have the same issue as currently exists, so you've saved nothing. Quote:
Now, the S&I interface is the code that you call up to do the sorting for you, since there is no distinct table for the BPO/BPCs (all items are included in that table so don't even bother suggesting additional columns) that's the only way you have to look at it.
Which is fine because that view is only called up when people are looking for that information, as opposed to every time someone is viewing their ammo or hangar or dies and has to drop loot etc. Quote:
To get more features, and discrimination between BPOs and BPCs you need to really restructure the DB. It's not easy, it already has a lot of bugs, mistakes and whatnot (well, I prefer simpler and more straightforward ways, they obviously try to save on space and reduce DB load, so they use fancy programming. I am just an Engineer, they do this for a living). IF you feel up to redesigning the DB, you should talk about hourly wages with CCP for DB restructuring and debugging.
There's not really any way to do it without sacrificing performance or altering the way BPs are treated so they are somehow separate items from all other items, in which case you would have a separate view just like the S&I window anyway. Basically, there is no opportunity for any more gain than exists. I wouldn't structure databases the way CCP do either, but then to me performance doesn't matter as much. If I was to design a system with 300,000 users I would pretty much have to cave to the way they were doing it unless my income per user was many times higher, and even then, it wouldn't make sense to spend money to gain performance that could be gained by simply altering the way people behave incredibly slightly. |
DrKuLa |
Posted - 2009.07.16 14:48:00 - [ 26]
Originally by: Qual
See I am sure you solution includes actually reading from BOTH tables, and THATS the performance issue. This is not a tech issue as you say, its purely a performance issue. Any kinda of join, on disc or in memory of these datasets is too costly given thier repective sizes.
Beeing a devloper and DB admin myself I know exactly what the problem is from thier description, I find it kinda funny that you, given your 8 years experince, can't see that.
not really a good mix be a dev and dba because it means not good at both... exception for few and very rare exceptions. I just hope you are not be another .NET dev that thinks that knows everything about DBs like my 7 devs that think that are the best coders but reality shows that they know s*h*i*t when they start writing SQL. Most of the times their code goes straight back for partial/full rewrite if not hang the dev that wrote it it by the ears outside the 5th floor window to learn the lesson on writing good SQL or start learn to fly out of the window. Of course there always a good reason for not to... But of course there are always a solution for every single problem... The fact is not everyone has a gift to think out the box and place a solution that not only works on 1st attempt but primarly works faster when DBs are involved. But when someone claims that isn't possible... well then perhaps that someone reached its own limitation, fair enough! Because as far as I know there are only two things in this world that are impossible and none of them have to do with code/programming/DB related. Now saying that is impossible because it would slowdown... of course it could slowdown if firstly don't have the right design... that also shows the typical dev lazziness and resitence for change and to get things right. have fun |
DrKuLa |
Posted - 2009.07.16 15:08:00 - [ 27]
Originally by: Tagami Wasp
Edited by: Tagami Wasp on 16/07/2009 13:17:31
P.S. My rate is 150 Euro per hour, thank you and good luck
you are too cheap  So you got the job waiting in Iceland!  good luck and fortune! Not less than £500/h is what I charge in the city even during economic recession...(btw what recession?)  |
Lord Fitz
Project Amargosa |
Posted - 2009.07.16 15:28:00 - [ 28]
Originally by: DrKuLa
Originally by: Tagami Wasp
Edited by: Tagami Wasp on 16/07/2009 13:17:31
P.S. My rate is 150 Euro per hour, thank you and good luck
you are too cheap So you got the job waiting in Iceland! good luck and fortune!
Not less than £500/h is what I charge in the city even during economic recession...(btw what recession?)
You would think that for that price you would get someone who knew basic English spelling and grammar. Nothing is 'impossible' obviously, but there is plenty that is not possible without a compromise to performance, storage or accuracy. In this case far from being lazy, this issue HAS been solved by the developers. Some players are still having issues grasping the solution though. Good luck to you, but I'd be willing to bet you're not developing anything that comes close to having 300,000 interacting users and 50,000+ using your systems concurrently. There are only a handful of applications world wide that do so, and most have a significantly more limited scope. Quote:
But of course there are always a solution for every single problem...
Violence, clearly. |
DrKuLa |
Posted - 2009.07.16 16:15:00 - [ 29]
@Lord Fitz That’s different… I left my basics at work, don’t really care much while I chill out while having my hols; can I offer you a pint by 1st class post or would be preferable a fast courier? Apologies for the dreadful basics mishaps. Next time I'll ask my PA to edit it before formalising submit to your perusal to post in this forum in 4 different languages – including Welsh and Celtic. This is a promise depending on how much you would like to pay! Who knows if this moment isn’t the precursor of changing my career to become a Gold winner writer on EVE forums? Anyway, you clearly failed to see the point put across... and that simply was "There are always solutions for every single problem" btw violence of any kind is hardly a solution and often generate more problems (well exception in the famous EVE's forum that all is cool if not, too bad). Cheers |
Tagami Wasp
Caldari
Sarz'na Khumatari
Ushra'Khan |
Posted - 2009.07.16 16:39:00 - [ 30]
@DrKuLa
I don't think we disagree on the basic premises. I understand they had to have a small RAM allocated space and they went the coding way to do it, which is fine. However that does make their development margin smaller and the evolution overhead higher, since to change anything they need to rewrite code. I understand they are rewriting a lot of code these days, so they might manage to include streamlining the items DB as well.
To recap the important bit though: The S&I interface is the correct way to handle and sort issues regarding BPOs and BPCs, because that is the part of the code that can differentiate between those two different items. Otherwise it's like looking at two closed doors and wondering what's behind without bothering opening them.
Thank you |
|
All Channels
Science and Industry
