> Thanks for your detailed plan! It looks very reasonable, and as you say, some parts,
> especially the ones involving adding some GUI would probably have to be done in a
> plug in to avoid cluttering the standard GUI.
> You mentioned that you want to use the meteor code as an example code. While it is a
> good base for understanding the StelModule architecture, I think your satellites will need
> to be themselve instances of StelObjects, so that they can be searched and selected as
> other objects. This also means that the base module should inherit StelObjectModules
> instead of directly StelModule.
Thanks for the tips. I figured that there would be reasonable separation points between the
code that "drives under the bonnet" and UI and that's helped a lot for getting started. The
idea behind phase 1 was to actually avoid any UI work initially and concentrate on those
parts that "just get things done" so the above is a good lead/starting point.
> So to summarize, I would say that your code should be architectured like that:
> Create a ArtificalSatelliteMgr class
inheriting StelObjectModule. This class
> manages a collection of insteances of the ArtificialSatellite class, which inherit the
> StelObject class.For a better integration, the ArtificalSatelliteMgr should not manage
> GUI-related features (then it can be included in the base code of stellarium)
> I think it would be a clean start for you. In the future, we may want to integrate the
> code more with the current system for SolarSystem, but as this is currently not so nice
> code, it will need further cleaning before attempting that.