Are .CEL scripts deprecated?

[BrainDead]

Well,why my message was ignored?
It is more than an year,that the Deep Space Tour is not updated.With a better presentation of DSOs,this could be considered.Don??t you think?
Actually,it had beem several months since no new script is created.I don??t know why.I am talking about a downloable script,not this cut and paste methods.
The last solar system script was Pluto Tour,I think and since then,no more updates have been available...

First of all, I wrote the solar system touring scripts (At least the scripts
which tour the planets individually) and then I had to leave for a while
because I was in the hospital. When I came back, I found that no one really
wanted CEL scripts anyway, so I'm in the process of trying to learn the CELX
scripting process.

Also, since I never heard one word of thanks or comments from you
concerning any of the CEL scripts I did create, there didn't seem
to be much hurry to get new scripts finished anyway. If this bothers you
so much, why don't you just write your own scripts?

As shown in earlier in this thread, Hank and Clive have provided almost
every available means of educating someone in the CELX language, so
why don't you take advantage of these resources to try and learn
something instead of complaining all the time.

Just a thought.

[Harry]

When I came back, I found that no one really wanted CEL scripts anyway, so I'm in the process of trying to learn the CELX scripting process.

I don't think that's true. Most people don't even know the difference. As long as CEL-scripting suffices to achieve what you want to do, then there is no need to switch. It's just that you can do some things with CELX which are simply impossible to do with CEL - the question of whether you actually need these additional possibilites is a completely different matter.

Harald

[hank]

When I came back, I found that no one really wanted CEL scripts anyway, so I'm in the process of trying to learn the CELX scripting process.

I don't think that's true. Most people don't even know the difference. As long as CEL-scripting suffices to achieve what you want to do, then there is no need to switch. It's just that you can do some things with CELX which are simply impossible to do with CEL - the question of whether you actually need these additional possibilites is a completely different matter.

Harald

Harald, I'm wondering if you had any comment on my suggestion in a previous post that CEL scripts might be converted to Lua/CELX with a few trivial syntax changes?

- Hank?

[Harry]

Harald, I'm wondering if you had any comment on my suggestion in a previous post that CEL scripts might be converted to Lua/CELX with a few trivial syntax changes?

There are some problems with this. For instance the CELX goto command is dependent on an observer (i.e. you call the command on an observer-object). AFAIR the goto command in CEL always uses the currently active observer.

What may work (not sure if this was what you had in mind) is to create something similar to a library, made up of a number of commands which are named and behave just like their CEL counterparts. In most cases the translation should be straightforward.

However you already can integrate an unchanged CEL-script within a CELX-script, using some fairly simple code (which can be copied & pasted). And when you need functions which are beyond CEL, then you have to understand CELX anyway

Harald

[danielj]

Your work was very good.But I only think the scripts should be update,specially the Mars and Saturn tour,because of the new discoveries.
I didn??t know that only you write the scripts...
What about the Deep Space Tour?Who did it?

Well,why my message was ignored?
It is more than an year,that the Deep Space Tour is not updated.With a better presentation of DSOs,this could be considered.Don??t you think?
Actually,it had beem several months since no new script is created.I don??t know why.I am talking about a downloable script,not this cut and paste methods.
The last solar system script was Pluto Tour,I think and since then,no more updates have been available...

First of all, I wrote the solar system touring scripts (At least the scripts
which tour the planets individually) and then I had to leave for a while
because I was in the hospital. When I came back, I found that no one really
wanted CEL scripts anyway, so I'm in the process of trying to learn the CELX
scripting process.

Also, since I never heard one word of thanks or comments from you
concerning any of the CEL scripts I did create, there didn't seem
to be much hurry to get new scripts finished anyway. If this bothers you
so much, why don't you just write your own scripts?

As shown in earlier in this thread, Hank and Clive have provided almost
every available means of educating someone in the CELX language, so
why don't you take advantage of these resources to try and learn
something instead of complaining all the time.

Just a thought.

[hank]

What may work (not sure if this was what you had in mind) is to create something similar to a library, made up of a number of commands which are named and behave just like their CEL counterparts. In most cases the translation should be straightforward.

Yes, that's what I had in mind. This approach would allow the use of basic Lua features, such as variables, expressions for command parameters, conditionals, loops, etc. while still using the simpler CEL command style interface to Celestia. It might be a helpful step towards learning to use the more powerful CELX interface. Also, new CEL-style functions could be written in Lua-CELX to provide support for new Celestia features more easily than implementing them with new built-in CEL commands. And eventually perhaps it would be possible to eliminate the built-in CEL code entirely. Backward compatibility could be maintained with a simple built-in CEL->CELX translator.

- Hank

[cpotting]

Clive,

Is your CELX UI code packaged for general use?

- Hank

Yes and no. I tried to create fairly generic routines, but the Guide was a big project and some things just had to be tailored for its use. I am assuming that by "packaged" you mean a set of functions that can be copy/pasted into a script and used without any additional functions or setup..

If you look at the code, you can see that I have divided the functions into sections with the functions appearing alphabetically in each section. The sections are bordered by comments full of "vvvvvvvvvv" characters at the top and "^^^^^^^^^^' characters at the bottom.

They are listed as:
Celestia Cleanup Function
This one should really be renamed to "Settings Functions" and include restore_settings() and save_settings() to be considered a packaged set. I'll do that for the next update.

Keyboard Related Functions and Variables
This one could be considered a package.

Generic Utility Functions
I'd have to double check this section, but I believe the functions in this section are self-contained (packaged). Again, restore_settings() and save_settings() really belong with the celestia_cleanup_callback() function.

In this section, the function with the most potential for re-use is the show_and_hold() function. This has proved very useful while debugging scripts.

Miscellaneous Functions Used Througout The Script
This also appears to be a pretty good package, with the exception of string_common(). Though it could be considered portable, it's use is pretty esoteric, and I can't imagine anyone getting much use out of it.

One the other hand, I am quite proud of the travel_to() function in this section. It is, by far, the most complex and syntactically difficult of all the functions in the Guide. It arose because I noticed that there is a flaw in all of Celestia's "goto" functions that causes an error in the ending position of the observer unless the time rate is 0 (time is frozen). The error is slight, but shows up dramatically when one moves over light-years while the time rate changes the simulation time over a period of millenia. Anyway - to get around it (and to challenge myself) I decided to try building my own. I learned a lot about frames and rotations while writing travel_to(). It could definetly be considered a package onto itself.

Menu Related Functions and Variables
These could be adapted foruse by other scripts (and in fact I plan to do so), but as they are currently written, I think they depend too much on the overall structure and function of the Guide.

The remaining sections are definitely Guide-specific.

I tried to document the functions with leading comments as well.

If you are interested in the how any of them work, or have problems or questions about getting them to work in your scripts, just drop me a line. I'd be glad to help.

[cpotting]

What may work (not sure if this was what you had in mind) is to create something similar to a library, made up of a number of commands which are named and behave just like their CEL counterparts. In most cases the translation should be straightforward.

Yes, that's what I had in mind. This approach would allow the use of basic Lua features, such as variables, expressions for command parameters, conditionals, loops, etc. while still using the simpler CEL command style interface to Celestia. It might be a helpful step towards learning to use the more powerful CELX interface. Also, new CEL-style functions could be written in Lua-CELX to provide support for new Celestia features more easily than implementing them with new built-in CEL commands. And eventually perhaps it would be possible to eliminate the built-in CEL code entirely. Backward compatibility could be maintained with a simple built-in CEL->CELX translator.

- Hank

I had thought of this myself (a translation program), and mulled it over, trying to decide if it would be to good learning tool for a CELX student, or would it become a crutch, holding them up from really advancing past CEL.

It occurred to me that a slight variation might provide the same learning tool, without the "crutch-factor": what would you think of a a set of cut-and-paste ready CELX templates - one for each CEL command. For instance:

CEL:
select { object "|string1|" }

CELX:
celestia:select(celestia:find("|string1|"))
or
body = celestia:find("|string1|")
celestia:select(body)

Of course, I picked a simple one. CEL commands like orbit are a little more difficult. But the idea is that the programmer can continue to envision their goals in CEL while writting the code in CELX.

I think it provides the same sort of painless transisition to CELX that a translator does, but give the student a bit more hands-on experience with CELX.

[cpotting]

When I came back, I found that no one really wanted CEL scripts anyway, so I'm in the process of trying to learn the CELX scripting process.

I don't think that's true. Most people don't even know the difference. As long as CEL-scripting suffices to achieve what you want to do, then there is no need to switch. It's just that you can do some things with CELX which are simply impossible to do with CEL - the question of whether you actually need these additional possibilites is a completely different matter.

Harald

I agree with Hank. I loved the tours and other scripts done with CEL - they were a great introduction to the things to be found in Celestia. In fact, it was the tours that showed me the power ofCelestia and made me decide to look into this program even more.

I don't think CELX replaces CEL. I prefer to think of it as a more powerful version of CEL. If CEL wasn't around, so many people would have been put off by the learning curve needed to start in CELX, that we wouldn't have any of the great scripts that we do now. CEL is a great way to program Celestia. It's simplicity makes it accessible for everyone. For those who want to go a step further - there's CELX. They both have their place.

[hank]

What may work (not sure if this was what you had in mind) is to create something similar to a library, made up of a number of commands which are named and behave just like their CEL counterparts. In most cases the translation should be straightforward.

Yes, that's what I had in mind. This approach would allow the use of basic Lua features, such as variables, expressions for command parameters, conditionals, loops, etc. while still using the simpler CEL command style interface to Celestia. It might be a helpful step towards learning to use the more powerful CELX interface. Also, new CEL-style functions could be written in Lua-CELX to provide support for new Celestia features more easily than implementing them with new built-in CEL commands. And eventually perhaps it would be possible to eliminate the built-in CEL code entirely. Backward compatibility could be maintained with a simple built-in CEL->CELX translator.

- Hank

I had thought of this myself (a translation program), and mulled it over, trying to decide if it would be to good learning tool for a CELX student, or would it become a crutch, holding them up from really advancing past CEL.

It occurred to me that a slight variation might provide the same learning tool, without the "crutch-factor": what would you think of a a set of cut-and-paste ready CELX templates - one for each CEL command. For instance:

CEL:
select { object "|string1|" }

CELX:
celestia:select(celestia:find("|string1|"))
or
body = celestia:find("|string1|")
celestia:select(body)

Of course, I picked a simple one. CEL commands like orbit are a little more difficult. But the idea is that the programmer can continue to envision their goals in CEL while writting the code in CELX.

I think it provides the same sort of painless transisition to CELX that a translator does, but give the student a bit more hands-on experience with CELX.

What I have in mind is a collection of Lua functions using CELX to implement each of the CEL commands, so that users could write CELX code that looks nearly identical to existing CEL. For example:

CEL:
select { object "|string1|" }

CELX:
select{object="|string1|"}

This example would involve the following Lua function:

select = function(args)
local object = args.object
celestia:select(celestia:find(object))
end

A collection of such functions could serve the didactic purpose of indicating how each CEL command could be specified in CELX, and could also be used directly to allow existing CEL scripts to run under CELX with minor syntax changes. A translator could be written to perform this syntax conversion automatically, and it could be used internally by Celestia to retain backward compatibility with CEL scripts while eliminating the c++ code that currently implements CEL independently of CELX.

- Hank

[cpotting]

What I have in mind is a collection of Lua functions using CELX to implement each of the CEL commands, so that users could write CELX code that looks nearly identical to existing CEL. For example:

CEL:
select { object "|string1|" }

CELX:
select{object="|string1|"}

This example would involve the following Lua function:

select = function(args)
local object = args.object
celestia:select(celestia:find(object))
end

A collection of such functions could serve the didactic purpose of indicating how each CEL command could be specified in CELX, and could also be used directly to allow existing CEL scripts to run under CELX with minor syntax changes. A translator could be written to perform this syntax conversion automatically, and it could be used internally by Celestia to retain backward compatibility with CEL scripts while eliminating the c++ code that currently implements CEL independently of CELX.

- Hank

Understood. And the two approaches are very similar. The function approach you outlined is an easier bridge for the neocelxer (oooh, I like that word!). My only concern is that it may encourage some to just write CEL scripts in CELX and never entice them into the wonderful world of quaternions, vectors and (my favourite) object objects.

I was thinking that with the cut/paste template approach, the end product is a CELX script that the neocelxer can build upon.

Perhaps there is room for both - have a document or file that presents a CEL-in-CELX select() function, and cut-and-paste CELX template, and let the neocelxer choose.

[BrainDead]

I don't think CELX replaces CEL. I prefer to think of it as a more powerful version of CEL. If CEL wasn't around, so many people would have been put off by the learning curve needed to start in CELX, that we wouldn't have any of the great scripts that we do now. CEL is a great way to program Celestia. It's simplicity makes it accessible for everyone. For those who want to go a step further - there's CELX. They both have their place.

Thanks for that Clive... This is exactly why I got involved in Celestia.
The CEL scripts were so easy to write, that even us Brain-Dead types could
contribute something. If I had had to learn CELX, I'd have never contributed
a thing to the project.

I really would like to learn CELX though. Now that you and Hank have
given me some education, I'm slowly, but surely getting there. Oop-speak
is simply very difficult for me personally, but I'll get there.

Thanks again Hank, Clive for your educational materials. Also, just so I
don't leave Harry out of this, I have also downloaded your CELX manual.

Now that I have some MORE background with CELX, the guide makes
more sense to me. So, thank you too Harry.

Good stuff.