-
-
Notifications
You must be signed in to change notification settings - Fork 838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StelCore: reduce confusion around location signals #3180
Conversation
Great PR! Please pay attention to the following items before merging: Files matching
Files matching
This is an automatically generated QA checklist based on modified files. |
By the fact |
Do I understand that targetLocationChanged is "next location to be set, but with a transition animation". This means, LandscapeMgr should receive targetLocation to prepare a new landscape, but without changing location. And the actual location switch should not trigger other things. Currently the RemoteSync landscape switch seems to fail. |
Broke everything except one feature is not a good solution :) In Location dialog |
- Also docfixes - LandscapeMgr: I commented away a blocking test. I hope it does not break anything elsewhere...
We are breaking things in circles without knowing. Somebody fixes something, breaking others in the way. That needs a bit more study, and documentation of developers intents and observations. Not "not a good solution", but "not a good solution because...". Also, if a comment was "NOTE: Use ...", the next "fix" should not break what is written in the note and remove it. For example, probably the SpaceShipObserver::update(double deltaTime) should NOT set a new landscape when it has reached its target, when that has been done already because LandscapeMgr has received the targetLocationChanged signal. But maybe it is required because some other effect would else be missing. Still, landscape should probably be switched only once where needed. |
I now try 10s transitions for the solar eclipses (1-2s would be good for a soft move, this is just for demonstration). They are really bad, at around 1fps. Are there just too many computations (RTS, local circumstances, always requiring lots of extra computations...), or is there still some signal loop? |
D'oh! Found while testing #3187... I had a huge ssystem_minor.ini. With default file, it is just as I wanted it! *-/ Probably when auto-moving between locations, updating SolarSystem or at least MinorPlanets and Comets should be inhibited. It's usually just for a few seconds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! I forget about Qt::UniqueConnection
for signal/slot
Seems we need a fallback to "zero" landscape when going e.g. to Venus (as unattractive as that location may be) or other sites with no default planet landscape. |
This comment was marked as outdated.
This comment was marked as outdated.
In the Config/Tools tab we have "Auto-enabling for the environment" and "auto select landscapes". These may be better in the Location dialog or in the View/Landscape tab. Also, one sets landscape, the other both landscape and atmosphere. Seems somewhat redundant. |
Probably splitting onto 2 options - to follow atmosphere and landscape settings from the planet - and moving both into Location dialog seems acceptable to avoid misunderstandings |
468b213
to
24194a7
Compare
Conflicts have been resolved. A maintainer will review the pull request shortly. |
The auto-colored zero horizon works in the location dialog. Clicking e.g. into the desert now shows a sandy color sampled from the map. However, selecting best place from the solar eclipse list now shows the default green zero landscape. I could add a general coordinate->color lookup to StelLocationMgr. Before I continue, @alex-w , @10110111, @worachate001, do you agree on this feature? Should then any location change switch to zero+mapColor? (only for "flagLandscapeAutoSelection"). Probably even when storing zero as default landscape, it could then be re-colored on startup (or color stored in config.ini?). To continue on that, this could be extended to a LandscapeMgr.PolygonalLandscapeColor property that is applied to all polygonal landscapes. Maybe in the next round, however. |
Just tried going to the best point of a solar eclipse, and both atmosphere and ground were disabled. I enabled them, chose another eclipse, but again they get disabled. The same happens when I click on the map. If I enable atmosphere and ground and save settings, then they don't get disabled on location switch. Generally, the choice of color from the map sounds good. Though, if we appear in the ocean, the landscape could better be "Ocean", rather than "Zero Horizon". |
Have you enabled both "Auto-enable environment" and esp. "Auto select landscapes"? I must check (and probably fix) behaviour with these settings disabled. These switches should also move into the LocationDialog. The problem about using ocean is that the color of the ocean in our map is not singular, and the dark-blue may be used in small interior lakes as well. See the bright-blue Caribbean sea. If we had another 1-bit map or 4-bit land characteristics map, we could develop/define "typical" landscape panos with as close-to-zero as possible skylines. These could be used for flat snow fields and open grassland. But problems are of course mountaineous landscapes or forested areas... this is beyond the current PR. Another coordinate-based lookup could define time zones, but this may have to change occasionally. Another way to extend the location map would be a zooming option. I think you have added the larger map image. This is never fully utilized. Or we extend with the latest Qt feature, https://doc.qt.io/qt-6/qml-location5-maps.html. This could start as optional plugin on Qt6.5+. The map feature must remain available also for offline use of course. |
|
Cleanup debug messages
When clicking the map, I get the following message in the log:
And the Zero Horizon auto-selected landscape is black. This is on Qt 6. |
I also get this warning at the loading time:
Full log: log.txt. |
Huh? It works on Windows 10 64-bit, Qt 6.4.2. |
Maybe |
(Thanks, Ruslan!)
Yes, I usually run my test builds from the source dir (probably @Atque does the same), so these files are found. |
This warning originates from |
- also trim gray excess in a few images.
The connect(sender, SIGNAL(...), receiver, SLOT(...)) syntax is used almost everywhere simply by tradition. |
This should change just as |
Yes |
|
Missing include, let me check |
Sorry, I seem to have missed a few includes because of PCH. |
Hello @gzotti! Please check the fresh version (development snapshot) of Stellarium: |
Hello @gzotti! Please check the latest stable version of Stellarium: |
Description
StelCore has two signals after a location change.
Those were likely introduced with different intentions in mind, but now are both emitted. Their documentation was lame.
Several other components are connected to the signals or emit them by themselves, with possible side effects.
See #3173 and see difficulties around the "best eclipse sites".
IMHO this area of location settings needs to be checked thouroughly and slimmed down or at least made more intuitive.
These points are to be considered
Fixes: #3173 and other possible signal loops or unexpected results or non-results.
I invite @alex-w and @10110111 to collaborate on that.
Screenshots (if appropriate):
Type of change
How Has This Been Tested?
Test Configuration:
Checklist: