-
-
Notifications
You must be signed in to change notification settings - Fork 792
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
Cannot find 1P/Halley in historical apparitions #3349
Comments
@gzotti did you used 1000 comets from master? |
No, 23.2 with the data file from its own directory. Did you change something later? (I don't usually build the SSE plugin, so just used the regular program.) |
Please attach data file |
You can use files from master or from 23.2. Result is the same. Does it work (does it list and let you you select any of the expected Halley entries) on Linux? |
@gzotti I can't reproduce the "group" issue on Windows too - what you did doing? |
Result: This only finds P/Halley from 989. When I set date to e.g. 1456, Halley (in its apparition of 1456) is not displayed. Line 3544:
|
Yes, I can reproduce this issue, and it's expectable due to the current implementation of search/matching the data in Search Tool.
I don't see these warnings in my log |
Then the search/match tool must be fixed accordingly. But I am afraid there is even more. In addition to not being found via search, I simply cannot find the comet visualized in 1456, when it was reportedly observed. The 1457 comets appear as expected. |
How was this ever planned to work? |
@gzotti please check the Search Tool/Lists/Comets - probably the issue is deeper that we think :( |
Maybe. The solution looks acceptable. Possible unique ID for comets with periodic designation is - "designation [perihelion year]" (e.g. "1P/Halley [1986]"). |
OK, Stellarium cannot load multiple celestial bodies with same names, so, we have possible 2 solutions: Both ways have a pluses and minuses and I prefer the way a) right now - we need update data file only (with revision the data) |
No need to update the data file! We have everything required to form a unique string for getID(). |
You're not right - please see filling |
Please see first part of changes in branch fix/3349 |
Indeed, here is a trap, and has always been there. Before the line we must test if secNameMap already contains such entry, and give a qWarning(). And in case of comets, where problems are now to be expected, you can just use |
It appears to me that most entries "iau_designation" for minor planets and the two Interstellar objects should be "discovery_code". Of course, IAU acknowledges progress in knowledge, so that they would use the refined designation like "(number) name". |
You’re wrong again, because many comets in ssystem_1000comets.ini file has joined designations as a name of the comet. We should split these data into separate parameters. |
I am speaking of the default ssystem_minor.ini. The 1000comets.ini has, as acknowledged in its header, still the old names, apart from the Halley entries. Please don't edit that now, I have just removed 6500 lines of default entries from there. After merge of #3371 it appears useful to update this file according to the latest developments. I will have a deeper look into this myself now and try to find a solution without even more extra data or variables. The object ID is still unused (or rather, equals englishName which is not unique here). Within the program, objects should be identified unambiguously with getID(), and to the user all labels can be shown in the Infostring, but it should be enough to use the combined name+date code. |
Hello @gzotti! Please check the fresh version (development snapshot) of Stellarium: |
Hello @gzotti! Please check the latest stable version of Stellarium: |
After the big renaming effort, the F3 search panel no longer can clearly indentify a comet in several apparitions.
Expected Behaviour
F3 search: "Halley" should list all known apparitions
Actual Behaviour
I can only find one entry for 1P/Halley which resolves to 989 N1, and another for P/Halley (1222) which does not load.
Steps to reproduce
Load ssystem_1000comets.ini, then search for Halley.
System
Logfile
If possible, attach the logfile
log.txt
from your user data directory. Look into the Guide for its location.The logfile indicates some message around a "stupid general group" which IMHO should not exist and indicates a bug.
Logfile of a previous run showed problems around a regular expression ('HALLEY(1456)'), but I cannot reproduce that now. I searched for "Halley", "Halley(1456)" and "Halley (1456)".
log.txt
The text was updated successfully, but these errors were encountered: