Fenerit and I are currently working on un update for our Ephemerides and OjectRiseSet plugins/addons for Celestia, to solve 2 bugs in our current versions of the plugins/addons.

To prevent an introduction of new bugs with these addons (as happened previous year ), thoroughly testing is now going on. So I also decided to test the OjectRiseSet plugin/addon in Celestia Spice now.

There I found the next strange behaviour, I cannot understand...

First below, we find the correct behaviour of the SunRiseSet calculation and visualization in Celestia WITHOUT Spice.



The calculated times are accurate and the Celestia visualization is accordingly.

Now below (generated with exactly the same code), we find the INcorrect behaviour of the SunRiseSet calculation and visualization in Celestia WITH Spice.



First of all, the times of RiseSet are practically the same and due to SPICE one could say the times may be more accurate because of more precise RA/DEC calculations in Celestia. So that is not my point.

BUT the visualization completely mismatches the calculation !!!!!

As you can see, WITH Spice the Sun is already coming up at a time NOT matching the calculation, about half an hour earlier and also the Sunset mismatches with the calculated times.
Also we can see that the Celestia Markers do not point down, but they point to the middle of the screen in Spice.

As said, exactly the same Scripting code is used, but the behaviour in Spice seems different.
The approach in the scripts is as follows:



It looks like however (also because of the different markers), that WITH Spice we landed on the surface somewere else...

At least I cannot explain this anymore, so I was hoping to find some help / explanation about this Celestia Spice behaviour here on the CM forum.

Marco

let me reread this thread a few times and it would help if you could pm me with a link to the new code

just a very early guess right now
it ? might? have something to do with MY spice files using the barycenter
and Celestia default using the body center

just a guess but one that i mentioned before ,in needing to explore other ways of using the spice data

IF that is the case , it would not be the first time in history that something was thought be be handled well but years later turned out to be the WRONG way
????????

or

it might be that i am using the Celestia DEFAULT planet rotation
the built in iau rotational

the spice was showing really no difference ,
maybe there IS a difference ?

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

I was thought the same thing, but the barycenter now (2014) is still inside the Sun, at half of the radius (if the SPICE's barycenter is that barycenter). Half an hour of difference in rise/set times seems too much even though the distances in Celestia would be computed toward it and not toward the true center of the Sun.
Then remember how Venus and Uranus in SPICE are flipped respect to their "natural" flipping condition of being reverse rotators. I do not think these issues are your mismatches with .SSC or whatelse.

_________________
Never at rest.
Massimo

--- edit ----
it would be a minor edit to use the spice rotational model and not the default built in

i am only using the spice rotation for moons , those looked to be WAY off
the planets looked to be correct but maybe not .

right now i can not post a file
later tonight i can post a edited version for the earth using the spice rotation


-------- added ----


earth IS using the spice rotation
i forgot i did add that

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

doing some reading
for earth this might solve it

download "earth_fixed.tf" from
ftp://naif.jpl.nasa.gov/pub/naif/generic_kernels/pck/



and see if that solves the earth


Are you using the SAME code in the add on on the ML
or is this an updated version
if updated can i get a link for testing and correcting MY files so it works

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

John, for me that "earth_fixed.tf" for rise/set times works!

same thing for planets and set time too.

_________________
Never at rest.
Massimo

good to know

i will add this fix then to the ssc file

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

John,

I didn't find time yet to test.
But I'll certainly do so.

Thanks very much in helping here !!!!

Marco

Maybe we are to be close to a solution for reverse rotators; at least Venus, which I test now.

Within the pck00010.tpc I've sobstituted the block:


with:


that is, added the minus sign befor RA, Dec and the problem of longitude/latitude of Earth/Sol is vanished. RA, Dec, longitudes, lat. and other astrometrics (AZ, elev, rise/set, axis too) until now returns like usual VSOP87. No apparent changes of position or whatelse. Cross fingers...

_________________
Never at rest.
Massimo

FAILURE!!!

The plugin "tricky" to account for SPICE has deceived me

_________________
Never at rest.
Massimo

SUCCESS!!!



that is: RA = RAorig. - 180, Dec = -DECorig. , PM = PMorig. - 180; then removed the minus sign before 1.4813688.

_________________
Never at rest.
Massimo

Checked for "turning point" date, in which the observer longitude (longitude of Earth) accomplish the turn (2014 Nov 07/08) I found this:

Its no bad!

_________________
Never at rest.
Massimo

this is starting to look like a custom file will need to be created

At least it is a text file and not binary

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE Leap 15 & CentOS 7.6

Maybe to find a way to collate another one with it...

Note for completeness: the plugin version for the tests is not the last version but the next one. if such a tests are repeated with the version hosted here, the Central Meridian definition and the position angle of axis can shows some differences, because their RA, Dec for the computation have been updated to the IAU 2009 resolution (the SPICE values) and no longer are the old ones.

EDIT LATER:

"SPICE = false" within the config file must remain false, otherwise you will be "deceived".

_________________
Never at rest.
Massimo

Unfortunately, I do not see the results here for the moment....
John, I PM-ed you the code of the scripts/Plugin.

Marco