Skip to content

** VERSION 1.3.2 CHANGELOG

(1) BUG – Ok folks, Murphy’s law hits again! Where’s pretty sure that a bug can be found? Obviously right in the place you didn’t test because you thought it safe. Well, I’m talking about the form where rising and setting of reference stars are computed. When a circumpolar or not visible star is found, all following stars appear in the same state. Give a look below. We are in Paris, not at the North Pole. Something’s going wrong 🙂

Of course the issue has been solved. Furthermore, in order to give a more greyish look to all similar windows (so trendy lately) this is the new appearance:


(1A) – BUG : when a “Tracking on coordinates” is active and a “Tracking on Object” is selected, the command is executed but tracking data (upper left) keep on showing Tracking on Coordinates info. SOLVED.


(2) While working to the bug mentioned above, I thought that giving the opportunity to change time reference directly into the window could be a wise move. The image below shows an example. We are in Nook, the capital of Greenland, and as you can see, we have here a more complicated situation than usual in terms of what’s never visible or circumpolar.


(3) Original Natural Earth Data make some confusion about Italian lakes Maggiore and Como. In few words the second one is missing, so I had to create polygonal data by myself (boring task indeed) and include them into my data.


(4) Small adjustments to the Canon of Solar Eclipses, mainly about non-central eclipses now divided into NOC TOT and NOC ANN (formerly NOC T/A in general). Here’s some numbers about my Canon:

UrukFSP Canon of Solar Eclipses (v. 14)
From : BCE 12782 Jul 01
To : CE 16973 Sep 25
Number of Events : 71238

Totals : 19011 (26.8%)
Annulars : 23333 (32.8%)
Hybrid : 3152 (4.4%)
NOC Tot : 141 (0.2%)
NOC Ann : 422 (0.6%)
Partials : 25179 (35.2%)

So far Non-Central eclipses were not handled, no path was computed. Actually a path exists, even though this type of solar eclipses has not a central line, and one of the limits (N or S) is missing. Let’s see why.

Image1

Image1 shows a non-central eclipse (BCE 2826 Oct 21, Annular) at its maximum. The center of lunar shadow will never “touch” the Earth’s surface, therefore a central line is not defined and a southern limit neither.

Image2

Image2 shows how the Path Descriptor appears in this case. Only a L2 limit is defined (Northern limit in this case), and Image3 represents the graphical result on Earth’s surface, typically a sort of “dome”. This category of solar eclipses is pretty rare (0.8%) , happening in areas not far from the geographic poles.

Image 3

(5) Location Default Archive: modified the name of some European cities (still in Italian) and added some new Chinese locations.

(6) When using asteroids downloaded by MPC now 8274 minor planets have a diameter (Km) associated. This value has been taken from the JPL minor planets archive.

(7) SE and LE navigators have a new type of control where the Year can be inserted. I didn’t like the behavior of the previous one, different with Windows, MacOS and Linux. Also zoom controls for Stereographic View have been added.

(8) Added a couple of sites about Weather into the “Useful Sites” menu.

(9) Canon of Solar Eclipses: eclipse happened on BCE 2805 Apr 04 was corrected from NOC ANN to PARTIAL.

Last minute changes:

(10) Data of Central Line now distinguish between SDRg (geocentric) and SDRt (topocentric). SDR is the ratio Moon Semidiameter / Sun Semidiameter. If this value is less than 1 the eclipse will be annular, else total. When analyzing a HYBRID eclipse, the value to be monitored is the topocentric one, being the Moon so close to the Earth’s surface.

(11) The button [ CL > CRLoc ] has been added. When an eclipse is linked and a central line exists, if we change the calculation time the CURRLOC will be set to the instantaneous central point instead of eclipse G.E.

(12) Precession model is always Vondrak 2011, so I used that position into the Status Bar to show if a solar eclipse is linked or not.

(13 Input boxes that need an Enter key in order to activate a keyboard inserted value show an [ Enter ] icon as a reminder.

Right click to enlarge in new panel


Closed activities for version 1.3.2. It should be out on next week.

8 thoughts on “** VERSION 1.3.2 CHANGELOG”

  1. Hi
    I have no idea if this problem is related to the bug regarding RTS of stars of historical interest.
    UrukFSP version 1.3.1 is working fine but when I click on Ephemeris / stars RTS
    this message is displayed : Invalid floating point operation. Press OK to ignore and risk data corruption. Press abort to kill the program.
    If I press OK, for instance using today 4 March, a window is displayed with the following stars: Sirius, Vega, Arcturus and Rigel. Of course if I press abort I kill the program.
    I try with 4 March 2023 BC. Same problem. When I press OK, only Sirius is displayed.
    Now if I press Central day, the message Invalid floating point operation is displayed.
    Same result when I press Previous days and Next days.
    Regards

  2. Hi

    By trial and error, I have found that as soon as the specified latitude reaches a value greater than 43.979 N, the window you refer to appears. The author will probably have to fix this.

    Regards

  3. Hi
    Thank you very much Kamil.
    You are right.
    If the latitude is 43° N, no error message.
    If the latitude is 44° N, the error message is displayed.
    Now for South latitude 44°, no problem.
    Regards

  4. Author

    Hi guys,
    the runtime error rises when a first circumpolar star is detected. Calculating the hour angle at culmination of a circumpolar star is not a good deal as requires a function ArcSin() call with an argument > 1. In Windows we have an exception but when running Linux or MacOs the compiler doesn’t stop program execution, returning a NAN value. That’s why the image above shows Capella as circumpolar (correctly) and the remaining stars in a wrong state, as if nothing happened. That’s evil! No compiler should do this, it’s a great way to hide bugs!!!!
    This crappy behaviour forced me to always carry out preventive checks on potentially dangerous mathematical operations, except here, where I forgot to put a check before the ArcSin() call.

  5. Hi
    I just downloaded version 1.3.2. At first sight everything works perfectly. I haven’t tested all the new improvements yet but thank you very much for the great work.
    Best regards.

Leave a Reply

Your email address will not be published. Required fields are marked *