Items that should be tested:
- Cameras and other equipment that you rely on, especially ZWO, since we had an issue last time.
- INDI Webcam, since we had an issue with that one last time too.
- The new terrain feature, since it is brand new
- Scheduler, since that has had problems in previous builds due to DBus issues.
- INDI Server and Plate solving since those are complex systems
- Whats Interesting and Mount Toolbox since they are based on QML and sometimes that causes build issues.
- Anything else you might find
I just tried this on my MacBook pro running 11.2.3. Seems generally fine, but I'm especially interested in the terrain feature.I made a terrain.png using the Google StreetView on iPhone, and it imports fine into KStars. But my old "Artificial Horizon" is in there as well. Very disconcerting!
The various interface elements for the new Terrain feature and the older Artificial Horizon feature are disjoint in the GUI so it's weirdly difficult to manage them together. I had to click around quite a bit first in KStars and then in Ekos Settings to find all the relevant options. After some fiddling, I was able to deselect Artificial Horizon and get rid of the red-shaded polygon overlay that closely tracks my terrain image.
Once I got rid of the old horizon polygon and turned off the downsampling, the terrain feature is amazing!
Thanks to both of you for getting this done. I am very eager to set up similar terrain images for my dark sites, and especially to have the Scheduler become aware of the horizon (I guess in 3.5.4).
Scott--thanks for testing the terrain feature. I guess, on the bright side, since you had an artificial horizon already there, it was easier to set your azimuth correction. I have set a keyboard shortcut to turning that artificial horizon on/off.
The terrain downsampling is mandatory if you're using a slower CPU, like an Raspberry Pi, which is why I defaulted it to 4, but I guess if you're using a fast MacBook, it could work with less. The real issue is that the KStars display code doesn't use the GPU. That apparently is a big project, and not something I'm familiar with.
I have also reworked the artificial horizon feature to get it ready for scheduler integration. The nice thing is now you can now edit your artificial horizon by clicking on the skymap while viewing your terrain image. E.g. see invent.kde.org/education/kstars/-/merge_requests/263 That work should also be in the release you're testing. I even have some artificial horizon / scheduler integration working in my private code. However, releasing the scheduler integration is on hold until the scheduler folks and I add more testing to the scheduler to make sure nothing breaks when new features are added. I'd like to add it in the next release, but want to make sure I work with them to make sure nothing regresses.
Thanks for this version. Unfortunately, it dos not connect with my devices, so I can't test it. I guess some dyn.libraries are not compatible with my current OSX (10.13), since they don't even load when in *not*autoconnect mode. Specifically, I was testing LX200Onstep with a QHY163M. Some other drivers seem to load fine, though.
Well this is really the point of the beta, to see if there were any build issues. Now if there are actual issues with the drivers, we should work on that later, but if it is an issue with the current build, we should address it now. Does the last release work with the same devices you are trying to test?
All fine here on Catalina 10.15.7, just one quirk on solving. At least all drivers work (Moonlite, G2-8300, EQMOD, DSI Pro III). Cameras work, EQMOD works, focuser too.
Now it needs a real test but the weather has been horrible, rainy rainy.... I am connecting to a remote lubuntu (x64 Core2Duo Mac Mini) server.
I Had to downgrade libindi/indi-bin because some drivers did not work (EQMOD and G2), but that's a lib problem not KStars.
That already happened before. Drivers are the latest versions.
As I said with the solving, the first time I used it, it crashed KStars. Can't repeat the same.
Will do a proper test when possible. Thanks for the build!
(PT) SC@ROS Observatory
TS 6" F4 Newtonian / Canon 550D / GPU CC / Datyson T7M / Arduino Moonlite DC Clone- HEQ5 Pro
Orion 120ST / Explore Scientific 80APO / TSAPO102Q Sextuplet / G2-8300FW5 / ES FF 2" / ASI120MM - Arduino Moonlite DC Clone - Vixen GPD2 www.flickr.com/photos/139335144@N03/
Terrain seems to work along with the horizon changes. However the image looks pretty pixelated - much more so than when I use the same image in kstars on rPi. It seems like it was the speedup settings which needed to be deselected although it still isn't as sharp as the linux version. Used Google Street view on an iPhone 11 to make the panorama and then used gimp to erase the sky over transparent background. Really fast and painless, it seemed to get the alignment automagically and the horizon profile I painfully measured by scanning my scope around with a reticle eyepiece pretty much aligns with the panorama horizon.
Borg 107FL, Astro-Tech AT130EDT; Rainbow Astro RST-135 SkyShed Pier; QHY600PH Chroma LRGBHa; QHY5-III-462C; IR Guiding WO Uniguide 50 & ASI290mm mini; ASUS PN51 ubuntu, kstars/ekos, & firecapture; Pegasus PPBA; Stellarvue Optimus + WO Redcat, Skyguider Pro RT90C, rPi4/stellarmate
Terrain works fine with my setup also. I'm missing an action to toggle terrain on/off, but I can live without it.
I have found that the problematic indi driver that also fails in 3.5.2 is libqhyccd.21.dylib; it is the one that has set minos to 10.15 and I'm on 10.13. I recall that this already happened in a past version with the previous version of the QHY indi driver...
I think I remember that issue from before yes. I don't build the dylib for QHY, that is done upstream. All I get is the binary file. So we need to ask Jasem or QHY to build that with the correct settings so it works on 10.13. Then we can rebuild with it.