Comment 6 for bug 1068529

Revision history for this message
Axel Hoff (0k-axel) wrote :

Hi Ross (hope that's your first name and not the last name, I don't want to be impolite...),

thanks for your comment. Of course you're right and I've got messed things up, just too much testing on the fly...

So the core.moveToAltAzi function is incorrect just as you stated for altitude of +/-90 only. I've corrected the script as you suggested and the logfile shows that stellarium will show altitude=90 and azimuth=270 regardless from the azimuth given to core.moveToAltAzi.

Nevertheless, there remain two other open questions with core.moveToAltAzi:

1. The script test_altazi3.ssc (attached) will produce the correct movements of view in stellarium. But the result of the core.getViewAltitudeAngle and core.getViewAzimuthAngle is correct only after the second call to core.MoveToAltAzi (cf. log file to script test_altazi3). The movement of view itself is done correctly already after the first call to core.MoveToAltAzi . This is in my opinion another bug of this function family (which I incidentally found by testing on your bug report), I don't know whether one should start a new bug report just for this...

2. When a script runs without explicit pause statements - core.pauseScript() as in my first script or core.wait(n) as in test_altazi3.ssc - not all movements due to core.MoveToAltAzi calls are executed by stellarium. When I run the script test_altazi4 (see attachment) starting from the default view (azimuth=180), only a smooth movement from azimuth=180 to azimuth=330 is shown by stellarium, but the initial movement and the movement from azimuth=0 to 180 is not shown and there are no labels printed at all. In this case, the output of the functions core.getViewAltitudeAngle and core.getViewAzimuthAngle does not follow the motion of the view at all. Furthermore, when calling the script again (with azimuth=330 as starting position), no movement of view at all can be seen.

I'm not sure if point 2 is considered as a bug or if this behaviour is by design (like e.g. in MATLAB, where no plots at all are done without explicit or implicit pause commands while a program is running...). If it is by design, a little hint in the API description could be helpful...

Thank you

Axel