Are .CEL scripts deprecated?

[hank]

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

- Hank

[BrainDead]

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.

[hank]

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:

Code: Select all

{
?  select { object "Sol/Jupiter/Io" }
?  follow {}
?  goto { time 5 }
?  gotolonglat { time 0 distance 2.5 longitude -122 latitude 47 } #? ? ? ? Seattle!
?  wait { duration 0.1 }
?  orbit { axis [ 0 1 0 ] rate 10 duration 7 }
?  wait { duration 5.0 }
}

you would have to write:

Code: Select all

?  select { object="Sol/Jupiter/Io" }
?  follow {}
?  goto { time=5 }
?  gotolonglat { time=0, distance=2.5, longitude=-122, latitude=47 } --? ? ? ? Seattle!
?  wait { duration=0.1 }
?  orbit { axis={ 0, 1, 0 }, rate=10, duration=7 }
?  wait { duration=5.0 }


Does that seem feasible?

- Hank

[BrainDead]

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.

[hank]

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

[hank]

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:

Code: Select all

?  select { object "Sol/Earth" }
?  follow {}
?  goto { time 5 }
?  gotolonglat { time 0 distance 2.5 longitude -122 latitude 47 } #? ? ? ? Seattle!
?  wait { duration 5.0 }


Using Lua you could do something very similar:

Code: Select all

?  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
?  gotolonglat { time=0, distance=2.5, longitude=-122, latitude=47 } --? ? ? ? Seattle!
?  wait { duration=5.0 }


But with Lua you could also use variables:

Code: Select all

  seattle = {lat=47, lon=-122}
?  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
?  gotolonglat { time=0, distance=2.5, longitude=seattle.lon, latitude=seattle.lat } --? ? ? ? Seattle!
?  wait { duration=5.0 }


...and functions:

Code: Select all

function flyover(place) {
?  gotolonglat { time=0, distance=2.5, longitude=place.lon, latitude=place.lat } --? ? ? ? anyplace!
?  wait { duration=5.0 }
  }

  seattle = {lat=47, lon=-122}
  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
  flyover(seattle)


... which can be used repeatedly:

Code: Select all

  function flyover(place) {
  ?  gotolonglat { time=0, distance=2.5, longitude=place.lon, latitude=place.lat } --? ? ? ? anyplace!
  ?  wait { duration=5.0 }
  }

  seattle = {lat=47, lon=-122}
  chicago = {lat=41, lon=-87}
?  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
  flyover(seattle)
  flyover(chicago)


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

Code: Select all

  function flyover(place) {
  ?  gotolonglat { time=0, distance=2.5, longitude=place.lon, latitude=place.lat } --? ? ? ? anyplace!
  ?  wait { duration=5.0 }
  }

  seattle = {lat=47, lon=-122}
  chicago = {lat=41, lon=-87}
  newYork = (lat=40, lon=-73}
  places = { seattle, chicago, newYork }
?  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
  countOfPlaces = table.getn(places)
  for i = 1,countOfPlaces do
    flyover(places[i])
  end


... and more:

Code: Select all

  function flyover(place) {
  ?  gotolonglat { time=0, distance=2.5, longitude=place.lon, latitude=place.lat } --? ? ? ? anyplace!
  ?  wait { duration=5.0 }
  }

  seattle = {lat=47, lon=-122}
  chicago = {lat=41, lon=-87}
  newYork = (lat=40, lon=-73}
  places = { seattle, chicago, newYork }
?  select { object="Sol/Earth" }
?  follow {}
?  goto { time=5 }
  countOfPlaces = table.getn(places)
  for i = 1,countOfPlaces do
    randomPlaceIndex = math.random(countOfPlaces)
    flyover(places[randomPlaceIndex])
  end


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

[Malenfant]

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

[selden]

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/

[BrainDead]

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.

[ANDREA]

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

[cpotting]

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.

[hank]

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.

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

[danielj]

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

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.

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

[hank]

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

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

Code: Select all

celestia:flash("Hello, Universe!")
wait(2.0)


Here's a little more complicated one:

Code: Select all

function flash(message)
   celestia:flash(message)
   wait(2.0)
  end

flash("Hello, Universe!")
flash("Goodbye, Universe!")


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

We can check the time:

Code: Select all

flash("Hello, Universe!")
time = celestia:gettime() - gets the current time (Julian date) in Celestia
flash("time now is "..time) -- uses the .. operator to join two strings
flash("Goodbye, Universe!")


Or Cassini's current distance from Saturn:

Code: Select all

flash("Hello, Universe!")
cassini = celestia:find("Cassini") -- finds object named Cassini
saturn = celestia:find("Saturn") -- finds object named Saturn
cassiniPosition = cassini:getposition() -- gets position of Cassini
saturnPosition = saturn:getposition() -- gets position of Saturn
distance = cassiniPosition:distanceto(saturnPosition) -- computes distance from  position of Cassini to that of Saturn
distance = distance-saturn:radius() -- adjusts for distance to surface
flash("Current distance from Cassini to Saturn is "..distance)
flash("Goodbye, Universe!")


Not so hard, really. Try it yourself!

- Hank

[BrainDead]

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.

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.

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,

[BrainDead]

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.

[hank]

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

[BrainDead]

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.

[hank]

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

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.

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