It is currently April 25th, 2024, 8:58 am

Astronomy Suite lua

Get help with creating, editing & fixing problems with skins
hardwired
Posts: 12
Joined: August 16th, 2022, 5:59 pm

Astronomy Suite lua

Post by hardwired »

I'm trying to make an astronomy skin that calculates values instead of using web parsing. Online I found the following skin:

https://www.deviantart.com/namestwister/art/Space-313902733

called 'Astronomy Suite' by NamesTwister. It seems pretty accurate, but it does not support leading zeros in rise/set times, and there's also a small bug: in very few cases, a rise/set time has a "XX:60" value, for instance, Jupiter rising at 19:60 hours. I used some substitudes to get leading zeros in, and also change all instances of :60 to :59. So it pretty much works right now, but I would really love to improve the accuracy (getting rid of the 60's) and get support for leading zero's by altering the LUA file.
User avatar
SilverAzide
Rainmeter Sage
Posts: 2605
Joined: March 23rd, 2015, 5:26 pm

Re: Astronomy Suite lua

Post by SilverAzide »

hardwired wrote: October 5th, 2022, 7:47 pm I'm trying to make an astronomy skin that calculates values instead of using web parsing. Online I found the following skin:

https://www.deviantart.com/namestwister/art/Space-313902733

called 'Astronomy Suite' by NamesTwister. It seems pretty accurate, but it does not support leading zeros in rise/set times, and there's also a small bug: in very few cases, a rise/set time has a "XX:60" value, for instance, Jupiter rising at 19:60 hours. I used some substitudes to get leading zeros in, and also change all instances of :60 to :59. So it pretty much works right now, but I would really love to improve the accuracy (getting rid of the 60's) and get support for leading zero's by altering the LUA file.
The problem with the ":60" times and the formatting has nothing to do with the Lua scripts. The problem is due to the horrible way the skin author is converting and formatting the times.

The Lua scripts are returning rise/set times in fractional hours; for example, 18.25 hours. The skin is then converting this to time using some awful logic I don't want to even pretend to understand, and substituting a ":" for the decimal. That's the reason you are seeing ":60" times, it's because of rounding of the seconds.

Rainmeter has a measure that already does the hard conversion work for you: the Time measure. The measure can take a timestamp (number of seconds) and converts it to a time formatted however you want.

Catch #1: It looks like some of the values being returned are negative numbers. It most likely means that this planet rose the day before today. The skin is not showing you this (and it probably should), because the times you see might be for the previous day, particularly if you see the rise time later than the set time.

Catch #2: This skin is not particularly accurate. If you go to https://in-the-sky.org/whatsup_times.php, the times shown in this skin are all off by anywhere from 5 to 20 minutes. Maybe that is close enough for you, it's your call. The moon measures are not working at all for me because of errors; I did not dig into this since it is a different issue due to the website this info is coming from.

So here's the simplest way to fix the Planets.ini skin for your format issues:
  1. Open the Planets.ini skin with your preferred text editor.
  2. Search for the measures that start with the letters "[con", as in [conSunrise],[conSunset], [conMercuryrise] etc.
  3. Replace the entire contents of the measure with this:

    Code: Select all

    Measure=Time
    Timestamp=((24 + [<parent measure>]) * 60 * 60)
    Format="%H:%M"
    DynamicVariables=1
    Note that the "[<parent measure>]" is the source measure for the data this Time measure is converting, so if this is the [conMercuryrise] measure, then you must use [Mercuryrise], which is the source measure you are converting.
  4. Change all the "rise" and "set" measures accordingly, then save and refresh the skin. Your times will have leading zeros due to the "%H" format string.
  5. Note that you don't need the 24 hour adjustment on the sunrise/sunset measure since those hours can never be negative, but for consistency I didn't change the formula. You can alternatively show something else if the times are negative (which indicate the previous day), but I'll leave that for you to decide.
Gadgets Wiki GitHub More Gadgets...
hardwired
Posts: 12
Joined: August 16th, 2022, 5:59 pm

Re: Astronomy Suite lua

Post by hardwired »

Thanks for your help and interesting explanations SilverAzide. As for the accuracy, I vaguely remember checking it years ago finding it to be within a five minute range of official online sources... Maybe a bad sample or memory, or maybe accuracy is different on different locations. I'm gonna improve my skin using your input anyway, and do some more testing.
hardwired
Posts: 12
Joined: August 16th, 2022, 5:59 pm

Re: Astronomy Suite lua

Post by hardwired »

SilverAzide wrote: October 5th, 2022, 10:04 pmCatch #2: This skin is not particularly accurate.
Hi Silverazide, in case you are interested, I been looking into this a bit further recently and I think it has to do with the fact that altitude is not considered in the calculations. For me its not much of a problem, as I live in the Netherlands at 0m alt (or -1.7m actually), and my rise/set times are very close to official astronomical sources of the nearest major Dutch city 25km/15mi east of here. I don't know where you live, but probably at hundreds of meters of elevation, giving less accurate results?

Still works well for me, thanks again for your help fixing it. :thumbup: