Celestia Forums

Why doesn't this script work?

According to http://celestia.h-schmidt.net/celx-summ ... t.html#API , 'parent' is a valid value returned from getinfo(), but while I can get a result from info.radius or info.rotationPeriod or info.type I can't get anything from info.parent. Instead I get an error message saying "[string "D:\Celestia\scripts\parent.celx]:9: attempt to concatenate global 'parent' (a userdata value)."

I tried this while selecting Earth (expecting "Sol" to be returned as the parent) and the Moon (expecting "Earth" to be returned as the parent).



More to the point, why is there a getchildren command and not a getparent command?

It won't be long and some of our lonely Celestia souls will ask for a "getgirlfriend" command ...

Bye Fridger

Funnily enough, Fridger, you're partly why I'm asking this. I want to test how Barycentres relate to the objects that orbit them. If they're consistent with everything else in Celestia then they should be parents of the stars around them. If they're not, then it's going to be very difficult to do anything in scripts that involve barycentres.

Malenfant wrote:Why doesn't this script work?

According to http://celestia.h-schmidt.net/celx-summ ... t.html#API , 'parent' is a valid value returned from getinfo(), but while I can get a result from info.radius or info.rotationPeriod or info.type I can't get anything from info.parent. Instead I get an error message saying "[string "D:\Celestia\scripts\parent.celx]:9: attempt to concatenate global 'parent' (a userdata value)."

I tried this while selecting Earth (expecting "Sol" to be returned as the parent) and the Moon (expecting "Earth" to be returned as the parent).

getinfo() is working. The value of parent is not the name of the parent, it is an object representing the parent, just like you get when you do a celestia:find(). Try:

cpotting wrote:getinfo() is working. The value of parent is not the name of the parent, it is an object representing the parent, just like you get when you do a celestia:find().

Sigh. Again, I like how this is totally NOT obvious in the documentation on Harald's site, which implies it's a value like the name or radius or any other property listed there...

Thanks though, that worked.

However, as I feared, it turns out that stars orbiting barycentres do NOT return the barycentre as their parent.

Malenfant wrote:

cpotting wrote:getinfo() is working. The value of parent is not the name of the parent, it is an object representing the parent, just like you get when you do a celestia:find().

Sigh. Again, I like how this is totally NOT obvious in the documentation on Harald's site, which implies it's a value like the name or radius or any other property listed there...

Thanks though, that worked.

However, as I feared, it turns out that stars orbiting barycentres do NOT return the barycentre as their parent.

I checked in a fix that makes parent work when getinfo is called for a star. The value of parent is set to the orbit barycenter for a star in a multiple star system, and is undefined otherwise (so the script needs to check for a nil value of parent rather than assuming it's set.)

--Chris

chris wrote:I checked in a fix that makes parent work when getinfo is called for a star. The value of parent is set to the orbit barycenter for a star in a multiple star system, and is undefined otherwise (so the script needs to check for a nil value of parent rather than assuming it's set.)

--Chris

Excellent! Thanks!

chris wrote:I checked in a fix that makes parent work when getinfo is called for a star. The value of parent is set to the orbit barycenter for a star in a multiple star system, and is undefined otherwise (so the script needs to check for a nil value of parent rather than assuming it's set.)

--Chris

Chris,

I just saw this after posting a reply to malenfant in this thread.

cpotting wrote:

malenfant wrote:
b) Barycentres need to be defined as the parents of objects that are orbiting them. Otherwise they are inaccessible in scripts (plus the current situation is just plain inconsistent with how other hierarchies are implemented in Celestia).

I'm not sure about this. My concern here is that if the parent object for a system is the barycentre, then it is not possible to tell which child is the traditional parent. E.g., if the all the bodies in our solar system orbit a common barycentre, then how can a script distinguish Sol as the main or traditional centre of the system? Similarly, if Jupiter and all it's moons orbit a common barycentre then how does one find that this is the "Jupiter" system?
Ideally (but probably not practically), we could define either the barycentre as the parent and Sol as the uncle, or visa versa.

Is there any chance that you could address this issue? I know that I have scripts that would have a hard time determining which system they are in. For Star/Planets or Planet/Moons it is not so bad (planets orbit stars so the star is the system centre... etc). But it won't be so easy for multiple star systems, or binary asteroids, etc.

cpotting wrote:

I'm not sure about this. My concern here is that if the parent object for a system is the barycentre, then it is not possible to tell which child is the traditional parent. E.g., if the all the bodies in our solar system orbit a common barycentre, then how can a script distinguish Sol as the main or traditional centre of the system? Similarly, if Jupiter and all it's moons orbit a common barycentre then how does one find that this is the "Jupiter" system?
Ideally (but probably not practically), we could define either the barycentre as the parent and Sol as the uncle, or visa versa.

Is there any chance that you could address this issue? I know that I have scripts that would have a hard time determining which system they are in. For Star/Planets or Planet/Moons it is not so bad (planets orbit stars so the star is the system centre... etc). But it won't be so easy for multiple star systems, or binary asteroids, etc.

Hm. How about a getparents() command as well as a getchildren()? getparents() would return everything 'above' the target body in the hierarchy (whether is star, planet, or barycentre), and then the user can pick whatever object he wants out of that?

Malenfant wrote:Hm. How about a getparents() command as well as a getchildren()? getparents() would return everything 'above' the target body in the hierarchy (whether is star, planet, or barycentre), and then the user can pick whatever object he wants out of that?

There would still be some ambiguity.

For example, take the following system:
A-C barycentre
--Alpha Centauri
----PlanetA
--Beta Centauri
----PlanetB
----Y-Z barycentre
------PlanetY
--------MoonX
------PlanetZ
--Proxima Centauri
----PlanetC

For MoonX, your suggested getparents() may return a list like:
{ PlanetY, Y-Z barycentre, Beta Centauri, A-C barycentre }
(I assumed the function would return the parents in order). Nothing in this list tells me that this is the Alpha Centauri system

Getting the children of the patriarch (the topmost parent, A-C barycentre) would give us:
{Alpha Centauri, Beta Centauri, Proxima Centauri }
We still can't tell which object is the system's primary, so we still can't tell that this is the Alpha Centauri system.

Perhaps what we need is new property for barycentres - primary:
A-C barycentre:getinfo().parent = nil
A-C barycentre:getinfo().primary = Alpha Centauri
Y-Z barycentre:getinfo().parent = Beta Centauri
Y-Z barycentre:getinfo().primary = PlanetZ
PlanetZ:getinfo().parent = Y-Z barycentre
PlanetZ:getinfo().primary = nil

This way, you can crawl up the list of parents, just like you have to do now. But you would end up with the A-C barycentre as the final patriarch(since it's parent is nil). You could then ask for the primary and get Alpha Centauri - bingo, we have the system's primary.

Of course, this means we need a new entry in the .ssc files.

We can still add the getparents() and getchildren() functions you suggested. They would most useful (e.g. not having to crawl up the list of parents, just select the last parent in the list of parents)