API Question Planet Module Problem

[Phoenix]

Hello.

I am trying to write a planet module but coming up against a basic problem. I have probably misunderstood something, but I can't work out what it is.

My module needs to know information about the Moon in order to do its own ephemeris calculation. The problem is, I can't get a handle to the Moon - the oapiGetGbodyByName("Moon") function keeps returning NULL. My planet renders, but at the centre of the Earth - it's defined as Earth:Moon2 = MyPlanet in the Sol configuration file. Here's part of my code:

int MyPlanet::clbkFastEphemeris(double SimT, int Req, double *pStateVector)
{
// Get a handle to the Moon.
OBJHANDLE hMoon(oapiGetGbodyByName("Moon"));
if(!hMoon) return 0;
// Get a CELBODY interface to the Moon.
CELBODY *pMoon(oapiGetCelbodyInterface(hMoon));
if(!pMoon) return 0;
// State vector store.
Vector3<double> Data[4];
// Get the state vector of the Moon at this SimT.
pMoon->clbkFastEphemeris(SimT, EPHEM_TRUEPOS | EPHEM_TRUEVEL, (double *)Data);

Does anyone know what I am doing wrong? Thanks for any help.

 

[Urwumpe]

I think you call the function when it can't be called, thus it fails.

 

[Phoenix]

Thanks.

 

[martins]

As a general rule, calling any functions with prefix "clbk" from an addon module is not a good idea. These are callback functions called by the Orbiter core at well-defined specific times. Calling them from arbitrary positions within a module often results in undefined behaviour.

Regarding this specific case: Orbiter performs the ephemeris updates with a fairly complicated, 2-pass recursive method. The solar system is defined as a tree structure, where each node first recursively updates the true relative positions of the leaves, then calculates the barycentre position of the node's sub-system relative to the parent. In the second pass, the true absolute positions of all bodies are evaluated iteratively starting from the root (the sun).

You can already see that calling another object's clbkFastEphemeris from your own clbkFastEphemeris has to be problematic, since it creates a race condition. The result depends on the order in which Orbiter updates the cbodies, which is not defined.

Ideally, all celestial bodies should be able to update their relative positions (relative to the local node) independently of any other celestial bodies, to avoid circular dependencies. Why do you need the moon's position? The only possible reason I can think of is if you do a dynamic, rather than an analytic update. If that's the case, I don't think it will work, because cbodies need to be able to report their state vectors at arbitrary times.

 

[Phoenix]

What I was trying to do was something non-standard. I was trying to create a local atmosphere on the Moon (only present during the lunar daytime) by implementing a small planet with an atmosphere and its position locked to a sub-surface location on the Moon. There would have been a dome of atmosphere that would have broken the surface of the Moon. That's why I needed a handle to this body.

I understand now why it doesn't make sense to be able to get a handle to another g-body. My idea probably wouldn't have worked anyway - there might have rendering issues, and Orbiter might not have known whether to apply atmospheric effects to a vessel's location and velocity when close to the Moon.

Thanks.

 

[martins]

I agree that this method probably wouldn't work. Orbiter implicitly assumes that celestial bodies are well-separated, and that any vessel can at most be within the atmospheric hull of the most proximate cbody. Whether it would consider the moon or your artificial planet is not clear. It is probably better to write a custom atmosphere module for this purpose.

Incidently, I think you could get round the ephemeris problem by making your artificial cbody a moon of the Moon, rather than a moon of Earth. Since you only need to calculate the ephemeris relative to the parent body, you wouldn't need the Moon's position at all. And the ephemeris calculation would be trivial, since the position would be fixed in the Moon's frame of reference.

 

[Phoenix]

That's originally how I wanted to do it, but I didn't realise Orbiter permitted a moon of a moon. How is that written in the Sol.cfg file? This doesn't work:

; === Configuration file for solar system ===
Name = Sol

Star1 = Sun
Planet1 = Mercury
Planet2 = Venus
Planet3 = Earth
Earth:Moon1 = Moon
Moon:Moon1 = MyPlanet
Planet4 = Mars

 

[martins]

Try

Earth:Moon:Moon1 = MyPlanet

 

[Phoenix]

This works, although it doesn't show up in the camera tree view:

; === Configuration file for solar system ===
Name = Sol
Star1 = Sun
Planet1 = Mercury
Planet2 = Venus
Planet3 = Earth
Earth:Moon1 = Moon
Earth:Moon1:Moon1 = MyPlanet
Planet4 = Mars

Using the name "Moon" doesn't seem to work.

Thanks.

 

[martins]

Earth:Moon1:Moon1 = MyPlanet

Using the name "Moon" doesn't seem to work.

Thanks.

You are correct. It has to be Earth:Moon1:Moon1
I can't check the camera dialog right now, but it is quite possible that this doesn't support structures deeper than sun/planet/moon. I'll keep it in mind.

 

[jangofett287]

Scratch that, ninja'd by martins.

 

[Phoenix]

My planet renders in lunar space as you said, but it seems this idea of mine isn't going to work because there are rendering problems that I suspected might happen but I thought I'd give it a go anyway.

Thanks for the help.