Oolite Bulletins

After reading in the forum that a few people had problems with Orbit, I downloaded version 1.2 to playtest it with the latest Oolite release.
Unfortunately, I couldn't get Oolite to crash, so the actual source of the freezes/crashes is probably within some other OXP, or maybe it's a specific combination of OXPs/OSs/video drivers...

However, after a bit of tinkering, I've managed to make Orbits compatible with Oolite v1.74.x.

It now requires v1.74 or above, and doesn't seem to generate errors.

I've tried to contact Ebi, the author of this OXP, but I had no luck. In the absence of signs of life from him, and without further ado, here's the link to the updated version:

Orbits 1.2.1

Any comments and / or bug reports about this new - possibly temporary - version, please reply to this post!

Cheers,

Kaks.

_________________
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

I had contact with Ebi about half a year ago. One of his problems was that he could not relocate the sun with 1.73. (The sun was relocated but the light still came from the old location. ) That light problem was fixed somewhere in January and I told him about this fix.
He intended to release a new version when 1.74 would be released.

_________________
UPS-Courier & DeepSpacePirates & others at the box and some older versions

Cool, the moment he returns to the boards, I'll make this version disappear!

_________________
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

All the planets look the same. 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:-

	"oplanet1" = {
		position = "spu 0 0 0.3";
		radius = 4000;	
		orientation = "0.0 1.0 0.0 1.0";
   	"polar_color_factor" = 1.0;
   	"rotational_velocity" = 0.0002;
	};

but apart from the radius and position, the definitions are identical and omit many possible parameters. And those parameters are inherited from... where-ever the main planet gets them from, and all the planets look like photocopies of one another.

Doesn't time fly? Ok, since Ebi is still MIA, I'll see what can be done to add some variety... hopefully after Switeck stops finding bugs in trunk!!!

_________________
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

http://www.box.com/s/1a72c8e8362b709d2e7d

Same script as version 1.2.1, but with very-slightly-better-looking planets.

On top of the planets all looking the same, there doesn't seem to be any moons (both moons of planets and planets-with-no-atmospheres) or gas giants.

Also, there doesn't seem to be any markers/beacons associated with the added planets, so it can actually be a little hard to find them all.

Are there any plans to update it for 1.80?

When I made the big update for Additional Planets, I naturally did some background research and tested this one also. The script is really cool, lots of maths there . 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 . It looks really weird when a planet behind the sun looks to be roughly the size of the sun. Because of that, I chose to position the planets behind the main planet when looking from the sun.

Need to get Additional Planets at last

IIRC this OXP broke with the release of 1.76. I was using it at the time and had to dump it. Can't remember what broke though.

Hi!

Someone has an opinions, ideas, help and feedback about the upgrade this pack for the Oolite 1.80 and more.

Started an investigations are underway, it might take a some time.

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.

Hi stranger. For what it's worth I think your English is quite good, and certainly not 'terrible'.

You summarise the issues with orbits very well. The goal of a dynamic system has much appeal in terms of variety - it would certainly make milk runs more interesting but at least one of the problems it presents is major.

I worked with spara on the additional planets oxp (he coded, I textured and gave feedback) and the small sun was a massive (ahem) issue.
As has been said, we went for a 'cinematic' look, so other planets weren't just dots in the distance, they were scenery, and moons lined up politely in little rows.

Looking at it now I think we got most of the decisions right (at least in the context of oolite) and avoiding planets on the far side of the sun was one of those I think. However, if dynamism is better then what can be done?

[Accepts vodka suggestion and ponders...]

• Visual Problems
  Small stars
  Eclipses (severe occurances)

What if only the moons orbited?

Real planetary orbits tend to take a long time (months or years) whereas moons can be shorter. Player travel is in hours/days and so player needs to travel to one system a lot or have an excellent memory to recall subtle changes in planetary positions.

• Advantages/Disadvantages
  No star issues
  Eclipses are interesting rather than severe
  Scope of system dynamism is reduced

Not every planet has moons of course but that only adds to the variety.

Orbiting requires a certain scale to look right IMO and so it can be achieved reasonably well with moons but not easily with planets within the typically cramped confines of the solar systems that oolite generates.

_________________
"With our thoughts, we make the world"

To Redspear

Thank you for interesting discussion!
Dynamic moons will be really interesting addition to Ooniverse. I have some experience realizing this idea. Planning to present it later. But let’s return to planets. Right. Let’s define main planet orbit radius as 1 OU. According to Third Kepler Law planet with orbit radius 4 OU will have orbital period 4^1.5 = 8 local years. Main planet orbital period in Orbit is 300 days – canonic year of Lave. So 8 local years will be 8 * 300 = 2400 days or 6.5 our Earth years. Seems precise modeling of such orbital periods will be overkill in terms of game setting.
But wait. Using real sun mass and luminosity as modeled in Sun Gear I have orbital period of main planet 90 days or so in system of red dwarf. Rebalanced Leesti with orange dwarf sun has a bit longer orbital period 115 days. Leesti-Diso trade route is most favored milk run opportunity for green Jameson. Having OXPs simulating dynamic market you can leave Leesti to search more profit in Tionisla-Isinor trade route for example. Returning to Leesti a week later you’ll see 22° changing of sun position – a visible effect on planet illumination. So planet dynamics gives quite noticeable visual changes and really adds flavor of dynamic world.