Movable Planets?

mdvalley, just try clicking the 'submit' link that is just below a small upload icon on the top of the downloads page. That should take you to a page which will allow you to upload a new file. I haven't got editing of old ones working yet.

And I will have a 'star' sig ready for you shortly

I would also have to echo what GrandpaTrout said...just getting a working version of this orbital mod, that could be applied to Torn Stars or other mods in the pipeline, would be a good and safe first step.

What I think I should do about the orbital data is a kind of hybrid system between options 1 and 2. If an object has an ini file entry, calculate it with the elliptical formulas. If it doesn’t, assume a circular orbit and simply advance it.

I could use globals to keep track of when the player last entered a system, so it knows how far to advance the circles. (Ellipses get recalculated from the ini’s). On loading a save, it uses the campaign time to advance the whole system that far from 0. Rounding errors shouldn’t be an issue (ellipses always calculate from zero, and circles calculate from zero on every save game load).

And yes, I plan on making this package work on any conceivable system.

I am now the proud owner of one (mostly) functional solar system.

As typical in programming, the part expected to be hard (the ellipses) was the easy part. The part expected to be easy (the circles) was the hard part. And the part expected to be hair pulling (the L-Points) was hair pulling.

The ellipses was simply taking formulas off the internet and implementing them. The pitch/yaw/roll aspect took a little thought, but it wasn’t that bad.

For the circles, it was just finding out where the moon was relative to the planet, and then advancing the angle, right? Wrong. It turns out that in POG, there is no direct way to find the exact position of an object relative to any other object. You’d think the vector property “position� would do it (in the Sim package), but despite possessing the property, the bodies all had it as (0, 0, 0). I had to create three waypoints at known positions, and, using only the distance and arc tan, triangulate the moon’s coordinates.

Finally, the L-Points. In the map file, an L-Point has two parents. In POG, it has one. If there’s a way of reading the other parent, I don’t know it. I had to write a nice big chunk of code to find out. Basically, it looks in the opposite direction of its parent for the closest item that is its sibling or its grandparent, system center excluded, but that was a pain to code and debug. But “hyperbolic body locator� sounds cool (the formula used ends up with the search area in the shape of a hyperbola).

When it comes time to place our L-Point, it uses the masses of the objects to calculate the position (already had that formula lying around). It checks to see if the L-Point is too close to the moon. If it is, then it moves it away to the edge of the safety zone (safety zone is 1.25 times the moon’s radius plus 200km).

Sim.PointAt worked as advertised. L-Points point at whichever object shares the first three characters of its name (the moon if both or neither).

Hard-coded ellipses work; I haven’t tested ini-read ellipses.

The package only supports circular orbits on the ecliptic. An off-plane object has an infinite number of possible orbits. Rather than guess one, the code simply places it back on the plane. Off-plane circular orbits can be entered via the ini file.

For some reason, asteroid belt markers don’t orbit. I’ll have to look into that.

Any object orbiting a zero-mass parent (L-Point, belt marker, station, system center) does not orbit. Its (absolute) position relative to the parent is unchanging. Right now, nebulas are counted as zero-mass, too. I might change that if anyone happens to know the mass of an EoC nebula.

Planets orbit the star much faster than their moons orbit them. I think it is because the planets are so close to the star, and the moons so far from the planets.

I discovered that you can resize a star simply by changing its “radius� property. Go figure. Unfortunately, the autopilot doesn’t notice the change and will happily fly you into the surface.

The mod depends on uString for the ini part of it (easy enough to cut ‘n’ paste the code over), and tTime for the campaign time. So it’s almost self-contained. I could make a “demo� version that needs neither, and simply advances a day for every button press. (A lot like what I’ve been testing it as, really).

Amazing! I take my hat off to you, Sir!

This is the kind of thing that Mehrunes would have loved to see.

I guess we will need to be careful placing planets, so they don't overlap orbits....

That's incredible, Mdvalley. Really amazing. [8D]

I’ve run into the strangest bug.

I put tOrbit.PlaceSystem (the function that moves the planets) into the scripts.ini file, to be called on system enter. When I started the game, my ship wouldn’t turn. I got the head-move effect, but no actual turning. With some experimentation, I found that the only place tOrbit.PlaceSystem could be put is with the final_setup, and even then only after tEpicMain.FinalSetup. But having it that late in the setup causes problems with Torn Stars (and it only processes the starting system, too).

Thoughts?