Post
by stranger » Sun Dec 23, 2018 4:47 am
I’m using Orbits (version 1.2.1, original Ebi script modified by Kaks) since 2011 – initialy “as is”, later with my own modifications. No any problems with Orbits engine from Oolite 1.76 to latest Oolite 1.86, so script per se seems to be OK. There are some appearance and compatibility issues however.
Sorry for bla-bla-bla, but let’s remember in brief how Orbits works.
// pore a glass of vodka from decanter
Orbits did not generates truly dynamic systens. It generates pseudo-dynamic systems instead – calculates positions of planets according to Third Kepler’s Law on moment of start from station or entering systems. Planet positions remains unchanged until next start/visit.
Moreover, positions of all additional planets initially declared in planetinfo.plist between system sun and main planet. Script “inflates” this embryonic solar system. Inflation affects position of every additional planet. Distance between sun and main planet remains unaffected, but coordinates of planet-sun-witchpoint (psw) triangle redefines too. Witchpoint is global reference point with zero coordinates, so it remains unchanged. AFAIK coordinates of main planet remains unaffected too, so it is sun changing position in Orbits. In any case relative positions of all system planets, including main planet, are recalculated using sun coordinates as new reference point.
The radius of a planet determines the distances to its neighbors, so orbits of large planets are separated by wider gaps. Large planets forms natural looking “zones of avoidance”, clearing their orbit vicinity from other planets.
There are 7 additional planets in original Orbits. Subset of planets in every system created using system name as seed, so there are few systems there you’ll see all planet set – usually 3 or 4 are presented, in few cases none of them.
These dynamic rules generates unique natural looking planet configurations for every system and for every visit on the same system. Really cool.
Now let’s discuss above mentioned issues.
Appearance issues:
Planet textures are not declared in planetinfo.plist
This is not just oversight – it is mentioned in readme. I don’t understand reasons for such decision. Orbits was developed with possibility in mind to use it together with System Redux OXP. Maybe idea was to use planet textures already declared in System Redux planetinfo.plist, but in reality System Redux and Orbits creates separate planet populations – textured System Redux planets and “bald” Orbits planets with procedural generated textures. Well, now procedural generated textures with Perlin noise, reflecting water bodies and atmosphere haze are not so ugly as it was in Oolite 1.74. Problem is that all Orbits additional planets has the same procedural generated texture, declared in planetinfo.plist for main planet.
A simple obvious solution of planet texture issue: just declare planet textures in Orbits planetinfo.plist directly and add Textures folder with texture files onto Orbits OXP. Or declare Orbits planet textures linked to external texture pack such as Additional Planets SR texture packs. More sophisticated approach is adding to Orbits script with some smart algorithm of texture selection. Just one note: use unique names for Orbits textures to avoid matching with textures of other planets if you have any OXPs adding planets besides Orbits.
Comparable size of Orbits planets and sun
This is evident issue if you observe planet behind sun. In vanilla game you rarely have possibility to see planet behind sun, but in Orbits it is regular case. Oversized planet disk ruins fragile sense of game world reality. This is not fault of Orbits per se, this is limitation of game setting. So in Additional Planets SR planet configuration adjusted to “cinematic view configuration” to avoid such “malconfigurations”.
Large suns and vast solar systems will be alternative solution of this issue. Having sun as large as 10...20 radii of common terrestrial planet the sun will always be perceived as dominant celestial body, not nearest planets. Having gas giants faraway you’ll always perceive it from proximity of main planet as small disks despite relatively large absolute radii.
Eclipses
In vanilla Oolite you always enter system having the same pleasant view of illuminated disk of main planet. In Orbits you have frequent cases of entering system from night hemisphere of main planet, having only narrow crescent to observe. Sometimes you are entering system in full darkness of main planet shadow. Some players likes this feature, some not so. I like. It gives me sense of more dynamic game world and sometimes additional challenges. Finding Salvage Gang hidden in planet shadow is not trivial task. And I always have possibility to admire pretty planet texture on F7 system info screen, eh?
// hmm… just another last glass of vodka maybe?
Now more serious issues sometimes compromising compatibility with other OXPs.
Indiscriminate mechanism of system inflation
Orbits takes indiscriminately all planets, not only defined in its planetinfo.plist. This feature was not declared explicitly in readme and initially catch me in surprise.
The most obvious and possibly less problematic exampe is Diso.oxp, adding 4 planets and 2 moons on Diso system. Being positioned outside Orbits embryonic system, these precisely placed additional planets are repositioned by inflation on periphery of created solar system. This is problem for Diso, not for Orbits – in any case you must choose static OR dynamic solar system, not both. So just exclude these additional planets from Diso planetinfo.plist if you enjoy bright nebulae of this system. Or totally remove this OXP if not.
Well, there is some reef in inflation mechanism.
You have idea to add really large moon to main planet. Moon as large as our Moon (radius 1738 km) or so. Nice idea. But Orbits did not taking into account class of celestial body, declared as addPlanet or addMoon. All what Orbits taking into account is radius of celestial body. All celestial bodies with radii above 10,000 m in game units (1000 km in planetinfo.plist) will be considered as planets. So Orbits will rip off your pretty moon from planet and send it far far away. This is not exactly what you was planned.
Evident cure in this case is to increase value, discriminating planets from moons in Orbits script, up to 25,000 m or so. A bit more complex and possibly more adequate solution is to add small time lag to moon seeding script to place moon onto right position when generation of system is already completed.
System inflation is problem if you want place in system additional unique planet with precise orbital parameters. You can exploit above mentioned time lag to place such planet, but in this case your’ll need extra code lines to integrate orbit of custom planet onto Orbits engine or just create your custom orbital mechanics script for this planet instead. If precise orbit is not crucial, simple solution will be adjusting custom planetinfo.plist or just adding system-specific planet(s) to Orbits planetinfo.plist to insert your planet(s) between Orbits ones.
Positioning of moons and stations for additional planets
Orbits script needs some time to generate solar system, so a small time lag in seeding of moons and stations for additional planets will be most obvious solution again.
Alternative approach is to integrate seeding of such moons and stations onto Orbits script. Me think it is not good idea – it will be hard task to maintain synchronization of modified Orbits script with new OXPs, placing objects near additional planets. Well, we have few of such OXPs now, but me think new ones must be adopted for dynamic Ooniverse, not vice versa.
Problems with system populator
System populator in vanilla game and custom OXP populators based on assumption of static Ooniverse with fixed psw triangle coordinates for every system. Orbits modifies psw triangle. Planet-witchpoint (pw) side of psw triangle remains unaffected and most of system ships populates along pw axis, so Orbits has no dramatic consequences ruining game or just leading to notable changes. Part of system population, however, is spreaded along ps and sw sides of psw triangle, so some such objects can be misplaced (thanks, Rustem, this detail was originally missed in my perception of whole picture!). Again, this is possibly no case for dynamic system replenishment, but case of misplaced objects beyond main route needs more detailed examination.
In any case overhauled Orbits deserves attention as interesting alternative game mechanics with great potential.
// finish rest of vodka from decanter
And sorry for my terrible English, gentlemen.
If the main planet is green, all the added planets are green, if the main planet is white, all the added planets are white. Here's the culprit, Orbits defines seven possible planets, rather simply, like this:-
. What was not so cool was when a planet was positioned behind the sun. To me that was a total turn off as it revealed how small the in-game sun actually is 
