Celestia Forums

After dividing Celestia's window into several Views, how can one select a particular View to manipulate?

Alternatively, how can a CELX script specify which View is to be Active?

(Note that these two questions are NOT the same. The Active View, the one with which the user's interactive commands are associated, should not necessarily be the same as the View that a CELX script is manipulating.)

As best I can tell, most operations (goto, etc) manipulate only the [edit]View which was active at the time of the call to getobserver()[/edit], and the Active View can only be specified by the user clicking in it. Associating a CELX command with a different "observer" does NOT cause it to manipulate the View for which that observer was defined.

For example, if obs1 is the observer associated with the 1st view, and obs2 is the observer associated with the 2nd view,
obs2:goto(target)
goes to the specified target in the [edit] view active at the time of the most recent getobserver() call[/edit]; it does not goto the target in the 2nd View. Comparably,
obs1:deleteview()
deletes the [edit] view active at the time of the most recent getobserver() call[/edit]; it does not delete the 1st View.

This problem has come up in my current Pointing Hubble Addon. I need to be able to manipulate the viewpoint of the View which was created at the beginning of the script, after creating several other Views.

Maybe I'm just misunderstanding how the observers and Views are interrelated. An example of code which manipulates the contents of multiple Views would be greatly appreciated.

Selden,

AFAIK, there's unfortunately no way to set the active view from celx/lua...
I've also spent quite a few hours trying to do this in one of my scripts, but came with the conclusion that it is not possible other than with a mouse click...

If this is effectively the case (maybe Hank can confirm), I'll have a look at the code and try to add the set/getactiveview methods to celx scripting.

Selden,

Please see http://celestiaproject.net/forum/viewtopic.php?t=7322
That confirms that there's no way in celx to set the active view.
However, it seems to be possible in celx to act on each observer independently...

Vincent,

Thanks for investigating. Being able to set/get active view would help a lot.

Unfortunately, my attempts to set/get the observer environment are not producing consistent results

A related issue:

obs:splitview()
does not return a value corresponding to the new observer. It should.

Having to discover the new view's observer environment by calling getobserver() is not appropriate. getobserver() returns an observer supposedly corresponding to the currently active view, which is not necessarily the same. The user might already have changed the active view by the time getobserver has been called.

Selden,

observers = celestia:getobservers()
will return a table with all observers in use.
This will allow you to control each view/observer.

As an example, here's a script that set a different speed value to each observer:

As another example, here a script that displays the speed value in ly/s for each observer:



Just click the different views and change the speed with the 'A'/'Z' keys...

Vincent,

Thanks!

selden wrote:Vincent,

Thanks!

Selden,

You're welcome !

Is there still a need for adding the set/getactiveview methods to celx scripting ?

Vincent,

Yes, I think there is.

(I still seem to be getting inconsistent view selections for some operations, but I haven't had the time to clarify to myself exactly what is happening.)

Selden,

You can already get the current active view in celx.
As an example, the following script displays the current active view:


Do you have an example of situation where setting the active view from celx would be useful ?

Vincent,

If I can manage to control the views in the ways I want by using an appropriate obs prefix (of which I am not yet convinced) then the primary use of setting a particular view active would be to ensure that the user of a script doesn't mess up the states of the other views.

In an educational situation, to pick one example, one would like to ensure that the object of interest stays visible so that the student is looking at something appropriate.

[edit]
Another would be when one wants the user to be modifying selections and viewpoints in one view while the script changes the other views to match. At the moment, the active view is always the last one "split". Being able to specify which view is active would greatly simplify how one has to design the view splitting.
[/edit]

selden wrote:Vincent,

If I can manage to control the views in the ways I want by using an appropriate obs prefix (of which I am not yet convinced) then the primary use of setting a particular view active would be to ensure that the user of a script doesn't mess up the states of the other views.

In an educational situation, to pick one example, one would like to ensure that the object of interest stays visible so that the student is looking at something appropriate.

Yes, I Agree. The setactiveview method would be a useful addition.

selden wrote:At the moment, the active view is always the last one "split". Being able to specify which view is active would greatly simplify how one has to design the view splitting.

In my last example above, the active view is not the last one split, but the first view.
And I could choose which view to split (the second one in my example) using:

OK, I've added the setactive() method to observer in my "experimental" Celestia built, and it seems to work fine. One will be able to set the active view using the following celx/Lua code:



Then, I don't think that adding a getactiveview() method would be useful since

already returns the current active observer (and yet, the current active view).

selden wrote:Vincent,

If I can manage to control the views in the ways I want by using an appropriate obs prefix (of which I am not yet convinced) then the primary use of setting a particular view active would be to ensure that the user of a script doesn't mess up the states of the other views.

In an educational situation, to pick one example, one would like to ensure that the object of interest stays visible so that the student is looking at something appropriate.

Another would be when one wants the user to be modifying selections and viewpoints in one view while the script changes the other views to match. At the moment, the active view is always the last one "split". Being able to specify which view is active would greatly simplify how one has to design the view splitting.

Maybe what you really need is the ability to "lock" a view (or views) so the user can't change it?

- Hank

Hank,

That sounds like a reasonable additional feature, yes!

I am working on a project that would greatly benefit from this command. Has anything been done on this?? if so where can I find it?