Question Make a base class for other modules to inherit

[SolarLiner]

Hi,
Still thinking about the Satellites idea I had (and thought out loud in the Random Comments Thread), I want to make a base "satellite" class that will handle everything a satellite has to handle, then make inherited classes for different types of satellites (especially an observation one for making pictures).

The problem is: How can I actually code the said classes and let the developers inherite these classes to make their addons based on it?
I mean it like this:

Sat
-CommSat
---TDRS_By_Someone

With each class being inherited from the class above. "Sat" may contain everything about power management, then "CommSat" inplements communication relay system, and then some author adds the desired satellite (here a TDRS), links to the module and eventually make custom code.

My question here is: How can I make these classes? What will the developer have to do to inherit from these classes further on?

Thanks for the answers here

 

[thepenguin]

I'm currently in the process of coding something similar to what you are suggesting, but much more advanced.

You would probably want to set it up as a library (SAT.lib or something), then the developer would go:

class TDRS: public SAT {

Although, before you write such a library, you should be sure to know what exactly it is going to provide that is unique or special about it. I don't think you want to be part of a GenericVessel/spacecraft3 case where there are 2 different libraries doing the exact same thing. (I know that one is open-source and the other is not, but I have to think that this schism causes more trouble than it fixes...)

Seeing as I am working on something close (at least it sounds like it), I am just curious about what you are proposing to do, specifically.

 

[jedidia]

My question here is: How can I make these classes? What will the developer have to do to inherit from these classes further on?

make all function calls virtual, and either give further developers access to the source code or build them as a static lib and only release the headers so other developers can import it into their project.

 

[Enjo]

I think that my HUDDrawer SDK's code and documentation should give you a lot of information about what you want to do. There's also ModuleMessaging SDK, but it may be less obvious for your case, although the library itself is simpler.

 

[SolarLiner]

Thanks for the answers

What I plan to do is code an "as functional as possible" satellite base class which simulates power management, directional tracking (for observation sats) and sunlight tracking (in case of rotating solar panels) and other features that I didn't think of yet.
The project will be open source as usual, but if a project like this is already in development, I'll stop and let it finish, or better, be glad to take part of the development.

Thanks Enjo for the links, I'll dig that out

 

[thepenguin]

Thanks for the answers
What I plan to do is code an "as functional as possible" satellite base class which simulates power management, directional tracking (for observation sats) and sunlight tracking (in case of rotating solar panels) and other features that I didn't think of yet.
The project will be open source as usual, but if a project like this is already in development, I'll stop and let it finish, or better, be glad to take part of the development.

Thanks Enjo for the links, I'll dig that out

If you are serious about wanting to help, I could use some assistance with an algorithm for determining line-of-sight between communication satellites/ships/ground stations. Something where a satellite would go into radio blackout when it crossed behind the moon if it was setup for direct earth relay.

All I would really need is an algorithm for saying if there is a line of sight between two points in space (may be on the surface of a planetary body, an orbiting satellite, or a DG relaying back data from the far side of the moon) in a given planetary system.

Of course, the details of data relay and protocol are another matter altogether; what I need is a Boolean-return function to tell me if I have line-of-sight to another ship. Then I would have a reason to work on more complex systems for radio because the signals couldn't plow through the moon.

For "Bonus Points":
1. Maybe do something with relativity warping the beam ever so slightly around a planet? I don't think the difference is very significant, though.
2. Signals take time to travel. If the function were able to deal with movement in either of the points as the signal travels, that would be awesome. (when sending commands to vessels in Mars/Jupiter orbit, it adds up)
3. Something for improving radio signals within an atmosphere (like HAM radio bouncing off the ionosphere).

I don't expect any of these three "Bonus Ideas" to be implemented in the first version of the algorithm (just trying to calculate LOS with random spherical bodies blocking your view in an arbitrary planetary system is tough enough), but if they interest you and you want to do for it, so much for the better!

 

[SolarLiner]

I am serious about helping, I'm always glad to help in some way

Artlav's [ame=http://www.orbithangar.com/searchid.php?ID=4864]Videnie orbit drawer[/ame], the lines were occluded by the planet, so there is a way to get the bounding sphere of a planet and see if a link is possible or not.
Problems are that there are no ways to shoot a ray to another satellite in the API that I know of, so we would have to either create it, or use an other trick.

Assuming antennas are omnidirectional, it is really simple to get the time signal takes to travel from a sat to another. Get the distance between the two relays, then divide it by the speed of light, then boom you're done, you got the time it takes.

Relativity warps the beam so slightly that it will be a waste of CPU cycles to actually compute that (unless you're putting a sat around a neutron star or a black hole). So nothing about relativity for me.

Maybe something for atmospheres only, like short range atmospheric relay system for remote-controlled vehicles (think of little rovers that UMmu could drive around to explore!), that's a good idea, yep.

I'll try to find something to correctly occlude signals between sats to start with.

Is it part of OBSP or for a "standalone" addon ?

 

[jedidia]

Problems are that there are no ways to shoot a ray to another satellite in the API that I know of, so we would have to either create it, or use an other trick.

If this is for a line of sight check, why do you have to shoot a ray via the API? You have all the positions. A bit of relatively simple trigonometry and the planets radius will make for a perfectly sufficient check. IMS does this to determine whether a vessel is in planetary shadow (I.E. it takes the position of the vessel, the position of the sun, and sees if the refference planet is in the way).

 

[thepenguin]

I am serious about helping, I'm always glad to help in some way

Glad to hear it.

Artlav's [ame=http://www.orbithangar.com/searchid.php?ID=4864]Videnie orbit drawer[/ame], the lines were occluded by the planet, so there is a way to get the bounding sphere of a planet and see if a link is possible or not.
Problems are that there are no ways to shoot a ray to another satellite in the API that I know of, so we would have to either create it, or use an other trick.

Assuming antennas are omnidirectional, it is really simple to get the time signal takes to travel from a sat to another. Get the distance between the two relays, then divide it by the speed of light, then boom you're done, you got the time it takes.

I was also planning on monodirectional (focused) antennae, but those details could be tacked on after-the-fact.

Relativity warps the beam so slightly that it will be a waste of CPU cycles to actually compute that (unless you're putting a sat around a neutron star or a black hole). So nothing about relativity for me.

Yeah, it doesn't seem very important for a single planetary system

Maybe something for atmospheres only, like short range atmospheric relay system for remote-controlled vehicles (think of little rovers that UMmu could drive around to explore!), that's a good idea, yep.

Glad to hear you will explore this.

I'll try to find something to correctly occlude signals between sats to start with.

thanks!