N0B0DY wrote:

There are issues if the Hiparcos.cvs is disabled. I was orbiting Proxima b and the whole proxima system has disappeared. Space Engine is doing an awesome job in merging the dublicates so better leave it there..
I suspect (but I may be wrong) that in its final form, the GAIA catalog will complement the Hipparcos catalog. But to achieve this a lot of work must be done to filter out the dublicates.

Indeed. That's what I was planning on doing after I got done with getting rid of columns of stars, which is almost done.

SpaceEngineer wrote:

Hornblower wrote:

Source of the post There are duplicate stars caused by the mod (idk how you could fix this). But since this adds stars and doesn't replace them, some stars already in space engine also have a duplicate in the gaia catalog. Example: HIP 81852 and [too long of a name to copy over]. This gives a sort of expansion effect. 

This is a great problem. GAIA catalog, to be included in SE by default, must be cross-matched with existing stars. FastFourierTransform working on this currently, we had a large discussion about future integration of the GAIA dataset. It will require major changes in engine though: star catalog will be split into chunks which will be loaded from disk on-demand, similar to how planet textures works.

About the duplicates. I was thinking on replacing the distance of Hipparcos stars with Gaia distance as it's more accurate. Everything else (mass, luminosity, spectral class, etc.) will be left as it is.

Does the SE converter have the ability to convert non-gaia data? Cuz I tried to get that cross reference archive, but I couldnt use the same terms in the query box

And, you keep saying columns. Did you mean rows?

PlutonianEmpire wrote:

Does the SE converter have the ability to convert non-gaia data? Cuz I tried to get that cross reference archive, but I couldnt use the same terms in the query box

And, you keep saying columns. Did you mean rows?

No, I seriously mean pillars (or columns) of stars. See page 1 of mod thread. They are caused by uncertainties and errors in the parallaxes of the stars in a cluster.
Edit: Also no, the converter cannot get data from anything but that specific gaia search as variables other than those you get from the gaia searcb are not specified in the code.

Phunnie wrote:

Another problem is that star clusters with great uncertainty, like 47 Tucanae are rendered as long columns of star. It looks fine from Earth, but looks extremely strange from anywhere else in the galaxy.

47 Tucanae, taken by Vigo Hornblower.

Updated some clusters in paks 800k, 3M, 4M and 5M.

Clusters are now no longer massive pillars of stars radiating away from Earth, well most of them anyways. I only changed the ones that were very apparent and had more than 15 stars. My method of doing it is also in no way accurate as I took the stars that were stretched out and put them in a compressed cube at their supposed to be location. Don't worry, they still look fine and normal from Earth, and from most angles. The RA and DEC of each star is still accurate, but the distance is not as I randomized it. Sometimes, "layers" of stars can be visible within the cluster, but that's from the seed of the generator. I don't have enough time to create a perfect sphere generator, nor do I have the time to create a tool that will perfectly pick out the stars belonging to a cluster. It's not the best, but it works, and it's certainly better than having those pesky pillars of stars, or deleting the clusters completely.

On a side note, while changing the clusters, I have found that some clusters need to be tweaked according to both gaia and online data.

47 Tuc: Radius from 28 to ~35
NGC 6231: Distance from 1243 to 1809
Trumpler 14: Distance from 2500 to ~2750 (perhaps even more according to Gaia)
Trumpler 16: Distance from 3900 to 2842
NGC 6397: Distance from 2300 to 2400, radius from 5.289 to ~9.8 (maybe even a little more)
(Everything in parsecs)

Example of change:

► Show Spoiler

The horrendous 47 Tuc cluster taken by VIgo Hornblower
to

Phunnie wrote:

Updated some clusters in paks 800k, 3M, 4M and 5M.

Thank You Phunnie! Any chance for the 2M pak? I find this one to have the best balance of coverage vs performance vs stability (ok less stable than the 800K )  and is also on the borderline of the hard-coded octree limitation that Space Engineer mentioned previously.

Well, I only did 800k, 3M, 4M and 5M because those catalogs have no set distance limit so the clusters alongside their pillars were included in the catalog. For 2M, the distance limit is 1000 light years, and so it does not extend far enough for broken clusters with massive errors to appear.

Aah sorry didn't think of that.
On a side note the 800K version now shows only as a ~60Kb .pak size. Is this normal?

I have not downloaded this add-on yet but my first question is how do you convert the GAIA magnitudes to V magnitudes. Looking at the data it seems to lose sensitivity toward the redder Stars and I wondered if you saw the same. Do you use a formula?

N0B0DY wrote:

Aah sorry didn't think of that.
On a side note the 800K version now shows only as a ~60Kb .pak size. Is this normal?

Strange. It shows 61kB for me as well, but says uses 96 MB of storage.

Gnargenox wrote:

I have not downloaded this add-on yet but my first question is how do you convert the GAIA magnitudes to V magnitudes. Looking at the data it seems to lose sensitivity toward the redder Stars and I wondered if you saw the same. Do you use a formula?

I'm not entirely sure what you mean by GAIA magnitudes to V magnitudes. I'm guessing you mean the spectral class? Gaia doesn't give the spectral class, and calculating spectral class is very complicated. Since SE currently requires a spectral class to be specified (otherwise it renders as planemo), the decision was made to put all the stars as main sequence (based on T_eff) and the spectral class I to V was randomized.

That's what I was wondering. Thanks!

I was hoping the 2m would be fixed too because I still have this problem when I have 2M installed: Stars that shouldn't exist or shouldn't be that bright show up in weird spots in our sky with weird names:

PlutonianEmpire wrote:

Source of the post I was hoping the 2m would be fixed too because I still have this problem when I have 2M installed: Stars that shouldn't exist or shouldn't be that bright show up in weird spots in our sky with weird names:

You might have an outdated version.

Hi is this worth downloading or will GAIA catalogs be incorporated into the next version?  Also which one is recommended to download I want to get as wide a variety of stars as possible from all different spectral classes and luminosities.  And is it still recommended to disable procedural stars?

Also what is with this posting error that seems to be having more frequently

General Error
SQL ERROR [ mysqli ]

User cg43099_fm already has more than 'max_user_connections' active connections [1203]

An sql error occurred while fetching this page. Please contact an administrator if this problem persists.
occurred while fetching this page. Please contact an administrator if this problem persists.

Phunnie wrote:

Source of the post Gnargenox wrote:
I have not downloaded this add-on yet but my first question is how do you convert the GAIA magnitudes to V magnitudes. Looking at the data it seems to lose sensitivity toward the redder Stars and I wondered if you saw the same. Do you use a formula?

I'm not entirely sure what you mean by GAIA magnitudes to V magnitudes. I'm guessing you mean the spectral class?

No, he is talking about apparent magnitude. V is a standard visual band, but GAIA has its own sensitivity curve which is not match the V band.

A-L-E-X wrote:

Source of the post Hi is this worth downloading or will GAIA catalogs be incorporated into the next version?

Definitely no. A huge works must be done before GAIA catalog became default for SE: data cleaning, cross-matching with other catalogs, merging with existed SE catalogs, changing how star octree works in SE so it can handle missions of stars, implement data streaming from the disk.