Celestia Forums

Are .CEL scripts deprecated? Does anyone still write them? Does Celestia still need them?

- Hank

hank wrote:Are .CEL scripts deprecated? Does anyone still write them? Does Celestia still need them?

- Hank

All I know is that you have to be a rocket-scientist to write CELX scripts, but
any old Brain-Dead fool can write a nice CEL script. What's this functionality
worth? I still write CEL scripts cause I can.

I'm examining CELX, but even with the best manuals and a great little
demonstrator (Thanks again, Clive!) I'm still unable to do what I wish
to do outside of a CEL script.

Thanks.

BrainDead wrote:

hank wrote:Are .CEL scripts deprecated? Does anyone still write them? Does Celestia still need them?

- Hank

All I know is that you have to be a rocket-scientist to write CELX scripts, but
any old Brain-Dead fool can write a nice CEL script. What's this functionality
worth? I still write CEL scripts cause I can. :wink:

I'm examining CELX, but even with the best manuals and a great little
demonstrator (Thanks again, Clive!) I'm still unable to do what I wish
to do outside of a CEL script. :roll:

Thanks.

Bob,

Thanks for responding. I'm asking because I think it might be fairly easy to convert .CEL scripts into .CELX scripts. You'd have to make these changes:

1. Start comments with -- instead of #.
2. Put a = after each command parameter keyword.
3. Separate command parameter keyword/value pairs with commas.
4. Enclose vectors in { } instead of [ ].
5. Separate vector components with commas.

So instead of:


you would have to write:

Does that seem feasible?

- Hank

hank wrote:Bob,

Thanks for responding. I'm asking because I think it might be fairly easy to convert .CEL scripts into .CELX scripts. You'd have to make these changes:

Does that seem feasible?

- Hank

Certainly this seems feasible, but why bother? Are you anticipating that
CEL will no longer be supported in FT1+? So far, I haven't noticed that any
scripts no longer work.

This topic really does confuse me too. I guess I need to be shown why
a CELX script is better than a CEL script. Is this because the OOP
concept allows you to manipulate parts of a spacecraft or something?

Let me ask another way... If all I wish to do is tour the known universe,
why do I need CELX?

Thanks.

BrainDead wrote:Certainly this seems feasible, but why bother? ... I guess I need to be shown why a CELX script is better than a CEL script.

Bob,

As in my example, you'd be able to continue to write .CEL-style scripts pretty much as you did before, with the minor syntax changes I indicated. But you'd also be able to make full use of the power of Lua programming. You'd have expressions, variables, conditionals, loops, functions, etc. It would also make it easier for developers to implement new .CEL-style commands to provide you with access to new Celestia features.

- Hank

BrainDead wrote:I guess I need to be shown why a CELX script is better than a CEL script.

Just to offer a small example of what I think Lua might give you...

Using .CEL scripting, you can do something like this:

Using Lua you could do something very similar:

But with Lua you could also use variables:

...and functions:

... which can be used repeatedly:

... and you'd also be able to use arrays and loops:

... and more:

...which might be hard to do with .CEL scripting. (Just in case you didn't follow, this last example flys over the cities in random order.)

- Hank

hank wrote:Just to offer a small example of what I think Lua might give you...

Now this topic is turning out to be perfect for a scripting noob like me.

Is there a list of celx/lua commands/keywords anywhere? Doesn't seem too tricky if you know a little about programming...

Harald has a summary of Celestia's Lua functions at
http://www.h-schmidt.net/celestia/

If you haven't already, you probably should take a look at the Lua manual:

http://www.lua.org/manual/5.0/

Okay Hank...

First of all THANKS for the examples you posted above. Now I
think I understand what the advantages might be with CELX.

If I understand what you've shown me thus far, I can define a single
function one time (In your example "flyover"), and then call it repeatedly
from anywhere in the CELX script after defining the parameters it uses.

Again, in your example I would define different values for LAT, LON and
any other related parameters which I had already incorporated into
the "flyover" function.

Am I understanding you correctly here?

If so, then I have one other simple question. Where can you define these
functions? In other words, I think I've been confused because functions
can be defined anywhere in the script. Is this true?

For an old, step-by-step programmer like myself, is it possible to place
all of your function definitions in one place, say at the end or beginning
of the completed script? This would be useful. I think that what
bothers me about CELX is that I don't know where to look to find the
function definitions. Am I on the right track here?

Sorry for the questions, but I reall am interested in learning why CELX
is so hard for me, personally. I'm not adverse to change, but I simply
haven't been able to understand the structure of CELX yet.

Thanks again.

BrainDead wrote:Okay Hank...... but I simply haven't been able to understand the structure of CELX yet. .

I absolutely agree with Bob.
I tried to understand the CELX "philosophy", but haven't been able to dive sufficiently deep to make me love .celx as I love .cel scripting way.
I tried to use Harald's reference text but it, though very complete (thank you Harald!), gives me the doubt to be written for programmers, not for poor men like me, trying to understand something out of our world, as object programming is.
Just for an example, I missed somewhere the little tricks needed to transform a .cel script in .celx (the -- and = additions), and probably there are many other features that are equally easy to use to modify .cel scripts, but lost in the quantity of objects, operators and callbacks given in the manual.
Is there something about differencies-similitudes between CEL and CELX?
And benefits-drawbacks?
So, please, someone (Hank?) could try to write a "CELX Manual for Dummies", taking us by hand, step by step, with plenty of practical examples, possibly?
Could it be possible to add urls showing the CELX script effects?
This probably could give the possibility of the quality step that I (and probably someone else) need to start writing in CELX.
Thank you very much.

Andrea

ANDREA wrote:So, please, someone (Hank?) could try to write a "CELX Manual for Dummies", taking us by hand, step by step, with plenty of practical examples, possibly?
Could it be possible to add urls showing the CELX script effects?
This probably could give the possibility of the quality step that I (and probably someone else) need to start writing in CELX.
Thank you very much.

Andrea

Hmmm. That would be quite a challenge. I think any such manual would have to also be a programming tutorial, because that is the main difference between CELX and CEL.

CEL is a scripting tool. It lets you write a step of instructions to be followed the same way every time - like a cooking recipe. It never varies and always produces the same results:
- go to Jupiter
- circle around it twice
- go to Earth

CELX is a programming tool. It is capable of doing things with the instructions that CEL can't:
- decisions: IF Jupiter closer to the viewer than Saturn then choose Jupiter, otherwise choose Saturn
- use variables: go to the chosen planet
- calculate: set x to the chosen planet's radius divided by Earth's radius
- create re-usable routines: a set of instructions to circle a planet
- loop: call the circle planet routine x times
- and still do what CEL can do: go to Earth

A lot of those points are demonstrated by the excellent examples given by hank above.

The main point though, is that any such undertaking would be a programming tutorial, not just a manual. That's not an easy undertaking for the creator and for the student. The student must first understand that they will have to cover a LOT of ground before they gain enough knowledge to do anything useful.

But the more I think about it... the more I like it. If you don't mind, perhaps I will start working on a set of "lessons" to take one from CEL to CELX. Whaddya all think?

In the meantime, the Celx Visual Guide (available on the Motherlode) is by no means a tutorial. But it does have examples for every call that may shed some light on things.

And for those of you looking at how deep the CELX pool is and wondering if you'll drown in it: persevere! Once you find out what you can do, your head will start exploding with all the ideas of what you want to do.

BrainDead wrote:Okay Hank...

First of all THANKS for the examples you posted above. Now I
think I understand what the advantages might be with CELX.

...

Sorry for the questions, but I reall am interested in learning why CELX
is so hard for me, personally. I'm not adverse to change, but I simply
haven't been able to understand the structure of CELX yet. :oops:

Thanks again.

ANDREA wrote:Just for an example, I missed somewhere the little tricks needed to transform a .cel script in .celx (the -- and = additions), and probably there are many other features that are equally easy to use to modify .cel scripts, but lost in the quantity of objects, operators and callbacks given in the manual. 8O

Let me clarify that the hypothetical examples I gave above don't really use the CELX scripting facilities as such. Rather, they use the Lua programming language with CEL-style commands. These examples won't actually work until the CEL-style commands are implemented. Sorry if that wasn't clear.

CELX is a powerful tool that provides very flexible, object-oriented access to Celestia. It's complex partly because of the complexity of Celestia at the level it addresses (reference frames, etc.), partly because of the flexibility it provides, and partly because of its object-oriented programming style. What I'm suggesting above is that with a slight syntax change to CEL-style commands it might be possible to make the basic features of Lua programming available for use with the simpler CEL-style approach.

The CEL-style commands would be implemented using CELX internally, but you wouldn't need to know that to use them. Another advantage of this approach is that it would be easier to add additional CEL-style commands (as Lua functions) without rebuilding the application.

So again, just to be clear, what I've described above would be a way to script Celestia using Lua with simpler CEL-style commands rather than CELX. Of course, CELX as such would still be available to power users.

- Hank

Other thing is that no more new .cel and .celx scripts for months...The Deep Space Tour script needs an update.I can only put 20 objects in it,no more...

hank wrote:

BrainDead wrote:Okay Hank...

First of all THANKS for the examples you posted above. Now I
think I understand what the advantages might be with CELX.

...

Sorry for the questions, but I reall am interested in learning why CELX
is so hard for me, personally. I'm not adverse to change, but I simply
haven't been able to understand the structure of CELX yet.

Thanks again.

ANDREA wrote:Just for an example, I missed somewhere the little tricks needed to transform a .cel script in .celx (the -- and = additions), and probably there are many other features that are equally easy to use to modify .cel scripts, but lost in the quantity of objects, operators and callbacks given in the manual.

Let me clarify that the hypothetical examples I gave above don't really use the CELX scripting facilities as such. Rather, they use the Lua programming language with CEL-style commands. These examples won't actually work until the CEL-style commands are implemented. Sorry if that wasn't clear.

CELX is a powerful tool that provides very flexible, object-oriented access to Celestia. It's complex partly because of the complexity of Celestia at the level it addresses (reference frames, etc.), partly because of the flexibility it provides, and partly because of its object-oriented programming style. What I'm suggesting above is that with a slight syntax change to CEL-style commands it might be possible to make the basic features of Lua programming available for use with the simpler CEL-style approach.

The CEL-style commands would be implemented using CELX internally, but you wouldn't need to know that to use them. Another advantage of this approach is that it would be easier to add additional CEL-style commands (as Lua functions) without rebuilding the application.

So again, just to be clear, what I've described above would be a way to script Celestia using Lua with simpler CEL-style commands rather than CELX. Of course, CELX as such would still be available to power users.

- Hank

BrainDead wrote:For an old, step-by-step programmer like myself, is it possible to place all of your function definitions in one place, say at the end or beginning of the completed script? This would be useful. I think that what bothers me about CELX is that I don't know where to look to find the function definitions. Am I on the right track here?

Lua allows you to define functions pretty much anywhere. You can put them at the beginning of the script if you prefer. You can also define a group of functions in a separate file and then use them in different scripts after loading the file. Usually the functions loaded from a file are provided as a library which you reference with a prefix that indicates which library they are defined in. For example, the trig sin function is referenced as math.sin because it's in the math library. That's a standard library which is usually built in, but you can define your own libraries similarly.

- Hank

A simple way to experiment with Lua in Celestia is the use the CELX flash function, which briefly displays a message on the screen. For example, here's a very simple CELX script:

Here's a little more complicated one:

(From now on we'll just assume our flash function has been defined.)

We can check the time:

Or Cassini's current distance from Saturn:

Not so hard, really. Try it yourself!

- Hank

cpotting wrote:CEL is a scripting tool. It lets you write a step of instructions to be followed the same way every time - like a cooking recipe. It never varies and always produces the same results:
- go to Jupiter
- circle around it twice
- go to Earth

CELX is a programming tool. It is capable of doing things with the instructions that CEL can't:
- decisions: IF Jupiter closer to the viewer than Saturn then choose Jupiter, otherwise choose Saturn
- use variables: go to the chosen planet
- calculate: set x to the chosen planet's radius divided by Earth's radius
- create re-usable routines: a set of instructions to circle a planet
- loop: call the circle planet routine x times
- and still do what CEL can do: go to Earth

Thanks very much for that explanation, Clive. I really am
trying to grasp the CELX/LUA concepts here.

cpotting wrote:The main point though, is that any such undertaking would be a programming tutorial, not just a manual. That's not an easy undertaking for the creator and for the student. The student must first understand that they will have to cover a LOT of ground before they gain enough knowledge to do anything useful.

But this is precisely why I'm frustrated here. I am a
programmer, (Sorry, IBM mainframes), and even *I* don't have a
clue what goes on with LUA/CELX.

cpotting wrote:But the more I think about it... the more I like it. If you don't mind, perhaps I will start working on a set of "lessons" to take one from CEL to CELX. Whaddya all think?

Sustained Applause from the BrainDead Gallery....

Thanks,

hank wrote:Lua allows you to define functions pretty much anywhere. You can put them at the beginning of the script if you prefer. You can also define a group of functions in a separate file and then use them in different scripts after loading the file. Usually the functions loaded from a file are provided as a library which you reference with a prefix that indicates which library they are defined in. For example, the trig sin function is referenced as math.sin because it's in the math library. That's a standard library which is usually built in, but you can define your own libraries similarly.

Well now, THAT'S helpful... Do you understand why someone might
be confused when confronting a function that may be defined at anyplace
in the script and/or program? Please understand, I'm not criticizing here,
I'm just trying to explain why someone who is unfamiliar with the
language might be confused when trying to understand a script. Let me
ask though, why wouldn't you place all functions in a place where
you could easily find, edit and reference them?
Are there LUA tools available to find defined functions?

We're making real progress here. And you thought you were only
gonna get two or three replies in this topic.

Thanks again for the education.

BrainDead wrote:Do you understand why someone might be confused when confronting a function that may be defined at anyplace
in the script and/or program? Please understand, I'm not criticizing here, I'm just trying to explain why someone who is unfamiliar with the language might be confused when trying to understand a script. Let me ask though, why wouldn't you place all functions in a place where you could easily find, edit and reference them?

Actually, there are very good reasons for allowing functions definitions to appear anywhere. But it's a little difficult to explain at this point.

Meanwhile, I've made a start on a simple CELX scripting tutorial for the Celestia wikibook. Feel free to check it out.

- Hank

hank wrote:Meanwhile, I've made a start on a simple CELX scripting tutorial for the Celestia wikibook. Feel free to check it out.

Well now, that's interesting. Should I ask/post questions on the wikibook
site? Or can I throw them out here for anyone else who might be
interested?

For example, how is it that the "flash" function is already defined by the
object "celestia" and can also be re-defined within the script? If I do
understand the wikibook information, then Celestia itself must already
contain the pre-defined "flash" function. Yes?

I do understand the function definition and setup as you described, but
again I'm at a loss to understand why you wouldn't want these definitions
in a single location so you know where to find them. No problem though...

I'll take it one step at a time.

Thanks again for your consideration here. This is free education
and I do appreciate it.

BrainDead wrote:

hank wrote:Meanwhile, I've made a start on a simple CELX scripting tutorial for the Celestia wikibook. Feel free to check it out.

Well now, that's interesting. Should I ask/post questions on the wikibook
site? Or can I throw them out here for anyone else who might be interested?

It would probably be best to put your quesions on the Talk page for the wikibook tutorial. That way other wikibook readers can see them.
But since you asked...

BrainDead wrote:For example, how is it that the "flash" function is already defined by the object "celestia" and can also be re-defined within the script? If I do understand the wikibook information, then Celestia itself must already contain the pre-defined "flash" function. Yes?

I thought I explained this in the tutorial, but I guess I wasn't clear enough. We didn't redefine anything. Both functions exist at the same time. The two functions are completely different, and unrelated (except for the fact that one calls the other). Although they have the same name, they have different owners. One belongs to the "celestia" object, and the other belongs to the script. If we want to use the function that belongs to the object, we have to include the object's name as a prefix. Otherwise we'll get our script function. Any number of objects, by the way, could have a "flash" function. We would distinguish between them by using the object name prefix. You are correct that the "flash" function of the "celestia" object is built in (along with many others). It's part of the object definition.

BrainDead wrote:I do understand the function definition and setup as you described, but again I'm at a loss to understand why you wouldn't want these definitions in a single location so you know where to find them. No problem though...

I'll take it one step at a time.

Sorry it can't be easily explained. But trust me, there are cases where this flexibility is needed. Of course, in most cases, it's best to put your functions in well-organized and documented libraries (or objects), as you indicate, unless they're for one-time use only.

- Hank