New "plug-in" for Celestia

[Cham]

Working from the orbit back to the central mass is probably going to give inconsistent stellar masses in the multiplanet systems, if only because of parameters being quoted to a limited degree of precision appropriate to the observational errors on the quantities.

Precisely, this is a feature of the plug-in ! I tested it on several extrasolar systems (especially RHO1 Cnc with its 5 planets), and the mass values are consistent to 2 or 3 significant digits. The variations are actually a very strong pedagogical feature of the plug-in and shows a bit the limitations on measurements.

I also tested the plug-in on the PSR 1257+12 system (3 telluric planets). Also there, the values are interesting and pretty consistent to some precision, of course...). I also tested Gliese 876, and the data is pretty nice there too.

[Fenerit]

Merci Vincent, that code help me alot on several questions. You are a very precious man! Before I got the elongation, now I will get the illuminated fraction. If you are interested about le correxions par les excentricit?s planetaire, I found some links. For the rest I've tested the plugin a bit and Pluto is wrong. Surely must have been corrected in that evolution, right?

[Vincent]

Merci Vincent, that code help me alot on several questions. You are a very precious man! Before I got the elongation, now I will get the illuminated fraction. If you are interested about le correxions par les excentricit?s planetaire, I found some links. For the rest I've tested the plugin a bit and Pluto is wrong. Surely must have been corrected in that evolution, right?

Massimo, you're welcome.
As to the Pluto-Charon system, this is precisely the last issue we
were dealing with before releasing the final version of the addon.
The issue is that Pluto is defined in solarsys.scc as a child of Sol,
whereas its orbital declaration refers to the Pluto-Charon barycenter...
So we decided to display the orbital parameters of the Pluto-Charon
barycenter when the selected object is Pluto, Charon or Pluto-Charon.

Attached is what should be the final version of the addon.
I'll shortly add a post to the Add-on release section.
Any feedback is still greatly appreciated, of course.

[Chuft-Captain]

Very nice work guys.

Not sure how useful this will be for my addons, but I am certainly interested to have a look at the code when I get a chance to see some of the techniques you've used to achieve this.

Works for the Rungworld...

rungworld.jpg

(although in this circumstance I think it's of limited usefulness, as I expect all 360 sections of the Rungworld will have pretty much the same orbital parameters. )

CC

[Cham]

Chuft-Captain,

according to the parameters shown in the window, on your picture above, you should define all your cylindrical parts as "component", in their SSC file.

As I already said, the plug-in is extremely usefull to detect SSC mistakes. I already detected several "errors" in my own addons, using the plug-in.

[Chuft-Captain]

according to the parameters shown in the window, on your picture above, you should define all your cylindrical parts as "component", in their SSC file.

Interesting observation... which parameters in particular made you come to this conclusion?

As I already said, the plug-in is extremely usefull to detect SSC mistakes. I already detected several "errors" in my own addons, using the plug-in.

Sorry, i wasn't meaning to downplay it's usefulness to you and to others... it's just that I don't make mistakes in my SSC's, so it may be less useful to me.

PS. Just joking..

[Cham]

[which parameters in particular made you come to this conclusion?

Many !

First, the selected component is described as a Giant gas, which it isn't !
Second, its mass is highly unrealistic (2 millions of solar masses !!).
Third, the eccentricity = 1 is irrelevant, as most probably the Orbital Period...

If you change the Class of your object, in its SSC ("spacecraft", or maybe "component", instead of something else), it should gives some more relevant parameters.

EDIT : If your model is centered on Sol in the SSC file (semi-major axis set to 0), the plug-in may "crash". I'm not sure of this, though.

[t00fri]

What I would find of considerable "educational interest" would be a display of the difference between the "isolated" Keplerian 2-body predictions and those from the REAL orbits (Celestia?). Orbits often get strongly distorted wrto Kepler by the cumulative effects of neighboring massive bodies! The Jovian system is a good example: Due to Jupiter's spheroidal shape, the planet itself is NOT a spherical source of gravitational potential and there are plenty of neighboring bodies when navigating in-between its moons.

The fun would be to look out for large deviations from Kepler and then to try to qualitatively understand why this happens!! Conversely, in cases where Kepler is quite accurate (binaries...) one might try to justify this...

Fridger

[Chuft-Captain]

First, the selected component is described as a Giant gas, which it isn't !

Don't know why this is. I assume your script is making an educated guess based on the distance from Sol???

Second, its mass is highly unrealistic (2 millions of solar masses !!).

It appears that your script calculates an object's Mass based on it's period (on the assumption that the object is in a Keplerian orbit, which in this case it is decidedly not! ...as you'll see if you examine the code below.)

If you change the Class of your object, in its SSC ("spacecraft", or maybe "component", instead of something else), it should gives some more relevant parameters.

Interesting that you suggested this....as I recently began upgrading the addon to use 1.6.0 features, and converting to Components or SurfaceFeatures was on the agenda.

EDIT : If your model is centered on Sol in the SSC file (semi-major axis set to 0), the plug-in may "crash". I'm not sure of this, though.

Centered in this case on the "Ladder" object using an OrbitFrame and FixedPosition of zero.

FWIW, here's the current state of the code for the Rungworld section displayed earlier:

Code: Select all

"Ladder Section 109" "Sol"
{
   Mesh      "ladder.cmod"
   #Texture  "Aluminm4.*"
SpecularColor [ 0.5 0.5 0.55 ]
SpecularPower 25.0
   Radius    5943991.495 #1.02au tan 1
   Mass    5.8333e24 # 350 earths/360
   EllipticalOrbit {
      Period  1e12    # 9.11/365
      SemiMajorAxis   4.54 #au 153000000 km
      ArgOfPericenter  109
      }
   RotationOffset    109
}

"Rung Section 109" "Sol"
{
   Mesh      "rung09.cmod"
   Radius    5862965.874 #1.02au tan 1
   Mass    5.8333e24 # 350 earths/360

     OrbitFrame { BodyFixed { Center "Sol/Ladder Section 109" }}
     FixedPosition  [ 0 0 0]

     BodyFrame { BodyFixed { Center "Sol/Ladder Section 109" }}
   UniformRotation
   {
         Period       24.0
         Inclination    0
         AscendingNode    0
         MeridianAngle    0
         Epoch       0.9
   }
}


This is currently in a state of change however.
I suspect that the "2 millions of solar masses is caused by the "Period 1e12" statement.

CC

PS. Your addon is really designed for Keplerian Objects, which is really the reason why I don't expect it to be very useful for my addons, because I make extensive use of Orbitframes with FixedPositions etc.. in my addons, but that's OK because I have my own techniques for Quality Assurance.

[Cham]

[Don't know why this is. I assume your script is making an educated guess based on the distance from Sol???

No, not at all. The plug-in checks the Class of the object AND its size.

The SSC code above is not well designed for Celestia 1.6, since the Class isn't defined. So, in this case, the plug-in assumes that the object is a planet (exactly as Celestia 1.6) ! You really need to add a Class in the SSC code. In the case shown above, your component should be described as what it is, actually : a "spacecraft" or a "component". Then, and only then, the plug-in would gives relevant values, whatever the orbit (be it keplerian or not). The plug-in is fully "Celestia 1.6" in its design, and this is why it's also a very good tool to check addons "coherence" (relative to Celestia 1.6)!

I suspect that the "2 millions of solar masses is caused by the "Period 1e12" statement.

Actually it's the reverse ! For a given distance, a large mass implies a faster revolution, since [tex]T \propto \frac{1}{\sqrt M}[/tex]. Or for a given period, [tex]M \propto a^3[/tex]. So larger is the size of the orbit, larger is the mass which makes the objet revolves for the given period. This is exactly the case of your component, since the plug-in says it's revolving with a period of 24 hours only (1 day !). For a distance of 4.50 AU to its central mass, the central mass must be huge to make the object revolving in that short period of time ! The origin of this weirdness is that your component (Rung Section 109) is fixed in a frame which is rotating with a period of 24h, while its "parent" is Sol (that's from your SSC). Like what I've said, the only way to get relevant values in the plug-in is to define the object's Class according to what it should be : a "component", i.e. a part of the Ladder Section 109 (since the Rung Section 109 is defined relative to it, in the SSC code above).

Believe me, I know EXACTLY how SSC is working in Celestia 1.6, especially since I made several complicated addons myself, with reference points, barycenters, ScriptedOrbits, etc. AFAIK, the plug-in was made to take care of most (if not all) of the SSC possibilities (assuming that addons creators are making their SSC correctly, for Celestia 1.6).

[Chuft-Captain]

The plug-in checks the Class of the object AND its size.

Does the "Mass" statement get ignored completely?

The SSC code above is not well designed for Celestia 1.6, since the Class isn't defined. So, in this case, the plug-in assumes that the object is a planet (exactly as Celestia 1.6) ! You really need to add a Class in the SSC code. In the case shown above, your component should be described as what it is, actually : a "spacecraft" or a "component".

Agreed - As I said, it's currently undergoing conversion from circa.1.3/1.4 to 1.6 code, so the posted code is a WIP, but what you suggest regarding Class definition is already planned.

I suspect that the "2 millions of solar masses is caused by the "Period 1e12" statement.

Actually it's the reverse ! For a given distance, a large mass implies a faster revolution, since [tex]T \propto \frac{1}{\sqrt M}[/tex]. Or for a given period, [tex]M \propto a^3[/tex]. So larger is the size of the orbit, larger is the mass which makes the objet revolves for the given period. This is exactly the case of your component, since the plug-in says it's revolving with a period of 24 hours only (1 day !). For a distance of 4.50 AU to its central mass, the central mass must be huge to make the object revolving in that short period of time !

Hang on though Cham, the 24 hours is the "Rotation Period" of the Rung, NOT an "orbital" period. Each Rung rotates about it's own axis to provide a 24 hour day-night cycle. (like the Earth rotates about it's axis)
This however has nothing at all to do with it's Orbit, so IMHO has not a lot to do with Keplers Laws.
In fact, as the Rung's position is fixed to the Ladder...

Code: Select all

     OrbitFrame { BodyFixed { Center "Sol/Ladder Section 109" }}
     FixedPosition  [ 0 0 0]


... it effectively has the same orbital period (relative to Sol) as the Ladder (1e12 years).
But, more correctly, it has a fixed orbit (with infinite or zero period) relative to the Ladder.

The origin of this weirdness is that your component (Rung Section 109) is fixed in a frame which is rotating with a period of 24h, while its "parent" is Sol (that's from your SSC). Like what I've said, the only way to get relevant values in the plug-in is to define the object's Class according to what it should be : a "component", i.e. a part of the Ladder Section 109 (since the Rung Section 109 is defined relative to it, in the SSC code above).

I'm planning to change the Parent to be the Ladder. The use of Sol as the Parent is a hangover from 1.3/1.4.
Notwithstanding this fact, I think your addon should be using the OrbitFrame Center if it's available rather than the lexical "parent" to determine the Orbital parameters (and then it wouldn't matter iwhether I changed the Parent, or left it as "Sol".)
I may be over-stating, but in 1.6 the lexical parent becomes effectively irrelevant as far as the orbit is concerned when an OrbitFrame defines the orbit. (as is the case in the Pluto-Charon system.)

Believe me, I know EXACTLY how SSC is working in Celestia 1.6, especially since I made several complicated addons myself, with reference points, barycenters, ScriptedOrbits, etc. AFAIK, the plug-in was made to take care of most (if not all) of the SSC possibilities (assuming that addons creators are making their SSC correctly, for Celestia 1.6).

It may be difficult to cover all the possibilities that the Reference Frames provide for, but recognizing the difference between OrbitFrames and BodyFrames would be a good start. It definitely shouldn't be assuming that the 24 hour period has anything to do with it's orbit in this example.

Perhaps some of these issues will sort themselves out when my upgrade is complete, but there seems to be a little confusion in your script wrt. RotationPeriod vs OrbitalPeriod, BodyFrame vs OrbitFrame.

Hope this feedback is useful.
Cheers
CC

[Vincent]

CC,

Thanks for testing the plug-in, even if as you previously wrote, it should be used for objects in a Keplerian orbit.
Using it in the case of your addon is quite interesting, though...

Does the "Mass" statement get ignored completely?

Right. The Mass statement can't be used because it is rarely defined.
Here, the mass is computed from the instantaneous velocity value and using
the Kepler's third law as described by Martin in his first post.

Perhaps some of these issues will sort themselves out when my upgrade is complete, but there seems to be a little confusion in your script wrt. RotationPeriod vs OrbitalPeriod, BodyFrame vs OrbitFrame.

There's no confusion at all in the plug-in. The 24h value displayed for the Orbital Period
doesn't come from your Rotation Period statement. Just try to change your Rotation Period
value to anything else than 24, and you'll see that the value displayed for Orbital Period
sticks to 24h. You'll find the explanation in the Celestia orbit code itself. In the case of
a fixed orbit, the returned value for Orbital Period is a constant equal to 1 day = 24 hours:

(orbit.cpp, line ~579)

Code: Select all

double FixedOrbit::getPeriod() const
{
    return 1.0;
}

[Chuft-Captain]

CC,

Thanks for testing the plug-in, even if as you previously wrote, it should be used for objects in a Keplerian orbit.
Using it in the case of your addon is quite interesting, though...

I certainly don't have any expectations that your addon will give meaningful numbers for an addon like the Rungworld.

Does the "Mass" statement get ignored completely?

Right. The Mass statement can't be used because it is rarely defined.
Here, the mass is computed from the instantaneous velocity value and using
the Kepler's third law as described by Martin in his first post.

Perhaps it might be useful to use the Mass value rather than the calculated value IFthe addon maker has provided a Mass value. This would allow creators of nonsensical addons such as mine to replace the meaningless calculated values with another value....but then you may consider that this might defeat the aims of your addon....(Just a thought... )

There's no confusion at all in the plug-in. The 24h value displayed for the Orbital Period doesn't come from your Rotation Period statement. Just try to change your Rotation Period value to anything else than 24, and you'll see that the value displayed for Orbital Period sticks to 24h. You'll find the explanation in the Celestia orbit code itself. In the case of a fixed orbit, the returned value for Orbital Period is a constant equal to 1 day = 24 hours...

OK. Just an unhappy coincidence then. Thanks for the explanation.

[ajtribick]

Does the "Mass" statement get ignored completely?

Right. The Mass statement can't be used because it is rarely defined.
Here, the mass is computed from the instantaneous velocity value and using
the Kepler's third law as described by Martin in his first post.

Perhaps it might be useful to use the Mass value rather than the calculated value IFthe addon maker has provided a Mass value. This would allow creators of nonsensical addons such as mine to replace the meaningless calculated values with another value....but then you may consider that this might defeat the aims of your addon....(Just a thought... )

One of the reasons I didn't end up implementing mass units was because apparently no-one was doing anything with them... if using mass values becomes more common it might be worth investigating doing so. Furthermore mass values cannot at present be specified for stars, which would limit the utility somewhat.

[Fenerit]

Well, initially I was thinking to open a new thread but just to rest in theme of testing and about plugin development, I decided to post here what I would say.
I'm close to end my first little plugin showing the illuminated fractions, elongations and phases of the planets/moons. In doing this my purpose was also that of having the kleperian plugin displayed AS IT IS, without interfere with. Now, these plugins are mutually excluding, either one or another but altogether. First, I suggest to change the statements

Code: Select all

adds_t = {

"KeplerParamBox",

}


within lua_edu_tools.lua with some like:

Code: Select all

plugins = add_t


where

Code: Select all

add_t = {
"KeplerParamBox",
"your_newBox",
}


be included within a file called plugins.lua in /extras folder; then add the require "plugins" to the lua_edu_tools.lua. in this way the things works pretty well:



The PROBLEM is another. First, note that in my "phase" plugin there isn't nothing similar to the keplerian one from the point of view of the boxes costructions so that it avoid sovrappositions. Second my plugin is static, that is define the screen origin as zero and then customize the toplef, topbottom positions. (in the image topleft = 0, topbottom = 104) In this way it is resolution independent, as is seen below:

(windowed)


(400x300)


and so on for 16:9 screens (topleft = 0 is the same, isn't?).
Now, I point out the problem. The problem is the screenBox hardcoded function that prevent the possibility of having both the metods meeting; because after a full screen switch and return, phases plugin rest where is, while the keplerian shatter itself:



So, at this point i'm waiting for suggestions, being aware that a way for hold screen settings as the INI file is required, because all the next plugins will starts always in the same position, overlying itselves.
Hope this contribution be taken as one "in topic" concern.

[Cham]

With the help of Vincent, I designed a pictures window, integrated to the other LUA "modules" (or "plug-ins"). The first version works perfectly, but is currently limited to only one picture per object. The number of objects is unlimited, however. The window can be dragged and placed anywhere inside Celestia's window. This new "plug-in" should be very usefull in the classroom. Here's a preview :

[Fenerit]

This is good! Perhaps need a button for closing the box? One thing Martin: I see that you have also the compass: if this latter is static, what happen in your configuration when switch in full screen mode and then return in windowed? The other two restart from the half screen right and the compass is moving from its position?

[Vincent]

Massimo,

As you're suggesting, I thought about adding a configuration file to the Lua plug-ins
so as to easily enable/disable each feature or customize the key shortcuts...
However, I'd like this version to keep "light", or at least, much lighter than all the
Lua Edu Tools stuff... That's why I'm still hesitating about adding a config file or not...

Now, I point out the problem. The problem is the screenBox hardcoded function that prevent the possibility of having both the metods meeting; because after a full screen switch and return, phases plugin rest where is, while the keplerian shatter itself:

What do you mean by "shatter itself" ?
After resizing the main Celestia window, the Keplerian parameters window should simply get back
to its initial position... If this is not the case, you may want to define your iwidth, iheight values
as local. That's what I did in the final version of KeplerParamBox.lua :

Code: Select all

local iwidth, iheight = celestia:getscreendimension();

[Fenerit]

Hallo Vincent, happy you are here, so I can precise more the issues.
First, I've downloaded the new keplerian version tonight and I haven't did the time to control, so probably its beaviour is best. My concerns are upon an "unified" path about how to install the "plugins" seamlessy once developed and in the way to be showed all, not just one by one. Moreover, the users should be at repair from find either problem of any sort or conflicts upon boxes; for that an exclusive configuration file accounting for successive insertions was a fist step.

As you're suggesting, I thought about adding a configuration file to the Lua plug-ins
so as to easily enable/disable each feature or customize the key shortcuts...
However, I'd like this version to keep "light", or at least, much lighter than all the
Lua Edu Tools stuff... That's why I'm still hesitating about adding a config file or not...

Second, my preference is as always that these plugins be activated from the LUATOOLS interface, at least in the way the add-on already did: e.a a "plugin" button on the toolkit > plugin toolbox > single plugin checked. Once documented about to do, would be easy accomplish the operation.

What do you mean by "shatter itself" ?
After resizing the main Celestia window, the Keplerian parameters window should simply get back
to its initial position...

Third, and the more significative point, is about the way in which the screeBox function control the box behaviour. I think that the path followed so far, at least in the alpha version of keplerian plugin, is inadequate. I speak about the screenBox setting of letting to decide the displacement of the plugin box to the height and to the width (and fractions) of the screen, because - although working - prevent the user from having the plugin box where he wish; e.a. keplerian start on the half right of the screen, I move it on the left and then I switch in full screen: the plugin return on the half right, and so on. Not only, but this setting based upon the screen-width screen-height is incompatible with the other - user definied - method, as you can see in my last screendump above, because LUA engine must accomplish two different screen update and "destroy" the box screen-width, screen-height based.
In sumn, the settings are two: one for the simple plugin insertion, one for "nail" the boxes on screen; this latter also in case of restarting Celestia (io.open, io.write perhaps?); but, on the whole, without to rule the boxes' behaviour trought the screen' resolution propriety in terms of "hardware management", just by user-defined pixels inside that "hardware management"; this way "stick" the plugins by default, of course, and a floating plugin will can moves over it without interference, thing that is not possible whether to the floating plugins are assigned positions in function of screen-wifth, screen-height. Yes, I know, I'm a bit ripetitive but I lack of words for better explaining.

[Cham]

The first version works perfectly, but is currently limited to only one picture per object. The number of objects is unlimited, however.

The newer version is now able to use an unlimited number of pictures per object ! Clicking two "hotspots" on the picture let the user cycle through the whole pictures set (forward and backward)
This module is awesome ! Thanks Vincent !

EDIT : I'm really excited with this pictures plug-in. We now can show scenes like this one below, for example. I'm sure fans of Science-Fiction will be pleased by the new capabilities, in Celestia. And the plug-in has a very nice feature : we can add pictures on the fly, without the need to restart Celestia to see some new pictures !

Teaching astronomy will never be the same, now !