Celestia Forums

Don and others (Chris himself may be!)

Don, I appreciated a lot your version of Sun vs Planets script , initially written by Christoria.
However,my point relates to some technical aspect. I began, some time ago to write a .cel script
on the Galileo trip (also triggered by the recent accurate xyz trajectories provided by )
For this purpose I "prepared" each starting step from a adequate spot that I created in favorite.cel.
as an example:
"Galileo_launch 10 89" {
isFolder false
parentFolder "Galileo"
base [ 0.003275837369038961 4.223817707317069e-009 -6.857289016768809e-006 ]
offset [ -1.371903892571913e-013 -2.710505431213761e-019 -2.879098869035257e-016 ]
axis [ 0.612721 -0.596664 -0.518232 ]
angle 1.0249
time 2447818.616593328
selection "#0/Galileo"
coordsys "ecliptical"
}
This allows to get and galileo on the same screen. Then I copy and paste the hence found position and orientation in the .cel as :
(partial script)
{
cancel {}
time {jd 2447818.616593328}
wait { duration 1.00 }
timerate { rate 0 }
select { object "#0/Galileo" }
setframe { ref "#0/Galileo" target "#0/Galileo" coordsys "universal"}

setposition {
base [ 0.003275837369038961 4.223817707317069e-009 -6.857289016768809e-006 ]
offset [ -1.371903892571913e-013 -2.710505431213761e-019 -2.879098869035257e-016 ]
}
setorientation { angle 1.0249
axis [ 0.612721 -0.596664 -0.518232 ]
}
print { text "lancement Galileo le le 19 octobre 1989 ?.2H 47 min . .\nPress ESC to end." row -5 column 2 duration 5 }


wait { duration 40.00 }
}

Surprisingly (for me) the position and orintation is not well reproduced despite of the same data. The orientation is wrong and the position is off by several hundreds of Km (no problem for planets, but inacceptable for Galileo. I was almost giving uu this approach when I read your thread.
Looking at the large number of digits found in your setposition and setorientation, , l guessed that you use a similar approach, this is the reason of my call.

I tried to modify the setframe { and the coordsys posibut without any effect. Position and orientation stay inchanged.
Before entering more deeply in the code, I look for any help, may be I made a big mistake.
Thanks in advance.
MB

Howdy MB,

As you can see in my script, I too had a problem with orientation, which required me to rotate the sun. I am not sure why the methods of using data from the favorites.cel file -or- a Cell://URL are not accurate in .cel scripting. It would take some serious mucking around in the source code to figure out, when Chris and maybe even Christophe probably know right off the top of their heads <smile>.

Thinking of a different way to accomplish your goal, have you considered starting your voyage close to Earth, where you have better control of the position and orientation values? Then, once the appropriate Coordinate System is set (follow, etc.) you could speed up time to each of the "stopping points" on your voyage, slow it back down, look around, and then continue. Just an idea, but not sure how well it would work.

-OR-

Using the values from the xyz file, and then "tweaking" them to back off a short distance?

-Don G.

Don
I did not notice that you got similar problem. Back to this, I am still VERY surprised. Considering (i) the number of digits involved here (ii) the position given approximately (but too roughly) that suggested to me that the very same data are used both in favorite .cel and in the .cel scripts (incidently why to use the same .cel extension for two different scripts). It is hard to suspect a bug or what?
It is a pity, it would be so easy to write nice script.
I expected some reaction of the developpers.
Christophe primarily use Linux, I use either linux or Windows (both in CVS with the kind help of Christophe!). Unfortunately in the Linux celestia the Favorites are written in xml language not readable, at least for me. Therefore I cannot extract the position and orientation.
Incidently I consider as a drawback that the favorite is not written in the same language in both platforms.
So I have to dive in the code. In my job as a scientist, I had the oportunity to write C++ code (Borland 4.5 with Windows and Qt with Linux and OpenGL in both platforms) but as an amateur. This as nothing to do with the extremely professional but very heavy code of celestia!

Considering your suggestions, the Pb is not the proximity of Earth that is OK, but that of Galileo. Otherwise I already wrote a complete voyage with acceleration and so on, but a "random" position of Voyager.
MB

Howdy MB,

Don't lose heart. Changes happen to Celestia every day.

MB wrote:Considering (i) the number of digits involved here (ii) the position given approximately (but too roughly) that suggested to me that the very same data are used both in favorite .cel and in the .cel scripts ...

That is what seemed to make sense to me also, but it would seem that Celestia does other things internally when re-creating a saved favorite or Cell://URL that are not available to us in scripting -- yet.

A short while ago, there was a topic on this subject alone, and Chris offered to provide a means for a script to use a Cell://URL. So, this is probably on a to-do list for us to look forward to.

We need to remember that .cel scripting was added only 2 releases ago, and shortly after that, Chris found Lua, which offers a much richer language, and sort of stopped doing anything with .cel scripting. It would be really nice to have a developer come on-board who loves writing scripting interface code as much as Chris loves writing graphics code!

MB wrote:... (incidently why to use the same .cel extension for two different scripts).

If you are talking about using .cel for files that should probably have a .txt or some other extension (ie. favorites.cel, guide.cel) I think that was probably done so these files would be associated with Celestia in the respective OS file systems. Yes, it is confusing.

MB wrote:I expected some reaction of the developpers.

Well, Chris just returned from an out-of-the-country, 2-1/2 week holiday / vacation, so it's probably going to take him a little while to get caught up at home and at work, let alone on the Celestia forums. And, Chris is the main "core" developer along with being the Windows UI developer.

As for the other developers, maybe one or more of them will have a peek at the code IF it interests them, to see if they would be able to do anything, BEFORE even saying anything here.

MB wrote:Unfortunately in the Linux celestia the Favorites are written in xml language not readable, at least for me.

Anyway, I would expect to see the same values being stored as in the Windows version, since there is probably only one Celestia code section that de-codes them.

MB wrote:Incidently I consider as a drawback that the favorite is not written in the same language in both platforms.

The reason for this may be that the Windows version is a bit behind in this aspect. For example, the Linux version offers 3 or 4 different ways to capture a Cell://URL, where Windows offers only one. These differences arise when a UI developer takes a step ahead, usually with Chris saying okay, and then Chris has to "catch up" to the new code in the Windows version. In the particular case of the favorites file, I think the direction is towards XML. Christophe would be more qualified to describe why.

MB wrote:This as nothing to do with the extremely professional but very heavy code of celestia!

HEAVY indeed!

Are the values in the XYZ file not usable in a script? I've not tried this myself, so I don't know.

Hang in there MB, scripting is becomming easier and more robust with every new release.

-Don G.

There is something people apparently don't realise about the KDE favorites: they don't exit!

See on the one hand we have cel:// urls and on the other we have a nice platform provided bookmark manager, and there you go: the linux version doesn't make use of the favorite code because there is no need to. All that was needed was to plug the bookmark manager in.

The XML bookmark file uses the standard XBEL DTD to store cel:// urls.

Ohhhh, you're a sneaky one Christophe!

What a TREAT, to have *usable* source code and a mini-app come with your OS, that can simply be plugged into your own apps! Wow!

-Don G.

Thanks Don,
you comfort me! and let's wait..
Concerning the xyz files, I did not ask the question to myself, I use it and it seems to work if you select the right object with the corresponding xyz reference included in the .scc file.
Christophe,
you perfectly understood what I meant! It is exactly my (small) problem that favorites do not exist in the linux version, I thought it would have been a way, looking at the celestia linux bookmark to elucidate the problem. Thanks for the XBEL link, but I am not at all familiar with this language, I just wanted to read in "clear" and I did not find the adequate tool.
MB

I've done some reading of the favorites code yesterday and things are now clearer.

The favorite and setposition functions use 6 doubles to represent the 3 internal BigFix coordinates (16 bytes). The url code simply Base64 encodes them. It should be relatively easy to use the Base64 encoded strings in place of the 6 doubles in the script code.

I've already added a gotourl function (which should be in fact setpositionurl since it doesn't travel to the url position but sets you there). I can also add a gotolocationbase64 for example, is there a need for that?

Christophe,
Thank you for your effort. I need to think more before answering since I am a bit lost reading your answer (I never use the gotourl function for example).
MB

Howdy Christophe,

Christophe wrote:The favorite and setposition functions use 6 doubles to represent the 3 internal BigFix coordinates (16 bytes). The url code simply Base64 encodes them. It should be relatively easy to use the Base64 encoded strings in place of the 6 doubles in the script code.

Hmmm.

setposition wants 2 sets of 3 numbers -- base [ x y z ] and offset [ x y z ]. How would we split the 3 Base64 values into 6 x y z values?

Christophe wrote:I've already added a gotourl function (which should be in fact setpositionurl since it doesn't travel to the url position but sets you there).

Thank you Christophe! Yes, I think the name should be changed before submitted so it is not confused with the action of goto commands.

I've not had time to look at your new code, update my CVS, add it, and test it, but I will try my best today! My wife picked up a used PC yesterday that I needed to clean up and test.

I'm not sure about having a gotourl function, as the date/time could change between the two, making the display look very strange while slowly moving between the two cel://URLs, no?

Christophe wrote:I can also add a gotolocationbase64 for example, is there a need for that?

That would be a setpositionbase64, versus a "goto", right? I'm not sure if this would help or confuse, since nothing but position would be set -- ie. no orientation, date/time, etc. Hmmmm, not sure.

-Don G.

MB wrote:Thank you for your effort. I need to think more before answering since I am a bit lost reading your answer (I never use the gotourl function for example).

That's because I haven't commited it yet! But it's coming soon.

don wrote:setposition wants 2 sets of 3 numbers -- base [ x y z ] and offset [ x y z ]. How would we split the 3 Base64 values into 6 x y z values?

Doubles are 4 bytes, so 2 doubles is 8 bytes = 1 BigFix.
Base codes the highier 4 bytes, offset the lower 4.

don wrote:I'm not sure about having a gotourl function, as the date/time could change between the two, making the display look very strange while slowly moving between the two cel://URLs, no?

Yes, that's not doable.

don wrote:That would be a setpositionbase64, versus a "goto", right? I'm not sure if this would help or confuse, since nothing but position would be set -- ie. no orientation, date/time, etc. Hmmmm, not sure.

Ok, so let's say a setpositionbase64 and a gotolocationbase64?

Christophe wrote:

don wrote:setposition wants 2 sets of 3 numbers -- base [ x y z ] and offset [ x y z ]. How would we split the 3 Base64 values into 6 x y z values?

Doubles are 4 bytes, so 2 doubles is 8 bytes = 1 BigFix.
Base codes the highier 4 bytes, offset the lower 4.

My question was based on your writing, "It should be relatively easy to use the Base64 encoded strings in place of the 6 doubles in the script code." What I was asking is, how is it possible to use 3 "strings" when 6 "numbers" are required in the *current* setposition command. Obviously, source code changes are required (setpositionbase64) <smile>.

Christophe wrote:Ok, so let's say a setpositionbase64 and a gotolocationbase64?

Well, hold on for just a minute <smile>. Gotta put my thinking cap on here ...

You've already coded this wonderful new seturl command which is based on a complete Cell://URL. Which means this command already has all of the text available in the Cell://URL. Which means all we really need is some way to tell this command exactly what we want to do with the information in the Cell://URL we just gave it -- right?

The first thing I would do is change the command name to usecellurl, then add the following parameters to it:

type is one of the following:
* set
* goto
* seturl (uses all Cell://URL values-ignores using)

using is one or more of the following:
* position
* orientation

Would all of the following items be set automatically, or should the scripter decide which ones get set?
* FOV (Field of View)
* timescale
* LTD (Light Time Delay)
* renderflags
* labelmode

Example...

That seems nice, but that'd be a lot more difficult to do than having separate functions using the strings extracted from the cel url.

Actually we can overload cel functions :

Howdy Christophe,

Overloading (passing different parameters) sounds okay to me, but why bother picking out and sending individual parameters? Why not make it easy and just pass each command the entire Cell://URL?

-Don G.

Back to the web at home after the Paris trafic jam, Therefore this has nothing to do with your points that I will read after that. So another point:
Although reading the code is not easy to read, I found that in the "favorite", the "setorientation" angle is expressed in radians while it is expressed in degrees in the *.cel scripts. Therefore you just multiply by 180/p = 57,2957795 the value shown in "favorite" and you put this value in the .cel script, I checked several cases, it seems OK, that can be useful for preparing the view point in script. One point solved, simple apparently.
Remains the problem of the "setposition", although the data extracted from the "favorite" are approximately correct and can be transferred in most cases in the .cel scripts , they are not accurate enough for me due probably to the close position of the spacecraft. After the points raised by Christophe, I suspect that the accurate BigFix position data are "downcasted" in "double". If I am right, (question to the developpers) I am affraid that nothing can be done without changing the code.
MB

Howdy MB,

Christophe is currently working on code modifications that will allow the direct use of Cell://URL values in scripting. That's what our prior messages are discussing. So, hopefully, if all works out well, we won't need to be picking out and/or converting values from saved Cell://URLs <big smile>!

-Don G.

You can find a patch against the latest CVS here.

As discussed previously it adds a cel script function and overloads four existing functions.

Christophe,
Just one word to thank your effort I apologize to do that so lately,
I compiled apparently your code successfully after some efforts since I don't know to use patches! ( I always update with the sourceforge CVS) But I could do that manually.
The first results are encouraging, I will tell you later, I have still various things to check.
Thanks again
MB

Howdy Christophe,

Thank you for these GREAT additions!!!

I've tested them with the current CVS and Windows XP and all the commands seem to work perfectly.

Thank you!

-Don G.