Planetary Systems
Moderators: winston, another_commander
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Planetary Systems
Planetary Systems
Core package:
Current OXZ version 1.8.0
Uploaded 15 July 2021
Planetary System Texture Pack A...Z
Current OXZ version 1.6.0
Uploaded 23 November 2020
This project was started as tweaked Orbits. Old good Orbits (authors Ebi and Kaks) with textured planets and improved compatibility with large moons. Now it is heavy mod of original Orbits but original Orbits script, realizing generation of solar system and orbital dynamics, remains as crucial component of Planetary Systems OXP. So let’s start presentation from Orbits script modifications.
System layout and orbital mechanics
Maximal additional planet number in system raised from 7 to 8.
Like original Orbits script generates planet subset, selecting planets from planetinfo.plist on pseudo-random base, but technically there are 10 variants for every planet class in planetinfo.plist. Mini-terra for example presented with radii 2750, 2775, 2800...2975 km. Script preudo-randomly selects one from ten variants for every planet class in generated subset. Ten radius variants for every planet class is not just for visual diversity (it is hard to notice visual difference between 3400 and 3600 km radius without specially planned experiment). Main reason is provide more diversity for initial data, used by PlanetEngine (about PlanetEngine a bit later)
These planets are divided onto classes based on radius:
Miniterra – Mercury analog
Venus-like planet or desert Terra-like planet
Subterra – Mars-like planet
Superterra aka Super-Earth
Two gas giants like Jupiter or Saturn without rings
Ice giant – Neptune analog
Dwarf terra – Pluto analog
It seems to be similar to our Solar system layout with exception of super-earth, but really Orbits generates wide range of possible layouts. You can see systems with only gas giants except main planet or with only terrestrial planets.
Discriminating borderline between large moon and small planet is raised from 1000 to 2500 km (from 10,000 to 25,000 m in game units). So you can simulate large moons such as Titan or Ganymede.
Original Orbits has fixed orbital period of main planet 300 days (standard year of canonic Lave). Modified script uses orbital period of main planet calculated on base of sun mass and distance (this part of work is provided by AstroLibrary external function in Sun Gear). So you’ll have not only unique planet layout for every system, you’ll have unique value of local year.
Like original Orbits, Planetary Systems generates more compact systems than our real Solar system. Tionisla for example has almost all planets except Neptune analog, but with following arrangement:
0.63 OU – Miniterra
1.00 OU – Main planet
2.20 OU – Terra
3.04 OU – Subterra
3.79 OU – Superterra
4.77 OU – Gas Giant
5.94 OU – Gas Giant
6.67 OU – Dwarf Terra
Planetary Systems script, inherited from Orbits, limits possible layouts. You’ll never have two planets between sun and main planet as in our Solar system, only one is possible. You’ll never have second planet close enough to habitable zone so you’ll never generate lovely sci-fi setting with two or more habitable planets in system. And you’ll never generate systems expanding beyond 9 OU or so.
Planetary Systems like original Orbits is not intended for simulation of elongated elliptical orbits, high inclination orbits, orbital resonances etc. All planets orbited in same plane without any dynamic interaction. Extremely simplified model from school astronomy handbook, of course.
Technically more complex model is possible to realize by code upgrading, but some crucial parts of original code are too hard for me to clearly understand it and to modify without risk of breaking. So I was focused on more evident tasks.
PlanetEngine
Planet mass and chemical composition are two initial parameters, determining planet appearance. For moons and terrestrial planets you have such building materials as water ice (density 0.9), rock (density approx 2.5) and iron-nickel alloy (density approx 8.0). So for planets and moons composed mainly from these materials you’ll have mean density between these extreme values. In inner region of Solar system where solar irradiation is enough to sublimate volatiles you have mostly mix of rock and metal with only few volatiles and mean density of terrestrial planets are between 3.940 for Mars and 5.515 for Earth. In outer region of Solar system beyond frost line all three building materials are present so moons of gas and ice giants composed mainly from mix of water ice, rock and metal and mean density is from 0.98 (Tethys, composed mainly from water ice) to 3.53 (extremely dehydrated due to volcanic activity Io).
There are also more exotic materials such as dry ice (solid carbon dioxide), nitrogen ice, water-ammonia brine, high pressure water ice modifications etc. But as rule of thumb: more distance from sun – less insolation – less equilibrium temperature – less sublimation effects – more volatiles – less mean density.
Situation with planet mass is more complex. Mean density of terrestrial planet depends not only from its bulk composition. More massive planet with same composition will be more dense due to gravitational compression. From a different standpoint, more massive planet in the same region of space can capture more volatiles, thus reducing mean density.
Having sufficient mass planet can effectively capture hydrogen and helium from primordial nebula, so super-earth with critical mass above 10 Earth mass will develop extremely massive atmosphere and will transforms onto ice giant or gas giant. Difference between ice giants like Uranus and Neptune and gas giants as Jupiter and Saturn mainly in inner composition, not in visual appearance. Uranus for example consists mainly from water, ammonia and methane ices (approx 9.3...13.5 Earth masses) and rocky core (0.5...3.7 Earth masses). Hydrogen and helium in Uranus atmosphere are only 0.5...1.5 Earth mass. Jupiter, for contrast, contains relatively small core – 12...45 Earth mass. Most of Jupiter’s 318 Earth mass consists from metallic, liquid and gaseous forms of hydrogen.
This is real astronomy. In Oolite we have no planet masses nor planet density simulated, so PlanetEngine deals with some retro-engineering: taking planet radius and planet density (calculated as function of insolation and radius) it calculates planet mass. There are really three functions for planet density in PlanetEngine: for terrestrial planet, for ice giants and for gas giants (in case of ice and gas planets located deeply outside frost line insolation is not taken into account, just planet radius). Having planet mass and radius, calculations of surface gravity and escape velocity are trivial tasks.
Just one note. PlanetEngine uses planet with 6400 km radius as Earth analog for simplicity, not 6371 km real Earth mean radius (6378 km, mentioned in Sun Gear topic, is Earth equatorial radius), so calculated surface gravity and escape velocity will be slightly different from real values based on precise calculations using gravitational constant G.
Atmosphere parameters are less formalized data on project. Look on our Solar system. Extremely thin and cold Mars atmosphere (6 mbar pressure on “sea level”) is a present result of dissipation of more dense initial atmosphere. Extremely dense and hot Venus atmosphere (93 bar and 735 K on surface level) is a result of limestone degassing caused by runaway greenhouse effect. Extremely oxygen enriched Earth atmosphere (21% oxygen) is result of activity of life on planet. We have no yet exact knowledge of initial atmosphere parameters for these planets nor accurate general model of atmosphere evolution during 4.6 billions years from formation of Solar System. So this part of PlanetEngine is a bit wild and, honestly, oversimplified speculation based on some assumptions.
PlanetEngine calculates atmosphere mass per unit of surface square based on initial atmosphere pool (more planet mass and less insolation – more fraction of volatiles) and rate of dissipation (again more planet mass and less insolation – more atmosphere remains). Atmosphere pressure is calculated as weight of atmosphere mass per surface unit (you can calculate it having only atmosphere mass per surface unit and surface gravity).
Atmosphere temperature calculation is not so simple. Greenhouse effect is roughly calculated based on atmosphere mass per surface unit. Final temperature on surface level is a sum of equilibrium temperature of planet surface without atmosphere and greenhouse offset. This is oversimplified model, not taking into account planet albedo nor atmosphere composition. But it simulates diversity of conditions, generating planets with extremely rarefied cold atmosphere like Mars, dense cold atmospheres like Titan or superdense extremely hot atmosphere like Venus.
Planet Data Interface
Let’s enough about details of PlanetEngine internal functions. How it will be manifested in game?
If you have PlanetFall OXP (author Thargoid) or my PlanetLand (OXP with similar functionality, based on PlanetFall) installed, after docking with planet/moon surface port you’ll have access to new F4 screen Planet Data interface. It generates pages with slightly different output for planets and moons.
Planet Data Sheet for planet ports:
ORBITAL DATA
Orbit radius in OU
Orbit period in days
PHYSICAL DATA
Radius, km
Mean density, g/cm^3
Mass, TU – Terran Units
Escape velocity, km/s
Surface gravity, g
Atmosphere pressure, bar
Surface temperature, K
Output for Moon Data Sheet is almost the same, but orbit radius is displayed in host planet radius units, not in OU.
There are two tricks in case of super-earths, ice giants and gas giants.
Gas giants has no surface in common sense. Gas deeply below cloud layers smoothly reaches state of supercritical fluid. So Planet Data Sheet page takes 1 bar atmosphere pressure level as reference point in case of gas and ice giants.
Non-linear scale is implemented to large planets (super-earths, ice and gas giants). Being only 172,500 m radius in game really, largest gas giant is displayed in Planet Data Sheet page as gas giant of 72,500 km radius instead 17,250 km of default planet scale. Planet mass, escape velocity and surface gravity is displayed scaled too. This non-linear scale is used for display purposes only. Any calculation are based on internal scale. This is forced decision. Honest simulation of planet with 72,500 km radius (slightly more than Jupiter’s 71,500 km equatorial radius) will create too wide zone of mass-lock. Starting from surface port on Cobra Mk III, you’ll need 34.5 min on full throttle to leave mass-lock zone. Honest displaying of real 17,250 km radius of Jupiter analog will lead to too low mass of planet: having density 1.325 like real Jupiter its analog will have only 4.7 mass in Earth units, not real 318!
There is also bias in small planet parameters. Mercury and Pluto analogs in Planetary Systems are larger than prototypes. Initially it was implemented as simple way to avoid confusion between small planets and large moons.
There are two parameters, extremely important for good sci-fi setting and completely missing in PlanetEngine yet.
Planet axial rotation period (local day)
Typical value of rotation_speed parameter in planetinfo.plist included in game is between 0 and 0.005 radians/s. Having rotation_speed 0.0045 and radius 4116 km (case of vanilla Lave), you’ll have rotation period only 23 min 16 s and linear rotation velocity on equator 18.5 km/s! Such planet in reality will be ripped off by centrifugal forces. Of course, this is setting just for visual appearance. It seems nice idea to give player opportunity to observe almost all planet during short trip from witchpoint to main station. But if you have PlanetFall and descending to low altitude, the things seems to be wrong – planet rotation looks too fast comparing with ship speed.
Setting rotation_speed to honest value 0.0001 or so (rotation period 17 hours 45 mins) will solve this problem, but at the cost of visual appearance – it is problematic to note subtle changes in planet details visibility during few minuts of flight. I have no idea to solve this conflict.
Planet axis tilt
This parameter is crucial for climate modeling. But in Oolite planet orientation seems to work unpredictable – despite the same orientation declared for all additional planets in planetinfo.plist some of them are almost upright, some are lying on side. I have no idea how to fix it. Honestly.
Smart selection of planet texture
Initially Planetary System has predetermined set of textures for every planet class such as Martian texture set for analogs of Mars, Venusian for analogs of Venus and so. Mercury analog orbit always created between sun and orbit of main planet, so it is safe to give Mercury analog texture of heavy cratered dry world such real Mercury or Moon. Terra-like planet in absence of Mercury analog will be be inside main planet orbit and looks like Venus, but if Mercury analog is present, Terra-like planet will be placed outside main planet orbit and looks like snowball Earth. Pluto analog is extreme case: in rare events of absence of other additional planets it occupies place of Mercury and looks like dry hot airless world, not icy cold airless one. These variations were implemented in next iteration of Planetary Systems.
Now textures for terrestrial planets selected using not planet positions per se but surface temperature and atmosphere pressure, calculated by PlanetEngine. So we have more possible variants in planet appearance: it may looks like Mars with polar ice caps or without ones, like cold windy rocky desert or hot sandy desert, like snowball Earth or volcanic world. I hope it will be fun to explore these variations.
There a five variants of every type of texture (60 in sum), selected for every system pseudo-randomly.
Dependencies
This OXP uses AstroLibrary functions in Sun Gear OXP to calculate properties of system planets and moons. So Sun Gear OXP is obligatory.
Habitable Main Planets OXP is highly recommended to provide more reliable data for main planet. This is no way to match calculated atmosphere density and surface temperature for planet of 3000 km radius, for example, with vanilla game classification of such world as agricultural/tropical paradise.
Known issues
Interaction of Planetary Systems OXP with planets added by other OXPs can cause inflation of system far beyond planned size. Diso.oxp with 4 additional planets is a good example of such system.
Planetary Systems OXP is incompatible with Additional Planets SR due to same reason.
Like original Orbits, Planetary Systems needs some time to generate solar system, so problems with positioning of moons, stations and ships added by third party OXPs or system populator can appear. See more details discussed in my post from Dec 23, 2018 in topic https://bb.oolite.space/viewtopic.php?f=4&t=8216
Specific case of incompatibility is Market Cooldown OXZ (author spara). It uses sum of station distances to witchpoint and to sun as unique key for port identification. This method works in static deterministic system, but fails in dynamic systems with changing psw triangle.
Planetary Systems in combination with Sun Gear generates really vast solar systems. Having planet with radius 6400 km and sun on distance 695 planet radii, planet on outer 7.5 OU edge of system will be on distance 333,600,000 m in game units – slightly less than distance between Earth and Moon in reality. It is 8 hours 16 minuts for Cobra Mk III flight on Torus drive, so you need special instruments for exploration of distant planets such as Norby’s Torus to Sun or my warp drive, implemented in Hard Way. Navigation in vast systems is almost impossible without ASC upgrade. These considerations, however, are implemented only to intra-system navigation: distance between main planet and witchpoint remains unaffected.
OXP structure
To provide easy updates all planet textures repacked as separate texture packs.
Planetary Systems.oxp - core package.
Planetary Systems Texture Pack A.oxp - Ice Deserts
Planetary Systems Texture Pack B.oxp - Cold Deserts
Planetary Systems Texture Pack C.oxp - Sand Deserts
Planetary Systems Texture Pack D.oxp - Volcanic Deserts
Planetary Systems Texture Pack E.oxp - Cold Mars Analogs
Planetary Systems Texture Pack F.oxp - Hot Mars Analogs
Planetary Systems Texture Pack G.oxp - Gas and Ice Giants
Planetary Systems Texture Pack H.oxp - Miscellaneous (Mercury, Pluto, Venus analogs and super-earths).
Original planet textures were reprocessed. Reprocessing includes converting JPG file format onto PNG, rescaling image size to standard aspect for lat-long maps 2:1 with size 2 * 2^n width and 2^n height, using color saturation and lights/shadows level correction filters.
Texture size 4096x2048 was used as compromise between file size and visual quality, but due to shortage of high-res texture files medium-res 2048x1024 textures also used to complete texture sets.
Credits
Orbits main script - Ebi, Kaks.
Textures - Celestia Motherlode and freebitmaps.blogspot.com.
See more detailed texture credits in Texture Pack Readme documents.
Core package:
Current OXZ version 1.8.0
Uploaded 15 July 2021
Planetary System Texture Pack A...Z
Current OXZ version 1.6.0
Uploaded 23 November 2020
This project was started as tweaked Orbits. Old good Orbits (authors Ebi and Kaks) with textured planets and improved compatibility with large moons. Now it is heavy mod of original Orbits but original Orbits script, realizing generation of solar system and orbital dynamics, remains as crucial component of Planetary Systems OXP. So let’s start presentation from Orbits script modifications.
System layout and orbital mechanics
Maximal additional planet number in system raised from 7 to 8.
Like original Orbits script generates planet subset, selecting planets from planetinfo.plist on pseudo-random base, but technically there are 10 variants for every planet class in planetinfo.plist. Mini-terra for example presented with radii 2750, 2775, 2800...2975 km. Script preudo-randomly selects one from ten variants for every planet class in generated subset. Ten radius variants for every planet class is not just for visual diversity (it is hard to notice visual difference between 3400 and 3600 km radius without specially planned experiment). Main reason is provide more diversity for initial data, used by PlanetEngine (about PlanetEngine a bit later)
These planets are divided onto classes based on radius:
Miniterra – Mercury analog
Venus-like planet or desert Terra-like planet
Subterra – Mars-like planet
Superterra aka Super-Earth
Two gas giants like Jupiter or Saturn without rings
Ice giant – Neptune analog
Dwarf terra – Pluto analog
It seems to be similar to our Solar system layout with exception of super-earth, but really Orbits generates wide range of possible layouts. You can see systems with only gas giants except main planet or with only terrestrial planets.
Discriminating borderline between large moon and small planet is raised from 1000 to 2500 km (from 10,000 to 25,000 m in game units). So you can simulate large moons such as Titan or Ganymede.
Original Orbits has fixed orbital period of main planet 300 days (standard year of canonic Lave). Modified script uses orbital period of main planet calculated on base of sun mass and distance (this part of work is provided by AstroLibrary external function in Sun Gear). So you’ll have not only unique planet layout for every system, you’ll have unique value of local year.
Like original Orbits, Planetary Systems generates more compact systems than our real Solar system. Tionisla for example has almost all planets except Neptune analog, but with following arrangement:
0.63 OU – Miniterra
1.00 OU – Main planet
2.20 OU – Terra
3.04 OU – Subterra
3.79 OU – Superterra
4.77 OU – Gas Giant
5.94 OU – Gas Giant
6.67 OU – Dwarf Terra
Planetary Systems script, inherited from Orbits, limits possible layouts. You’ll never have two planets between sun and main planet as in our Solar system, only one is possible. You’ll never have second planet close enough to habitable zone so you’ll never generate lovely sci-fi setting with two or more habitable planets in system. And you’ll never generate systems expanding beyond 9 OU or so.
Planetary Systems like original Orbits is not intended for simulation of elongated elliptical orbits, high inclination orbits, orbital resonances etc. All planets orbited in same plane without any dynamic interaction. Extremely simplified model from school astronomy handbook, of course.
Technically more complex model is possible to realize by code upgrading, but some crucial parts of original code are too hard for me to clearly understand it and to modify without risk of breaking. So I was focused on more evident tasks.
PlanetEngine
Planet mass and chemical composition are two initial parameters, determining planet appearance. For moons and terrestrial planets you have such building materials as water ice (density 0.9), rock (density approx 2.5) and iron-nickel alloy (density approx 8.0). So for planets and moons composed mainly from these materials you’ll have mean density between these extreme values. In inner region of Solar system where solar irradiation is enough to sublimate volatiles you have mostly mix of rock and metal with only few volatiles and mean density of terrestrial planets are between 3.940 for Mars and 5.515 for Earth. In outer region of Solar system beyond frost line all three building materials are present so moons of gas and ice giants composed mainly from mix of water ice, rock and metal and mean density is from 0.98 (Tethys, composed mainly from water ice) to 3.53 (extremely dehydrated due to volcanic activity Io).
There are also more exotic materials such as dry ice (solid carbon dioxide), nitrogen ice, water-ammonia brine, high pressure water ice modifications etc. But as rule of thumb: more distance from sun – less insolation – less equilibrium temperature – less sublimation effects – more volatiles – less mean density.
Situation with planet mass is more complex. Mean density of terrestrial planet depends not only from its bulk composition. More massive planet with same composition will be more dense due to gravitational compression. From a different standpoint, more massive planet in the same region of space can capture more volatiles, thus reducing mean density.
Having sufficient mass planet can effectively capture hydrogen and helium from primordial nebula, so super-earth with critical mass above 10 Earth mass will develop extremely massive atmosphere and will transforms onto ice giant or gas giant. Difference between ice giants like Uranus and Neptune and gas giants as Jupiter and Saturn mainly in inner composition, not in visual appearance. Uranus for example consists mainly from water, ammonia and methane ices (approx 9.3...13.5 Earth masses) and rocky core (0.5...3.7 Earth masses). Hydrogen and helium in Uranus atmosphere are only 0.5...1.5 Earth mass. Jupiter, for contrast, contains relatively small core – 12...45 Earth mass. Most of Jupiter’s 318 Earth mass consists from metallic, liquid and gaseous forms of hydrogen.
This is real astronomy. In Oolite we have no planet masses nor planet density simulated, so PlanetEngine deals with some retro-engineering: taking planet radius and planet density (calculated as function of insolation and radius) it calculates planet mass. There are really three functions for planet density in PlanetEngine: for terrestrial planet, for ice giants and for gas giants (in case of ice and gas planets located deeply outside frost line insolation is not taken into account, just planet radius). Having planet mass and radius, calculations of surface gravity and escape velocity are trivial tasks.
Just one note. PlanetEngine uses planet with 6400 km radius as Earth analog for simplicity, not 6371 km real Earth mean radius (6378 km, mentioned in Sun Gear topic, is Earth equatorial radius), so calculated surface gravity and escape velocity will be slightly different from real values based on precise calculations using gravitational constant G.
Atmosphere parameters are less formalized data on project. Look on our Solar system. Extremely thin and cold Mars atmosphere (6 mbar pressure on “sea level”) is a present result of dissipation of more dense initial atmosphere. Extremely dense and hot Venus atmosphere (93 bar and 735 K on surface level) is a result of limestone degassing caused by runaway greenhouse effect. Extremely oxygen enriched Earth atmosphere (21% oxygen) is result of activity of life on planet. We have no yet exact knowledge of initial atmosphere parameters for these planets nor accurate general model of atmosphere evolution during 4.6 billions years from formation of Solar System. So this part of PlanetEngine is a bit wild and, honestly, oversimplified speculation based on some assumptions.
PlanetEngine calculates atmosphere mass per unit of surface square based on initial atmosphere pool (more planet mass and less insolation – more fraction of volatiles) and rate of dissipation (again more planet mass and less insolation – more atmosphere remains). Atmosphere pressure is calculated as weight of atmosphere mass per surface unit (you can calculate it having only atmosphere mass per surface unit and surface gravity).
Atmosphere temperature calculation is not so simple. Greenhouse effect is roughly calculated based on atmosphere mass per surface unit. Final temperature on surface level is a sum of equilibrium temperature of planet surface without atmosphere and greenhouse offset. This is oversimplified model, not taking into account planet albedo nor atmosphere composition. But it simulates diversity of conditions, generating planets with extremely rarefied cold atmosphere like Mars, dense cold atmospheres like Titan or superdense extremely hot atmosphere like Venus.
Planet Data Interface
Let’s enough about details of PlanetEngine internal functions. How it will be manifested in game?
If you have PlanetFall OXP (author Thargoid) or my PlanetLand (OXP with similar functionality, based on PlanetFall) installed, after docking with planet/moon surface port you’ll have access to new F4 screen Planet Data interface. It generates pages with slightly different output for planets and moons.
Planet Data Sheet for planet ports:
ORBITAL DATA
Orbit radius in OU
Orbit period in days
PHYSICAL DATA
Radius, km
Mean density, g/cm^3
Mass, TU – Terran Units
Escape velocity, km/s
Surface gravity, g
Atmosphere pressure, bar
Surface temperature, K
Output for Moon Data Sheet is almost the same, but orbit radius is displayed in host planet radius units, not in OU.
There are two tricks in case of super-earths, ice giants and gas giants.
Gas giants has no surface in common sense. Gas deeply below cloud layers smoothly reaches state of supercritical fluid. So Planet Data Sheet page takes 1 bar atmosphere pressure level as reference point in case of gas and ice giants.
Non-linear scale is implemented to large planets (super-earths, ice and gas giants). Being only 172,500 m radius in game really, largest gas giant is displayed in Planet Data Sheet page as gas giant of 72,500 km radius instead 17,250 km of default planet scale. Planet mass, escape velocity and surface gravity is displayed scaled too. This non-linear scale is used for display purposes only. Any calculation are based on internal scale. This is forced decision. Honest simulation of planet with 72,500 km radius (slightly more than Jupiter’s 71,500 km equatorial radius) will create too wide zone of mass-lock. Starting from surface port on Cobra Mk III, you’ll need 34.5 min on full throttle to leave mass-lock zone. Honest displaying of real 17,250 km radius of Jupiter analog will lead to too low mass of planet: having density 1.325 like real Jupiter its analog will have only 4.7 mass in Earth units, not real 318!
There is also bias in small planet parameters. Mercury and Pluto analogs in Planetary Systems are larger than prototypes. Initially it was implemented as simple way to avoid confusion between small planets and large moons.
There are two parameters, extremely important for good sci-fi setting and completely missing in PlanetEngine yet.
Planet axial rotation period (local day)
Typical value of rotation_speed parameter in planetinfo.plist included in game is between 0 and 0.005 radians/s. Having rotation_speed 0.0045 and radius 4116 km (case of vanilla Lave), you’ll have rotation period only 23 min 16 s and linear rotation velocity on equator 18.5 km/s! Such planet in reality will be ripped off by centrifugal forces. Of course, this is setting just for visual appearance. It seems nice idea to give player opportunity to observe almost all planet during short trip from witchpoint to main station. But if you have PlanetFall and descending to low altitude, the things seems to be wrong – planet rotation looks too fast comparing with ship speed.
Setting rotation_speed to honest value 0.0001 or so (rotation period 17 hours 45 mins) will solve this problem, but at the cost of visual appearance – it is problematic to note subtle changes in planet details visibility during few minuts of flight. I have no idea to solve this conflict.
Planet axis tilt
This parameter is crucial for climate modeling. But in Oolite planet orientation seems to work unpredictable – despite the same orientation declared for all additional planets in planetinfo.plist some of them are almost upright, some are lying on side. I have no idea how to fix it. Honestly.
Smart selection of planet texture
Initially Planetary System has predetermined set of textures for every planet class such as Martian texture set for analogs of Mars, Venusian for analogs of Venus and so. Mercury analog orbit always created between sun and orbit of main planet, so it is safe to give Mercury analog texture of heavy cratered dry world such real Mercury or Moon. Terra-like planet in absence of Mercury analog will be be inside main planet orbit and looks like Venus, but if Mercury analog is present, Terra-like planet will be placed outside main planet orbit and looks like snowball Earth. Pluto analog is extreme case: in rare events of absence of other additional planets it occupies place of Mercury and looks like dry hot airless world, not icy cold airless one. These variations were implemented in next iteration of Planetary Systems.
Now textures for terrestrial planets selected using not planet positions per se but surface temperature and atmosphere pressure, calculated by PlanetEngine. So we have more possible variants in planet appearance: it may looks like Mars with polar ice caps or without ones, like cold windy rocky desert or hot sandy desert, like snowball Earth or volcanic world. I hope it will be fun to explore these variations.
There a five variants of every type of texture (60 in sum), selected for every system pseudo-randomly.
Dependencies
This OXP uses AstroLibrary functions in Sun Gear OXP to calculate properties of system planets and moons. So Sun Gear OXP is obligatory.
Habitable Main Planets OXP is highly recommended to provide more reliable data for main planet. This is no way to match calculated atmosphere density and surface temperature for planet of 3000 km radius, for example, with vanilla game classification of such world as agricultural/tropical paradise.
Known issues
Interaction of Planetary Systems OXP with planets added by other OXPs can cause inflation of system far beyond planned size. Diso.oxp with 4 additional planets is a good example of such system.
Planetary Systems OXP is incompatible with Additional Planets SR due to same reason.
Like original Orbits, Planetary Systems needs some time to generate solar system, so problems with positioning of moons, stations and ships added by third party OXPs or system populator can appear. See more details discussed in my post from Dec 23, 2018 in topic https://bb.oolite.space/viewtopic.php?f=4&t=8216
Specific case of incompatibility is Market Cooldown OXZ (author spara). It uses sum of station distances to witchpoint and to sun as unique key for port identification. This method works in static deterministic system, but fails in dynamic systems with changing psw triangle.
Planetary Systems in combination with Sun Gear generates really vast solar systems. Having planet with radius 6400 km and sun on distance 695 planet radii, planet on outer 7.5 OU edge of system will be on distance 333,600,000 m in game units – slightly less than distance between Earth and Moon in reality. It is 8 hours 16 minuts for Cobra Mk III flight on Torus drive, so you need special instruments for exploration of distant planets such as Norby’s Torus to Sun or my warp drive, implemented in Hard Way. Navigation in vast systems is almost impossible without ASC upgrade. These considerations, however, are implemented only to intra-system navigation: distance between main planet and witchpoint remains unaffected.
OXP structure
To provide easy updates all planet textures repacked as separate texture packs.
Planetary Systems.oxp - core package.
Planetary Systems Texture Pack A.oxp - Ice Deserts
Planetary Systems Texture Pack B.oxp - Cold Deserts
Planetary Systems Texture Pack C.oxp - Sand Deserts
Planetary Systems Texture Pack D.oxp - Volcanic Deserts
Planetary Systems Texture Pack E.oxp - Cold Mars Analogs
Planetary Systems Texture Pack F.oxp - Hot Mars Analogs
Planetary Systems Texture Pack G.oxp - Gas and Ice Giants
Planetary Systems Texture Pack H.oxp - Miscellaneous (Mercury, Pluto, Venus analogs and super-earths).
Original planet textures were reprocessed. Reprocessing includes converting JPG file format onto PNG, rescaling image size to standard aspect for lat-long maps 2:1 with size 2 * 2^n width and 2^n height, using color saturation and lights/shadows level correction filters.
Texture size 4096x2048 was used as compromise between file size and visual quality, but due to shortage of high-res texture files medium-res 2048x1024 textures also used to complete texture sets.
Credits
Orbits main script - Ebi, Kaks.
Textures - Celestia Motherlode and freebitmaps.blogspot.com.
See more detailed texture credits in Texture Pack Readme documents.
Last edited by stranger on Thu Jul 15, 2021 12:28 am, edited 6 times in total.
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Re: Planetary Systems
Just realizing appearance issue: too long names for Planetary Systems texture pack files, overlapping with version numbers in game expansion pack manager.
Is it easy way to fix this issue without re-uploading 500 MG of content?
UPD. Fixed. Re-uploaded texture packs with edited names.
Is it easy way to fix this issue without re-uploading 500 MG of content?
UPD. Fixed. Re-uploaded texture packs with edited names.
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Re: Planetary Systems
Version 1.6.0
Minimal planet radius decreased from 2700 to 2500 km.
Recalibrated radii of Pluto, Mercury and Mars analogs. Pluto and Mercury analogs still remains oversized comparing with prototypes, but Mars analogs radii range now includes real Mars.
Minimal planet radius decreased from 2700 to 2500 km.
Recalibrated radii of Pluto, Mercury and Mars analogs. Pluto and Mercury analogs still remains oversized comparing with prototypes, but Mars analogs radii range now includes real Mars.
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Re: Planetary Systems
Version 1.7.0
Fixed error generating in log in case of misjump.
Fixed error generating in log in case of misjump.
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Re: Planetary Systems
There is issue with new lighting model in Oolite 1.90. Old planet and moon textures looks too bright.
Planetary Systems Texture Pack A...H readjusted to Oolite 1.90.
The same issue with moon textures will be fixed soon.
Planetary Systems Texture Pack A...H readjusted to Oolite 1.90.
The same issue with moon textures will be fixed soon.
Re: Planetary Systems
Latest.log complains about namespace pollution. To fix:
Line 115 in Scripts\orbits.js: function mkPlanetIndex()
Can be changed to: this.mkPlanetIndex = function mkPlanetIndex()
And line 377: var planetsarray = this.mkPlanetIndex();
Line 115 in Scripts\orbits.js: function mkPlanetIndex()
Can be changed to: this.mkPlanetIndex = function mkPlanetIndex()
And line 377: var planetsarray = this.mkPlanetIndex();
- stranger
- ---- E L I T E ----
- Posts: 351
- Joined: Thu Apr 05, 2018 5:31 am
- Location: Vladivostok, Russia
Re: Planetary Systems
@Milo
Thank you! I'll fix these issues.
UPD
Version 1.8.0 with fixed lines 115 and 377 ( function mkPlanetIndex() unsafe declaration issue) uploaded.
Thank you! I'll fix these issues.
UPD
Version 1.8.0 with fixed lines 115 and 377 ( function mkPlanetIndex() unsafe declaration issue) uploaded.
Re: Planetary Systems
Here is an idea how to improve a bit compatibility with OXPs that use relative coordinate systems in the system populator functions -
Add a method for them that will allow them to set up the system before they start working with their coordinates like this:
But, as always, there are a couple of pitfalls:
Add a method for them that will allow them to set up the system before they start working with their coordinates like this:
Code: Select all
this.systemWillPopulate = function () {
if(worldScripts["PlanetOrbits"])
worldScripts["PlanetOrbits"].setUpSystem()
///The rest of the populator code will use the already "rotated" positions of the system bodies...
}
- As I mentioned here, normal execution of this.createOrbits in the system populator is hindered by the fact that a beacon object in the system is used to determine the location of the witchpoint, which does not yet exist at that time, but if I haven't missed anything, it should be pretty easy to fix.
- Because multiple OXPs can use this method, and so that OXP doesn't have to deal with reconfiguring the system itself by Planetary Systems, this external function only needs to do the actual work once per system.
this.shipWillExitWitchspace
for this and add a reset of this.systemDone
when leaving the system:
Code: Select all
this.setUpSystem = function()
{
if (this.systemDone || system.isInterstellarSpace) return;
var w = worldScripts.AstroLibrary;
var sunRadius = system.sun.radius;
var sunMass = w.$astroLib_sunMass(sunRadius);
var mainYr = w.$astroLib_solPeriod(sunMass);
this.Yr = mainYr;
this.createOrbits();
this.systemDone = true;
}
this.shipWillExitWitchspace = this.setUpSystem;
this.shipWillEnterWitchspace = function () {
this.systemDone = false;
}
- Cholmondely
- Archivist
- Posts: 5366
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Planetary Systems
If this is code for me to put in my oxp's I'll need more information as to where it goes ("we dumb pilots", and all that!). If instead you plan to rejig Stranger's oxp's, I hereby offer to test-pilot them for you (Clapham Omnibuses and Venetian Vaporetti permitting!).Alnivel wrote: ↑Fri Sep 16, 2022 4:17 pmHere is an idea how to improve a bit compatibility with OXPs that use relative coordinate systems in the system populator functions -
Add a method for them that will allow them to set up the system before they start working with their coordinates like this:But, as always, there are a couple of pitfalls:Code: Select all
this.systemWillPopulate = function () { if(worldScripts["PlanetOrbits"]) worldScripts["PlanetOrbits"].setUpSystem() ///The rest of the populator code will use the already "rotated" positions of the system bodies... }
I propose to slightly modify the already existing function that is used in
- As I mentioned here, normal execution of this.createOrbits in the system populator is hindered by the fact that a beacon object in the system is used to determine the location of the witchpoint, which does not yet exist at that time, but if I haven't missed anything, it should be pretty easy to fix.
- Because multiple OXPs can use this method, and so that OXP doesn't have to deal with reconfiguring the system itself by Planetary Systems, this external function only needs to do the actual work once per system.
this.shipWillExitWitchspace
for this and add a reset ofthis.systemDone
when leaving the system:Code: Select all
this.setUpSystem = function() { if (this.systemDone || system.isInterstellarSpace) return; var w = worldScripts.AstroLibrary; var sunRadius = system.sun.radius; var sunMass = w.$astroLib_sunMass(sunRadius); var mainYr = w.$astroLib_solPeriod(sunMass); this.Yr = mainYr; this.createOrbits(); this.systemDone = true; } this.shipWillExitWitchspace = this.setUpSystem; this.shipWillEnterWitchspace = function () { this.systemDone = false; }
I do wonder, though, if it might make more sense to totally overwrite the SunGear code in Planetary Systems with new code for each system so that these fake suns never appear?
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
Re: Planetary Systems
First of all, don't need to blame SunGear, it doesn't add anything to the system by itself (probably doesn't, I just took a quick look at its code).Cholmondely wrote: ↑Fri Sep 16, 2022 4:48 pmI do wonder, though, if it might make more sense to totally overwrite the SunGear code in Planetary Systems with new code for each system so that these fake suns never appear?
All of these phantom planets and stars come into existence as the Planetary System places its planets in place of planets from other OXPs. In order to fix this, in PS need to add a check whether any celestial body is already in the planned orbit and in this case do not add its own planet.
Anyway, my suggestion is not about that, and fixing the problem with fake suns will not help with the incorrect calculation of relative positions.
Did you use that dirty tweak of mine? Here I suggest a more "right" way to do what it does, and which will work with custom populator functions.
Of course, the best way would be to ask for a world script handler that will be called before the populator function, but it would be nice to fix this problem now.
This is a change to the Planetary System itself, but so that other OXP authors can make their creations compatible with Strangers World.Cholmondely wrote: ↑Fri Sep 16, 2022 4:48 pmIf this is code for me to put in my oxp's I'll need more information as to where it goes ("we dumb pilots", and all that!). If instead you plan to rejig Stranger's oxp's, I hereby offer to test-pilot them for you (Clapham Omnibuses and Venetian Vaporetti permitting!).
To test it you need:
- Replace orbit.js in Planetary Systems with this file.
- In an OXP that have this.systemWillPopulate (for example, Commies) add to begining of the function those lines:
Code: Select all
if(worldScripts["PlanetOrbits"]) worldScripts["PlanetOrbits"].setUpSystem()
- Make sure you have SWBeforePopulator disabled.
- Check log file and if stations with OXP are in the correct places.
Re: Planetary Systems
Dirty as your previous solution was, it didn't require that other OXPs beyond Planetary Systems be modified.Alnivel wrote: ↑Fri Sep 16, 2022 4:17 pmHere is an idea how to improve a bit compatibility with OXPs that use relative coordinate systems in the system populator functions -
Add a method for them that will allow them to set up the system before they start working with their coordinates like this:
<snip>
This is much cleaner (I usually cringe when I think about one OXP modifying the functions defined by other OXPs... if it becomes common, debugging - and finding the culprit OXP - will turn into a nightmare...), but updating all OXPs that would need it to run well with PS would in many cases fall to the end user (because the author can't be reached and the OXP license doesn't allow modifications, because the author is still around but doesn't see value in making his/her OXP PS compatible, etc.)
- Cholmondely
- Archivist
- Posts: 5366
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Planetary Systems
Brilliant! Thank you! For the first time ever in my game the Commie systems look the way that they should. Thank you, Alnivel, you seem to have finally fixed it. Inonri's SLAPU was right up against the sun, inside the blinding glare, etc. Wonderful!Alnivel wrote: ↑Fri Sep 16, 2022 6:43 pmHere I suggest a more "right" way to do what it does, and which will work with custom populator functions.
This is a change to the Planetary System itself, but so that other OXP authors can make their creations compatible with Strangers World.
To test it you need:
- Replace orbit.js in Planetary Systems with this file.
- In an OXP that have this.systemWillPopulate (for example, Commies) add to begining of the function those lines:
Code: Select all
if(worldScripts["PlanetOrbits"]) worldScripts["PlanetOrbits"].setUpSystem()
- Make sure you have SWBeforePopulator disabled.
- Check log file and if stations with OXP are in the correct places.
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- Cholmondely
- Archivist
- Posts: 5366
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Planetary Systems
Progress Report on Alnivel's latest fix (just above!):
I've now been using this for a week. No problems. Not one! And some of the other oxp's also seem sorted, despite my not tweaking them! I probably did not need to tweak Commies.... just add in Alnivel's fix to Planetary Systems itself...
This does not however fix the issue with the delayed deployment of the system which only seems to affect Galactic Almanac. But that is minor - and LittleBear's oxp'ed comment on it is very amusing...
I've now been using this for a week. No problems. Not one! And some of the other oxp's also seem sorted, despite my not tweaking them! I probably did not need to tweak Commies.... just add in Alnivel's fix to Planetary Systems itself...
This does not however fix the issue with the delayed deployment of the system which only seems to affect Galactic Almanac. But that is minor - and LittleBear's oxp'ed comment on it is very amusing...
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
Re: Planetary Systems
As Cholmondeley noted, one OXP using this method will, as a side effect, "fix" other OXPs that call their populator setup functions after it.
But anyway, the main intention of this proposal was to make it possible for PS to be compatible with custom populators.
Can I ask if that tweak as a standalone oxz didn't work for you? In order for it to work, of course, you need to tweak PS (in orbits.js that I sent for testing, this has already been done), but it works fine for me.Cholmondely wrote: ↑Sun Sep 18, 2022 12:11 pm... For the first time ever in my game the Commie systems look the way that they should. ...
Calling the setUpSystem method sets up the system earlier than PS itself would, and all OXPs that set up the populator after calling this method (even if they didn't do it themselves) are already using "rotated" coordinate systems. SWBeforePopulator works on a similar principle - insolently get in front of the whole queue and set up the system before others start calculate coordinates in it.Cholmondely wrote: ↑Fri Sep 30, 2022 9:26 amI've now been using this for a week. No problems. Not one! And some of the other oxp's also seem sorted, despite my not tweaking them! I probably did not need to tweak Commies.... just add in Alnivel's fix to Planetary Systems itself...
Because the Galactic Almanac just checks if there is SW, not if it has already added all the planets, moons, etc., which SW usually does the first time only when starting from the station. If all this is moved early, then this stub screen can be removed (unless, of course, I missed something else), but this is just a minor inconvenience.Cholmondely wrote: ↑Fri Sep 30, 2022 9:26 amThis does not however fix the issue with the delayed deployment of the system which only seems to affect Galactic Almanac. But that is minor - and LittleBear's oxp'ed comment on it is very amusing...
If my memory isn't playing with me, somewhere on Roolite Stranger (should I write the nickname as it is, or with a capital letter?) mentioned that he moved this whole setup to launch from a station to speed up the game's load time. Unfortunately, this good intention turned out to be incompatible with showing the structure of the system before the player could see it with their own eyes.
- Cholmondely
- Archivist
- Posts: 5366
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Planetary Systems
Alnivel, What would you like me to try?Alnivel wrote: ↑Fri Sep 30, 2022 12:08 pmCan I ask if that tweak as a standalone oxz didn't work for you? In order for it to work, of course, you need to tweak PS (in orbits.js that I sent for testing, this has already been done), but it works fine for me.Cholmondely wrote: ↑Sun Sep 18, 2022 12:11 pm... For the first time ever in my game the Commie systems look the way that they should. ...
i) I can reset Commies to the old version.
ii) I can go back to the old Planetary Systems and stick your js.script in my Scripts folder in AddOns.
iii) I can do something else...
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?