Nope. It doesn't work that way. What happened with my moon if proof of that. The moon, Kuma, has as parent body Goyra, a planet, which in turn has as parent body the star Kiru, which is declared in catalog\stars. And yet the moon highjacked the very barycenter of the 24 Draconis star system, which has no parent body.

But as long as the catalogs are not checked and corrected in this regard, remains only the solution to give your moon a different name! Of course, you could also check and correct the catalogs!

Thing is: I don't know every single name celestial objects have, nor do I know every single name addon-makers decide to give their objects. Nobody does. So situations like this will happen again, unless something is done to prevent them. I made two suggestions towards a solution (inclusion of possible name collisions in the logs and/or a system of name complementation). SpaceEngineer will know which one is more feasable or if some other solution is better. But a solution will be needed; it won't be just a matter of updating catalogs.

- Docked ships do not always stay docked when re-loading game? I'm sure I read a thread somewhere about this but cannot find it, I think it was Harbinger that suggested that the game loads before the docked ships are loaded? But is there any fix for this or a planned fix?

- Ships in orbit are often not in orbit when re-loading game? They often end up somewhere far from the object, on the surface of the object or simply drifting into deep space.

Other small issues are:

- Some textures do not match up on some gas giants and asteroids.

- Some Brown dwarfs are visible behind planets. (An old issue I know)- Also Brown dwarfs in a binary systems can sometimes disappear if the main star (A) is hidden behind an object.

- Sometimes I cannot select planets from the dark sides?

- I still have intermittent problems with the shuttle and skylone becoming uncontrollable for no reason while trying to take off and leave atmospheric planets. They can spin widely out of control for no reason and the kill rotation switch cannot be activated, also the move left, right, and rotation keys get locked out. The thrusters and engines can still be controlled. Disabling aerodynamics prevents the issue.

I would really love Carbon stars, Zirconium stars, and Wolf-Rayet stars to be procedurally generated

Added.

QuoteJCandeias ()

Because there's this annoying bug, you see? A bug that seems to be ignored, by which a brown dwarf in a regular planetary orbit around another star turns the star it orbits into another brown dwarf of the same type and size. It kind of contaminates it, zombifying it.

This is because you didn't described the Sun itself in the planet catalog. If there is some stars in planet catalog, SE scans them and determines the whole system spectral type and luminosity by the most bright star. In this case, it is a brown dwarf Jupiter. This is doing at catalog loading stage. So whole Solar System have not T5 spectral type. Then planetary system is being generated (at program runtime), SE generates default star in the system center (because you have described sytem as "Star" in the star catalog), which class is T5 according to calculation in the catalog loading routine. After that, SE adds all other planets, moons and stars (Jupiter) to the system.To fix that, you must also add the Sun script to the planet catalog. Look into SolarSys.sc and copy/paste/remane it. Here I changed Jupiter to T5 dwarf in the SolarSys.sc just to test it, no problems:

You have mixed up stars catalog and planets catalog. The first 5 parameters are belong to stars catalog, the last 4 - to the planets catalog (Class and AbsMagn can be used in both, but not the other parameters).

Aaah! I see. I thought we needed to have something in the star catalog to sort of "reserve" the place for the star system. What you're telling is that whole systems, including the stars themselves (and even barycenters in multiple systems?) can be defined in a single file, no matter where it's placed, is it? That's really nice to know.

Added: hm... apparently not, as per the next answer. Now I'm confused. Again.

Added later: Right, I guess I sorted it out. Sorry, man, I'm sure you must have had good reasons for it, but I find this way of doing catalogs needlessly redundant and clumsy. One looks at the Sun's barycenter in the star catalogue and finds

Code

Lum 1 Class "G2V" MassSol 1 RadSol 1 Age 4.57 FeH 0

Then one checks the Sun's planet catalogue and there it is:

Code

Class "G2V"Luminosity 1.0Age 4.57FeH 0.0

MassSol 1.0RadSol 1.0

Come on! Surely there must be a better way to do this. Surely it's a waste of resources to reload the same thing twice...

JackDole, my problem is solved: I changed the way I defined the moon -- that's what the tests I made were about. What I'm discussing now is not that specific problem, but how to avoid similar issues in the future, be it with my own addons or with anobody else's.

Aaah! I see. I thought we needed to have something in the star catalog to sort of "reserve" the place for the star system. What you're telling is that whole systems, including the stars themselves (and even barycenters in multiple systems?) can be defined in a single file, no matter where it's placed, is it? That's really nice to know.

No. SE needs at least 2 files:

1) The script in addons/catalogs/stars/ defines the planetary system itself, ie it's coordinates, brightness and color (spectral type). This info is used to generate the stars in galaxy - ie points on screen, which can be clicked. You can use two options to define the planetary system:Star{} - adds a planetary system with default star in it's center, with luminosity/class/mass/radius/temperature which can be also defined in this script. If there is no planets/stars/other bodies defined in the planet catalogs, the procedural planets will be generated.StarBarycenter{} - adds a planetary system without default star in it's center. SE assumes what you will define the single central star in the planets catalog (as Sun in the Solar System with no Orbit{} tag), or define binary/multiple stellar components with this StarBarycenter as a parent and a proper Orbit{} tags. No procedural planets will be generated.

2) The script in addons/catalog/planets/ defines all components of the planetary system, ie planets, moons, multiple stars or (optionally) a single central star. If a single central star is not defined, it will be generated using data provided in the star catalog (only luminosity/class/mass/radius/temperature, all other parameters such as rotation will be procedural).

Added later: Right, I guess I sorted it out. Sorry, man, I'm sure you must have had good reasons for it, but I find this way of doing catalogs needlessly redundant and clumsy. One looks at the Sun's barycenter in the star catalogue and finds

Come on! Surely there must be a better way to do this. Surely it's a waste of resources to reload the same thing twice...

If you think more, it's vise versa! It is not a waste of resources, but a way to make a massive stars-only catalog with correct mass/radius/temperature data. In older version, stars catalog can't have this data, so stars has procedurally generated mass/radius/temperature, not always correct. The only way to avoid this was defining needed stars as StarBarycenter, then add a planet catalog with needed data. There was a catalog of famous supergiants and close red dwarfs made this way. Now this is not needed, SE catalogs became more compact. Even HIPPARCOS.sc have a columns for mass/radius/temperature (not filled yet thoug), so huge amount of stars will have correct parameters in the future (then I decided to uptdate the HIPPARCOS catalog).

You may not use these data in the stars catalog, if you wish. You also may not use Class and Luminosity/AppMagn/AbsMagn, if you defined them in the planets catalog for all system stars. SE automatically sums up their luminosity and determines the system's spectral class as the spectral class of the most bright star in the system. So, it is another way to "compress" the catalogs, and get rid of boring manual calculations.

Yeah, I get it. I don't get why everything worked fine before and only started to cause these problems in recent versions (which is why SolarSys3000 was as it was without the need for a barycenter for it to work just fine) or why it had to be changed, but hey, you're the boss and I guess I'm in grumpy old man mode.

One note, though: replacing the star in the star catalog with a barycenter changes the way the main star is rendered in the planet browser. Compare Mosfet's image in message #3062 with JackDole's in #3064 or mine in #3066. It's the same star, with the same characteristics, but the way it's rendered is totally different.

Re-edit: Nope. Strike that. No changes. Those differences were due to the highjacking of Kuma. The planet browser was assuming the diameter of an A V star as basis for the rendering of the main star. An M star is tiny by comparison, hence the images in #3064 and #3066. So false alarm.