posted Feb 7, 2010 7:10 AM by Bome D
|
We released the new dominion DB last week. Updates have been sparse mostly because like many others, real life has that nasty tendency to get in the way. Rest assured though that we are still doing work and incorporating your requests as quickly as we can. |
posted Jan 1, 2010 6:46 PM by Bome D
Work still continues on where we want to take the program now that its been out for a while, and we dont seem to have any real bugs (thank goodness). I have tweaked the item/blueprint pages so they now change items instead of closing and recreating themselves as you browse through your assets, which means that they should load faster and brings us closer to having forward and back buttons under assets viewing. I also am working to improve the flow through your assets with double-clicking lines. If you look up a station and double-click a container, you open that container up. If you double-click an item it goes right to the item's page. This should make browsing through your assets more intuitive.
I also finally added alerts, such as when an industry job finishes, a little notification pops up telling you. I dont know why it took this long, as it was an easy thing to add, but its done now. There will be options of course to disable any alerts in case you dont want to be bothered. I need to figure out a simple way to check your market orders and make that into an alert.
Grimdahl has added manual entry of prices into the production plugin, so that will go out as soon as he give me the all clear. |
posted Dec 23, 2009 3:04 PM by Bome D
|
One big problem for Eve-MEEP version 2 was that it was a complicted program, and not easy to understand. Well that has not really changed for version 3, although I would like to think that we did a better job making it more intuitive. To help with this, I have begun to write up information in the 'About' section of this website. As people ask questions of the forum thread or e-mail them to me, I try to write up more information here, so everyone can find it. Along ith How-To guides, I also have a few posts about the inner workings of the program, both incase anyone cares, and also so that I and others can refer to it when things need fixing. |
posted Dec 16, 2009 11:05 AM by Bome D
So, we traced the potential profile issues to 2 or 3 different locations, and tweaked each spot. The most likely issue was because we were not flushing/closing the stream that writes the profile to xml, and instead letting the GC do it for us, and thats not really good practice. We also applied this fix to the Updater, and it actually seems like it loads considerably faster, since it waits less time to get to read the component.xml file that the main app writes. We also fixed an issue in the updater that wouldnt put the plugins in the correct folder, and resulted in many people having the app tell them incorrect MD5 or wrong version.
Today's Trick: How do you see wallet information, such as transactions and journal entries? Easy, go to the overview page, find the wallet you want, and double-click it. I hope to make this more obvious in the future, but now you know! |
posted Dec 14, 2009 4:39 PM by Bome D
So we typically seem to have one major issue, and a number of minor ones. The major issue is the application locking up when you create a new profile. I believe this to be from thread-pool starvation, since we grab each piece of API data per character/corp on its own thread. 6 x 12ish APIs = alot of threads, and .net only has so many per application. My initial reaction is to set the API threads at a below-normal priority and leave it at that, so the UI will continue responding even when downloading everything, but I am worried that we will have problems with writing to a dataset and reading from it, even though we make liberal use of locks. On top of that, it only really happens when first creating the profile, not for instance when you load the app one day and it goes to update all information. As far as I know, that works just fine.
Second issue stems from that first issue, where it seems a profile is not written fully to disk when the app freezes, resulting in an improper xml file. When the application is loaded again, it tries to read that xml file and does not like it. Then it gives an error about some array not existing when you go to view pages. I believe I have this fixed, but an easy fix for your end if you are experiencing this is simply to make another profile, and it should work fine.
Minor issues are things like the production time of blueprints is calculated incorrectly on the Production calc, but thats has been fixed already and is just awaiting deployment (I want to make sure I get most of the bugs first before I send out an update). There is also an issue with the production calc that does not let you right-click a blueprint in the assets window and open them in the production window, but that too has been fixed. |
posted Dec 11, 2009 2:53 PM by Bome D
After about 11 months of development we released today. We had probably 2 dozen different computers to test the application on, many different accounts, all the windows operating systems (didnt work on win95), and about a month of testing time. And still, still there is a horrible error that crashed the application, filling the first page of the thread with crash reports. I feel like microsoft when they release an OS, and it gives me a greater respect for everyone who writes programs for a living (I thankfully do not).
So what was this terrible error?
When you create a new profile, the first thing is to download a list of all the characters on the account, and their corporations. The application then makes new entities (thats the class name for chars and corps), and from there downloads char/corp sheets and all the other API stuff. Well, this error was in how the corp image is rendered. We use a website to generate corp logos on demand, which are saved to your HD for the future. This error came about because it tried to get the corporation's ID number from the corpsheet before it was loaded. This is a silly error for two reasons. First we did not check to see if the corpsheet existed, second because we already had the Corp ID from when we made the list of entities in the first place, and didnt even need to use the sheet! Yea.
So, I had fixed that problem, when literally seconds later Deamos came into the IRC channel and told me that there was some issue reading the xml files now that the first issue was fixed. My bet was on the application crashing before all the info was written to disk, so he deleted everything, uninstalled, and reinstalled. This worked, and I thank him very much for the help. It is amazing how this community goes out of their way to help with bugs and support 3rd party work.
As someone told me, Release Rule: you will find 2 bugs 5 minutes AFTER release.
|
posted Dec 7, 2009 8:04 AM by Bome D
Good news is that we fixed an issue we had where the app wouldnt launch on 64-bit systems, caused by the sqlite lib we were using. Bad news is tht it exposed an issue with the updater, mainly that since it was tied in to the main app, you would have to run the main app as an admin to let the program update itself.
Solution? Make the updater its own little application.
Problem? The main app is really the only thing that can generate the list of all the proper files, as well as the database version.
So, I now have to have the main app create an xml file of all its components and their info, then start the updater with admin privs and pass that file to it as an arguement. |
posted Nov 28, 2009 7:15 AM by Bome D
Thanksgiving is always such a good holiday. Food, family, more food, and then time to work while everyone takes naps.
CCP released the Dominion database this week, and there were some slight changes. They dropped the table that is used for looking up refining/producing/etc. materials for blueprints, and added one table containing materials you get from refining (which are the ones that waste applies to), and a table with everything else. This is not really eaiser than before, since getting the materials list is now a 3 setp process than where everything was one table, but it comes with Asteroid/Ice refining information, which we previously lacked. The downside is that now we have to go back and fix all the plugins to work again. As of this writing, efficiency and reprocessing are fixed, but production is giving me a hard time. |
posted Nov 25, 2009 10:32 AM by Bome D
So after that mishap with the uploader, I went back and redid a bit of it, so it now works as intended. This meaning it will download the files on a background thread and not block the ui for 5 minutes as it downloads a new database. This will probably be how I keep it, and later go back and change it so the updating is not dependant on the UI window showing.
So what is left? Well, dominion is coming out in about a week, so we will probably hold off for that, while redoing the sov API code to reflect the recently announced changes. There apparently is also a know issue about the POS fuel api not quite calculating fuel correctly that Grimdahl is working on. Beyond that we are looking into the blueprint code, because there have been bugs reported with saving/loading them.
Assuming nothing major crops up in a week, I believe we should be on target for releasing after dominion comes out. |
posted Nov 21, 2009 1:48 PM by Bome D
|
So I thought things were going well, we have the base plugin set done, the core program done, etc. Then I play a bit more with the updater and I am still having silly threading issues. Dominion is 10ish days away, so we may just wait for that to come out. This would let us distribute the database with the app instead of afterwards, but nothing is set yet. Again, nothing is set in stone. We also changed the way the program checks for an internet connection, which used to be by pinging, but apparently some networks dont allow pings, and now its just a straight request to google. |
|