I think we're on the final stretch for finishing the 3.05 release and we should start thinking about what we want to work on for the next release.
I've been testing the simulation with fast time compression and running it over lengths of time to see how the settlement inhabitants fare at longer durations (around a Martian year or more) I've made some tweaks to allow them to gather ice more efficiently so they don't run out of water so quickly.
We put a lot of effort into trying to get the project to be submittable to the Ubuntu Software Repository, but we ran into a lot of hurdles and I think we should table it for now. We do have a debian package file generated with our release files, so I think we should post this on our project website for downloading directly with the 3.05 release. This should be useful for people with Debian-based linux systems.
I've finished integrating the new emergency supply mission into the mission tool and the mission creation wizard.
I've been looking over Christian's older work on the mars-sim-config subproject in maven. It appears to have been complete and usable at the time of its creation, but not integrated into the simulation. I've updated some of the maven plugin versions of castor for it and switched it to use the Sun regular expression evaluator (that comes with the JVM standard libraries) rather than the deprecated Jakarta evaluator. The XML configuration files and their schema files will need to be updated, but I don't think this will be a lot of work. I also don't think integrating the configuration classes into the simulation will be a lot of work either (replacing the current configuration classes in the simulation). There could be some gotchas I'm not seeing at the moment, however.
The question is, assuming that replacing the current simulation configuration system with the Castor-based mars-sim-config subpackage configuration system isn't a significant amount of work, is it worth doing? Is this new configuration system preferable to our old system?
Pros for mars-sim-config:
It uses Castor to autogenerate source code based on the XML schema files, so any changes to the XML structure will be handled automatically. The current system requires XML parser classes to be modified manually if the XML structure changes.
The simulation configuration code in mars-sim-config is separated from the simulation code, allowing for better organization.
I don't know if performance is better, worse, or the same between mars-sim-config and the current configuration classes. We might create some tests to find out.
Cons for mars-sim-config:
It generates a whole lot of source code classes, significantly adding to the size of our code base.
It uses the castor and tapestry libraries, which overall add a few megabytes to the release tarball size. On the other hand, these libraries could potentially be used elsewhere as well.
Christian: feel free to add to or correct any points I've made with the pros and cons. I may be missing some things.
Let me know what you guys think about using the mars-sim-config subpackage. I will go through the config files and update them and the XML schema. I'll create a few unit tests to see if any problems come up.
Mars Simulation Project