Oolite Bulletins

After an absence of 2 or so years I've got back into Oolite. Hurrah. Love all the work that's been done so congrats to all involved.

One thing that I'm not sure of is how big a system actually is. Looking at System Redux all the planets seem quite close to each other. Is there anyway of editing the OXP to make them further away and therefore give a more 'realistic' system rather than have the planets bunched together like a Solar System poster you'd find in a school.

Just wondering. If not, then so be it.

Cheers everyone

G

Yes!

Oh you want a proper answer?

Well on mine I also use Orbits.oxp, which adds all the planets on orbits around the sun, and also can change the distances between planets and the sun.

Alternatively you could investigate the contents of the planetinfo.plist in the System Redux Config folder.

And for a general essay on distance and size in Oolite please consult the FAQ (last question in the Gameplay-section).

Thanks for the help guys.

Incidentally this discussion brings to mind a problem I have been having.

I use Orbits to add more than one planet to a system (by default it adds 6 planets).

I also use Planetfall and Planetfall Taxi to add destinations on the other planets/moons in the system. Sometimes the Taxi mission requires going to XXX Minor (replace XXX with the system name). It seems that XXX Minor could be any of the planets other than the main planet. I think this is odd behaviour.

The Advance Space Compass gives a heading towards the sun and the planet. However not for any additional planets, which is a pain on the taxi mission!

Thargoid wrote:

The Planetfall "minor" behaviour in unfortunately the best that can be done at the moment. It's simply because whilst we can add additional planets/moons etc to the system, currently we have names for only the system, not the planets themselves (and also no way to identify one added planet from another other than visually).

Hence why I just used "Prime" (the planet that would be there if no other OXPs were installed), "minor" (any added planets) and "moon" (any added moons).

Hmmm why can't you use the Greek alphabet, much like astronomers do?

So you could have planets called System Prime, System Minor Alpha, System Minor Beta, and so on? Also the greek characters are available in most fonts so you can use the actual symbols as well. That way you could use the character on the compass to identify each moon/planet,

Thargoid wrote:

If the underlying planetinfo.plist availability (and hence SR) could be improved, then PF could go to specific planets. But at the moment we can't tell them apart at a code level.

Sounds like a good suggestion for a future version of Oolite! I think Orbits' functionality could be built into the main code.

I wish someone able would create an oxp that made real solar systems.

My own rather pitiful attempts to do it always turned out as short of the mark I wanted to reach.

Even the scale problems can be solved, easily. Shove the sun away 3-6 times the usual distance, put the additional planets into a whole orbital plane and create jumpgates to witchpoint distances to them between them and/or some sort of inner system jumpdrive - voila.

I really hope someone does (and finishes) this one day. Frame made a good start at some point, but got frustrated with it I remember

That would only solve some of the scale problems, and would certainly not create a "real" system, but if it could be done nicely... I can see some nice changes due to multiple planets -- each could have its own station, and it might become viable to have player ships that are not witchspace capable and just trade inside a system.

There are problems, for example the system descriptions are really of a planet, and we would expect to see different climate, industry (due to varying minerals etc) for each planet, none of that fits the existing model.

A problem for me is that I dont see how any of this can be done without fundamentally changing the game dynamics.

For me, and this is a personal view only, I think that oolite would need a lot of changes, and a big move away from elite to do "real" systems justice. I think you would want to tweak the economies, the types of ships (lots of local traffic), redo all the system information etc.

Or it couls be just cosmetic and have some more balls of dust hanging in space in plane, but I think thats quite easy and to me, not very rewarding.

Thargoid wrote:

And unless I'm mistaken, the fundamental problem is that you can't actually name the added planets and moons (in planetinfo.plist or wherever you add them code-wise to the system - the name key there is the name of the whole system)

This is semi-not-true: you can add arbitrary properties to most objects in JavaScript, so you could set planet.name even though Oolite doesn’t currently define it, and establish it as a de facto standard for scripts. (This is potentially dangerous in that Oolite might add a conflicting property in future, but in this case I think it’s safe to say that a standard planet.name would be a read/write string.)

The problem is that system.addPlanet() and system.addMoon() (being wrappers for legacy stuff) don’t return the new planet so you can manipulate it. This looks easy to fix, though is fixed for 1.74.

Lestradae wrote:

Even the scale problems can be solved, easily.

No, it couldn’t. As Frame has pointed out vociferously, you run into numerical precision problems if you try to make the system too big.

JazHaz wrote:

Thargoid wrote:

If the underlying planetinfo.plist availability (and hence SR) could be improved, then PF could go to specific planets. But at the moment we can't tell them apart at a code level.

Sounds like a good suggestion for a future version of Oolite! I think Orbits' functionality could be built into the main code.

Only as a switchable option, please, if at all.

For me, the one system-one sun-one planet layout is part of the Elite-legacy. It is also deeply rooted in the game's layout (see the remark about the system descriptions). And Elite/Oolite simply isn't meant to "realistically" simulate a solar system.

This is not saying that it isn't nice to have plot-driven multiple planets in certain systems when doing a certain mission. But as a general feature, I don't want it.

Needless to say, this is just my personal opinion.

Ahruman wrote:

Thargoid wrote:

And unless I'm mistaken, the fundamental problem is that you can't actually name the added planets and moons (in planetinfo.plist or wherever you add them code-wise to the system - the name key there is the name of the whole system)

This is semi-not-true: you can add arbitrary properties to most objects in JavaScript, so you could set planet.name even though Oolite doesn’t currently define it, and establish it as a de facto standard for scripts. (This is potentially dangerous in that Oolite might add a conflicting property in future, but in this case I think it’s safe to say that a standard planet.name would be a read/write string.)

The problem is that system.addPlanet() and system.addMoon() (being wrappers for legacy stuff) don’t return the new planet so you can manipulate it. This looks easy to fix, though is fixed for 1.74.

Lestradae wrote:

Even the scale problems can be solved, easily.

No, it couldn’t. As Frame has pointed out vociferously, you run into numerical precision problems if you try to make the system too big.

Hnece the first 4 words in my post

The other problems are identifying the planet in-flight (as you can't target it - but that could be worked around using a comms message or something) and knowing which one to navigate to (a "very short range chart" or something on the (advanced space) compass would be needed).

But it wouldn't help planetfall, as I said before it just uses any added planets and moons that happen to be there, it doesn't add any of its own. And I think it adding its only planet/moon names to bodies added by other OXPs is asking for even more conflicts.

Identifying planets by greek letters is easy to implement. You just need to iterate over planets[] and check a planet's distance to the sun. The nearest is alpha, the next beta etc.

Oolite knows the Entity class. It has a method owner() which returns the parent object. Wouldn't it be a good idea to build a system as a tree, i.e. the owner of a planet is the sun, the owner of a station or moon is a planet. Then it would be possible to express distances in different units depending on the subsystem. You would measure distances between planets in AUs, distances between station and planet in kilometres. That could avoid foating point overflows and could also speed up rendering.