New script: an interactive spacecraft trajectory creator

[Toti]

Hello all,

I recently uploaded a new CELX script: an easy to use, interactive spacecraft trajectory creator.

This program lets the user enter the points of a rough path (by visiting and marking the places where the curve will pass through) and then improves its resolution (using a X-order B-Spline) and saves it as a .xyz file, that can be used by Celestia to render spacecraft orbits.

Using it is indeed very simple: start Celestia, load the script, enter the output file name and the total number of curve points that will be written to disk.
Move your observer to certain position, adjust the simulation time (e.g: Aug 10 2061) and hit ctrl-Enter. Repeat for a few points, changing (obviously) your position and time, making a rough "drawing" of the orbit. You can remove any erroneous entry by pressing ctrl-backspace.
Once done, hit ctrl-x to save the trajectory (you'll find it in your Celestia folder).

Here's the link (BTW, many thanks to the people at the Motherlode site):
http://www.celestiamotherlode.net/creators/toti/XYZBuilder.zip

Bye

[jestr]

Thanks for this Toti,I'm sure it will be a great help for a lot of people,I have been trying for a few months to build an (as yet fictional) xyz for the descent of Huygens to its projected landing site on Titan and have made all the different models for the different phases of the approach,and the xyz I made by hand was quite close,but had some nasty kinks in the orbit.I tried out this script but the numbers came out a lot different to the ones I have arrived at by hand.What reference point does your script use,there doesnt seem to be any way to change it.For instance the one I did by hand was Sol centred,could the one the script produced be Titan centric.What if I want to make an xyz for a spaceship in another star system?Heres a pic of some of the descent

I hope this isnt tempting fate.All the best Jestr
PS.I used this sketch as a reference for the various stages of the descent

[Toti]

Jestr,

The script uses an heliocentric coordinate system: it won't work for extrasolar systems, but I think that's easy to fix.

About the other point, I quickly made a crude Huygens probe trajectory (about 10 hand-entered points) that starts near Cassini and intersects Titan on 1/7/2005.
In order to keep it small, it just has 200 samples: I'll PM it to you.

PS. that sounds like a really great addon!

[blake6489]

im haveing a hard time using the srcipt. the first time i press ctrl-enter, it asks for a target name, and ive tried several things, but none have worked. what am i supposed to put for the target name? Camera? an object like earth...?
thanks

[Toti]

Have you read the accompanying .txt? Everything is explained there.
You must enter:
--the output file name
--the maximum number of trajectory points that will be written to disk
--the adaptive angle.

And then you can start adding the points with a key press. Could you please post the actual message you are receiving? There shouldn't be such a thing.

[blake6489]

K, when i run the script it says
--type y to contiue...
--enter file name
--number of points

there isnt another prompt after this... so i press ctrl-enter
what i have just realized is that this is a typical Celetia response for when i press enter...

but that dosnt help my use the script yet

thanks

[Toti]

There should be another message asking you the adaptive angle. Are you running Celestia on Windows?

[blake6489]

nope, using a recent Ubuntu dist.
the Celestia version is 1.3.2 if that matters

[Toti]

Yes, that explains it. Celestia-Linux keyboard management under CELX (Lua) is broken: for example, ctrl-Enter gets mapped the same as Enter, pageUp/pageDown keys don't work, etc.

Scripts that make use of these keymappings won't run properly on Linux. I could use other keys, but as many important ones don't work at all, 3d movement is seriously constrained, rendering the script pretty useless in the first place.

[blake6489]

well im glad to know that im not just a idiot that cant follow instructions.
do you know if the break is just on a recent version or if it just always been like that for Linux?
thanks for the help

[Toti]

I think it's been there from the beginning, but I don't know the details.

[Christophe]

I've run some tests and I don't see any problem with the celx keyboard callback under KDE.

Of course shortcuts for KDE actions are intercepted and never reach the celx script but that's the expected behaviour. We could disable all shortcuts when a script asks for keyboard control, but I'm not sure that is desirable (maybe disable only single key and CTRL-key shortcuts?)

About CTRL-Enter, I don't know how Windows handle this, but I don't see why you should get something different than when pressing Enter?

Same thing with PageUp/Down, there are no ASCII codes for those. What does Windows use?

[Christophe]

We could disable all shortcuts when a script asks for keyboard control, but I'm not sure that is desirable (maybe disable only single key and CTRL-key shortcuts?)

Actualy we already do disable single key shortcuts, so the problem is only with CTRL-Key shortcuts.

[Toti]

I've run some tests and I don't see any problem with the celx keyboard callback under KDE.

Did you test this with my script?

Of course shortcuts for KDE actions are intercepted and never reach the celx script but that's the expected behaviour. We could disable all shortcuts when a script asks for keyboard control, but I'm not sure that is desirable (maybe disable only single key and CTRL-key shortcuts?)

Yes, but that behavior changes when you run a celx script. (Home/End and PgUp/PgDown work OK with Celestia but they do not respond anymore when pressed from inside a script. This makes 3D movement almost impossible)

About CTRL-Enter, I don't know how Windows handle this, but I don't see why you should get something different than when pressing Enter?

In Windows they trigger two different actions: in the script, I left Enter to select bodies by name (as usual), and I used ctrl-Enter to add points to the trajectory. In Linux they both report the same input code 13.

[Christophe]

I've run some tests and I don't see any problem with the celx keyboard callback under KDE.

Did you test this with my script?

I haven't, but from reading it I understand that it doesn't work.

Of course shortcuts for KDE actions are intercepted and never reach the celx script but that's the expected behaviour. We could disable all shortcuts when a script asks for keyboard control, but I'm not sure that is desirable (maybe disable only single key and CTRL-key shortcuts?)

Yes, but that behavior changes when you run a celx script. (Home/End and PgUp/PgDown work OK with Celestia but they do not respond anymore when pressed from inside a script. This makes 3D movement almost impossible)

What do you mean by "from inside a script". If a script is running and has requested the keyboard, then key presses are passed to the script and not to Celestia, that is the expected behaviour.

About CTRL-Enter, I don't know how Windows handle this, but I don't see why you should get something different than when pressing Enter?

In Windows they trigger two different actions: in the script, I left Enter to select bodies by name (as usual), and I used ctrl-Enter to add points to the trajectory. In Linux they both report the same input code 13.

I understand that it is a desirable behaviour to be able to distinguish Enter from CTRL-Enter, my point is that considering the current implementation of the keyboard callback there is no reason to return a different code. The Windows behaviour is more a bug than a feature.

Doing keyboard handling properly is complex, the current solution uses only ASCII codes and doesn't allow the use of modifiers, this also results from the way Celestia handles keyboard input. I think that before improving the celx keyboard callback we should work on the way Celestia handles the keyboard and bring it beyond pure ASCII.

[Toti]

Yes, but that behavior changes when you run a celx script. (Home/End and PgUp/PgDown work OK with Celestia but they do not respond anymore when pressed from inside a script. This makes 3D movement almost impossible)

What do you mean by "from inside a script". If a script is running and has requested the keyboard, then key presses are passed to the script and not to Celestia, that is the expected behaviour.

But Home/End/ PageUp/Down must then be being intercepted by Windows, because I can use them to maneuver in 3D space while the script is running. In Linux these keys do nothing, not even return a keycode, which brings the main point up: I know it's possible to select which keys will be managed by the script and pass the others to Celestia, but again, in Linux the navigational keys aren't even being detected, so no special handling can be done.

[Christophe]

You're right, there was a problem for keys which are handled through key down/up events instead of charEntered, those weren't sent when a celx script had requested the keyboard. This is fixed in CVS.

[Toti]

Christophe,
Works great! There's only a small glitch: when a script doesn't capture them, numpad keys not only move the viewport, but also change the selected planet (eg. 4: mars, 6: Saturn, etc.)

blake6489,
The script should work now. Just change all occurrences of "\010" (at lines 29, 43 and 279) with "\009".
To add a point, press ctrl-i

[Christophe]

Christophe,
Works great! There's only a small glitch: when a script doesn't capture them, numpad keys not only move the viewport, but also change the selected planet (eg. 4: mars, 6: Saturn, etc.)

That's strange, I can't reproduce that. Whether a script is running or not, whether it has acquired the keyboard or not, whether numlock is on or not, the numpad keys don't change the selection. Can you provide a script that triggers it?

[Toti]

Strange. This one (that does not acquire the keyboard) shows the effect in my system:

Code: Select all

function celestia_keyboard_callback(input)
    return false
end


celestia:requestkeyboard(true)
while true do
    wait()
end