Feature Request: Automatic Time Setting

[maxim]

I know this starts to be an endless story of requests. But I continue to discover (or miss) things that I would find quite usefull and especially timesaving.

Having spacecrafts/objects for which there is a timeframe provided, it would be a good thing if a select/goto command would also change the simulation time to the beginning of that time frame automatically.

maxim

[Harry]

Having spacecrafts/objects for which there is a timeframe provided, it would be a good thing if a select/goto command would also change the simulation time to the beginning of that time frame automatically.

I don't think this is good general behaviour - the user may not expect this, and this could destroy a carefully setup scene. Changing the time also changes the positions of most celestial bodies - what position should the observer have after changing the time? Keeping the current frame of reference is probably in many cases, but not always.

But then again: this can be done using CELX-scripting (Ha! Anybody surprised? ), at least in recent versions of Celestia. The obivous problem for such a script is it's limited lifetime (i.e. until another script is started or ESC is pressed), which brings back the discussion about "background script"...

A script could also ask the user if he actually wants to change the time, which IMHO is better than simply changing it.

Harald

[maxim]

I don't expect it to be a general behaviour. Just another button in the solarsystem browser next to 'goto' called (i.e.) 'goto with timeset' and/or another menupoint 'goto selection with timeset'.

And, thought it'll be possible, it won't be much timesaving to select one out of dozens (hundreds?) of celx scripts for a certain spacecraft/object.

maxim

[Harry]

I don't expect it to be a general behaviour. Just another button in the solarsystem browser next to 'goto' called (i.e.) 'goto with timeset' and/or another menupoint 'goto selection with timeset'.

Creating a special goto-command has also the nice effect that there is much less worry about the current view getting ruined by changing the time - it's changing anyway. But logically the timechange should happen when you select an object...

And, thought it'll be possible, it won't be much timesaving to select one out of dozens (hundreds?) of celx scripts for a certain spacecraft/object.

This only makes sense if you have one script running all the time, which takes care of this for all objects. The script itself is not the problem, but having it running all the time can be difficult because it's easy to stop it by accident - that's where the idea of background-scripts comes in, which has been discussed on the developer mailing list, but without any final conclusion.

Harald

[maxim]

But logically the timechange should happen when you select an object...

Having some thoughts on this, I see that there has to be a more precise description:

Obvious there are different situations:

Concerning spacecrafts:
Most of them (about 80% on my installation) exists completely in the past. If you want to visit or watch them, changing the timeframe is unavoidable. If you want to see only track or orbit data you don`t need to change time, because these 'live' forever. Same for the ones completely in the future. If the craft exists also in (simulation) present, I would think it's unusual that you want to be set to the start of the timeframe.
Concering movement: Most time you 'goto' the craft. It's seldom that you are still there.

Planetal Bodies:
Most time you are still there, and only want to see a future/past version, so no 'goto' here. If you select a present one, no timeset is wanted usually. Selecting a past/future one usually inherits the need for a timeset.

I see the valuability of a programmed timeset because I spent alone six hours yesterday for commenting all my spacecraft ssc's with the gregorian dates out of the julian day data, playing around with copy,paste,calculate,... all the time. And I still have to open the ssc's to look when I want to go - while celestia already knows this internally.

There are three main selection sources:
Navigation->Select Object, Navigation->Go To Object:
Two checkboxes 'Set to timeframe start' and 'Set to timeframe end' would do a great job.

Solar System Browser:
Those two checkboxes would also do the job I think.

Autoselection List initiated with [RETURN]:
I'm not sure how to get along with this. A different color for those not existing in present? How about a hotkey that sets time to the framestart of selected object - this maybe an overall solution.

This only makes sense if you have one script running all the time, which takes care of this for all objects. The script itself is not the problem, but having it running all the time can be difficult because it's easy to stop it by accident - that's where the idea of background-scripts comes in, which has been discussed on the developer mailing list, but without any final conclusion.

I think it's worth being further considered.
Do my opinion these scripts are still event handlers. Not for user events, but for Celestia internal events. Or do I mention something different here? Perhaps this is stuff for another thread - I think Celestia (simulation-)internal events should be able of being handled anyhow. Hmmm...

maxim

[Harry]

Do my opinion these scripts are still event handlers. Not for user events, but for Celestia internal events. Or do I mention something different here? Perhaps this is stuff for another thread - I think Celestia (simulation-)internal events should be able of being handled anyhow. Hmmm...

I am not sure what you mean, i.e. what is it that you call internal/user events

The most simple solution for a script in this case would be to poll for a change in the selected object (e.g. once every 0.1s), and on change check if the current simulation time is within the timeframe for the new object (and if not, change simulation time).

Harald

[Oni]

I remember my first experience of selecting an old spacecraft object only to find nothing there when I arrived. After searching the forum and learning about beginning and ending times I figured it all out. Still had trouble though later on even knowing all that. Never could remember when the objects began or ended so I went through and changed every object name to include the start date. Ex: "Explorer 1" "Sol/Earth" became "Explorer 1 (January 31, 1958)" "Sol/Earth" I still have to set the date manually, but at least now I don't have to search online, through the ssc files, and convert the Julian date to find out the date...it's there on the screen beside the object name. Of course I had to also go into every script file and edit each Select object or Mark object to reflect the changed names, good thing I don't have many script files to edit yet Not the best solution, but it works for me thus far. Also edited names of other objects to show what they were and to help sort them all out. Ex: "Borrelly" "Sol" became "Comet - Borrelly" "Sol" and "1950 DA" "Sol" became "Asteroid - 1950 DA" "Sol". True if I keep it like this I'll have to edit every script and ssc file I get from now on, but it's a small price to pay for a better organized list.

[maxim]

Oni:
Theoretically your object status is known in the 3D display.
But I know what you mean. Inside the solarsystem browser it is not recognizeable which type of object you have: an asteriod, a spacecraft or a comet - until you're already familiar with the names. I stumble over this too.

Harry:
User events are the usual ones:
mouse move/click/hover
keyboard events
joystick movement

Program internal events are:
An object is selected.
Timerate is changed.
An alternate texture is selected.
Star representation is changed.
...

Simulation internal events are:
Spacecraft is lauched
Spacecraft is lost
Spacecraft drops probe
Probe enters orbit
Object passes sun-nearest point of orbit
Object passes sun-farest point of orbit
Eclipse starts/ends
Probe touchdown
Object starts swingby manoevre.
Probe passes nearest point to object
asteriod passed nearest point to earth.
...more of that

I just got some ideas about the last ones. I have to work this out for another thread.
Could be of worth for professional use of the simulation.

maxim