If you don't mind, I'll offer some constructive criticism.
(1) There is currently no provision in your development tree for "automated stations": weather balloons, met stations, robotic mines, automated greenhouses, storage/emergency depots, etc., etc. In the current model, it's a full-fledged "settlement" or nothing. Considering the *major* role of robotic stations on Mars today and the likely continued importance of automatic elements to a Mars colony (cf. RGB Mars, for example), I think it important that an "Auto-Station" be implemented. Such a class could re-use the same classes that the Settlement class uses to create the Garage, Storage, Greenhouse, etc.; but an Auto-Station would not be required to include all elements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(1a) Once the Auto-Station is implemented, it might be interesting to model the maintenance that would obviously be required by such a station. Storage begins to deteriorate if not visited and repaired once every 5 simulated orbits; Industrial mining robots begin to malfunction after 6 simulated months; that sort of thing. It definitely gives all those rovers more to do!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vehicle maintenance and mechanical failures are working in the pending 2.7 release. It wouldn't be hard to extend this behavior to settlements and perhaps to structures.
I'm not sure if satellites and robots should be under the vehicle class hierarchy or not. I haven't decided just yet.
Scott Davis
Project Administrator
Mars Simulation Project
scud1@users.sourceforge.net
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done a bit of thinking about the current design with respect to entities within the simulation (ie. Settlements, Vehicles, and new entities like Landmarks, Satellites, etc.).
Essentially with some redesign of the current classes -- specifically to more fully encapsulate the implementation of these entities, uncoupling the user interface from the entities -- it would create a system that is more dynamic and easier to construct new entities.
New entities could then be designed by non-simulation developers by simply conforming to one or more interfaces. On a tangent, it'll be possible to implement entities in Python -- this is interesting because it allows non-Java programmers to design their own entities to launch into a simulation (this functionality would be provided by using the fantastic JPython).
The system would then be configured with an XML specification file (a la XML deployment descriptors in Enterprise JavaBeans), such that a tag directly corresponds to an entity object (and it's parameters are also specified in the XML file). The entire process of starting a simulation with a new creation simply involves implementing the entity class and updating the XML deployment file.
I'll send some more information about this to the developers list within a day or so (I hope).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I was actually thinking of adding a "Structure" class between "Unit" and "Settlement" that would cover supply caches, power stations, weather stations, etc. and could be extended to other things.
I already have support for automatic behavior in settlements. The clockpulse signal (currently representing 10 minutes or so of compressed time) gets sent to all units. A settlement sends it on to its greenhouse. Once a greenhouse is planted, the seeds will grow at an automatic rate until harvest (the top progress bar in the user interface). People must also tend the greenhouse to get food by harvest time.
An auto station could use this clock pulse to do its work.
Scott Davis
Project Administrator
Mars Simulation Project
scud1@users.sourceforge.net
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you don't mind, I'll offer some constructive criticism.
(1) There is currently no provision in your development tree for "automated stations": weather balloons, met stations, robotic mines, automated greenhouses, storage/emergency depots, etc., etc. In the current model, it's a full-fledged "settlement" or nothing. Considering the *major* role of robotic stations on Mars today and the likely continued importance of automatic elements to a Mars colony (cf. RGB Mars, for example), I think it important that an "Auto-Station" be implemented. Such a class could re-use the same classes that the Settlement class uses to create the Garage, Storage, Greenhouse, etc.; but an Auto-Station would not be required to include all elements.
(1a) Once the Auto-Station is implemented, it might be interesting to model the maintenance that would obviously be required by such a station. Storage begins to deteriorate if not visited and repaired once every 5 simulated orbits; Industrial mining robots begin to malfunction after 6 simulated months; that sort of thing. It definitely gives all those rovers more to do!
Vehicle maintenance and mechanical failures are working in the pending 2.7 release. It wouldn't be hard to extend this behavior to settlements and perhaps to structures.
I'm not sure if satellites and robots should be under the vehicle class hierarchy or not. I haven't decided just yet.
Scott Davis
Project Administrator
Mars Simulation Project
scud1@users.sourceforge.net
I've done a bit of thinking about the current design with respect to entities within the simulation (ie. Settlements, Vehicles, and new entities like Landmarks, Satellites, etc.).
Essentially with some redesign of the current classes -- specifically to more fully encapsulate the implementation of these entities, uncoupling the user interface from the entities -- it would create a system that is more dynamic and easier to construct new entities.
New entities could then be designed by non-simulation developers by simply conforming to one or more interfaces. On a tangent, it'll be possible to implement entities in Python -- this is interesting because it allows non-Java programmers to design their own entities to launch into a simulation (this functionality would be provided by using the fantastic JPython).
The system would then be configured with an XML specification file (a la XML deployment descriptors in Enterprise JavaBeans), such that a tag directly corresponds to an entity object (and it's parameters are also specified in the XML file). The entire process of starting a simulation with a new creation simply involves implementing the entity class and updating the XML deployment file.
I'll send some more information about this to the developers list within a day or so (I hope).
Thanks, I appreciate constructive comments.
1) I was actually thinking of adding a "Structure" class between "Unit" and "Settlement" that would cover supply caches, power stations, weather stations, etc. and could be extended to other things.
I already have support for automatic behavior in settlements. The clockpulse signal (currently representing 10 minutes or so of compressed time) gets sent to all units. A settlement sends it on to its greenhouse. Once a greenhouse is planted, the seeds will grow at an automatic rate until harvest (the top progress bar in the user interface). People must also tend the greenhouse to get food by harvest time.
An auto station could use this clock pulse to do its work.
Scott Davis
Project Administrator
Mars Simulation Project
scud1@users.sourceforge.net