Lua scripting

[Harry]

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

[Bob Hegwood]

Outstanding...

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

Take care, Bob

[Harry]

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

[don]

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.

[Harry]

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

[Guest]

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

[ANDREA]

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

[don]

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.

[Harry]

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

Great, feel free to ask if you need help.

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

[Harry]

* 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?

* 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

* 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.

* 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]

[don]

Howdy Harald,

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>!

[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.

* 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.

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?

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.

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.

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.

[Harry]

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.

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.

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)

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.

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.

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

[Guest]

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

[Harry]

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

[don]

Howdy Harald,

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!

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!

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.

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.

... 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.

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.

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.

[ANDREA]

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

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

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

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.

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

[Harry]

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).

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).

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

[don]

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.

[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.

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.

[Harry]

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

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

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.