wtf? sorry for russian

I'm running an older PC with Windows 10 and an ATI Radeon HD 3200 Graphics card. I launched Stellarium in Angle Mode with previous versions and do so with 17.0 also, and it worked fine previous to the upgrade. Now when I launch Stellarium my toolbars are blank. I can use the keyboard shortcuts to bring up thinks like the Azimuth sphere, and when I do click in the toolbars where I think a tool should be I do momentaril get the tool up in the screen but it quickly disappears. When I launch Stellarium normally, (not in Angle mode ) everything is working fine, but when I exit out my display becomes "garbled" and extremely pixelated and I'm forced to restart the pc before it degenerates so badly my display is completely garbled. I know this is an issue with my older graphics board but I was wondering if you have any suggestions. Thanks for a great planetarium software.
log.txt

Stellarium 0170 crashes for me every time I go to the morning of January 31st and look at the Moon while eclipsed. The instant the Moon is observed, the program crashes 100% of the time.

Actually crash for any lunar eclipse.

log:
2018-01-28T14:53:08
Operating System: Windows 10
Product Name: Windows 10 (10.0)
Compiled using MSVC++ 14.0 (Visual Studio 2015)
Qt runtime version: 5.9.3
Qt compilation version: 5.9.3
Addressing mode: 64-bit
Total physical memory: 32589 MB
Available physical memory: 20847 MB
Physical memory in use: 36%
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Processor speed: 2808 MHz
Processor name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
C:\Program Files\Stellarium_0.17.0\stellarium.exe --user-dir=C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0

[ This is Stellarium 0.17.0 - http://www.stellarium.org ]
[ Copyright (C) 2000-2017 Fabien Chereau et al. ]

Writing log file to: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\log.txt"
File search paths:
0 . "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0"
1 . "."
Config file is: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\config.ini"
Default surface format: QSurfaceFormat(version 2.0, options QFlagsQSurfaceFormat::FormatOption(), depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DefaultSwapBehavior), swapInterval 1, profile QSurfaceFormat::OpenGLContextProfile(NoProfile))
Desired surface format: QSurfaceFormat(version 2.1, options QFlagsQSurfaceFormat::FormatOption(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DefaultSwapBehavior), swapInterval 1, profile QSurfaceFormat::OpenGLContextProfile(NoProfile))
StelGLWidget constructor
StelGraphicsScene constructor
initializeGL
OpenGL supported version: "4.5.0 - Build 22.20.16.4836"
Current Format: QSurfaceFormat(version 4.5, options QFlagsQSurfaceFormat::FormatOption(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 1, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile))
StelMainView::init
Detected: OpenGL "4.5"
Driver version string: "4.5.0 - Build 22.20.16.4836"
GL vendor is "Intel"
GL renderer is "Intel(R) HD Graphics 630"
GL Shading Language version is "4.50 - Build 22.20.16.4836"
GLSL Version Number detected: 4.5
GLSL version is fine, we should not see a graphics problem.
Cache directory is: "C:\Users\kajaj\AppData\Local\stellarium\stellarium\cache"
Sky language is "ar"
Planetary features language is "ar"
Application language is "ar"
Loading Solar System data (1: planets and moons) ...
Loading from : "./data/ssystem_major.ini"
Texture "./textures/earth-shadow.png" does not exist
Loaded 77 Solar System bodies
Loading Solar System data (2: minor bodies)...
Loading from : "C:/Users/kajaj/AppData/Roaming/Stellarium_0.17.0/data/ssystem_minor.ini"
Texture "./textures/earth-shadow.png" does not exist
Loaded 101 Solar System bodies
File ssystem_minor.ini is loaded successfully...
Loading nomenclature for Solar system bodies ...
Loaded 15449 / 15454 items of planetary surface nomenclature
Loading star data ...
"Loading .\stars\default\stars_0_0v0_7.cat: 0_0v0_7; 4979"
"Loading .\stars\default\stars_1_0v0_7.cat: 1_0v0_7; 21806"
"Loading .\stars\default\stars_2_0v0_7.cat: 2_0v0_7; 150850"
"Loading .\stars\default\stars_3_1v0_4.cat: 3_1v0_4; 425807"
Finished loading star catalogue data, max_geodesic_level: 3
Loading scientific star names from ".\stars\default\name.fab"
Loaded 4506 / 4506 scientific star names
Loading variable stars from ".\stars\default\gcvs_hip_part.dat"
Loaded 6916 / 6916 variable stars
Loading double stars from ".\stars\default\wds_hip_part.dat"
Loaded 16412 / 16412 double stars
Loading cross-identification data from ".\stars\default\cross-id.dat"
Loaded 108338 / 108338 cross-identification data records for stars
navigation/preset_sky_time is a double - treating as jday: "2451514.25001"
Loading DSO data ...
[...] "Stellarium DSO Catalog, version 3.3 (standard edition)"
Loaded 90416 DSO records
Loading DSO outline data ...
Loaded 63 DSO outline records successfully
LandscapeMgr: initialized Cache for 100 MB.
Loading star names from ".\skycultures\western\star_names.fab"
Loaded 847 / 847 common star names
Loading DSO name data ...
Loaded 1004 / 1021 DSO name records successfully
WARNING - No position data for 17 objects: "PGC 621, PGC 2345, PGC 2906, PGC 2907, PGC 14098, PGC 23521, PGC 28759, PGC 29167, PGC 34658, PGC 42102, PGC 54559, PGC 59117, PGC 73957, PGC 95597, PGC 100170, PGC 100170, PGC 119230"
Loaded 88 / 88 constellation records successfully for culture "western"
Loaded 85 / 85 constellation art records successfully for culture "western"
Loaded 88 / 88 constellation names
Loading constellation boundary data ...
Loaded 782 constellation boundary segments
Error in Asterism "TA6" : can't find star with coordinates 2.14697 / 8.55097
ERROR reading asterism lines record at line 63 for culture "western"
Loaded 53 / 54 asterism records successfully for culture "western"
WARNING - asterism abbreviation "TA6" not found when loading asterism names
Loaded 43 / 44 asterism names
stel.OpenGLArray: Disabling VAO usage because of Intel driver bugs
stel.OpenGLArray: Vertex Array Objects are not supported on your hardware (this is not an error)
Initializing basic GL shaders...
Creating GUI ...
Loaded plugin "Exoplanets"
[Exoplanets] Version of the format of the catalog: 1
[Exoplanets] loading catalog file: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\modules\Exoplanets\exoplanets.json"
Loaded plugin "FOV"
Loaded plugin "MeteorShowers"
MeteorShowersMgr: Loading catalog file: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\modules\MeteorShowers\showers.json"
Loaded plugin "Novae"
[Novae] version of the catalog: 1
[Novae] loading catalog file: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\modules\Novae\novae.json"
Loaded plugin "Oculars"
Ocular plugin - press Command-O to toggle eyepiece view mode. Press ALT-o for configuration.
Oculars::validateIniFile ocular.ini exists at: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\modules\Oculars\ocular.ini" . Checking version...
Oculars::validateIniFile found existing ini file version 3.1
Loaded plugin "Satellites"
[Satellites] loading catalog file: "C:\Users\kajaj\AppData\Roaming\Stellarium_0.17.0\modules\Satellites\satellites.json"
Satellite has invalid orbit: "OSNSAT" "41939"
Loaded plugin "SolarSystemEditor"
Using the ssystem_minor.ini file that already exists in the user directory...
Initializing planets GL shaders...
Got location "Riyadh, Ar Riy??, Saudi Arabia (24.6537, 46.7152; Asia/Riyadh)" for IP "93.168.232.180"

Bug Description

I noticed in Stellarium 14.1beta (and back to Version 12) there is a problem with the proper motions.

If you look at Alpha Centauri, the future motion is moving northwards at a PA of about 345 degrees, however that is not possible. If the HIP2 parallax is -3679.25 and +473.67 mas/year, the position angle should be about 277.3 degrees, calculated as tan-1(-3679.25/473.67) in Quadrant 4. I.e. It should be heading just little north of Beta Centauri, not northwards!.

Yet if you select the star HIP 57367 (11.5 magnitude) in Musca, which has an equally large proper motion but is in the opposite direction. I.e. +2663.91 and -347.38 mas/ yr, the position angle is +97.4 degrees.

The motion in Stellarium is seemingly wrong for Alpha Centauri but appears roughly correct for HIP 57367.

I also checked , being roughly correct.

Arcturus, pm. -1093.99, -2000.16 mas/yr, moving in PA 208.7 deg.
Sirius , pm. -546.01, -1223.07, PA 204.8 deg.
Barnard's Star -798.71, 10337.2 mas/yr, PA 353.6 deg.

1. Please check the calculations when adding proper motions.
2. Could someone point out the C++ file that does these proper motions calculation?
3. Are the proper motion calculated independently of the precession, as some stars move as arcs against the background stars in Stellarium rather than straight lines? (I.e. Follow the motion of HIP 57367.)

Alpha Centauri is a critical star because of its brightness and being the closest star, and educationally is important to many who us Stellarium. It is critical that something is done to fix these apparent errors.

Kind regards and appreciation to its solution,
And hope this is useful.

Andrew

I use Mac OS X 10.7.5, ATI Radeon HD 4670 256MB graphics

Note 1 : it is possible there is something wrong in solving the tan ambiguity here, where the PA is being calculated incorrectly.

Note 2 : As previously noted, SIMBAD gives the following proper motions;

Alpha Centauri : -3608, 686 mas/yr [PA 280.8 deg]
http://simbad.u-strasbg.fr/simbad/sim-id?Ident=alpha+cen&NbIdent=1&Radius=2&Radius.unit=arcmin&submit=submit+id

Alpha Centauri A : -3679.85, 473.67 mas/yr [PA 277.3 deg]
http://simbad.u-strasbg.fr/simbad/sim-id?Ident=%403396054&Name=*%20alf%20Cen%20A&submit=submit

Alpha Centauri B : -3614.39, 802.98 mas/yr [PA 282.5 deg]
http://simbad.u-strasbg.fr/simbad/sim-id?Ident=%403396297&Name=*%20alf%20Cen%20B&submit=submit

As the stars are labelled individually, the two components appear to diverge and are moving wider apart, rather than towards their common mutual shared motion.

The HIP2 file should be modified to either Alpha Centauri's mean motion of -3608, 686 mas/yr [PA 280.8 deg], or the mean motion of AB -3648.62, 638.33 mas.yr (HIP2) [PA 279.9 deg]. This number should be assigned to both the A and B stars in Stellarium's HIP2 star file.

Original report with detailed dicussion

https://bugs.launchpad.net/stellarium/+bug/1527856

Bug Description

I would like a new feature to be added in order to plan and drive mosaic shooting sequences.

I guess this feature should be added to the ocular plugin or to the telescope plugin, not sure about which one.

A series of rectangles should be overlayed and centered on the current view, sized and scaled depending on the current zoom level and sensor pixel size / resolution.

The rectangles should be slightly overlapping (20%, possibly configurable) and the number of rows and columns should be calculated depending on the sky area the user is interested in, expressed in arcmin or arcsec.

Upon "start" button being hit, the plugin should send the telescope (via ASCOM or currently selected interface) the commands to position at the centers of the rectangles, iterating through all the rectangles by columns and rows. The plugin UI should present a button to command going to the next rectangle, allowing ccd or webcam imaging to take place.

Movement to the next rectangle should be expressed in ra/dec offsets initially calculated for the whole matrix. Being the mount continuously tracking, the plugin should query the current position, apply the offset and ask the mount a goto to these new coords.

All needed selections and parameters should be saved to disk, same for the "shooted" rectangles in order to be able to suspend the imaging session and start again on different nights.

I recognize this is a major addition, but IMHO this feature would be appreciated by many of us :-)

Thank you for reading all of this :-)

Cheers,
Mario

Original report

https://bugs.launchpad.net/stellarium/+bug/987360

I am trying to view the total lunar eclipse in Jerusalem on April 14th in 2033. Shortly after the moon rises, right about at the time the eclipse should begin, the program crashes. I have attempted to run it 5 times and it crashes at the same point every time. This is actually the main reason I downloaded the software so I'm hoping it can be fixed. I am running Windows 10. I tried downloading both the 32 bit and 64 bit versions and the same thing happened with both versions.

Thanks.

Original report: https://sourceforge.net/p/stellarium/discussion/278769/thread/42b17b79/

Hello, I am still using version 0.12.5

Last night I took an image of the area around 119 Tau and noticed there was a mag 9.7 star on Stellarium which was not on the photo. Simbad confirms there is no star in that position. So is it possible to delete a false star to avoid confusion? I include a screenshot.

I can confirm the issue in the star catalog.

January 31st at 21:21 stellarium crashes every time without fail.

Since the update, the sky is pink during the day

If I understood how your HTML was converted into POT (intltool?), I might try a pull request, but hopefully the attached file is adequate for action.

I'd like to propose i18n enhancement of the stellarium-remotecontrol.pot file by adding these wiki-links as translator comments in the HTML in such a way that they are parsed into the POT file.

stellarium-remotecontrol_i18n_enhancements.txt

Are there any plans?

I would be interested in it.

Hi,

The program languages for zh_TW (臺灣正體中文) and zh_HK (香港繁體中文) do not work on version 17.0. It seems we only have correct sky culture languages of zh_TW and zh_HK.

Warmest Best,
Freeman

First, brilliant program, which has aided me greatly in my current research. LOVE IT. That said, I have uncovered a minor glitch. My work concerns Ancient Greece. When you move into negative dates (BC/BCE) [eg -432], the years regress by one. In other words, Julian days prove correct with regard to what happens in the sky, but it renders the date one year too early. id est, 1563101.370900 renders as 16 July 433, when it is actually 16 July 434 BCE.

Improve approximation of the typical light curves to the real data for different types of supernovae

Downloaded version 17 of Stellarium and installed on two Macs today ... one running Yosemite the other El Capitan.
App opens fine, but it crashes EVERY TIME I pan to a new view direction ( by Click-Dragging the mouse.) Does this on both Macs and both OS's.

Version 15 was working fine. Guess I will be downgrading till this is fixed.

I wanted to check how the Sun will go with time, using the Astronomical calculations_→_Ephemeris facility, but it appears that the markers are slightly off the target. For details see the screenshot below. I've enabled azimuthal grid to be able to see that Altitude in the selected line doesn't match actual altitude in the scene.

Any attempt to view the Moon during the times of 1/31 eclipse causes Stellarium to crash. I'm using EST. I can advance the time to 5:51 or later, 60 degree f.o.v. as long as the Moon is not being displayed. Panning to the west, when the Moon becomes visible, the program to crashes. Or, if the Moon is in the field of view, advancing the time beyond 5:51 will cause the program to crash.
I knew I wouldn't get to see all of the eclipse, but I guess Stellarium doesn't want me to see an animation, either.

Every time I try to view the 1/31/18 lunar eclipse Stellarium crashes. Version info is Stellarium 0.17.0 on MacOS 10.13.3

Looking at the log, I suspect

Texture "/Users/bgold/Applications/Stellarium.app/Contents/Resources/textures/earth-shadow.png" does not exist

is a problem, but in case that's a red herring I've attached the full file

log.txt

Bug Description

When I activated the orbit line for Pluto, it was not drawn correctly and was shown as a broken line. To reproduce this bug, try to see Pluto from Caronte, for example. See attached image for visual information about the issue.

Thank you & best regards!

Original report

https://bugs.launchpad.net/stellarium/+bug/1490223

A phantastic program.
But the distance to the moon is mistaken. Can you please check?

Started in #19

leonardcj commented 10 hours ago •
@alex-w I'm not a Catalan-speaker, but I am the Translation Team Coordinator for Sugar Labs and I've got a very good Catalan localizer. My confidence in asserting the errors in your PO came after I merged you POs with the one for our little StarChart activity and compared differences. It is also based on the i18n enhancements I made to insert wiki links into the code (and POT file) that allows interwiki look up. see https://github.com/sugarlabs/starchart/blob/master/po/StarChart.pot and the embedded translation comments linking to the relevant pages. I would be happy to collaborate on developing similar links for your program, but I'm pretty busy and I'm starting to think wikidata links may be better than regular wiki links. Reach me at [email protected] and we can discuss the concept.

@alex-w
Member
alex-w commented 10 hours ago
Thanks for the info! In one side the link on the wiki may be helpful, in other side some astronomical background is required for translators of astronomical software, because some special terms has other translation in common software.

@leonardcj
leonardcj commented 2 hours ago
It is all in how you view it. Consider the wiki link as a means of acquiring some that specialized background and you expand beyond the educated stargazer into a way of creating more of them. You could even leverage it as a way of encouraging more wiki articles to be created in other languages and providing a deeper dive into the celestial objects you display.

How better to point out the special meaning of certain terms than linking to an article explaining it? I don't advocate a link for every entry, just proper nouns (e.g. object names) and terms like Longitude, Latitude, etc that are concepts with wiki pages.

I see you have a long list of country names, basically an embedded copy of ISO-3166-1. I can absolutely help you with that in pretty much all languages. I am leveraging wikidata retrieval e.g .see here for Afghanistan in many languages http://tinyurl.com/yb6lmmky and CLDR Unicode locales (which also contain ISO-3166-1 to a great extent) and the Debian Alioth iso0codes translation project to identify canonical and conflicting translations of those country names. I can add a check of your country names and flag possible corrections and additions.

@alex-w
Member
alex-w commented 2 hours ago
Could you make a patch for countries list please?

@leonardcj
leonardcj commented an hour ago
Sure, a pull request against the PO file is acceptable? Someone else will take care of synching back to Transfex?

Or were you suggesting a translator comment to the wiki page embedded in code to appear in POT after regeneration? Such as I use in https://translate.sugarlabs.org/templates/CLDR_regions/translate/CLDR_regions.pot#filter=incomplete

@alex-w
Member
alex-w commented an hour ago
The pull request may be acceptable. Technically src/translations_countries.h generated by script and I may just add links to wikipedia within script as comments.

@leonardcj
leonardcj commented 15 minutes ago •
Is this sufficient? .xlsx format because github would not accept .csv
Columns

1 sequential integers for ordering
2 List of countries (in order found in src/translations_countries.h) with code markup from file
3 Corresponding wikilinks, note pre-pended #: is PO file comment mark, not needed in other contexts.

What is your script's input? I can easily add a column for two-letter ISO-3166-1 code if that would help.

I noticed you are missing a few obscure locations (e.g. Diego Garcia), do you want that list?

@leonardcj
leonardcj commented 11 minutes ago
I'm not against trying to properly format this as a patch, it's just that you might be able to do it more easily with higher confidence. If you could do that, I'll take care of going through each language PO file to look for opportunities to pick up new translations. If I do that would you like the new entries default marked as "fuzzy" for human review, although I would just take them as I have very high confidence in them, some people (like me) have strong feelings about machine translation, but I make an exception for the country names in the manner I am deriving them.

@leonardcj
leonardcj commented 4 minutes ago

Shall we start this in a new open issue? This has gone far afield from Catalan typos and orthography.

I noticed two relatively minor errors in your Catalan translation. The correct terms are below. Marian was incorrect as Mairan and Pleiades is missing the accent on the e.

Nebulosa de Marian

Plèiades

Currently Stellarium is using $HOME/.stellarium for storing configuration and other data.

It's proper to switch to XDG base directory spec instead.

I have recently started using an OAG with my telescope and find the Oculars plugin fantastic for helping to determine targets that are likely to give me good stars for guiding. One thing that I think is missing is the ability to rotate the angle of the guide sensor with respect to the orientation of the main camera. I know that you can already rotate the guider angle around the perimeter of the main sensor, what I'd like to do though is rotate my guide cam sensor in place. This is because my Celestron OAG allows me to screw my camera in place using a C-T adapter and T-thread extension to a helical focuser which keeps everything nice and secure but doesn't allow me to rotate my guide camera such that NSEW on the guider is aligned with NSEW on the main camera. Is this something that could be added to the OAG section of the Oculars plugin?

As discussed on the mailing list, it would be good to get the translations off Launchpad too and host them somewhere else, where the translators might get the following goodies:

• Fuzzy matches from the translation memory. This way, small changes won't completely kill the string for those who are not translating offline
• Support for additional file formats for the sky culture and landscape etc. translations

The 2 options I like best personally are:

Pootle

• This tool is free as in freedom, and Stellarium will have full control over everything
• Translators can switch on other translations to guide them, e.g. a Bulgarian translator could display both the English source strings and the Russian translation at the same time
• Glossary function
• You will have to run your own Django

I have never run a Pootle server, but they do have a step-by-step guide on how to do it. Pushing and pulling translations can be fully automated.

http://pootle.translatehouse.org/

Transifex

• Non-free, but free-to-use for FLOSS projects
• Displaying other languages is blocked, unless you're a member of the other language's translation team too
• Glossary, social features and issue tracker
• You won't need to take care of the hosting

You can push and pull translations with the Transifex client.

http://transifex.com/

Please, provide AppImage for Stellarium 0.12.x (LTS) tree too

• https://github.com/Stellarium/stellarium/tree/0.12
• http://stellarium.org/release/2017/04/02/stellarium-0.12.9.html

For example.

The magnitude of some DSO is wrong, such as M88, M91。

Hello,

I am a bit surprised by some of the names appearing in my favorite planetarium software for some deep sky objects...

I think this tracks back to commit ee300ad

Impacted file :  nebulae/default/names.dat (and possibly translations of it ?)

The indicated source for the names is : the list of 'The 500 Best Deep Sky Objects' by Don Pensack; https://www.cloudynights.com/topic/472872-500-best-dso-list/

(later tagged "B500" once comments were allowed, i.e from commit 9192214)

Although the list itself is fine and certainly useful, the "name" column contains mostly nicknames for which I don’t find any primary source. To my opinion they should not appear in Stellarium, which should stick to official identifiers (or more commonly accepted name sources).

I would suggest to remove the lines with B500 source (I can submit a PR if agreed).

Anyway thanks for the good work on Stellarium !

Hi! I've noticed that in 0.17.0 all polish names of planets are now in english. In version 0.16.1 everything was ok.

I enjoy Stellarium every day, thanks to your great effort.
In the latest version 0.17.0, it looks that Moon's day or synodic month (0.0-29.5) is not shown. If my understanding is correct, really hope to add this information.

Regards,
A stargazer in Japan

Is it possible to get a database containing information about the spatial objects against variables like their distance from earth, sun, angle made with other spatial objects.. etc? How much should I pay for such a service?

I can not start Stellarium. Every time I try, I get the same error: "LoadLibrary failed with error 1114: Error in a dynamic link library initialization routine (DLL)" and the start aborts. I've tried with versions 0.17.0 and 0.16.1 both 32 and 64 bits, and both languages English and Spanish. I use an HP G72 notebook with Intel core i3 with 4 GB of RAM, Windows 10 Pro 64 bit operating system compilation 15063.

I am linking translations.fab to wiki pages to help localizers. For some reason there is no en.wikipedia.org article for Asteroid (2758) Cordelia although such an article exists in many other European language wikis. It would be a great if such an article could be created by an astronomy-minded community member in en.wikipedia.org.

I think there is a redirect at https://en.wikipedia.org/wiki/2758_Cordelia that sends you to
https://en.wikipedia.org/wiki/List_of_minor_planets:_2001%E2%80%933000#758 when the linkage should really be the other way around, a link from the index to the main article for Asteroid (2758) Cordelia.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages

Here is an overview of some projects that are already distributing upstream-provided, official AppImages.

https://github.com/probonopd/linuxdeployqt has lots of real-world examples on how to do this. Let @probonopd know if something is not clear or you need some help.

https://github.com/probonopd/uploadtool script will help you setup Travis-CI for uploading built AppImage's automatically back to Github repo in "Releases" section.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net

Ask @probonopd for help you on Github ;-)

Bug Description

Inter-operability between KStars and Stellarium through DBus.

Copy of email from maillist (https://sourceforge.net/p/stellarium/mailman/message/34798862/):
KStars is beginning to expose a lot of functionality through D-Bus, the inter-process communication bus on Linuxy operating systems. I'm not sure how portable it is to Windows, but maybe it is, because the bus itself seems to be fairly lightweight. In any case, it can be made optional.

The advantage that Stellarium as well as KStars have with respect to D-Bus is that Qt makes it really easy to expose functionality on DBus. Qt has a qdbusxml2cpp compiler that turns XML descriptions of a DBus interface into appropriate C++ code seamlessly. Examples of how to create DBus interfaces with Qt are available on, for example, the KDE technical wiki:
https://techbase.kde.org/Development/Tutorials/D-Bus/Creating_Interfaces
https://techbase.kde.org/Development/Tutorials/D-Bus

The advantage of exposing functionality over DBus is that one can build very powerful scripts in standard scripting languages that combine the abilities of our planetarium software with that of general scripting. For example, in a shell script, these DBus interfaces may be accessed using the qdbus program. Here is an example using qdbus to get KStars to do various things:
https://kstars.wordpress.com/2014/01/02/astro-scripting-using-kstars-d-bus-interface/
and here's Jasem's tutorial on how to use python to interface with KStars/INDI through DBus:
http://www.indilib.org/support/tutorials/148-dbus-scripting-with-kstars-python.html
In fact, with a month of efforts, I was able to create this project that relies heavily on KStars DBus interfaces to produce this:
http://bas.org.in/~akarsh/Logbook-Project/

Our previous attempts at inter-operability on this mailing list seemed to center around harder tasks / projects, such as trying to share a code-base, or trying to share a data format or the like. These are more involved tasks, probably why we never got around to them. However, if Stellarium and KStars implement D-Bus methods that are designed to share functionality across the two software, we will be able to provide some amount of inter-operability with minimal code changes and ease.

Immediate examples would be to choose objects from Stellarium and center them in KStars, or vice versa; transfer date/time/geographic location settings across the software; etc. Eventually, we may start exposing the ability to use features that are implemented in one software in the other, reducing effort duplication the easy way. For example, one may eventually be able to invoke KStars' star-hopper in Stellarium, so that a power user could use Stellarium's wonderful interface with KStars' unique backends.

It would be good to eventually have Cartes du Ciel interoperability as well. Cartes exposes functionality through a TCP/IP server. One glue program that translates DBus calls to this TCP/IP server will then allow both KStars and Stellarium to interface with Cartes.

Maybe we should all eventually agree on some standard DBus methods for common functionality such as centering, setting zoom, setting time etc. I am happy to improve DBus interfaces in KStars to enable better interoperability with Stellarium.

The idea at the end of the day is to unite the open source astronomy projects so that we can hope to provide a completely open source astronomy solution for almost all needs. This is especially important for Linux users, who have little access to proprietary software.

Regards
Akarsh

Original report

https://bugs.launchpad.net/stellarium/+bug/1562673

Including the skycultures with the general stellarium repo is suboptimal from the point of view of contributors who want to enrich the skycultures without daring to touch the stellarium code.

As it is, the stellarium repo is giant and formidable. Repo admins take a long time to merge pull requests - so rebasing is often required. But rebasing changes can be quite the chore for such contributors. Pushing giant changes that result can result in github timeouts. My own recent experience was to just give up, delete the fork, create a new fork and make the changes all over again.

Having a separate repo would make skyculture contribution easier and more enjoyable - ultimately leading to more of it.

Bug Description

There is a slight error in our ELP2000 lunar positions. I am pretty sure it has been here for years, only now we want to go into higher accuracy.

Compare photo and simulation from the same location. The star (at 2 o'clock in the photo) reappeared seconds before 04:52:12 where Stellarium has it reappearing more than a minute earlier. Camera time was corrected to NTP-adjusted PC, so cannot be more than 1-2sec off. DeltaT setting default near 69s.

Obviously related:

• Eclipse 2017 Bug https://bugs.launchpad.net/stellarium/+bug/1275092

Likely also related:

• Forum discussion https://sourceforge.net/p/stellarium/discussion/278769/thread/374439f7/#9c2b/5620/0694/19fe/9a9b/02a7/e123/e498/fe8b/fb2a

Original report

https://bugs.launchpad.net/stellarium/+bug/1509659

I want to have a plugin that has the following features:

1. Allows users to easily add a square the nebula image, integrated astrometry.net function, the program can automatically determine the coordinates of four corners.
2. Allow users to upload the nebula image to the server, the official audit to determine whether the incorporation of stellarium procedures.
3. If the user uploads more information, depending on these photos may add new features. Of course, if the server resources are not enough, then can some way to limit the number of uploads?
   there are too many people want to contribute their nebula image to Stellarium but do not know the channels and methods.

Hello,

When I turn the time back before 1 AD(CE) the s/w includes a year zero - therefore all years before 1AD are one year out because of this e.g 7 BC is in Stellarium -6 , because year 0, which never existed is allowed in Stellarium - I am not aware that anyone has reported this before.

I have a rather old version of the s/w so this may have been corrected.

Improve approximation of the typical light curves to the real data for different types of novae

http://stellarium.org/translation/2017/10/07/planetary-features-call-to-translators.html

still points people to LaunchPad

Bug Description

Hello,
I’m using Stellarium 0.12.0 for scientific works with university students. I find it’s a great software which gives good information on the characteristics of the stars.

But, I think that it’s possible to bring an important improvement on the accuracy of the parallax (the distance) of the stars :

1. In Stellarium, parallax is given based on the Hipparcos Catalogue I/239 from 1997.
   Now, there is a new, more accurate catalogue : Hipparcos I/311 published in 2007.
   Would it be possible to upgrade Stellarium with the last Hipparcos release ?

2. In addition, parallax is provided as a such, with no indication of the related absolute error. It may be technically possible to extract these data from the Hipparcos catalogue for an implementation within Stellarium. It would be very instructive to display the absolute error after each parallax.

For instance :
For HIP 110991 (delta Cep) :
Stellarium parallax (1997) : 3,32 msa.
Catalogue I/311 (2007) : parallax : 3,77 ± 0,16 msa.

For HIP 34088 (dzeta Gem) :
Stellarium parallax : 2,79 msa.
Catalogue I/311 (2007) : parallax : 2,37 ± 0,30 msa.

Hoping someone will add these new information for all the stars…

Best regards

Original report

https://bugs.launchpad.net/stellarium/+bug/1382306

I would like to add a config file option to change the sky background color from black to something else. This is part of a project that uses Stellarium to create artwork.

Can anyone point me in the right direction? I can't find where this black color is set in the code.

Hi, I found an error in displaying stars, etc. in the Stellarium. To find the error, enter NGC 6723 or NGC 6726 in the search. There is an incomprehensible square.Thank you for you work

Bug Description

The arcs of orbit lines coinciding with the planet are either shown through the parent planet or completely hidden by it. Please see the attached screen shots.

Original report

https://bugs.launchpad.net/stellarium/+bug/978576

When language is selected to Bengali, some texts are outside of ocular on-screen control area.

In skycultures/translations.fab, why do you insist on

.# TRANSLATORS: Asteroid (2867) Steins
.# TRANSLATORS: https://en.wikipedia.org/wiki/2867_%C5%A0teins
._("Steins","minor planet")

instead of the correctly accented spelling with the diacritic mark on the Š?

.# TRANSLATORS: Asteroid (2867) Šteins
.# TRANSLATORS: https://en.wikipedia.org/wiki/2867_%C5%A0teins
._("Šteins","minor planet")

Is just because you use MPC as your canonical reference for spelling?

It seems a mark of disrespect to Kārlis Šteins not to spell his name correctly.
https://en.wikipedia.org/wiki/K%C4%81rlis_%C5%A0teins

Just curious.

Whenever I try to set the screenshot directory to my home directory (e.g. /home/user) via the Configuration -> Tools GUI menu, the setting is not retained, and the next time I run stellarium it reverts to /home/user/Stellarium.
Manually setting screenshot_dir in the config.ini works as expected.
Tested on Ubuntu 16.04, stellarium 0.17.0.

When typing the Screenshot directory name into the Configuration -> Tools GUI, a new directory gets created at each keystroke. For example, entering "/home/user/images" as the directory name (and assuming the "/home/user" prefix was already present in the textbox) causes the "i", "im", "ima", "imag", "image", "images" directories to be created under /home/user.
Ubuntu 16.04, stellarium 0.17.0.