I was just playing around in the editor and I noticed and when you set a moon or planet to orbit another that it can be set to an oval orbit, which is really fun to mess around with, however i find myself wanting to use this to make moons have an interplanetary orbit, as in, starting at planet 1 then when it gets to close to another, (if the planet 2 mass is high enough to counter the gravitational pull of planet 1), it would then transfer into an orbit around planet 2. This is an odd topic, and I'm not sure i made myself clear, but i was wondering if this is a possibility in future system editor updates? I feel that this would be a very interesting addition to the interplanetary game play.
Nice Idea. very interesting. I dont think this is planned but I dont see any reason y this shouldnt be doable. At any rate if it doesnt make it in at initial release im sure some modders will look at this and be able to do it
Yeah as it is it seems to just be outside the scope of the game. Maybe well past release when they have the time to work on more niche stuff liek this. On the flip side Uber does want it so that once you get an asteroid engine'd up you can send it into orbit around other planets instead of just crashing it into it so you can artificially recreate this at least. Mike
It shouldn't be that hard to implement. Each planet requires a velocity property that constantly gets added to position. For each planet add all the other planets' masses divided by the target planet's mass that has been multiplied by the squared distance of the planets, then multiply the result with the unit direction vector from the target planet to the pulling planet and then add the product to the target planet's velocity. Ok that sounded complicated. But the really complicated part would be predicting the orbits without just simulating that really fast. There's a slight chance it may have not been divided by the target planet's mass though.
This suggestion is cool, but unrealistic. I believe that it was already discussed in a thread a while back. I partially remember gravity being N-body for a little while and trying to get things to have stable orbits was literally impossible. The (small) scale of the systems means that you cannot discount the gravitational force from any body, so each and every body needs to be accounted for when calculating the solution for orbits. The only way that I could possibly see is having built in stable orbit points (A local minimum in the gravitational force curve at certain radii). This would make the force equation significantly more complex, but it would allow for these types of interactions to take place (in very controlled and calculated systems). I concur with Knight here; being able to control which planet a moon orbits with engines should suffice.
Actually, multiplying the distances before squaring their components enables the scaling of the effect, nearly nullifying the mass of the planets further away, allowing the smaller scale system to have the stability of a system with a larger scale.
A moon spontaneously switching orbits due to the proximity of two planets is an event so rare it's pretty close to "never". Why? Because two planets being that close to each other would interact directly with each other as well. The system would be unstable. Either the planets would throw each other into orbits further apart, or they'd end up orbiting each other, or possibly even collision or breakup would occur. Realistically, two planets would not form that close together in the first place, so that they ended up that close in the first place means an extremely rare event occurred to cause a very unstable system. In short, the whole scenario might sound cool, but it is unrealistic. +1.
I just explained how it is hard to code. To have a system that would allow moon juggling would mean that the moon needs to be aware of N-bodies rather than just the planet that it is orbiting. At that point, how do you code in when the computer needs to start calculating forces? A gravitational orbit isn't definable by any boolian, so it would need to be constantly taking the force from every body in the system into account, which means the orbits would be unstable. Look at it this way. You have 2 options. 1- 2-body calculation method (current one). Stable orbits. Only way to change orbits is by using Halleys. 2- N-body calculation method (proposed one). The possibility of actually having moons transfer to other planets (probably a 1:1x10^50 chance) and completely unstable orbits where having any more than 1 planet in the system would make it so that no planet would even be able to complete an orbit around the sun because the other planets threw it off course. There is no middle ground here; I would go with option 1.
Or you could look at the middle ground (which is in fact there waiting to be manipulated) which is the scaling system of the planets. Because this is a game it does not have to abide by real world physics, and the developers have already said numerous times that they are not making this game realistic, they are making it awesome. So you could classify any celestial entity that is movable by Halleys a moon, and celestial entities that are not movable by Halleys could be considered planets, and then you could then just have moons able to have their orbit switched if they came into range of a stronger gravitational pull. While having the planets completely un touched by any of that chaos that is real world physics.
I'd settle for the following: -Ability to use Halleys to tweak planet orbits using controls similar to the editor, plus swapping moons to new planets -Current "ANNIHILATE" option -Accidental collisions being possible if you, say, put your planet in an opposite-direction orbit and set it on a course to slam into another planet, or an oval orbit goes horribly wrong
I don't see how any of that is difficult to code, so I took the liberty of making an attempt to do it myself. Here is a kind of a formalization of the logic I came up with. for(int i1 = 0;i1 < numplanets;i1 = i1 + 1) { for(int i2 = 0;i2 < numplanets;i2 = i2 + 1) { if(planets[i1].Id != planets[i2].Id) { planets[i1].Velocity = planets[i1].Velocity + (planets[i2].Mass * n2) / square(magnitude(planets[i1].Position - planets[i2].Position) * n) / (planets[i1].Mass * n2) * unit(direction(planets[i1].Position,planets[i2].Position)); } } } The variables should be self-explanatory. With the correct number as n, the orbits should remain stable. As the logic makes an attempt to mimic real life, the spontaneous transferring of a moon from orbit to another is highly improbable, as expected.
I never said proper physics would be impossible to code, I said that coding stable orbits where moons are naturally juggled would be insanely hard to code... As I recall, there was a proper N-body simulation code at one time in the system editor (I believe it was alpha? can somebody help me out?) and it was impossible to keep stable orbits on anything. Your code would also have that problem and thus, doesn't prove your point.
The variable "n" I had there increases orbit stability. Due to the fact that the pull is divided by distance squared, multiplying the to be squared distance would make planets further away have less effect. Adding a variable that multiplied the mass of the pulling planet would, in turn, make heavier bodies have an increased effect and, hopefully, stabilize orbits. The correct plotting of planet orbits should also help them stay as they are supposed to be.
I don't think you understand what I mean by "stability"; I am talking about equilibrium orbits, not ones that happen to last a long time due to reduced long-range gravitational effects. Sure, decreasing the effect with distance would make it harder for planets to throw each other off course, but what it does do is ruin the orbital mechanics involved with the sun, as well as compounding the slingshot effects that were present in the N-body when planets DO come close. I really don't want to argue physics in a game forum. Your code is just a watered down version of the N-body formulas that are used and is still subject to their issues (even if at a -slightly- reduced rate).