If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-12-29
No problem Alex, happy to help catch it
I see the changes you've made to the StelMainScriptAPI.cpp. Is there any way I can implement them into 0.12.4, or is it a case of waiting for release of the next version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can add this patch to source code for Stellarium 0.12.4 and rebuild it from source code. Or you can add workaround for current wrong values in script.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-12-29
Honestly I don't think I can work out how to build from source, I read the instructions but they don't make a whole lot of sense to me, not really my area... :)
No problem, I guess for the time being I can enter the azimuth values I need to know manually. I did try to work out an Excel formula that could compensate but again, getting beyond my knowledge
Anyway, the bug's been taken care of at your end now so fix will be in next public release (I assume), I'll eagerly look forward to that!
Thanks again Alex
Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-01-02
Hi Alex
Just a quick follow up on this...
So I got brave and did actually work out how to compile 0.12.4 from source and have successfully produced a libStelMain.dll for 0.12.4 32-bit Windows that includes the fix for the azi/alt figures. Works great, script / core.getSelectedObjectInfo() is now reporting correct numbers and my project is well under way. Would be happy to send this file to you if it's of any use to you or anyone else.
Don't know if this might be important to you, but in the updated StelMainScriptAPI.cpp, there is reference to a variable 'az' (lines 735-848) - I could only get it to compile successfully if that variable was 'azi', as it was before the fix.
Thanks, Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all!
I think I've come across a bug with getSelectedObjectInfo(), specifically the figure it reports for a selected objects azimuth.
For the record I'm using 0.12.4 64bit on Win 7 Home Premium 64 bit. Also tried with the 32bit version of Stellarium but no difference.
There's a couple of examples below, but if you run the script in the console with an object selected, you'll see similar strangeness
This is the script:
Observer Location: London
Date: 2013-12-11 04:30 UTC
Target: Arcturus
Azimuth: +95° 54' 54"
Altitude: +29° 18' 57"
These are the figures shown in the information panel, top left of screen - all good
And when I run the script, the numbers that come out are haywire.
Script Azimuth: 84.08502474297381 (84° 05' 06.09")
Script Altitude: 29.31577612575129 (29° 18' 56.793")
The altitude is correct, but the azimuth is not.
It only makes sense with the formula:
180° - Actual Azimuth = Reported Azimuth
e.g.
180° - 95° 54' 54" = 84° 05' 06.09"
This is only true of objects with an actual azimuth of between 0° and 180°. Things get stranger if you go past 180°....
====================================
Observer Location: London
Date: 2013-12-11 04:30 UTC
Target: Pollux
Azimuth: +236° 26' 14"
Altitude: +57° 00' 46"
Script Azimuth: -56.43734108748945 (-56° 26' 14.4276")
Script Altitude: 57.01283417030654 (57° 00' 46.2018")
Again altitude is correct, but the situation with the azimuth is worse. Now the formula appears to be
Actual Azimuth - 180° = (-)Reported Azimuth
e.g.
236° 26' 14" - 180° = -56° 26' 14.4276"
You see what happened? It took the actual azimuth, subtracted 180° to get a result, and then made the result negative!
I also noticed this behaviour with getObjectInfo
Any input greatly appreciated!
Many thanks
Richard
This is bug - thanks for report!
Bug report - https://bugs.launchpad.net/stellarium/+bug/1264805
A fix has been committed as revision 6426 of the trunk branch in Stellarium's Bazaar repository at Launchpad:
http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/6426
No problem Alex, happy to help catch it
I see the changes you've made to the StelMainScriptAPI.cpp. Is there any way I can implement them into 0.12.4, or is it a case of waiting for release of the next version?
You can add this patch to source code for Stellarium 0.12.4 and rebuild it from source code. Or you can add workaround for current wrong values in script.
Honestly I don't think I can work out how to build from source, I read the instructions but they don't make a whole lot of sense to me, not really my area... :)
No problem, I guess for the time being I can enter the azimuth values I need to know manually. I did try to work out an Excel formula that could compensate but again, getting beyond my knowledge
Anyway, the bug's been taken care of at your end now so fix will be in next public release (I assume), I'll eagerly look forward to that!
Thanks again Alex
Richard
Hi Alex
Just a quick follow up on this...
So I got brave and did actually work out how to compile 0.12.4 from source and have successfully produced a libStelMain.dll for 0.12.4 32-bit Windows that includes the fix for the azi/alt figures. Works great, script / core.getSelectedObjectInfo() is now reporting correct numbers and my project is well under way. Would be happy to send this file to you if it's of any use to you or anyone else.
Don't know if this might be important to you, but in the updated StelMainScriptAPI.cpp, there is reference to a variable 'az' (lines 735-848) - I could only get it to compile successfully if that variable was 'azi', as it was before the fix.
Thanks, Richard
I think the provision of separate libStelMain.dll does not make sense