Distance between star systems

[qwery123]

What will be the average distance between different star systems?

[jastrone]

one will probably be very close or maybe orbit the original while others are a bit further away but we dont know

[Pthigrivi]

21 hours ago, qwery123 said:

What will be the average distance between different star systems?

We don’t know for sure, but if its anything like real life its a LONG way. Jupiter is 5.2 au from the sun, five times farther than the earth. The nearest star, Proxima Centauri is 272,000 au away, over 5,000 times Jupiter’s orbit. The Kerbol system is scaled down by a factor of 10, so its possible the distance to stars will be 1/10 as well, but even at that distance you’ll be a long way out even from Jool. 
 

Numbers like this tend to be unintuitive so I like using analogies. The difference between the earth and Jupiter is like the difference between 1 and 5 minutes. The difference between Jupiter and Proxima Centauri is like the difference between 5 minutes and 6 months. 

Edited September 7, 2021 by Pthigrivi

[MCWither_Storm]

On 9/7/2021 at 6:23 AM, Pthigrivi said:

Numbers like this tend to be unintuitive so I like using analogies. The difference between the earth and Jupiter is like the difference between 1 and 5 minutes. The difference between Jupiter and Proxima Centauri is like the difference between 5 minutes and 6 months. 

If the nearest star system is 5000 times farther away from the Sun than Jool is, that's a semi-major axis of about 343,867,801,600 kilometers.

To put that in perspective, the distance to the Heliosphere in our own Solar system is only about 18 billion kilometers. Even at a scale of 1/10 the distances are absolutely huge.

[PlutoISaPlanet]

Remember, in certain clusters, star systems are much closer to eachother than in our IRL local system.

[K^2]

On 9/7/2021 at 5:23 AM, Pthigrivi said:

The nearest star, Proxima Centauri is 272,000 au away, over 5,000 times Jupiter’s orbit.

The distances involved are huge, don't get me wrong, but a lot of that is going to be absorbed into using torch drives. In KSP, we are currently dealing with typical relative speeds of a few kilometers per second. For interstellar, the speeds will have to be in thousands of kilometers per second, and that's going to cut into the distance gap dramatically.

Using times for comparison is the right call, but we should also take into account the tech leap required to go interstellar. The efficient transfer from Kerbin to Jool takes a little over 1.5 Earth years of real time. The maximum time warp of 100k reduces that to about 8 minutes.

Now, suppose you have a torch drive that can provide you with sustained 1g of acceleration. If we take the same 1/10th scale distance to Proxima Centauri, the trip there is a little under 1.3 Earth years of real time. Again, if we can get the same 100k time warp, we can be making a trip there in under 7 minutes. This is very reasonable. And in fact, interstellar trips taking a few minutes of real time is right there in the ballpark of what would probably be good gameplay.

The real trick here is maintaining these 100k of simulation speed multiplier with engines running. You can push physics warp a little past what vanilla KSP lets you, but even if you mod the game to remove that cap, you aren't getting into anywhere near the numbers you need here. So it would have to work different. Crucially, however, not having some kind of warp that lets you run engines isn't an option. Times required to reach outer planets of KSP are already on the silly side. So Intercept is in a bit of a bind. They can't place other stars too close, because then you could get there with chemical rockets by just waiting a little longer, and they can't put the stars really far away without relying on something like physics warp, because nobody is going to wait for a real life month to get there. So it's a problem Intercept will have to solve, and we can assume that we will have ability to use torch ships with time warp.

So where does this leave us with interstellar distances? Well, if Intercept can squeeze out the same 100k multiplier, the 1/10th scale is still very reasonable for interstellar distances. If not, how far can the distances be shrunk? The really icky part is that distance is quadratic in time under constant acceleration. So if we still want the trip to be under 7 minutes and we can only do 10k time warp, the distance would have to go down by a factor of 100, or be just 50 times further out than Jool. That would border on broken, because a rocket that can cross that distance in a few hours under warp can be built with tech we have in KSP, and that doesn't feel sufficiently interstellar. So the time warp in KSP2 can't fall much bellow the 100k we have in KSP while still supporting torch drives. And then we're fine with Kerbal-scale versions of real interstellar distances.

[Pthigrivi]

2 hours ago, K^2 said:

The distances involved are huge, don't get me wrong, but a lot of that is going to be absorbed into using torch drives. In KSP, we are currently dealing with typical relative speeds of a few kilometers per second. For interstellar, the speeds will have to be in thousands of kilometers per second, and that's going to cut into the distance gap dramatically.

Using times for comparison is the right call, but we should also take into account the tech leap required to go interstellar. The efficient transfer from Kerbin to Jool takes a little over 1.5 Earth years of real time. The maximum time warp of 100k reduces that to about 8 minutes.

Now, suppose you have a torch drive that can provide you with sustained 1g of acceleration. If we take the same 1/10th scale distance to Proxima Centauri, the trip there is a little under 1.3 Earth years of real time. Again, if we can get the same 100k time warp, we can be making a trip there in under 7 minutes. This is very reasonable. And in fact, interstellar trips taking a few minutes of real time is right there in the ballpark of what would probably be good gameplay.

The real trick here is maintaining these 100k of simulation speed multiplier with engines running. You can push physics warp a little past what vanilla KSP lets you, but even if you mod the game to remove that cap, you aren't getting into anywhere near the numbers you need here. So it would have to work different. Crucially, however, not having some kind of warp that lets you run engines isn't an option. Times required to reach outer planets of KSP are already on the silly side. So Intercept is in a bit of a bind. They can't place other stars too close, because then you could get there with chemical rockets by just waiting a little longer, and they can't put the stars really far away without relying on something like physics warp, because nobody is going to wait for a real life month to get there. So it's a problem Intercept will have to solve, and we can assume that we will have ability to use torch ships with time warp.

So where does this leave us with interstellar distances? Well, if Intercept can squeeze out the same 100k multiplier, the 1/10th scale is still very reasonable for interstellar distances. If not, how far can the distances be shrunk? The really icky part is that distance is quadratic in time under constant acceleration. So if we still want the trip to be under 7 minutes and we can only do 10k time warp, the distance would have to go down by a factor of 100, or be just 50 times further out than Jool. That would border on broken, because a rocket that can cross that distance in a few hours under warp can be built with tech we have in KSP, and that doesn't feel sufficiently interstellar. So the time warp in KSP2 can't fall much bellow the 100k we have in KSP while still supporting torch drives. And then we're fine with Kerbal-scale versions of real interstellar distances.

Im not a programmer but could there be a stripped-down physics warp that only accounts for mass, acceleration, and trajectory but treats the vessel as rigid?

[K^2]

18 hours ago, Pthigrivi said:

Im not a programmer but could there be a stripped-down physics warp that only accounts for mass, acceleration, and trajectory but treats the vessel as rigid?

Yes, it'd have to be something like that, I think. But there is still a lot going on. Resource use has to be accounted for, and KSP had it set up in a way where it was a huge resource hog just to process fuel priorities. (I haven't looked at that code, but I suspect either a bug or bad algorithm. Performance of that system was terrible.) KSP2 should be better, but with a complex enough ship, it's still far from free. And then there is question of ship orientation. If you simulate torques, changes in orientation, and thrust applied in different directions, then not only do you have to reduce simulation time step to avoid errors, but you also have to consider how any stability/guidance systems will work. You could completely lock orientation, like regular time warp does now, of course, but then you basically don't have to think about thrust symmetry at all. Just slap engines wherever, and hit warp to prevent your ship from flipping. That's not great from gameplay perspective. You might want to have something in between. Perhaps, start with normal physics warp, and only if the ship remains stable, allow you to go into higher warp levels with engines still firing.

So while it's clear that what you have to do is simplify simulation and increase the time step it can handle for this particular case, the devil's in the detail of how to actually achieve it. And it's a mix of engineering and design challenges. So it's not immediately clear to me what the correct solution is. Intercept has good game designers, though, and had more time to think on it, so hopefully, whatever they came up with will be fun to play.

[MCWither_Storm]

There is just one problem I feel:
100k timewarp is not fast enough. I play with OPM, and I've sent a mission to Plock only once. That took ages at max time warp, waited about 15 - 19 minutes for the ship to finally get there.  There are a few mods that allow faster warps, perhaps that should be allowed once you get to about the distance of Jool?

[shdwlrd]

8 minutes ago, MCWither_Storm said:

There is just one problem I feel:
100k timewarp is not fast enough. I play with OPM, and I've sent a mission to Plock only once. That took ages at max time warp, waited about 15 - 19 minutes for the ship to finally get there.  There are a few mods that allow faster warps, perhaps that should be allowed once you get to about the distance of Jool?

The devs have said you can thrust under warp. That will speed up the transit greatly including higher time warp levels.

[MCWither_Storm]

2 minutes ago, shdwlrd said:

The devs have said you can thrust under warp. That will speed up the transit greatly including higher time warp levels.

True.  Hopefully thrusting under warp will help with using ion engines in KSP2.  
Only thing I can see might cause some problems is that fact that the SOI of Kerbol is infinite as of now. Wouldn't that mess stuff up?

[shdwlrd]

58 minutes ago, MCWither_Storm said:

True.  Hopefully thrusting under warp will help with using ion engines in KSP2.  
Only thing I can see might cause some problems is that fact that the SOI of Kerbol is infinite as of now. Wouldn't that mess stuff up?

You can't compare what is now in KSP1 to the future capabilities of KSP2. KSP2 is being developed from scratch with the new capabilities in mind.

[MCWither_Storm]

3 minutes ago, shdwlrd said:

You can't compare what is now in KSP1 to the future capabilities of KSP2. KSP2 is being developed from scratch with the new capabilities in mind.

True. But computers can only handle numbers so big before they begin to break down.

[shdwlrd]

1 hour ago, MCWither_Storm said:

True. But computers can only handle numbers so big before they begin to break down.

What are you referring to? If you're worried about the distances involved, Squad had a solution to that. And Intercept is expanding on that solution.

[K^2]

3 hours ago, MCWither_Storm said:

But computers can only handle numbers so big before they begin to break down.

Sure, in theory, but these numbers are considerably larger than what's reasonably necessary to assign every atom in the known universe a unique identifier and its coordinates with precision to within the Planck length.

As for using floating point arithmetic specifically, this is handled with origin relocation and is already part of KSP code.

[magnemoe]

On 9/12/2021 at 11:20 AM, K^2 said:

Yes, it'd have to be something like that, I think. But there is still a lot going on. Resource use has to be accounted for, and KSP had it set up in a way where it was a huge resource hog just to process fuel priorities. (I haven't looked at that code, but I suspect either a bug or bad algorithm. Performance of that system was terrible.) KSP2 should be better, but with a complex enough ship, it's still far from free. And then there is question of ship orientation. If you simulate torques, changes in orientation, and thrust applied in different directions, then not only do you have to reduce simulation time step to avoid errors, but you also have to consider how any stability/guidance systems will work. You could completely lock orientation, like regular time warp does now, of course, but then you basically don't have to think about thrust symmetry at all. Just slap engines wherever, and hit warp to prevent your ship from flipping. That's not great from gameplay perspective. You might want to have something in between. Perhaps, start with normal physics warp, and only if the ship remains stable, allow you to go into higher warp levels with engines still firing.

So while it's clear that what you have to do is simplify simulation and increase the time step it can handle for this particular case, the devil's in the detail of how to actually achieve it. And it's a mix of engineering and design challenges. So it's not immediately clear to me what the correct solution is. Intercept has good game designers, though, and had more time to think on it, so hopefully, whatever they came up with will be fun to play.

They has said you will be able to do trust during warp and I assume also wile not flying the actual craft.
Now an constant 1 g acceleration all the way is not very realistic nor efferent but the devs talked of months of acceleration. 

I think the main problem is that the acceleration will increase as you consume reaction mass, however I think you can make an calculation to find position even with this. 
I assume ship is static under warp but that it will loose mass and trust will end then out of reaction mass. 
You will need to go out of warp to do anything including shutting down the engine, you need as much dV to brake. 

As for distances my guess is 500-1000 times the distance to Jool.  It will still feel interstellar and you need to aim well to get within the system. 
Obviously any interstellar ship will make an joke out of interplanetary travel.  Played around a bit with nuclear pulse mods and with say 20K dV you can reach Eve in an week then its closest. 

[K^2]

34 minutes ago, magnemoe said:

I think the main problem is that the acceleration will increase as you consume reaction mass, however I think you can make an calculation to find position even with this. 

And thrust can vary depending on availability of some resources (e.g. electricity for ions,) and some engines might cut out or switch modes as some of the resources are depleted, and the rate at which mass is consumed will vary with all of that... And that is if we decide to just forget about the rotation and keep orientation frozen, which is very exploitable, but might have to be done.

And that's on top of gravity and possible SoI changes. This is a hard problem. It's solvable, but KSP struggles with it without any thrust at all, just keeping orbital junk on rails and doing SoI checks. KSP2 has to do all of that with, likely, more debris, and be able to do that with thrust applied to some of the objects. And having both central potential and thrust in the mix makes the numerical solutions to differential equations way less stable. There are ways to work around it, if either can be treated as perturbation, but that's pages and pages of math on top of algorithmic complexity. And either way, this is going to be a lot of computation. If this was my project, I'd start asking questions like, "Should we really be doing this in C#?"

To be clear, I'm not saying that this can't be done, or even that it unlikely to be done by Intercept. It's just a lot of work, and it's not the only work that their physics engineer needs to get done. And we're still just talking about matching the 100k warp of KSP. Some corners somewhere might end up getting cut. Whether it's going to be simulation stability, ignoring some of the nuance of physics under warp, or simply smaller distances between stars remains to be seen.

[Gargamel]

12 hours ago, K^2 said:

Sure, in theory, but these numbers are considerably larger than what's reasonably necessary to assign every atom in the known universe a unique identifier and its coordinates with precision to within the Planck length.

But if we do that... we'll never know how fast they're going.

[MCWither_Storm]

4 hours ago, Gargamel said:

But if we do that... we'll never know how fast they're going.

And that's kind of a problem.

[Gargamel]

2 hours ago, MCWither_Storm said:

And that's kind of a problem.

It's not, because it was a joke. 

[K^2]

12 hours ago, Gargamel said:

But if we do that... we'll never know how fast they're going.

0.5c^*

^* To within ±0.5c.

[magnemoe]

On 9/14/2021 at 1:15 PM, K^2 said:

And thrust can vary depending on availability of some resources (e.g. electricity for ions,) and some engines might cut out or switch modes as some of the resources are depleted, and the rate at which mass is consumed will vary with all of that... And that is if we decide to just forget about the rotation and keep orientation frozen, which is very exploitable, but might have to be done.

And that's on top of gravity and possible SoI changes. This is a hard problem. It's solvable, but KSP struggles with it without any thrust at all, just keeping orbital junk on rails and doing SoI checks. KSP2 has to do all of that with, likely, more debris, and be able to do that with thrust applied to some of the objects. And having both central potential and thrust in the mix makes the numerical solutions to differential equations way less stable. There are ways to work around it, if either can be treated as perturbation, but that's pages and pages of math on top of algorithmic complexity. And either way, this is going to be a lot of computation. If this was my project, I'd start asking questions like, "Should we really be doing this in C#?"

To be clear, I'm not saying that this can't be done, or even that it unlikely to be done by Intercept. It's just a lot of work, and it's not the only work that their physics engineer needs to get done. And we're still just talking about matching the 100k warp of KSP. Some corners somewhere might end up getting cut. Whether it's going to be simulation stability, ignoring some of the nuance of physics under warp, or simply smaller distances between stars remains to be seen.

Think we can be pretty sure it will be constant trust, so you could perhaps cheat here doing stuff like braking into orbit of with an solar powered ion drive. 
And no warp under trust past an Soi border. Nor change anything . Assume running out of one type of resource like oxidizer on an dual mode nuclear thermal engine will kill warp. 

Calculating the trajectory I think will be the most challenging part, here you will need to calculate all the steps to get it accurate who will take an long time for very long burns. 
But it might not works for long low power burns like burning one day to get an Minmus intercept. 

[mcwaffles2003]

13 hours ago, K^2 said:

0.499999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999c^*

^* To within ±0.5c.

Fixed

[K^2]

22 hours ago, magnemoe said:

Think we can be pretty sure it will be constant trust, so you could perhaps cheat here doing stuff like braking into orbit of with an solar powered ion drive. 
And no warp under trust past an Soi border. Nor change anything . Assume running out of one type of resource like oxidizer on an dual mode nuclear thermal engine will kill warp. 

All of these things have to be checked for during every time step, however, as you are computing the trajectory. It doesn't matter that any of these conditions will simply end Warp, you have to check where it happens, and where you cross SoI boundaries depends on your trajectory computations. So you have to do a single time step of trajectory update, perform all of the SoI checks, adjust ship's mass for fuel spent, then go to the next step. So if trajectory computation is complex and requires more steps, you have to do SoI checks more frequently. And because SoIs move on their own rails, these checks aren't trivial.

Fuel checks don't depend on trajectory, but at least the way KSP does these checks, aren't trivial either. Consider core stage + booster in KSP with shared plumbing. Main engine is burning fuel from core stage and the booster, while booster burns fuel from booster only. When the booster runs out of fuel depends on consumption on the main stage. If you are doing this check incrementally, you have to check your entire ship's plumbing on every single tick of the simulation. Yes, you can pre-solve fuel consumption and know at what time which engines will cut off, and it's something that should be done, but that does require special code to write, verify, and maintain. Since code for fuel checks during normal flight is designed to work on a request system, because it has to deal with variable thrust and I_SP. And this is the point I'm trying to make, not that it can't be done, but that it's a complex problem with a lot of tricky edge cases and a lot of custom-written code just for the purpose of solving the warp-under-thrust.

22 hours ago, magnemoe said:

Calculating the trajectory I think will be the most challenging part, here you will need to calculate all the steps to get it accurate who will take an long time for very long burns. 

That's all we're doing here. Computing trajectory and verifying that the ship has resources to stay on said trajectory and hasn't encountered any obstacles. But you do have to do all these checks still and you do have to mix them in with trajectory updates, because fuel consumption affects the ship's mass, which affects the trajectory, which affects whether or not you cross SoI and if so, at what exact position. And trajectory computations here are about the most expensive kind you get in simple mechanics. Gravity and thrust don't mix well computationally. So you end up with very short time steps to get accurate trajectory. And if you have shorter time steps, you need to do more checks on fuel and SoI because, again, you need these for every step.

And as a point of comparison, KSP had all the time-warped ships on rails. They just follow conic patches and check for SoI boundaries. No collision checks - you simply drop out of Warp if you get within certain distance of planets and moons, and no fuel checks, as the engines aren't running. And KSP still struggled at 100k warp with enough space junk floating about. In KSP2, this is so, so much worse. Of course, KSP's trajectory updates were very poorly optimized, so there are going to be a lot of wins right out of the gate by simply writing better code, but at the end of the day, it's still a hard problem for a tiny developer team.

This isn't to call for concern, or anything. From the very inception of KSP2, this was one of the core problems that needed to be solved, and I don't think anyone on the team would underestimate that, so I'm sure the necessary work has been put into it. But some corners might have had to be cut. 100k might be a little too much to expect. And if the time warp is any less than 100k, you basically have to pull in the interstellar distances from the traditional 1:10th scale. Alternatively, there might be limits on how many ships we have in flight under power during warp, which will make trip planning a bit harder. Or any number of other potential limitations or sacrifices made to make this feature work.

[magnemoe]

14 minutes ago, K^2 said:

All of these things have to be checked for during every time step, however, as you are computing the trajectory. It doesn't matter that any of these conditions will simply end Warp, you have to check where it happens, and where you cross SoI boundaries depends on your trajectory computations. So you have to do a single time step of trajectory update, perform all of the SoI checks, adjust ship's mass for fuel spent, then go to the next step. So if trajectory computation is complex and requires more steps, you have to do SoI checks more frequently. And because SoIs move on their own rails, these checks aren't trivial.

Fuel checks don't depend on trajectory, but at least the way KSP does these checks, aren't trivial either. Consider core stage + booster in KSP with shared plumbing. Main engine is burning fuel from core stage and the booster, while booster burns fuel from booster only. When the booster runs out of fuel depends on consumption on the main stage. If you are doing this check incrementally, you have to check your entire ship's plumbing on every single tick of the simulation. Yes, you can pre-solve fuel consumption and know at what time which engines will cut off, and it's something that should be done, but that does require special code to write, verify, and maintain. Since code for fuel checks during normal flight is designed to work on a request system, because it has to deal with variable thrust and I_SP. And this is the point I'm trying to make, not that it can't be done, but that it's a complex problem with a lot of tricky edge cases and a lot of custom-written code just for the purpose of solving the warp-under-thrust.

That's all we're doing here. Computing trajectory and verifying that the ship has resources to stay on said trajectory and hasn't encountered any obstacles. But you do have to do all these checks still and you do have to mix them in with trajectory updates, because fuel consumption affects the ship's mass, which affects the trajectory, which affects whether or not you cross SoI and if so, at what exact position. And trajectory computations here are about the most expensive kind you get in simple mechanics. Gravity and thrust don't mix well computationally. So you end up with very short time steps to get accurate trajectory. And if you have shorter time steps, you need to do more checks on fuel and SoI because, again, you need these for every step.

And as a point of comparison, KSP had all the time-warped ships on rails. They just follow conic patches and check for SoI boundaries. No collision checks - you simply drop out of Warp if you get within certain distance of planets and moons, and no fuel checks, as the engines aren't running. And KSP still struggled at 100k warp with enough space junk floating about. In KSP2, this is so, so much worse. Of course, KSP's trajectory updates were very poorly optimized, so there are going to be a lot of wins right out of the gate by simply writing better code, but at the end of the day, it's still a hard problem for a tiny developer team.

This isn't to call for concern, or anything. From the very inception of KSP2, this was one of the core problems that needed to be solved, and I don't think anyone on the team would underestimate that, so I'm sure the necessary work has been put into it. But some corners might have had to be cut. 100k might be a little too much to expect. And if the time warp is any less than 100k, you basically have to pull in the interstellar distances from the traditional 1:10th scale. Alternatively, there might be limits on how many ships we have in flight under power during warp, which will make trip planning a bit harder. Or any number of other potential limitations or sacrifices made to make this feature work.

My point is that you know the amount of fuel the engines has, now if you use cross feed the boosters will run out first. At least mechjeb is able to calculate dV for boosters with cross feed so that is the easy part. 

The hard part as I see it is to calculate the trajectory close to orbital bodies under trust, KSP 1 assume all maneuverer node burns are done in an instance but if you have low trust and do an long burn from LEO you can get significant errors. It might only be possible to leave an ship under trust in solar orbit or interstellar space as the gravity gradient is pretty low in solar orbit. 
Now I assume you can find your position with an set of equations, know you can with fixed acceleration but not sure with increasing acceleration and probably not with variable gravity who impact your orbital velocity. 

KSP 1 is pretty smart in that it handles SOI changes and collisions with plants and moons even then not under control. I assume it set do sample along the trajectory some time forward in time and put down internal break points on SOI changes and remove objects who impacts, you can get asteroids temporary captured by the Mun as an example and the Mun also kickes stuff getting into its SOI out into solar orbit. 
And assumes KSP 2 does something similar but with much more complex formulas. 
Warp under trust of an craft you control is simpler, here you simply calculate change in position, it might be separate warp limits for under trust to. 

Now showing trajectories for an burn under trust node will be very hard for all the reasons you describe above so I don't really expect the nodes to change their behavior.