More real astronomy in Oolite

[stranger]

Commanders,

Oolite is not planetarium software like Celestia. Too real astronomy will ruin combat-based game experience. But I think a bit more real astronomy will improve exploration mood without compromizing game balance.
This more real astronomy is not only concept. It was implemented in my OXPs and tested in Russian sector of Ooniverse. Some pilots likes this tweaked game world, some not.
I plan to present details in more relevant topics. Now general idea.

Suns

We have main planet and sun in all systems in vanilla game. And we have planet scale 1:100 and sun scale 1:1000.
We have vanilla population of main planets with radii in range approx. 2700...6900 km (27,000...69,000 m in game units) and suns with radii approx. 100,000...200,000 km (100,000...200,000 m in game units). Combination of Earth twin (radius 6378 km) with sun of 150,000 km radius gives sun/panet radius ratio in game units only 2.35. In real reality Sun has radius 109 Earth’s. It is too big ratio to implement in game, but in vanilla game you have too small gap between large planets and small suns. No room for additional super-earths, ice giants as Neptune or gas giants as Jupiter.
Possibly this is not case if you have only vanilla sun and main planet, but if you have additional planets, you need system configuration adjusted to mask comparable sizes of sun and planets, such as implemented in Additional Planets SR. Or just increase sun radii. Not up to sun/planet radius ratio 100:1 of course, but if you enlarge suns to range approx. 500,000...1,000,000 m in game units, you’ll have plenty of space for ice and gas giants (approx. 100,000...250,000 m in game units) and red dwarf sun with radius 500,000 m in game units still will be most prominent celestial body in solar system, not gas giant.
Large suns of course needs enlarged distance between sun and main planet. Presentation of distances in Oolite before version 1.80 in integer format was the main obstacle for creation of really wide solar systems. Since Oolite 1.82 it is possible. Distance between main planet and sun increased up to 20...40 times of default values seems good solution. IMHO vanilla sun is too close to planet. Having sun of 5x radius on distance 20x...40x you’ll have sun angular size 4...6x smaller. Not matching angular size of sun in our Solar system, but more real looking.
Norby in Far Planets was first who exploited possibilities of floating-point distance format, but Far Planets is more proving ground than overhauling of vanilla game world.
Recalibrated sun radii gives opportunity to simulate real proportions of main sequence sun radii (not real radii per se!). Having suns in approx. 500,000...100,000 game units range, you’ll simulate real proportions of sun radii in range from M2V (red dwarf) to F8V (white star). Moreover, increased distance between main planet and sun gives opportunity to simulate relative radii of habitable zones aka Goldilock zones.
Of course we have only sun radius in planetinfo.plist, not sun mass nor sun temperature etc. Using script we can simulate these additional parameters however.
Sun radius, declared in planetinfo.plist, is constant value. You have no possibility to change sun radius dynamically and simulate variable stars like Delta Cephei or Beta Ceti. The only cataclysmic exception is Nova event. In any case variable star is not right sun for densely populated planet with tropical biomes. Variable stars are conflicting with vanilla game setting.
OK, we have sun colors in planetinfo.plist too. Again we have no possibility to change sun color dynamically by script, but we can simulate red, orange, yellow or white members of main sequence in Ooniversum (IMHO blue suns seems a bit ugly). Up to Oolite 1.80 all vanilla suns were white, but since Oolite 1.82 we have colored suns in Oolniversum. Alas, sun radius and color seems to be uncorrelated parameters in vanilla sun population, but we can override these default settings with more realistic radius-color correlation.
Solar flares however are different case. Solar corona flare level is encoded in planetinfo.plist too, but it can be changed by script. This possibility was used by Rustem in Distant Stars. Pure ambience so far, but you can add scripted procedure of fuel collection from solar wind and space weather will be part of game mechanics.
Technically it is possible to simulate suns beyond main sequence range, but such suns seems bad candidates as host stars for habitable planets. Hot blue supergiant stars as Rigel has too short life span to provide enough time for evolution to form advanced biomes. Red supergiant as Betelgeuse is a short phase in star evolution. If you already have habitable planet on orbit of main sequence star and this star will transit to red giant, all life on planet will be gone due to enormous increase of sun luminosity. Such scenario can be realized as rare event, like vanilla Nova mission, in system-specific OXP, but not as regular case.

Vast (pseudo)dynamic solar systems

Not counting obsolete System Redux / System Demux above mentioned Additional Planets SR is only way to implement additional planets and moons on regular basis for all 2048 systems. Like old System Redux it generates unique, but static planet configurations for every system. Wait, it was also Orbits with pseudo-dynamic solar systems. Orbits calculates initial planet positions, gives game time and recalculates new positions based on Third Kepler’s Law on moment of start from station or entering new system. You have not only unique positions of planets for every system, you have changed positions of planets for every new visit to the same system.
I don’t know what was wrong with Orbits. It has too cryptic code for my skills and I understand general idea but not details of realization. But combination of pseudo-dynamic solar systems with recalibrated distances and planet radii gives interesting results: vast solar systems with inner terrestrial planets and outer ice/gas giants.
Such pseudo-dynamic approach can be implemented for moons too.
Moreover, for small moons it is possible to use true dynamic approach, based on AI behavior. Satellites OXP uses AI behavior for circular orbits. Adopting algorithm from Satellites for large dockable stations was realized in my OXP, but technically speaking asteroid is ship and you can use Satellites with asteroid models to simulate small moons.

More planet diversity, more reality

We have 2048 main planets in vanilla game. More or less hospitable maybe, but all these worlds has multi-billon population. Seems all these planets has breathable atmospheres (it seems a bit hard to maintain multi-billion population in pressurized domes). All Oolite main planets belongs to garden terra class in terms used in Elite Dangerous. Or M class planets in terms of Star Trek universe. It is game setting inherited from Elite: already colonized highly populated GalCop world. And it will not wise to break this setting.
But we have additional planets and moons too. Again we have only planet radius in planetinfo.plist, not planet mass, nor mean density, surface gravity, atmosphere density and temperature etc. By default planet radius is the only one parameter influencing game mechanics (radius of planet mass-locking). Well, atmosphere with aerodynamic friction may be second one. Again we can simulate additional parameters using script.
Possible applications? At the least, smart mechanism of planet texture selection based on atmosphere density and temperature. More or less favorable conditions for colonization and market diversity as consequences. Generation of specific missions.

More complex flight dynamics

Vast solar systems needs updated flight dynamics.
It is not case if you’ll exploit vanilla trade route from system entry point to main station. Distance from system entry point to main planet is 10...14 main planet radii, distance from main planet to sun in vanilla Ooniverse is 20 planet radii. Taking planet radius 6400 km (64,000 m in game units), you’ll have one or one and half minutes of flight on Torus drive from entry point to main planet for Cobra Mk III and two minutes from main planet to sun. Vast solar system with 25x sun distance multiplier means 50 min flight to sun and 5 hours of flight to remote gas giant on 6 OU distance (I prefer OU definition as distance between sun and main planet in local system, not in Lave system). A bit too long journey IMHO. And you need the same time for return.
This was the case for Norby to realize “quantum leap” FTL drive to cover enormous distances in his Far Planets. This was before Oolite 1.82. And now we have Norby’s Torus to Sun based on the same principle of “quantum leap” Torus drive. But now we have direct control of flight dynamics. Idea of my warp drive is simple: in free space (green state) parameter player.ship.maxSpeed is variable, proportional to distance to sun. There are some technical moments in this idea, such as scanning potentially dangerous objects beyond scanner range to avoid possible collisions, and Norby’s Far Planets / Torus to Sun realizes such early warning mechanism. Details will be in relevant topic.
Too long flight time to remote objects is not the only problem with vast solar systems. Finding these objects is a challenge too. Advanced space compass is useful, but not obligatory device if planet of destination looks as illustration in astronomy handbook. But ASC is must-have device if your target is just pale blue/green/red dot. I like this new feeling. It makes space travel more realistic.

[another_commander]

Interesting read, thanks. Just a small correction:

Again we have no possibility to change sun color dynamically by script,

This is not right. We can change sun color by script using e.g. system.info.sun_color = "blueColor";

[stranger]

Interesting read, thanks. Just a small correction:

Again we have no possibility to change sun color dynamically by script,

This is not right. We can change sun color by script using e.g. system.info.sun_color = "blueColor";

Thank you for correction!
And technical question - is it possible for sun color in RGB or HSB color space, not simple named colors?

[another_commander]

is it possible for sun color in RGB or HSB color space, not simple named colors?

It is possible to enter a sun color as any kind of string description. Strings representing RGB triplets separated with spaces and color identifiers will both do.

system.info.sun_color="1.0 0.6 0.3"
system.info.sun_color="50 38 185"
system.info.sun_color="yellowColor"
are all acceptable.

[stranger]

Thank you for this info, another_commander!

[Day]

Having simple solar systems is ok for a game where the player is traveling from systems to systems.
But for activities taking place mainly in one system, for example having a pirate base, a too simple solar system is too limiting.

So I think that developing Oolite geography will allow for more game scenarios

[stranger]

So I think that developing Oolite geography will allow for more game scenarios

Yes. Having additional planets and ports in system with custom markets and custom rules you'll have additional game dimensions. Emergent complexity

[Cholmondely]

Stranger's Feudal Raiders OXP now has a wiki page with a download link: https://wiki.alioth.net/index.php/Feudal_Raiders.

It piggybacks on Ramirez's Feudal States OXP, creating wild feudal raiders both inside those states and raiding the neighbouring systems (depending on the local governments).

I'm placing this announcement here so that Stranger sees it and can create his own dedicated BB thread for it. This seems to be the most generic Stranger's World thread!