Basic Questions and Observations about Celx

[hharris]

The followng is a discussion of some problems with Celx from my viewpoint. I'm offering this in the spirt of starting a discussion and maybe getting some explanation of points I'm still confused about. Bear in mind that most of this is based on my own limited experimentation and others may have more insight.

Let's start with the command "SetSpeed." Speed is the appropriate word because there's only one value, a scalar. Unfortunately this, by itself, makes no sense. We are actually setting a velocity vector in at specified direction but that direction is not defined in the documentation. My experimentation leads me to believe that what the documentation should say is that this command sets the velocity value of the x component of the orientation vector.

Constrast this with the command in Cel "move," which allows you to set a velocity vector (and is well-documented). Of course, you could duplicate this command in Celx by first setting the orientation and then calling "SetSpeed," but there is another problem. The look direction is in the direction of the orientation vector. You can change the look angle with LookAt in Celx but only to a position, which is not very useful. This means that the velocity vector (if you use this method) is tied to the look angle.

Cel, on the other hand, allows you full independent control of the camera which is well documented.

Now if one is only interested in writing toy programs in Celx this is probably all you need, but it ignores the most general problem where acceleration affects the full 3D velocity vector. It's as if the writers of Celx assumed that script writers were only interested in writing programs in which the universe had no forces. In my case I want the observer to "feel" the mass of a passing planet as a moving acceleration vector. I want an independent camera, not just one that can look at specified positions. There should be two vectors, one that represents the sum of all the forces on the observer, and another which is the direction the observer is looking.

Now the way to get around this is to ignore SetSpeed and use SetPosition but that means you have to write code that is already available in Cel, which is a bit crazy.

And then there is the lack of the equivalent comand to Cel's essential "orbit" which I've discussed elsewhere.

I believe that Celx is a great programming language but it needs better documentation and it needs to rethink its selection of basic commands that together form a useful set.

Henry

[cpotting]

Let's start with the command "SetSpeed." Speed is the appropriate word because there's only one value, a scalar. Unfortunately this, by itself, makes no sense. We are actually setting a velocity vector in at specified direction but that direction is not defined in the documentation.

Perhaps it would help the think of "SetSpeed" as a holdover, a legacy method, from the "old" keyboard way of doing things. I agree, that because speed is simply not a useful thing to set in Celestia - a better command would be setvector(). This can be done quite easily with .celx. But I don't think of this as a .celx shortcoming. It is just one of those commands that didn't translate well from UI to scipting. I find it easier to just ignore setspeed() and use the power of .celx.

My experimentation leads me to believe that what the documentation should say is that this command sets the velocity value of the x component of the orientation vector.

Technically yes. See the Celx Visual Guide script on the Motherlode for my take on what the documentation should say.

Constrast this with the command in Cel "move," which allows you to set a velocity vector (and is well-documented). Of course, you could duplicate this command in Celx by first setting the orientation and then calling "SetSpeed," ...

Again, I prefer to just ignore setspeed(). It is easy enough to calculate the desired vector and set up a loop that changes the observer's position appropriately.

Cel, on the other hand, allows you full independent control of the camera which is well documented.

So does .celx. I can't think of a single way to operate the camera that isn't available via the setorientation() and other observer methods.

Now if one is only interested in writing toy programs in Celx this is probably all you need

oooo... 'dem's fightin' words...

, but it ignores the most general problem where acceleration affects the full 3D velocity vector...

The power of .celx is that it allows you handle this yourself. Besides, I'm getting the feeling that you have not checked out the goto() method. I'm not sure that it answers your concerns, but if you haven't looked at it - perhaps you should.

Now the way to get around this is to ignore SetSpeed

Now you're talking...

and use SetPosition but that means you have to write code that is already available in Cel, which is a bit crazy.

But you can write a better routine than that available in .cel.

And then there is the lack of the equivalent comand to Cel's essential "orbit" which I've discussed elsewhere.

Agreed. The function can be duplicated, but it would have been nice to have a method available.

I believe that Celx is a great programming language but it needs better documentation and it needs to rethink its selection of basic commands that together form a useful set.

I think there is a lot more to .celx than you may at first have seen. It really is much more powerful than .cel

Sorry... gotta run off to work (that's why my responses really aren't very detailed). But let's keep the discussion going...

[hank]

Here's how I look at CEL and CELX:

CELX itself is not a programming language. It is a library of functions designed for use with the programming language Lua. In order to use CELX effectively, you have to understand Lua. But Lua is very powerful, so learning it is well worth the effort. And fortunately, Lua is small and well-documented. The basic documentation does assume some programming experience, but beyond that it's very good.

CEL is a programming language, but only barely. It does not supprt variables, expressions, conditionals, loops, functions, etc. It only provides for sequential execution of fixed commands. Obviously this is very limiting. It's possible to run CEL scripts using CELX, but this is an awkward workaround. A better approach would be to implement the CEL commands as functions that could be called directly from Lua, and in many or most cases this could be done with functions written in Lua using CELX. (More on this below.)

The CELX functions comprise an object-oriented API (applications programming interface) for Celestia. In order to use CELX effectively, you have to understand how these functions work. To a large extent, this means understanding how the underlying Celestia functionality works. Because CELX provides a relaticely low-level interface, you have to understand things like quaternions, transformation matrices, frames of references, and other things which an end user of Celestia wouldn't have to know about. Unfortunately, this stuff is not very well documented.

CEL also provides an API for Celestia, but at a higher-level than CELX. Unlike CELX, the CEL commands are defined in terms that would be familiar to most end users of Celestia. This makes CEL much easier to use for simple applications, especially by non-programmers. And because the CEL commands are close to the functions of the Celestia GUI (which users presumably know), documentation is less essential.

But as noted above, since Lua allows you to define new functions, in many or most cases the CEL commands could be implemented as functions written in Lua using CELX. Writing such a CEL library would require understanding the CELX low-level API. But once the library is written, it could be used by anyone. This approach would make CEL-style scripting much more flexible, because all the features of Lua could be used with CEL commands.

With respect to the CELX observer "setspeed" method, this reflects the underlying functionality of Celestia. You are correct that the speed is a scalar and the direction of motion is determined by the observer's orientation. That's how Celestia works. The CEL "move" command doesn't involve the observer's "speed". It simply adjusts the observer's position incrementally. As you realize, this can be done easily using the CELX observer "getposition" and "setposition" methods. And unlike the CEL "move" command, this approach isn't limited to constant speed rectilinear motion.

- Hank