#SE setting different mass for custom planets

42 messages · Page 1 of 1 (latest)

keen meteor
#

While I was making my mod which adds Adrian (Tau Ceti e) to the game, I noticed that the game is setting its mass to 2.9896 M_Earth even though I've specified its mass in its files as 3 M_Earth...

pale oracleBOT
#

Thank you for posting in the bug forums, mystic.xyz!

Please Follow These Guidelines while reporting Bugs:

  1. Official Releases Only: Bug reports must be from the official public or Beta branch of SpaceEngine on Steam. Reports from modded or unofficial versions will not be considered. This includes 0.980
  2. Update to the Latest Version: Ensure you are using the latest version of SpaceEngine from the public branch. Update your game if necessary before reporting.
  3. Detailed Information Required:
    • Logs: Please include your se.log file located at <Steamapps>/common/SpaceEngine/system/se.log
      -# Beta users can find the log file @ %USERPROFILE%\Documents\Cosmographic\SpaceEngine\logs
    • Steps to Reproduce: Describe in detail the steps to reproduce the bug. Include all necessary steps to allow us to replicate the issue.
    • Screenshots: If applicable, attach screenshots or images that illustrate the problem.
  4. Hardware and Software Details: Provide your CPU, GPU, RAM, and operating system details.
  5. Check for Duplicates: Avoid submitting duplicate reports. If the issue has been reported, add to the existing thread!!!!
    Is This a request for help modding? the correct place for mod help is https://discord.com/channels/148933808811409408/1164988630671044638

Bug Report Template:

   Summary: Example issue
   Description: What is going wrong?
   Steps to Reproduce: What steps did you follow?
   Actual Result: What did you observe?
   Expected Result: What was expected?
   Reproducible: Yes/No/Intermittent
   GPU: Your GPU model
   GPU Driver: Your GPU driver version
   Version: SpaceEngine version
   Modded: Y/N 

Failure to adhere to these guidelines will result in your post being removed without warning.

keen meteor
#

In its .sc file:

#

Someone else who makes custom systems had also pointed out (in a different server) this same bug that I was getting

verbal glen
#

I would think that this would be a rounding error, although that would be pretty weird for this, as you specify an integer for it

#

Maybe try setting it to different values, like 2 or 4, and see what happens there ?

twin ridge
#

Not exactly a rounding error when it can be a whole Earth mass off on larger planets.

twin ridge
#

I think it's happening to proc gen planets too since my 17.2 me terra is now 16.95me in the beta.

#

But I'll have to export the script later when I get home.

teal coral
#

Probably relates to this, if I had to guess the generator recalculates the mass based on the smaller mean radius and the normal density after adjusting for oblateness. So for procedural objects this might be fixed in a sense.

twin ridge
#

So yeah the oblateness-density bug is indeed fixed. Just not in an ideal way.

simple stag
#

This is technically "not a bug", but with a softness you could sleep on.
I'm looking into issues related to the density fix, and will add this to my reporting.

teal coral
twin ridge
teal coral
#

This has now produced a different bug where all orbits around oblate planets have inaccurate orbital period, because the new mass after adjusting for oblateness is smaller and the orbits are not recalculated.
Example:
RS 7081-452-2-16-262 3
Mass 40.546 Me
Eq diameter 52824.34km
Density 3.1375 g/cm3
Oblateness 0.033827
Moon: Mass 0.96985 lunar
SMA 140067.11 km
This moon has orbital period of 22h 21m 57s.
Based on Kepler's third law the orbital period based on this mass should be 22m 45m 17s.
For the orbital period shown in SE to be correct, original mass must be 41.969 Me.
If we keep eq radius and density constant but set oblateness to 0:
An oblate spheroid with equatorial radius a and flattening f has volume V = (4/3)πa²b, where the polar radius b = a(1−f). Setting f = 0 restores the full sphere, V = (4/3)πa³, so the volume grows by exactly a factor of 1/(1−f) — about 3.50 % in this case.
With an equatorial radius of 26,716.885 km and a density of 3.1375 g/cm³ (3137.5 kg/m³) held fixed, the spherical volume works out to 7.988 × 10²² m³, and the resulting mass is:
M ≈ 2.5063 × 10²⁶ kg ≈ 41.966 Earth masses. (The same as the original mass for that orbital period)
So this mismatch in orbital period is almost certainly because of this "fix". It affects every single planet and moon orbiting planets with oblateness > 0.
Again, the mass is not what needs recalculating. The mean radius should be kept constant and the equatorial radius increased to keep density the same.

#

Going to take this opportunity to also bump the bugs about binary stars not using their actual combined mass to calculate orbital period, instead using a fake value, and the bug about multiple star systems only using the dominant partner in the barycenter instead of the combined mass to calculate orbital period/SMA.

lament geyser
#

my 2c: this is a clever solution. we just need a new parameter called MassInfo, similar to OblatenessInfo, that serves the same purpose: mass in the wiki and tooltip.

#

however, it still doesn’t fix the root problem of equatorial radius being the "main radius" instead of mean radius.

lament geyser
# teal coral This has now produced a different bug where all orbits around oblate planets hav...

This has now produced a different bug where all orbits around oblate planets have inaccurate orbital period, because the new mass after adjusting for oblateness is smaller and the orbits are not recalculated.
I also wouldn’t consider this a bug beyond it displaying the wrong mass. the actual mass and orbital period of planets cannot be changed anyways after that stage of generation.

teal coral
#

Well the idea is the mass is changed to keep the density constant. If the mass is higher then the density is higher.

lament geyser
#

said recalculcated mass is only ever used in the tooltip and wiki though. it’s unnoticeable if they just display the original mass

#

the mass is, afaik, only changed after generation is 100% complete.

teal coral
#

The whole bug was that oblateness increased density because it reduced the volume. The fix here was to reduce the planets mass apparently so it does not increase density instead of making it increase the eq radius.

lament geyser
#

that’s why the planet editor and tooltip show different values, the planet editor reads the original mass. it just needs to display that.

lament geyser
#

the only difference is visual, that oblateness still only reduces the poles

#

that could probably be fixed separately without the refactors I brought up in the original post

teal coral
lament geyser
#

density is never used except in the tooltip and, afaik, only ESI, so again, it makes no difference

#

the idea should be to display the “old” mass and only use this lower mass in functions that are affected by the oblateness bug, they probably just missed that the new mass is used in the tooltip, somehow

lament geyser
teal coral
#

Ok but if old mass is displayed and it displays the new density that's just wrong. The volume is still the same, and the mass is still the same, so how would the density be different? Yes density is just something displayed there but this just makes everything inaccurate to each other.

lament geyser
#

yeah, that is a problem. I still feel like even at this point you’d rather display different, correct radii to the user (where mean radius = what is set in the script) alongside changing the rendering code instead of refactoring the entire generation code. thinking about it from what is feasible for them to do instead of what is ideal. an aside, unfortunately equatorial and mean radii are used so much in the code for planet generation that changing them to be correct now would definitely require a universe reset. it’s why I wished for it to get in before 0.991.

#

said correct radii will then give it the correct volume, and Radius in a script being mean radius would be a nice change, though would definitely be a breaking one. though they’ve done those in the past anyways, see Chthonias.

lament geyser
twin ridge