Celestia Forums

Art Blos wrote:What is your verdict? What is reason for inoperability of trajectory? In the Celestia code or in the converter?

I'm debugging it. I see that all windows builds return wrong results.

Art Blos wrote:At the same time, can you comment on this change? Is this something to do with the fact that you were getting strange numbers from my trajectory?

It was required to have a proper output in text files converted from binary form. Double numbers have 15 (or 13?) significant digits but previously it was artificially limited to 8+ digits. This change simply removes the limitation and again it's not related to your problems.

onetwothree wrote:I'm debugging it. I see that all windows builds return wrong results.

Okay, be sure to post your results. I follow the forum almost every hour.

Added after 5 minutes 1 second:
But it is important to make sure that this works not only on Windows.

Please check these artifacts https://github.com/CelestiaProject/Celestia/actions/runs/3867452265

onetwothree wrote:Please check these artifacts

Right now I checked the new versions of converters. Everything works! Neptune in its orbit. Thank you very much!

Next need to figure out why it is impossible to localize stars with Bayer designations.

for star and dso name localization I believe you need to check https://github.com/CelestiaProject/CelestiaConten ... /data/well-known-starnames.txt and https://github.com/CelestiaProject/CelestiaConten ... r/data/well-known-dsonames.txt . these are the list of them that are marked translatable and have entries in celestia-data.pot .

the list was originally generated by matching the first names of stars in celestia with what is in stellarium's sky culture https://github.com/Stellarium/stellarium/tree/master/po/stellarium-skycultures

Markerz < Thank you, but we already have quite developed lists. It would be nice if you could help Gleb deal with the above problem.

The problem with Bayer designations is that in catalog files you use abbreviations like ALF or BET but internally Celestia translates them into Greek letters, so to make translations work replace abbreviations in original English strings with Greek letters.

onetwothree wrote:The problem with Bayer designations is that in catalog files you use abbreviations like ALF or BET but internally Celestia translates them into Greek letters, so to make translations work replace abbreviations in original English strings with Greek letters.

Why is this needed? Replacing abbreviations in original strings is a bad idea and time consuming job.
In version 1.6.2 "ALF Centauri" after localization became "Альфа Центавра". Now it doesn't work, output is "α Centauri".
The program simply ignores attempts to localize strings with this abbreviations. This is definitely a bug. Moreover, it manifests itself on all systems.

onetwothree wrote:internally Celestia translates them into Greek letters

Why is this necessary in any rational universe?

john71 wrote:Why is this necessary in any rational universe?

I always thought that made it easier to type Greek letters into catalogs. It's really more convenient for me.

john71 wrote:Why is this necessary in any rational universe?

To make this translation only once on names load. Instead of performing it every frame, every search operation and so on.

onetwothree wrote:To make this translation only once on names load. Instead of performing it every frame, every search operation and so on.

Another reason why we should not abandon these abbreviations.

Linux Mint 20.3.

1) Data loading is not working correctly using the --dir and --conf commands (used simultaneously). Apparently, .cfg file is connected (since there is a reaction to the LuaHook line, see below), but the data is not.

2) LuaHook does not work when loading using the mentioned commands. If you put the data and .cfg file with LuaHook line in the program folder, the data is loading and Lua works.

onetwothree < Problems with binary trajectories. Again.
After the transition from the Keplerian orbit to vectors, the vector trajectory begins to be built at the wrong angle. While the celestial body continues to move in the old orbit.

And yes, localization on Windows in the native interface disappeared again. I'm not even talking about the bug with normals in format *.dxt5nm.

Will there be any reaction from the developers?

Do you think we dedicate 100% of our time to this forum?

onetwothree wrote:Do you think we dedicate 100% of our time to this forum?

Of course not, but in two days it was possible to write at least something like "noted, we'll look into it". People are also worried, silence seems to be inaction. There will be less and less time left, and if it remains too little, we will have to think about alternative options.

I converted laomedeia_2019-12-27_2028-11-16.xyzvbin to a text file, the tested this section with both binary and text representations:


Both gave the same image:


URL on the picture: cel://Follow/Sol:Neptune:Laomedeia/2023-02-02T18: ... 27&nrf=255&lm=128&tsrc=0&ver=3

For those whose videocards support GL >= 3.2, please check these artifacs. Do you observe any galaxy rendering speedup (FPS increase)?

https://github.com/CelestiaProject/Celestia/actions/runs/4085665942

onetwothree wrote:Both gave the same image

I see the same pictures, too, but the planes of the orbits are rotated 90 degrees to the ecliptic, and the objects are displaced from their orbits (the red mark). Tested on text and binary variants, with xyzv and without ones for Neptune.

Linux, d036fd5.


Text trajectories for Laomedeia only

Text trajectories for Laomedeia and Neptune

Binary trajectories for Laomedeia only

Binary trajectories for Laomedeia and Neptune


Bonus

Neptune with xyzv trajectories