Celestia Forums

Chris has made available a celestia version 1.3.1-1 at sourceforge. The only change to v1.3.1 is the inclusion of Lua-scripting, which had been omitted on windows (Linux versions should be fine). If you already installed 1.3.1, you can download celestia.exe (the only changed file) here: http://www.h-schmidt.net/celestia/celestia.exe.zip

Celestia now has two scripting languages, the one used by the normal .cel-scripts, which consist of a sequence of commands without control structures, and Lua-scripting (.celx), which is a complete embedded programming language. Even if you aren't interested in writing scripts yourself, you may still want to run some of the new scripts. I made some available at http://www.h-schmidt.net/celestia/. If you are trying all of them anyway, I recommend running the solarsystem-tour as the last one - otherwise run at least the solarsystem tour.

Post any problems you may encounter (but please first make sure you are using the correct version of celestia).

Those of you who are interested in writing scripts will find a summary of the available commands on the page. Lua-scripting supports much of the functionality of .cel-scripts, which combined with real programmability (variables, loops, if-then-else, ...) gives great freedom (at the cost of some complexity). It's still fairly new, so don't expect it to be free of bugs.

Have fun!

Harald

Outstanding...

Gonna give it a try Harald, and THANKS for the information.

Take care, Bob

Harry wrote:Post any problems you may encounter

Hmmm... No response?

I just saw there probably still is a bug I thought to be fixed in 1.3.1, preventing running scripts directly by double-clicking or from a website for many users. So if scripts don't work as expected, try downloading them and open them via the file-menu.

If you had problems with the scripts, could you please try again or post a report of your problem? Thanks!

Harald

Howdy Harald,

Chris only fixed the .cel double-click problem. The .celx problem (for Windows) still exists in the Registry but *only* when the exe path contains a directory greater than 8 characters or a space, such as "C:\Program Files\Celestia". It's in the Bug Tracker.

Regarding your scripts, have you made any changes since I last ran them and reported -- just before 1.3.1 final? I'd be hapopy to run them again if you would like.

Cheers,

-Don G.

don wrote:Regarding your scripts, have you made any changes since I last ran them and reported -- just before 1.3.1 final?

There is a new version of the Solarsystem Tour, with nice planet flybies and other minor improvements.

Harald

Harry wrote:

Harry wrote:Post any problems you may encounter

Hmmm... No response?
So if scripts don't work as expected, try downloading them and open them via the file-menu.
If you had problems with the scripts, could you please try again or post a report of your problem? Thanks! Harald

Hello Harald, many wishes, just to begin.
And regarding your scripts, I downloaded the new Celestia.exe file, opened the solarsystemtour.celx file, and launched it within Celestia.
It works nicely, and this has convinced me to study the LUA language.
Now I'm going to test your other celx files.
Just a little opinion: why so many asteroids in solarsystemtour.celx, and neither comets nor moons?
By soon

Andrea

Anonymous wrote:

Harry wrote:

Harry wrote:Post any problems you may encounter

Hmmm... No response?
So if scripts don't work as expected, try downloading them and open them via the file-menu.
If you had problems with the scripts, could you please try again or post a report of your problem? Thanks! Harald

Hello Harald, many wishes, just to begin.
And regarding your scripts, I downloaded the new Celestia.exe file, opened the solarsystemtour.celx file, and launched it within Celestia.
It works nicely, and this has convinced me to study the LUA language.
Now I'm going to test your other celx files.
Just a little opinion: why so many asteroids in solarsystemtour.celx, and neither comets nor moons? By soon Andrea

Sorry Harald, this post was mine.
Strangely I was not connected automatically, as usually happens.
Sorry

Andrea

Howdy Harald, THE Lua man!

The new version looks real nice and runs fine on Win XP with 1.3.1 final. You did real good Harald.

Lua sure looks a whole lot more complex than .cel scripting, but it sure does give you a lot of control!

Since you *did* ask for comments <grin>, and I *think* you know me by now (I always have opinions <laughing>) ...

* Me thinks maybe too many asteroids, unless you're a big asteroid fan, or those are all of the *biggies* that most folks would know (I don't know any of them).

* The comet fly-bys looked kind of strange with comet tails on (my setting, I think).

* Personal taste ... To me, it takes too long to "get to" and "go away from" each object, and it's not slow enough passing by it. Maybe you could start closer to the objects or use a higher velocity to start with, slow down more when close to it, and when it's out of view, speed up faster?

* With many of the objects, they are "sunlit" when approaching them, but as soon as the camera passes them, they are black, until later on when the sun shines on part of them again. Not sure what would look good here AND allow the object to be "sunlit" during approach and after pass-by?

Cheers,

-Don G.

Andrea wrote:It works nicely, and this has convinced me to study the LUA language.

Great, feel free to ask if you need help.

Andrea wrote:Just a little opinion: why so many asteroids in solarsystemtour.celx, and neither comets nor moons?

Currently the script visits all "children" of the Sun (the list you get when you right-click on sun and select planets [sic]) with radius > 1km, so comets should be included.

It's easy to change this and add moons, but it has some problems then. Try it:
http://www.h-schmidt.net/celestia/solarsystemtour_v1.1m.celx
This one visits everything with a radius of more than 10 km (to avoid all the small moons of Jupiter). You may notice some problems (like flying right through planets when going from one moon to another), and it will take ages just to visit the moons of Jupiter.

Harald

don wrote:* Me thinks maybe too many asteroids, unless you're a big asteroid fan, or those are all of the *biggies* that most folks would know (I don't know any of them).

I agree, this is simply the result of using the bodies known to celestia (see right click on Sun). Technically it's no problem to either use a fixed list, or remove for example all asteroids with radius < xx km. Any suggestions?

don wrote:* The comet fly-bys looked kind of strange with comet tails on (my setting, I think).

I guess the problem occurs because it is going through the comet tail. Maybe it should stay away farther from comets, so it doesn't enter the tail - but how far is far away

don wrote:* Personal taste ... To me, it takes too long to "get to" and "go away from" each object, and it's not slow enough passing by it. Maybe you could start closer to the objects or use a higher velocity to start with, slow down more when close to it, and when it's out of view, speed up faster?

Guess the Apollo-astronauts weren't happy with their travel duration either
Starting closer is no option - it's all one continuous motion (see script at bottom of post).
I am already using extreme acceleration to shorten the travel time. The speed near planets can probably be reduced further, but it is increasingly difficult to get right. I will have a look at it, but don't expect too much.

don wrote:* With many of the objects, they are "sunlit" when approaching them, but as soon as the camera passes them, they are black, until later on when the sun shines on part of them again. Not sure what would look good here AND allow the object to be "sunlit" during approach and after pass-by?

I can't think of a solution for this one (except increasing ambient brightness . The observer often moves from inner parts of the solarsystem to outer parts, and thus from the lit side to the unlit side of bodies.

To avoid this the observer would have to move parallel to the orbit, on the inner side. OTOH we want to take the shortest possible path between two bodies, and these two directions of movement don't go together well.

Actually, sometimes I like looking at the dark side, especially with Galaxy rendering turned on.

BTW, if you want to have a somewhat different view on the way the script works, take a look at this one (I recommend enabling orbits and markers):
http://www.h-schmidt.net/celestia/solarsystemtour_v1.1above.celx
This will position the observer far above the sun. The position where the observer would be in the unmodified version of the script is always kept in the center of the screen (try zooming), and the direction of movement is always up.

Harald[/url]

Howdy Harald,

Harry wrote:I agree, this is simply the result of using the bodies known to celestia (see right click on Sun). Technically it's no problem to either use a fixed list, or remove for example all asteroids with radius < xx km. Any suggestions?

Ahhh, since it's based on the internal Celestia list, then maybe this script should stay the way it is. Or, <very big grin>, since you are working on adding user input from the keyboard, ask the user what they want to see, in a series of Y/N questions (Planets, Spacecraft, Moons, Asteroids, Comets)? Yeah, <sigh>, I know that's probably a ways off yet.

The only other suggestion on this subject would be to create multiple scripts for each or combinations of these items. But, like you wrote, doing Jupiter's moons alone is an hour-long script <grin>!

Harry wrote:[RE: Comets] I guess the problem occurs because it is going through the comet tail. Maybe it should stay away farther from comets, so it doesn't enter the tail - but how far is far away

That is a tough question, since the comet tail graphic is drawn in front of the comet, as well as around and behind it. If you try to stay out of the tail, the comet may not even be visible without tails turned ON.

Harry wrote:

don wrote:* Personal taste ... To me, it takes too long to "get to" and "go away from" each object, and it's not slow enough passing by it.

Guess the Apollo-astronauts weren't happy with their travel duration either

That's why I'm not an astronaut. I wouldn't make a very good astronomer either.

Harry wrote:Starting closer is no option - it's all one continuous motion...

Does it *have* to be all one continuous motion? Or would breaking it up then require different code sections for each object, like in CEL scripting?

Harry wrote:I am already using extreme acceleration to shorten the travel time.

This can't be seen by the user because Celestia does not update the Speed display in either CEL or Lua. Personally, I think it should. Since learning / understanding that the script is one motion, I can now understand how difficult the speed issues must be to program! But, I'm sure I won't *fully* understand it until I code some Lua myself.

Harry wrote:I can't think of a solution for this one (except increasing ambient brightness .

I already have it set to Medium, which is the highest allowed via the UI. Part of it might be my LCD screen too.

Again, this was suggested with a mis-understanding of how the script worked. If the object visits were being controlled individually, then approach, fly-by, and departure speeds / view angles could be easily varied.

Harry wrote:BTW, if you want to have a somewhat different view on the way the script works, take a look at this one (I recommend enabling orbits and markers):

Thanks Harald! The script ran fine and is definately a different viewpoint <smile>.

Using this script, I tried to zoom in (Home key) on an object and discovered that unlike CEL scripts, none of the keyboard or mouse movement controls function while a Lua script is running. Actually, they function, but the display is being redrawn every couple of milliseconds which overrides whatever control you tried to execute. That must take a LOT of CPU cycles! Is this because of the script code, or Celestia code?

Thank you very much for sharing your Lua scripts Harald. I really *do* want to get into some of it, but have been spending a lot of time away from the PC and away from Celestia lately. Been quite sore lately (again) as the last pain med the docs gave me (24-hour morphine capsules) failed after a couple of weeks <sigh>. I'll get back "into the groove" soon <smile>.

Cheers,

-Don G.

don wrote:Ahhh, since it's based on the internal Celestia list, then maybe this script should stay the way it is. Or, <very big grin>, since you are working on adding user input from the keyboard, ask the user what they want to see, in a series of Y/N questions (Planets, Spacecraft, Moons, Asteroids, Comets)? Yeah, <sigh>, I know that's probably a ways off yet.

Of course I could simply remove all asteroids, most wouldn't be missed. Or at least visit comets before asteroids, so the user can stop when he/she had enough.

Regarding user-input: if all goes well it could be in 1.3.2. Or even some prerelease. But it's too early to say.

don wrote:Does it *have* to be all one continuous motion? Or would breaking it up then require different code sections for each object, like in CEL scripting?

No, you could do it differently. But this "one continuous motion" idea was what I had in mind when I started this script.

don wrote:This can't be seen by the user because Celestia does not update the Speed display in either CEL or Lua. Personally, I think it should. Since learning / understanding that the script is one motion, I can now understand how difficult the speed issues must be to program! But, I'm sure I won't *fully* understand it until I code some Lua myself.

While celestia's speed display can't be updated from a script, you can build your own seperate speed-display. Try:
http://www.h-schmidt.net/celestia/solarsystemtour_v1.1speed.celx
(I hope I got the numbers right)

don wrote:Again, this was suggested with a mis-understanding of how the script worked. If the object visits were being controlled individually, then approach, fly-by, and departure speeds / view angles could be easily varied.

Now this would be a great idea for another script, which could focus much more on the objects, maybe adding text and explanations.

don wrote:Using this script, I tried to zoom in (Home key) on an object and discovered that unlike CEL scripts, none of the keyboard or mouse movement controls function while a Lua script is running. Actually, they function, but the display is being redrawn every couple of milliseconds which overrides whatever control you tried to execute. That must take a LOT of CPU cycles! Is this because of the script code, or Celestia code?

Script execution and rendering works somewhat like this (of course much simplified):
Do the following in a loop:
1. Execute the script: this will set position and orientation to whatever the script wants (the script will run until it executes a "wait" command)
2. Update the simulation: rotate observer according to keypresses, move observer if speed != 0, update position if a goto-command is executed, set orientation to match any "Track"-command currently active, etc.
3. Render the frame with whatever the current position and orientation of the observer are now, and with planet-positions according to current time.

1 and 2 don't need much CPU, 3 does. What you see when you press any key during script-execution is phase 2 changing slightly the values set in phase 1, because the script has no chance to set the values again before rendering. I hope to change this so that scripts are executed just before rendering, so then it would have perfect control. The script could use the values set by phase 2 and accept any changes by the user.

As long as you aren't doing some complicated computations or forget to call wait, the execution of the Lua-code in phase 1 won't need much CPU, not compared to rendering.

don wrote:Thank you very much for sharing your Lua scripts Harald. I really *do* want to get into some of it, but have been spending a lot of time away from the PC and away from Celestia lately. Been quite sore lately (again) as the last pain med the docs gave me (24-hour morphine capsules) failed after a couple of weeks <sigh>. I'll get back "into the groove" soon <smile>.

I hope you will be better soon!

Harald

Harry wrote:Script execution and rendering works somewhat like this (of course much simplified):
Do the following in a loop:
1. Execute the script: this will set position and orientation to whatever the script wants (the script will run until it executes a "wait" command)
2. Update the simulation: rotate observer according to keypresses, move observer if speed != 0, update position if a goto-command is executed, set orientation to match any "Track"-command currently active, etc.
3. Render the frame with whatever the current position and orientation of the observer are now, and with planet-positions according to current time.
1 and 2 don't need much CPU, 3 does. What you see when you press any key during script-execution is phase 2 changing slightly the values set in phase 1, because the script has no chance to set the values again before rendering. I hope to change this so that scripts are executed just before rendering, so then it would have perfect control. The script could use the values set by phase 2 and accept any changes by the user.
As long as you aren't doing some complicated computations or forget to call wait, the execution of the Lua-code in phase 1 won't need much CPU, not compared to rendering.
Harald

Harald, I've a terrible doubt that I would like to be clarified.
This one: does LUA scripts give the same possibilities of .cel scripts PLUS the ones we have seen in your examples (that up to now are anyhow limited to a different way of approaching objects and to choose them, if I don't miss something ), even at the price of more programming, or it's another kind of approach/rendering?
I mean, does LUA allow preparing a show like the Bob Hegwood's MarsTour, without missing any of the "effects" actually available, but adding the LUA effects?
This is very important for me because, though if I'm not a programmer, I'm ready to study and use LUA language, but only if this is MORE valuable for my needs than .cel scripting.
Hope to have been clear, sorry for my bad English.
By and thank you.

Andrea

Maybe I should describe the differences between the two scripting languages:
Lua is a real programming language, you can remember values, you can repeat tasks, have decisions etc., while in .cel-scripting you have a list of commands which will be executed one after the other.
Both languages offer acces to many features in celestia, like printing text on screen, selecting planets or stars, activating follow or chase mode and many more. Because Lua-scripting still is relatively new, it does not yet support all features you find in .cel-scripting: it's lacking a command to preload textures, you can't set the ambient level or FOV, and most importantly it doesn't support all types of goto-commands available in .cel-scripting like gotolonglat. But all of this is easy to change, and it will change.

Eventually Lua-scripting will support all (or at least all useful) features available in .cel-scripting.

I think it's important to understand what a goto-command actually does (I hope I can explain this in an understandable way):
If you activate goto, celestia will remember your current position, the time the goto started, and your orientation (i.e. where you are looking at). Depending on the type of the goto-command it will then compute a time it should be finished, the orientation you should have and the position you should be at when it is finished.
From now on until the time it is finished celestia will after each rendering of the screen (i.e. planets, stars, orbits, ...) calculate a new position and orientation based on the values it remembered when you started the goto-command.
(Still with me? )
It will then use this updated position and orientation to render the next frame.

Lua-scripting has direct access to the position and orientation. So in principle it could simulate this behaviour (AFAIK right now it's only lacking a small detail to really do it, which is a way to examine your current orientation). The only difference would be that not celestia would remember the values and calculate the current position and orientation, but the script would do it - the user wouldn't notice any difference. Of course a script doing that would be pretty complex, so it still makes sense to have access to the goto-command in Lua, and let celestia do the work

Anyway, Lua-scripting isn't limited anymore to the movements you can do with those predefined goto-commands - if you know how to describe a movement in Lua (which requires some math), you can do it. Want to move along a line? Easy. Move in a circle? Easy. Don't move at all? Ok, really easy. Move along a way which will pass all planets in one smooth motion? Not easy, but possible.

Now I don't know if this answered your question (uh, what was your question again? ), but I hope it clarified the situation.

Harald

Howdy Harald,

Harry wrote:Of course I could simply remove all asteroids, most wouldn't be missed. Or at least visit comets before asteroids, so the user can stop when he/she had enough.

Or, have two versions: one with, and one without asteroids? Or, just include the ones that have been "in the news" recently, like with NASA's successful (to date) Stardust mission? Lots of choices!

Harry wrote:Regarding user-input: if all goes well it could be in 1.3.2. Or even some prerelease. But it's too early to say.

COOL!

Harry wrote:But this "one continuous motion" idea was what I had in mind when I started this script.

And it looks like it made you "dig deep" into your programming experience and into Lua and Celestia too.

Harry wrote:While celestia's speed display can't be updated from a script, you can build your own seperate speed-display. Try:
http://www.h-schmidt.net/celestia/solarsystemtour_v1.1speed.celx

Like I wrote earlier, YOU are THE Lua man!

Today, I was thinking (day dreaming) about how this could be done in Lua, and here you have already done it! Thanks Harald. Now to get Celestia to do it for us internally.

Harry wrote:... a great idea for another script, which could focus much more on the objects, maybe adding text and explanations.

Which is what I began doing in version 1.3 of my mods to your script. This one is a good place for me to start learning Lua.

Harry wrote:Script execution and rendering works somewhat like this (of course much simplified):

Thank you for the overview Harald. I was not sure in what order things happened.

Harry wrote:I hope you will be better soon!

Thanks Harald. I have learned to sometimes "overpower" the pain by simply focusing my mental attention on something, like a script , but now it's 10 times more exhausting than in my younger days when I could code 700-800 lines of debugged COBOL code in "a day's work" and then go out dancing that night. Life goes on!

Harald, I really appreciate the effort you have put forth on modifying Celestia's source code, as it relates to Lua scripting; providing some excellent example scripts; and for your Lua Summary. Your work has encouraged me to move forward and learn more (though I *did* want to get back into C++ too). Thank you Harald!

Cheers,

-Don G.

Guest wrote:Harald, I've a terrible doubt that I would like to be clarified.

Sorry Harald, the "Guest" with the terrible doubt was me.

Harry wrote:Maybe I should describe the differences between the two scripting languages: Lua is a real programming language, you can remember values, you can repeat tasks, have decisions etc., while in .cel-scripting you have a list of commands which will be executed one after the other. Eventually Lua-scripting will support all (or at least all useful) features available in .cel-scripting.

These are good news, because now I can imagine a bit more the possibilities of LUA scripting in the preparation of astronomy tours with many more "features" than with .cel files

Harry wrote:Anyway, Lua-scripting isn't limited anymore to the movements you can do with those predefined goto-commands - if you know how to describe a movement in Lua (which requires some math), you can do it. Want to move along a line? Easy. Move in a circle? Easy. Don't move at all? Ok, really easy. Move along a way which will pass all planets in one smooth motion? Not easy, but possible.

And this brings to the "terrible" side of the project: we have to study LUA Language. Well, you convinced me that it's worthwhile, so... I'll do it.

Harry wrote:Now I don't know if this answered your question (uh, what was your question again? ), but I hope it clarified the situation. Harald

Surely, Harry, you gave us a long and detailed asnswer. So we'll have to wait for further improvements of LUA in the next future and in the next Celestia releases.
By soon and thanks a lot for your big effort to help us understand LUA capabilities and potentialities.

Andrea

don wrote:Or, have two versions: one with, and one without asteroids? Or, just include the ones that have been "in the news" recently, like with NASA's successful (to date) Stardust mission? Lots of choices!

Hmmm.... Now I just had an idea (and that's your fault )

I think you will like this one:
http://www.h-schmidt.net/celestia/solarsystemtour_v1.1ask.celx

(ok, it's an ugly hack. Quick and dirty. Whatever, it shows the possibilities).

don wrote:Today, I was thinking (day dreaming) about how this could be done in Lua, and here you have already done it! Thanks Harald. Now to get Celestia to do it for us internally.

Celestia's speed display always shows the observer-speed (spacecraft-mode, or whatever you want to call it). So if you wanted to show the speed there, you would have to actually set the speed - but Lua-scripts can't do that. At least not yet (the order in which scripts are executed and observers are updated may cause problems too).

don wrote:This one is a good place for me to start learning Lua.

Oh I never expected anybody to use THAT script to learn Lua

Bye,

Harald

THE Lua man wrote:Hmmm.... Now I just had an idea (and that's your fault )

Harald! You are one VERY RESOURCEFUL fellow!!! I LOVE IT! It actually works quite well too. You are amazing Harald.

THE Lua man wrote:[Speed display] So if you wanted to show the speed there, you would have to actually set the speed - but Lua-scripts can't do that.

Yes, I understand this would be a modification. The user should not be roaming the universe while running a script anyway, as it messes things up pretty bad.

THE Lua man wrote:Oh I never expected anybody to use THAT script to learn Lua

Why not? It has already taught me how to define a long comment block.

Cheers,

-Don G.

don wrote:Harald! You are one VERY RESOURCEFUL fellow!!! I LOVE IT! It actually works quite well too. You are amazing Harald.

Whoohoo, thanks!

I guess I just had a good head start

don wrote:

THE Lua man wrote:So if you wanted to show the speed there, you would have to actually set the speed - but Lua-scripts can't do that.

Yes, I understand this would be a modification. The user should not be roaming the universe while running a script anyway, as it messes things up pretty bad.

Of course it all depends on who has the last word in this - the script (what I had called phase 1) or the celestia-code updating the observer-position (aka phase 2). Right now if you set a high speed, the position the script sets and which would look "right" is changed again by celestia, making the movement a mess. I probably will change this order, so whatever the script says goes. Then you could even (mis-)use the speed-setting to display the current speed without any problems (assuming a method to set it, but that is a trivial change), at least not as long as the script is still running

don wrote:

THE Lua man wrote:Oh I never expected anybody to use THAT script to learn Lua

Why not? It has already taught me how to define a long comment block.

I just think the scripts like that around-the-earth stuff are somewhat easier to understand.