Movable Planets?

The starmap updates immediately, even if it’s open. On occasion, the moon vanished from the map, but it re-appeared when I zoomed or centered on another object.

I was wondering about the angular velocity, too. It’d be nice to stop a planet (or better, make it rotate reeeealy slow).

Seeing as stations are also map entities, the same commands can place them just like moons. I don’t see any issues there.

The way I figure I’ll do it is to work in levels. Level 0 can be the system center. Level 1 is everything orbiting the system center (i.e., the star). Level 2 is everything orbiting the star. Level 3 is everything orbiting a level 2 object. Level 4 orbits level 3, and so on. When it’s time to position, I build the level tree, then place the level 2’s, then the 3’s, then the 4’s, and so on until I run out of objects.

Can a function call itself? That would be better. I could make one so it positions an object and calls itself on each child (unless no children, then it just positions and returns without calling itself). That would work nicely, unless POG doesn’t like that kind of nesting.

Alternatively, iMapEntity.GeogIndex is probably the order that it’s in the map file. And that’s in order of parent-to-child. I could make a list of all map objects, sort it by GeogIndex, and run down the list.

The L-Point that a player jumps to will move, too. I’ll need to make sure the player exits at the L-Point, and not where it was five days ago.

Finally, I will need to know how far to advance each system when the player enters. I have two ways of doing it:

1. Knowing where everything was initially, and advancing it by the campaign time. As far as I know, there is no way to read the map file through POG, so an ini file would be needed to keep track of it.

2. Keep track of when the player last visited a system, and then advance it by the difference in time when it’s arrived in. This would need a global for each system (so it saves out). Rounding errors will eventually add up, so the system might not be in the exact place it would be under option 1, but it would be really tough to notice.

I’m leaning towards option 2. Twenty-seven globals isn’t that bad. If we use randomly generated systems, then we can save their initial positions (via globals), use option 1 on them, and option 2 on the regulars. If we ever want elliptical or tilted orbits, then we need extra orbital data on the main 27, needing an ini file (at which point we might as well use option 1). Random systems can save their orbital data in the globals.

Wow. The flux engine never ceases to amaze me. I'm really interested in seeing what you can do with this Mdvalley.

Oh, and I fixed the site. You should be able to upload now. A few weeks back I had to reinstall the file system, and I haven't tested user uploading since. It should be good now. Let me know if it isn't.

PS Do you want a custom sig mdvalley? In the same vein as Shane perhaps...maybe with a star or planet in place of the ship? I think that would suite you more, as you are the astronomical wizard.

Once case you will want to check is where do the moons and planets go when you shut down the game. My guess is they go back to where they start. Which makes option 2 more difficult. I am guessing you will need some kind of record of where the planets start. The geog program could be modified to spit out such an INI file as it processes the system. It could even generate parent child information.

Now the only buttons under the download items are “Details�, “Download�, and “Unpublish�. Need that “Update� back and working.

Custom sig, eh? A star would do nicely.

After looking up some stuff, I found that the formulas for elliptical motion get really complex. Turns out it’s impossible to exactly say where a planet will be at time X and the best you can do is guess. Once you have that, you need to use either an arctangent or arccosine function to place it, and POG has neither. So more scouring got a good approximation function (read: even more code).

The way it’s set up, the full orbital data on a planet (or station) would need the following information:

Periapsis: The closest the planet gets to its parent.
Apoapsis: The farthest it gets.
Progress in orbit: From 0.0 to 1.0, indicating how far along it has been (time-wise) since periapsis at game start. (E.G., a value of 0.25 means that it is 25% of the way around, time wise. Objects with long orbits spend a lot of time at the far end.)
Pitch, yaw, and roll of the orbital ellipse. (Real astronomers use other methods for orientation, but this is more intuitive in my opinion and easier to code.) Zero is periapsis on the +Z (right as seen on map) with the long end going left.

That’s it. From those six numbers, a position can be calculated. Planets orbit clockwise (nothing’s stopping you from pitching it 180 degrees though).

Hmmm. so the system designer would need a new way to describe the orbit. And that means changes to the input format of Geog and the output format of save_type.

Rather than do all those changes, and then hit some hidden flux limitation that kills the whole project, I would just start with circular orbits. Then you get a chance to test the whole moving planets thing on a real cluster in undergoing real gameplay. Anyone could beta test your stuff.

And instead of using an INI file, there is code in the EpicFleet package that lets you triangulate an objects position. You could use this to locate all objects at the time the game starts. Assuming the objects return to standard position, it would give you the same information, without any geog changes or special files.

With those two adjustments, you could ship this as an add on that would work with any cluster in any game (not just torn stars). Once you know that flux will handle it, you can make it more complex.

Just my years of pog burned fingers speaking here. It would be quite cool.

Origianlly posted by Mdvalley
The starmap updates immediately, even if it’s open. On occasion, the moon vanished from the map, but it re-appeared when I zoomed or centered on another object.

Thanks... I'd wondered before whether the starmap updates constantly or only once (when opened).

Originally posted by GrandpaTrout
Rather than do all those changes, and then hit some hidden flux limitation that kills the whole project, I would just start with circular orbits.

Since the player interface (starmap) is 2-D, I'd think that anything other than simple rotation around the parent would not be noticed (by the player).

Consider this situation: After a great deal of work you get planets which move realistically. Planet A orbits on the standard system plane. Planet B is in a highly-elliptical orbit 90-degrees off-plane.

Because the Starmap is 2D, charting the movements of Planet B become problematic. At times it could (on the starmap) become eclipsed by the star (the player would find it difficult to select that destination).

In any case, when trying to communicate this orbital data to the player, you would be limited by the starmap's abilities. The player cannot discern location changes while flying in space (Hmmm... an EoC version of the Heisenburg Uncertainty Principal? ). The Starmap itself is the bottleneck here... not the POG code needed to move the planets about (which Mdvalley has just proved is possible).

What EoC needs to fully implement orbital mechanics is a good 3-D Starmap... and my hat would be off to any man who could build that!

Just some rambling thoughts. I'm very interested in this little excursion; one feature of the project I work on relies upon moving the player base from time to time at EnterSpace(). I'd wondered if it could be done with Flux. Congrats MD!