Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
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:
TargetData = core.getSelectedObjectInfo();
TargetName = TargetData["localized-name"];
TargetGeoAzi = TargetData["azimuth-geometric"];
TargetGeoAlt = TargetData["altitude-geometric"];
core.debug(TargetName + "\t" + TargetGeoAzi + "\t" + TargetGeoAlt);
Observer Location: London
Date: 2013-12-11 04:30 UTC
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
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°....
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
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!
You seem to have CSS turned off.
Please don't fill out this field.
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:
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
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.
I think the provision of separate libStelMain.dll does not make sense