How are Rask and Rusk going to work?

[Technical Ben]

9 minutes ago, KerikBalm said:

Its really not that bad, there's plenty of orbits that will stay there for 10,000 years, even ones that are stable for decades are fine for most purposes.

I only worry about the computational load

If it's stable for 10,000 years, even with "generation" ships in KSP, timeskip and smaller universe of the game, means why bother with n-body then? You'd not get to a point it actually matters in game (though it would in other sims).

[KerikBalm]

It would matter for some orbits, and not others.

It would certainly matter for orbits around a binary pair like rask and rusk

As I've said elsewhere, I think a good compromise would be 3-body physics with SOI that account for 2 massive bodies at a time (body 3 is the the orbiting vessel).

We don't need something that does calculations for the pull of eeloo and moho within kerbin's SOI for example.

Also if the system is made stable (ie change jools moon setup a bit) we could put the bodies on rails and just have the craft do the more complex calcs

[Teek]

I suppose I shouldn't hope for Outer Wilds style gravitational storms or lava asteroid planet destruction, but it would be cool! 

I am now really hoping that we get Lagrange points though, It'd be cool to build a few (hundred) colonies around there.  Fully adhering to the Antarctica treaty though, no colony drops.

[Xurkitree]

Do tell me guys.

In an n-body simulation, how do you set up the initial orbital parameters of Rask and Rusk such that they start orbiting together from the start? There isn't any central point around which they can be parented, and neither can they be set up to collapse to a binary after loading around whatever star they're around.

Meanwhile, for a body-on-rails thing, one can put them around a barycentre at the start. Maybe the barycentre can have some sort of HazardousBody effect that causes Ships to explode before they can come close enough for extreme orbital maneuvers.

Please, think about the practicalities of setting up such a system on the epoch, rather than thinking about its stability. AFAIK, even Principia can't set up Binaries from the outset. Its easier to just go for patched conics to set this up, and let the Kraken guard the barycentre.

[MDZhB]

4 hours ago, Xurkitree said:

Gravity doesn't work like that, you'd also have a naked singularity that would open up all kinds of abuse and would require modelling relativity to stop FTL speeds. Naked singularities plus a small burn right near the singularity = Holy Oberth-ing *expletive*!

4 hours ago, Xurkitree said:

The issue with the naked singularitiy is also kraken attacks. Venture too close and the kraken gets you.

Why not do what magnemoe said? Would this not work:

On 8/20/2019 at 6:14 AM, magnemoe said:

Now one cool tricks you could do is to have the gravity of the barycenter drop to zero as you get closer to it making it an fake larenge point.

[magnemoe]

4 hours ago, Xurkitree said:

The issue with the naked singularitiy is also kraken attacks. Venture too close and the kraken gets you.

You can get into an naked singularitiy in KSP if you clip trough the ground on an body with no atmosphere. 
This glitch out a lot, because of KSP physic, you fall towards it and speeds up, shortest possible time in KSP is 0.1 second, here the new acceleration and speed is calculated. Acceleration at last tick can easy be above an million g and you can get speed far higher than lightspeed., next tick will therefor be far from the singularity so gravity is much lower so you keep most of your speed. 
As game see you as moving above ground you can not switch but has to revert. 

36 minutes ago, Xurkitree said:

Do tell me guys.

In an n-body simulation, how do you set up the initial orbital parameters of Rask and Rusk such that they start orbiting together from the start? There isn't any central point around which they can be parented, and neither can they be set up to collapse to a binary after loading around whatever star they're around.

Meanwhile, for a body-on-rails thing, one can put them around a barycentre at the start. Maybe the barycentre can have some sort of HazardousBody effect that causes Ships to explode before they can come close enough for extreme orbital maneuvers.

Please, think about the practicalities of setting up such a system on the epoch, rather than thinking about its stability. AFAIK, even Principia can't set up Binaries from the outset. Its easier to just go for patched conics to set this up, and let the Kraken guard the barycentre.

Planets and moons will be on rails, anything else is asking for loads of bugs. 
Yes you might do cool stuff like two moons who swap orbits like two of Saturn's moons do. 
But its easy to script this.  

[TBenz]

11 hours ago, KerikBalm said:

Gravity doesn't work like that

Yes, but if we are stuck with a 2-body approximation model (which I think we probably are), then this is the best way to approximate a binary system that I can think of. N-body is very likely off the table here, and a special case 3-body system just for Rask and Rusk sounds like it could be problematic from a game design and implementation standpoint. 

11 hours ago, KerikBalm said:

you'd also have a naked singularity that would open up all kinds of abuse and would require modelling relativity to stop FTL speeds. Naked singularities plus a small burn right near the singularity = Holy Oberth-ing *expletive*!

I'm aware. Hence:

On 8/19/2019 at 10:05 PM, TBenz said:

The biggest issue is the question of what happens exactly at the barycenter? From what I understand of how KSP1 works, the physics would (somewhat) break down there. Perhaps they've fixed that for #2?

I'm probably going to hurt you even worse by saying this, but they could just slap a 4th, invisible, "SOI" in the middle with no gravity. Hardly a perfect fix, but hopefully a close enough approximation to work with a 2-body model.

[Drakenred65]

Recommended initial reading

 

https://en.m.wikipedia.org/wiki/Roche_limit

 

also see universal sandbox on you tube, a couple of people will be trying to replicate this!

[Bill Phil]

Maybe it’s not fully n-body but a kind of restricted n-body - where they set up a simulation and take out ephemeris data and just have that in the game - it’s how trajectory analysis is done in real life (at least initially). That would allow for full n-body for all planets without simulating the physics in game. Only the affects on spacecraft have to be calculated, and there may be a “range of ignoring” where the physics calculation ignores bodies beyond a certain distance. Or perhaps have a selective system that selects which point masses to use for the gravity simulation.

[neistridlar]

What if the small SOIs in this example were big enough that they actually encapsulate the barycenter. That would avoid the naked singularity issue, and replace it with the low gravity at the SOI edge.

[ChrisSpace]

18 hours ago, neistridlar said:

What if the small SOIs in this example were big enough that they actually encapsulate the barycenter. That would avoid the naked singularity issue, and replace it with the low gravity at the SOI edge.

Or, taking this a little further, have each planet's SOI hemispherical, intersecting at the barycentre, surrounded by the barycentre's SOI.

[Cunjo Carl]

One other thing to keep in mind is changing SOIs at high timewarp is hard on KSP, where rounding errors can cause craft trajectories to diverge rather suddenly. I suspect they won't want closed orbits to constantly hop between multiple SOIs.

For a specific 2 body system acting on a craft, I think they can precompute trajectories and toss them into a massive lookup table, like they do in present KSP but with an extra set of variables involved. KSP 2 is going to hog easily 3+GB of memory I'll bet, so 150MB of lookup table won't break their bank.

[M_Rat13]

Ok, I'm probably going to butcher real science, but what about some kind of push/pull system. As one planet gets too far from the 'rails', the other planet pulls in the veering planet, but this then pushes that planet away from the rails. The opposite then happens for each planet. Basically, the two planets allow some give and take, so they can change orbit a little, but then still ultimately right themselves before catastrophe strikes.

If someone understands what I mean, and can explain it better, please, do so. I'm really bad at this sort of thing.

[Cunjo Carl]

1 hour ago, M_Rat13 said:

Ok, I'm probably going to butcher real science, but what about some kind of push/pull system. As one planet gets too far from the 'rails', the other planet pulls in the veering planet, but this then pushes that planet away from the rails. The opposite then happens for each planet. Basically, the two planets allow some give and take, so they can change orbit a little, but then still ultimately right themselves before catastrophe strikes.

If someone understands what I mean, and can explain it better, please, do so. I'm really bad at this sort of thing.

Fortunately the planets themselves can be left on rails, despite orbiting eachother (see the video as an example). A space ship trying to fly between the planets though is another story...

 

[KerikBalm]

On 8/22/2019 at 8:01 PM, Xurkitree said:

Do tell me guys.

In an n-body simulation, how do you set up the initial orbital parameters of Rask and Rusk such that they start orbiting together from the start? There isn't any central point around which they can be parented, and neither can they be set up to collapse to a binary after loading around whatever star they're around.

Meanwhile, for a body-on-rails thing, one can put them around a barycentre at the start. Maybe the barycentre can have some sort of HazardousBody effect that causes Ships to explode before they can come close enough for extreme orbital maneuvers.

Please, think about the practicalities of setting up such a system on the epoch, rather than thinking about its stability. AFAIK, even Principia can't set up Binaries from the outset. Its easier to just go for patched conics to set this up, and let the Kraken guard the barycentre.

My Rald-Duna binary works just fine in Principia, with nothing needing to be adjusted:

It doesn't display the orbit of Rald around the barycenter, but Rald does move around the barycenter. The mass ratio of Rald to Duna is 3:1, and they are quite close (I should have zoomed just a little more so that Duna showed as a planet, and not a red Icon

On 8/22/2019 at 9:51 PM, TBenz said:

Yes, but if we are stuck with a 2-body approximation model (which I think we probably are), then this is the best way to approximate a binary system that I can think of. N-body is very likely off the table here, and a special case 3-body system just for Rask and Rusk sounds like it could be problematic from a game design and implementation standpoint. 

I'm aware. Hence:

I'm probably going to hurt you even worse by saying this, but they could just slap a 4th, invisible, "SOI" in the middle with no gravity. Hardly a perfect fix, but hopefully a close enough approximation to work with a 2-body model.

A very bad approximation that doesn't display the unique behavior for orbiting craft that it should.

 

On 8/24/2019 at 9:47 PM, neistridlar said:

What if the small SOIs in this example were big enough that they actually encapsulate the barycenter. That would avoid the naked singularity issue, and replace it with the low gravity at the SOI edge.

What you describe is the way my Rald-Duna system works without principia. Its a very poor approximation of the way it would actually work, and principia is needed to have it work right

[Xurkitree]

5 hours ago, KerikBalm said:

My Rald-Duna binary works just fine in Principia, with nothing needing to be adjusted:

It doesn't display the orbit of Rald around the barycenter, but Rald does move around the barycenter. The mass ratio of Rald to Duna is 3:1, and they are quite close (I should have zoomed just a little more so that Duna showed as a planet, and not a red Icon

A very bad approximation that doesn't display the unique behavior for orbiting craft that it should.

 

What you describe is the way my Rald-Duna system works without principia. Its a very poor approximation of the way it would actually work, and principia is needed to have it work right

I'm intrigued.How did you set it up? That's my question. I know that binaries are stable and all that, but are they in orbit around a body being a barycentre or have they created a barycentre of their own principia?

[chaos_forge]

1 hour ago, Xurkitree said:

I'm intrigued.How did you set it up? That's my question. I know that binaries are stable and all that, but are they in orbit around a body being a barycentre or have they created a barycentre of their own principia?

Orbits around a barycentre are an emergent property of n-body dynamics. Rask is exerting gravity on Rusk, and rusk is exerting gravity on Rask. The combined effect of that is that they rotate around their combined center of mass (just like any unconstrained system). "Barycentre" is just a fancy word for the center of mass of the system.

For another example, we can look to the fact that objects in space always rotate around their center of mass. When you build a rocket out of parts, the devs don't have to create a special "center of mass" object for the rocket to rotate around. They just set up the parts to follow the laws of physics and have certain predefined interactions with each other, and it works out that the rocket always ends up rotating around its center of mass. Because, well, that's physics. If you set up a simulation of objects that follow the laws of physics, you get the results that are predicted by those laws.

Edited August 26, 2019 by chaos_forge

[Xurkitree]

1 hour ago, chaos_forge said:

Orbits around a barycentre are an emergent property of n-body dynamics. Rask is exerting gravity on Rusk, and rusk is exerting gravity on Rask. The combined effect of that is that they rotate around their combined center of mass (just like any unconstrained system). "Barycentre" is just a fancy word for the center of mass of the system.

For another example, we can look to the fact that objects in space always rotate around their center of mass. When you build a rocket out of parts, the devs don't have to create a special "center of mass" object for the rocket to rotate around. They just set up the parts to follow the laws of physics and have certain predefined interactions with each other, and it works out that the rocket always ends up rotating around its center of mass. Because, well, that's physics. If you set up a simulation of objects that follow the laws of physics, you get the results that are predicted by those laws.

I'm talking in game, not IRL -

KSP's planets require an initial Orbit node, which contains all the orbital parameters at the epoch of the game. This also includes the reference body around which a body is orbiting. In the case of Rask and Rusk, which one orbits the other? In that case, with N-body mechanics, you'll have to wait a while before they stabilize into a binary pair, until then they'll continue to oscillate a bit. This means they aren't a binary at the epoch. Under patched conics, they wouldn't be a binary,  just a moon with the same size as the parent. Unless KSP2 has a completely different approach to setting up the inital orbital parameters of the planets, or allows orbits to be centered around any point whatsoever, i'd expect a body substituting the barycentre. My question about Rald/Duna was about the inital setup of the system, and in hindsight it seems obvious - Duna just orbits Rald, and it'll just collapse into the stable arrangement principia provides. The non-principia option is how most KSP binaries in planet packs are made - a barycentre orbited by the bodies you wants (Beyond Gnome being a meme good example)

 

[M_Rat13]

1 hour ago, chaos_forge said:

Orbits around a barycentre are an emergent property of n-body dynamics. Rask is exerting gravity on Rusk, and rusk is exerting gravity on Rask. The combined effect of that is that they rotate around their combined center of mass (just like any unconstrained system). "Barycentre" is just a fancy word for the center of mass of the system.

For another example, we can look to the fact that objects in space always rotate around their center of mass. When you build a rocket out of parts, the devs don't have to create a special "center of mass" object for the rocket to rotate around. They just set up the parts to follow the laws of physics and have certain predefined interactions with each other, and it works out that the rocket always ends up rotating around its center of mass. Because, well, that's physics. If you set up a simulation of objects that follow the laws of physics, you get the results that are predicted by those laws.

And suddenly, it all clicked. In KSP 1, you couldn't change the orbit of a body in the solar system, even something as small as Gilly. However, for Rask and Rusk to work, they need to be able to change each others orbits, so they force themselves to rotate around each other.

A 'simple' privilege system would do the trick, like a dev mode. In Dev mode, you can affect orbits of everything, but in normal mode (our mode), you can't. You'd have to somehow have both run simultaneously of course, which might have an impact on performance, and you'd have to find a way to stop players accessing Dev mode (apart from say, mods, to create you systems or tweak old ones), but, it would work.

[chaos_forge]

1 hour ago, Xurkitree said:

I'm talking in game, not IRL -

KSP's planets require an initial Orbit node, which contains all the orbital parameters at the epoch of the game. This also includes the reference body around which a body is orbiting. In the case of Rask and Rusk, which one orbits the other? In that case, with N-body mechanics, you'll have to wait a while before they stabilize into a binary pair, until then they'll continue to oscillate a bit. This means they aren't a binary at the epoch. Under patched conics, they wouldn't be a binary,  just a moon with the same size as the parent. Unless KSP2 has a completely different approach to setting up the inital orbital parameters of the planets, or allows orbits to be centered around any point whatsoever, i'd expect a body substituting the barycentre. My question about Rald/Duna was about the inital setup of the system, and in hindsight it seems obvious - Duna just orbits Rald, and it'll just collapse into the stable arrangement principia provides. The non-principia option is how most KSP binaries in planet packs are made - a barycentre orbited by the bodies you wants (Beyond Gnome being a meme good example)

All you need to define a physical system is an initial position and velocity for each object. Since the system is 3-dimensional, that gives us 6 numbers total: a position and velocity for each axis. The orbital parameters (which you'll notice are also 6 numbers) are just a fancy way to write the same information, just in a way that makes it easier to do certain calculations (like evolving the "on rails" orbit of a planet). So you can define the system however you want in Cartesian coordinates, and then just convert to orbital parameter coordinates, and you're good to go. It's just a coordinate change, nothing else.

Heck, you could even define Kerbin as orbiting the Mun for all it matters; as long as you have the right numbers to set up the appropriate initial conditions, it'll all still work out once you start the simulation.

50 minutes ago, M_Rat13 said:

for Rask and Rusk to work, they need to be able to change each others orbits, so they force themselves to rotate around each other.

A 'simple' privilege system would do the trick, like a dev mode. In Dev mode, you can affect orbits of everything, but in normal mode (our mode), you can't. You'd have to somehow have both run simultaneously of course, which might have an impact on performance, and you'd have to find a way to stop players accessing Dev mode (apart from say, mods, to create you systems or tweak old ones), but, it would work.

Yes, this is how it already works in Principia. The bodies aren't on rails, they just affect each other as determined by the law of Newtonian gravitation.

There's no need to have the planets be "locked" in their orbits. They're massive enough (and in stable enough orbits) that the player can't do anything to push them out of place.

Edited August 26, 2019 by chaos_forge

[M_Rat13]

1 minute ago, chaos_forge said:

Yes, this is how it already works in Principia. The bodies aren't on rails, they just affect each other as determined by the law of Newtonian gravitation.

There's no need to have the planets be "locked" in their orbits. They're massive enough (and in stable enough orbits) that the player can't do anything to push them out of place.

Challenge accepted. Well, not by me, but someone will try it, trust me. Especially if it's a small object like Gilly. Never underestimate a KSP player.

[Guest]

2 minutes ago, M_Rat13 said:

Challenge accepted. Well, not by me, but someone will try it, trust me. Especially if it's a small object like Gilly. Never underestimate a KSP player.

With the kind of engines and time warp needed for interstellar craft, I don't think it'd be impossible to shift Gilly's orbit, if it wasn't on rails that is. Unless it the effect is rounded out anyway.

Edited August 26, 2019 by Guest

[chaos_forge]

Just now, M_Rat13 said:

Challenge accepted. Well, not by me, but someone will try it, trust me. Especially if it's a small object like Gilly. Never underestimate a KSP player.

I mean, you can certainly try, but it's not really feasible. Celestial bodies are REALLY heavy. See this Scott Manley video for reference:

 

[M_Rat13]

6 minutes ago, chaos_forge said:

I mean, you can certainly try, but it's not really feasible. Celestial bodies are REALLY heavy. See this Scott Manley video for reference:

 

 

7 minutes ago, Brikoleur said:

With the kind of engines and time warp needed for interstellar craft, I don't think it'd be impossible to shift Gilly's orbit, if it wasn't on rails that is. Unless it the effect is rounded out anyway.

See. Already we have someone up for the challenge, and with an idea how to do it. Nothing's impossible in KSP, unless it's hard coded.

[chaos_forge]

1 minute ago, M_Rat13 said:

 

See. Already we have someone up for the challenge, and with an idea how to do it. Nothing's impossible in KSP, unless it's hard coded.

I suppose. I'll believe it when I see it.