Planning tools is not updating the time of the target. I have three screenshots, 8th December, 11th DEcember and 14th December for the same target and the time has not changed
OS:Windows 10 x64 Ver:3.1.0.403
I have been carefully monitoring the altitude lock since the problems seen in the BETA, and it appears that the altitude is not updating
As you can see from the following screenshot from the 8th December, I had set a time of 5 minutes after Transit of 19:46 which resulted in an Altitude of 79.8 Degrees
On the 11th December, I checked the target again, the time was still reporting 19:46 and an altitude of 79.8 degrees however the tarnsit time was now 19:35 so in theory it should have adjusted the start time to 19:40, here is the screenshot from the 11th December
I have checked again today, leaving it a few more days, and again it still reports a start time of 19:46 and an altitude of 79.8 degrees, however I have noticed that the end time has changed to 00:22 from 00:46
Thanks for all the details. I think the only other thing I need to know is what happened between each of those screenshots. For instance… was SGPro left open the entire time, did you close it and open it between days, etc.
Also, logs would be good here… I am logging a lot of info on this feature and I’m curious if the end time calculation is failing silently.
Ok, I have made a couple changes, but none that I suspect will alter this behavior. The primary purpose of changes for planning tools in 3.1.0.411 is to emit some better logging in an area of calculations that I think are to blame, but I am unsure. At any rate, they will allow me to perform the calculation exactly as they are being performed on your machine. Up in a few minutes…
Left it for a few days before firing it up again, as you can see again, Transit is now 19:13 but what is really interesting is that when I set 19:32 the other day, it is now saying 19:38 for 79.8, so rather than it decrease the start time to what should be 5 minutes past transit, it actually increased the start time
ok… well I see the problem now at least. I am unsure how to fix it at the moment without having the computer take a year to do it… the problem is that the current algorithms are imprecise when a start or end time exists where the slope is near non-existent. Will need to think a little on this… the math is pretty easy here, but I’m afraid that a lot of machines that people relegate to outside astro-computer might not be able to handle it all that well…
I’ve noticed something else tonight…Whilst a target is running, when you click on the settings for that target, it adjusts the end time to the time when you clicked on settings look:
I manually change the end time to say 20:20, then click OK, click back on settings and it changes it back to the current time 20:16 after changing it to 20:20