Distance between star systems

[Pthigrivi]

On 9/14/2021 at 7:32 PM, K^2 said:

0.5c^*

^* To within ±0.5c.

I cant remember exactly but I feel like in my reading about real-physics interstellar travel they were only accelerating to .15-.2c. I guess you're suggesting they might also want to buff that to get in-game time-warps down? 

One thing to consider in all this is that by the time you're sending interstellar vessels you've probably got an entire economy of other vessels tooling around the Kerbol system, and because all of these vessels require attention from time to time--launch windows, circularizations, dockings, minor course corrections, etc,  max-warping all the way to another star uninterrupted might not really be something that's likely to happen anyway. 

[K^2]

13 hours ago, Pthigrivi said:

I cant remember exactly but I feel like in my reading about real-physics interstellar travel they were only accelerating to .15-.2c.

This was in reference to particles whose positions are recorded exactly. Their momentum is infinitely indeterminate, meaning their speed can be anywhere between 0 and c.

[Wubslin]

So, I don't know if this footage has been available elsewhere but one of ShadowZone's recent videos has actually shown example Daedalus craft XYZ departing its orbital shipyard in a recent video. At about 9:23:

That is a RIDICULOUS amount of acceleration if we're going to be burning for months or years.  That was like, somewhere between 0.1 G and 1G. Which is nuts. If you ask me, it implies that although the Kerbol system itself is at a miniature toy scale then it seems that the distances in the local stellar neighborhood won't be. If anything, it almost implies that the planets you'll find out there will be more like the real life solar system in size. Is this a crazy guess? Maybe! That's still crazy acceleration if you ask me. 

[Bej Kerman]

3 hours ago, Wubslin said:

That is a RIDICULOUS amount of acceleration if we're going to be burning for months or years.  That was like, somewhere between 0.1 G and 1G. Which is nuts. If you ask me, it implies that although the Kerbol system itself is at a miniature toy scale then it seems that the distances in the local stellar neighborhood won't be. If anything, it almost implies that the planets you'll find out there will be more like the real life solar system in size. Is this a crazy guess? Maybe! That's still crazy acceleration if you ask me. 

Either that was timewarped - or, morel likely, we won't be burning for a very long part of the journey. The entire point of these propulsion methods are to create a high amount of thrust at a high ISP, yknow. We probably won't be accelerating the entire way at full throttle.

[K^2]

5 hours ago, Wubslin said:

That is a RIDICULOUS amount of acceleration if we're going to be burning for months or years.  That was like, somewhere between 0.1 G and 1G. Which is nuts. If you ask me, it implies that although the Kerbol system itself is at a miniature toy scale then it seems that the distances in the local stellar neighborhood won't be. If anything, it almost implies that the planets you'll find out there will be more like the real life solar system in size. Is this a crazy guess? Maybe! That's still crazy acceleration if you ask me. 

If you do the math, it takes about a year to get to 1c at 1g. (Which makes 1ly/yr a very convenient unit of acceleration!) If we ignore relativity, trip to Proxima Centauri takes just over 4 years at 1G. At 100k time warp, that would still be 21 minutes of real time. This is starting to get into territory of bad gameplay. This isn't a flight sim where you have to actually fly the plane and long voyages make sense. If you put a rocket into time warp and have to wait for 20 real life minutes, it's not a good experience. And i your acceleration drops to 0.1G, that goes up to over an hour of real time under maximum warp that was available in KSP. And this is the nearest star. This is just not practical.

Distances between stars will absolutely have to be at least an order of magnitude smaller than in the real world. That would bring it to KSP scale. As mentioned earlier, that's still a 7 minute trip to the nearest star under 100k time warp and constant 1G acceleration. This is getting into playable territory, similar to outer planets of KSP, but it's still not great. Distances might have to be shrunk even further. Especially, if time warp with thrust will have to be at a lower multipliler.

So yeah, 1G continuous seems like a lot when you're working on a scale of planets in the Solar System, but the moment you go into interstellar distances, it's still going to take a very long time to get anywhere.

[magnemoe]

41 minutes ago, K^2 said:

If you do the math, it takes about a year to get to 1c at 1g. (Which makes 1ly/yr a very convenient unit of acceleration!) If we ignore relativity, trip to Proxima Centauri takes just over 4 years at 1G. At 100k time warp, that would still be 21 minutes of real time. This is starting to get into territory of bad gameplay. This isn't a flight sim where you have to actually fly the plane and long voyages make sense. If you put a rocket into time warp and have to wait for 20 real life minutes, it's not a good experience. And i your acceleration drops to 0.1G, that goes up to over an hour of real time under maximum warp that was available in KSP. And this is the nearest star. This is just not practical.

Distances between stars will absolutely have to be at least an order of magnitude smaller than in the real world. That would bring it to KSP scale. As mentioned earlier, that's still a 7 minute trip to the nearest star under 100k time warp and constant 1G acceleration. This is getting into playable territory, similar to outer planets of KSP, but it's still not great. Distances might have to be shrunk even further. Especially, if time warp with thrust will have to be at a lower multipliler.

So yeah, 1G continuous seems like a lot when you're working on a scale of planets in the Solar System, but the moment you go into interstellar distances, it's still going to take a very long time to get anywhere.

Its pretty sure that interstellar distances will be 1/10 of real life.  The dev has talked about month long burns. I have an filling distances will be 1/100 of real world. so closes star will be 500 the distance to Jool. 
And we will not do 1g burns to turnover, not with the starship we saw is its a bit realistic, it also had centrifuges  

<rant>
In my view accelerating until turnover only make sense with something like an solar sail, it does not if you use reaction mass. 
The problem is that the last part of your acceleration only has very little impact on your travel time as its used for an short time before you start braking. 
It better to use an heavier and more powerful engine and say accelerate for 1/8 to 1/4 of of the distance traveled and do an equal braking burn on the end, now you braking burn will have higher acceleration as you has less reaction mass. I'm pretty sure use the last 5% of reaction mass in an burn to turnover actually slow you down as you are heavier and accelerate slower before you finally use it and get a bit higher velocity for 5% of the trip  
</rant>

[The Aziz]

4 hours ago, K^2 said:

At 100k time warp, that would still be 21 minutes of real time. This is starting to get into territory of bad gameplay. This isn't a flight sim where you have to actually fly the plane and long voyages make sense. If you put a rocket into time warp and have to wait for 20 real life minutes, it's not a good experience. And i your acceleration drops to 0.1G, that goes up to over an hour of real time under maximum warp that was available in KSP. And this is the nearest star. This is just not practical.

Nobody knows the upper limit of timewarp in the second game. Also, you know you can do other things in the meantime? While the interstellar ship flies? Do some errands around the solar system (oh I don't know, prepare second ship? Expand local colonies?) and the years will pass without you noticing.

Plus I highly doubt there will be enough distance to accelerate to anything close to c, afaik the devs said the most efficient engines will accelerate to a large fraction of c (and then would have to start braking). But even then the travel time between stars should be significantly longer than usual Kerbin-Eeloo trip. Long enough to feel real, but short enough to not make players stare at the screen (why would they, there's a lot to do elsewhere). I believe there's a fine spot between the two.

[Wubslin]

3 minutes ago, The Aziz said:

Nobody knows the upper limit of timewarp in the second game. Also, you know you can do other things in the meantime? While the interstellar ship flies? Do some errands around the solar system (oh I don't know, prepare second ship? Expand local colonies?) and the years will pass without you noticing.

Plus I highly doubt there will be enough distance to accelerate to anything close to c, afaik the devs said the most efficient engines will accelerate to a large fraction of c (and then would have to start braking). But even then the travel time between stars should be significantly longer than usual Kerbin-Eeloo trip. Long enough to feel real, but short enough to not make players stare at the screen (why would they, there's a lot to do elsewhere). I believe there's a fine spot between the two.

I think the number of notches on the flight UI we've been shown imply we get at least an order of magnitude better than KSP maximum, i.e. a million times normal speed. We may even get another on top of that - so 10 million times normal speed.

[shdwlrd]

Everyone seems to keep forgetting that there will be higher time warp levels than KSP1. Nate mentioned in one of the earlier interviews that they increased the time zoom for playability. We don't know what the levels will be beyond what is currently in KSP1. 

[LHACK4142]

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

I haven't looked at that code

How would you look at the code? KSP is not open source.

[K^2]

3 hours ago, LHACK4142 said:

How would you look at the code? KSP is not open source.

It's a Unity game, and so it is written in C#. C# compiles to CIL which does a lot of dynamic linking, so it holds on to a lot more symbols than you'd think. A decompiler does a pretty good job of converting compiled C# back into source code. You lose a lot of local variable names that you have to guess the meanings of, but the function and class names are preserved, so it's not actually that hard most of the time to figure out what's going on. I've decompiled KSP a few years ago to look around. Mostly, looking at how forces are applied to the craft.

Now, it's worth mentioning that, at least the time, the code was also obfuscated, but they used a standard, off-the-shelf obfuscator for which there was a good disobfuscation program out in the wild. Depending on what is used now, this might or might not still work.

5 hours ago, The Aziz said:

Nobody knows the upper limit of timewarp in the second game.

I mean, sure, but KSP struggled with 100k. We're talking doing everything KSP did across multiple star systems, potentially for a lot more objects, getting at least some form of colony update tick in there, and then also doing all the extra math for all the ships traveling under power. Sure, I expect KSP2 to be much better optimized overall, but even then, simply maintaining that 100k time warp as maximum is a challenge.

There are also gameplay reasons why higher time warp might not be the solution you're looking for. Even in KSP it feels a bit odd to just skip years of time for a longer mission. Now we're talking decades, and in a game where a lot more is happening over time. Shouldn't you be collecting science, updating your tech, building colonies? Simply losing this much time on a warp doesn't feel great.

5 hours ago, The Aziz said:

Also, you know you can do other things in the meantime? While the interstellar ship flies? Do some errands around the solar system (oh I don't know, prepare second ship? Expand local colonies?) and the years will pass without you noticing.

While in time warp? Building a ship in VAB might actually be ok. You'd be sharing CPU resources, but VAB isn't too expensive to run. Anything else is problematic, though. How do you edit a colony that's being simulated at 100k warp? Intercept is likely going to need to implement special time step for that already, one that assumes that no parameters change for a long time. Now you start introducing changes. At best, it's hard to implement. At worst, a source of endless bugs. I wouldn't touch that. And of course, while you can launch new missions, you'll have to drop out of warp to do the actual launch, and then the time slices for that mission are likely to be so short that you won't be making progress on interstellar mission. Yes, I suspect some players will have a bunch of interstellar missions in flight at once with various alarms set, but this is turning from rocket game into ATC game. Some people will enjoy that and more power to them.  You just can't rely on this to be solving your gameplay design challenges.

Edited September 21, 2021 by K^2

[shdwlrd]

1 hour ago, K^2 said:

Even in KSP it feels a bit odd to just skip years of time for a longer mission. Now we're talking decades, and in a game where a lot more is happening over time. Shouldn't you be collecting science, updating your tech, building colonies? Simply losing this much time on a warp doesn't feel great.

Can't disagree on this point. There will be players that will want to watch the whole transit play out each time they launch an interstellar mission. (To each their own.) So making that wait as short as possible is desirable. But again the distances between the stars needs to be enough to take a long time. (Thanks to the kraken, and boredom, I've been to the edge of the playable area in KSP v.90. That seemed too short of a distance to reach a new star since the Kerbol system was just off the edge of the screen.)

[K^2]

23 minutes ago, shdwlrd said:

Can't disagree on this point. There will be players that will want to watch the whole transit play out each time they launch an interstellar mission. (To each their own.) So making that wait as short as possible is desirable. But again the distances between the stars needs to be enough to take a long time. (Thanks to the kraken, and boredom, I've been to the edge of the playable area in KSP v.90. That seemed too short of a distance to reach a new star since the Kerbol system was just off the edge of the screen.)

Agreed! But there's a lot of room there. 0.42ly would still put nearest star at more than 50,000 the distance to Jool. As discussed at length, I think that's on the outer edge of playable with ~1G accelerations. On the other hand, anything less than 500x might not feel like there is a real vastness of space in between, requiring considerable change in tech to reach. But this still leaves a huge amount of room in between. And whether you want to go high or low on that range will depend on a number of factors we don't really know. What the tech tree progression will be like, how easy it is to get to 1G or above, and how exactly will time warp work. 

[Technical Ben]

I see no problem in KSP with the star systems being different "levels". Fit up a craft with the DV + tech + life support (modules only?) and once correct and in a transfer orbit press "go to next level" and the game adds 100s of years to the game timer, loads you in on an approach trajectory, and removes the crafts fuel transfer costs...

Everything would still be "simulated", but it removes the need to sit there waiting for a craft to get to it's position, and the need to crunch all the numbers in the process.

 

PS, one way to mitigate the "emptiness" of such a gameplay mechanic, is to load out the ship, but "track" it's progress in a mission control room. Instead of simulating the entire transit, you would view an orbital graph or bar graph of "progress %%%" or somesuch. Then players could continue at Kerbin making missions, or fast forwards to any point. IMO I would assume the devs are gonna load in/out each star system as a separate level, perhaps even permanent progression in game (moving from one to the next, prevents returning, like level 1 = Kerbin/sol, and level 2 is a new system, and no return to Kerbin, a totally separate colony). Unless they just load in/out resources and craft between systems. "Magically" appearing after the transit time has elapsed.

 

One way to allow returning to "Kerbin" from other star systems is to setup a "turns" option. "Turn" one, play all gameplay in Kerbin system. Then make an interstellar craft. To travel to another solar system, the game asks you to press a button for the transit, it then says "all craft in Kerbin will be saved on current orbits, any craft not in stable orbit will be lost, are you sure?" then say "Gameplay will be advanced 100 years, you can return to Kerbin, but will lapse 100 years each time you swap between star systems" and finally "All Kerbals go into deep sleep and hibernate while you are in the other star system". Then in the new solar system you are in "turn" two.

This way, you could switch/transport/play between star systems. Perhaps both modes could be used? Load/unload systems concurrently when not transferring craft, and timescales would be around the same. But when transits between solar systems, advance 100 or so years ahead in game.

Edited September 22, 2021 by Technical Ben

[OHara]

I took a guess at the answer to the question of the title,
and imagine that KSP2's time-warp mechanism need not be much different to KSP1's.

For context, Earth's orbital radius (SMA) is 145 Gm and period is 32 Ms (a.k.a. one year)
Jupiter's orbital SMA is 780 Gm and period 105 Ms.
The nearest star Proxima Centauri is 40'000'000 Gm from the sun,
but its nearest neighbour is 2'000'000 Gm away,
and that neighbour is the binary Alpha Centauri, two stars 3500 Gm apart.

Kerbin orbits 14 Gm from its sun with period 9 Ms.
Jool orbits 67 Gm away, with period 105 Ms
(One Jool orbit takes 1050 s player-time at maximum KSP1 time-warp.  A Hohmann transfer from the inner planets takes about 1/3 the time of an orbit, so 6 minutes(!) player-time, but going to Jool is a big event.  Folks using Outer Planets Mod probably use Better Time Warp and its 'Hyper Warp' option to accelerate time by 10⁷ when needed; this works fine for my on my laptop because KSP1 uses the sphere-of-influence approximation and can compute positions from Kepler-orbit formulas at each screen-update.)

So I guess there might be a 'nearStar' at 1'000'000 Gm (1 peta-meter if you know that prefix) from Kerbol.

KSP uses engines with reaction mass (no warp drive) and I can imagine the players might accept a speculative nuclear engine with magnetic-confinement nozzle producing 1000 km/s exhaust velocity (I_sp = 102'000 s×g). 
Delta-V = 1000  km/s × ln(10) = 2300 km/s, if 90% of the ship is fuel at departure.

Using half the delta-V to accelerate (ignoring the minor ~5 km/s to escape Kerbol) and half for arrival, the velocity is 1150 km/s = 1150 Gm/Ms (=0.4% c) for most of the trip.  So I'm guessing it would take about 870 Ms to get to nearStar.

Time acceleration at 10 Ms per 1 s player-time (KSP1-BetterTimeWarp's fastest setting) would make the trip take 90 seconds.  I think it is feasible to simulate craft under thrust at that rate, because each accelerating ship is a 1-body problem in 3-D space under a constant thrust plus gravity from a single celestial body (compare to Principia handling the n-body problem with n² interactions between the n=16 celestial bodies).

I would not expect engines to give anything close to 1-g acceleration. Speculative engines based on known principles would be limited to delta-V that makes the trip take a few years anyway.  In my guessed example, we could use 50 Ms on either end of the journey to accelerate/decelerate at 0.02 m/s².

[Bej Kerman]

17 hours ago, K^2 said:

Simply losing this much time on a warp doesn't feel great.

People like me don't like juggling ten squillion things at once, so I expect that KSP 2 will be friendly to that gameplay style of launching one mission at a time.

[SciMan]

For a long time now there have been mods for KSP that increase the maximum time warp rate allowed. Most of the time what they do is get rid of 5x and 50x and add 1,000,000x and 10,000,000x warp rates.

They don't really cause any big issues other than the odd "whoops the time step where the periapsis was in the atmosphere got skipped over", but you can already make that happen with stock time warp rates in KSP 1 without exiting Kerbin's orbit, so that's not such a big deal I think.

There will have to be some sort of alarm clock function built into KSP 2 that works (the one now in KSP 1 works fine, if you're having problems with SAC it's either your hardware or you have corrupted software somewhere, I'm not going to go into that here there's threads for that already elsewhere on the forums).

[Guest]

21 hours ago, K^2 said:

There are also gameplay reasons why higher time warp might not be the solution you're looking for. Even in KSP it feels a bit odd to just skip years of time for a longer mission. Now we're talking decades, and in a game where a lot more is happening over time. Shouldn't you be collecting science, updating your tech, building colonies? Simply losing this much time on a warp doesn't feel great.

This is a good reason to put some time-based mechanic like construction time and/or pad refurbishment in the game, I love doing multiple missions at the same time and wait out transfer windows by doing other missions  and I have learned to add made up delays (usually 15 days to a month or two) to avoid finishing my entire Mun program only to realize that I'm still in the first 2 months of my space program and I have to timewarp 4 years and an half for the first interplanetary window.

[K^2]

13 hours ago, SciMan said:

They don't really cause any big issues other than the odd "whoops the time step where the periapsis was in the atmosphere got skipped over", but you can already make that happen with stock time warp rates in KSP 1 without exiting Kerbin's orbit, so that's not such a big deal I think.

The problem is precisely that the moment you add thrust, these "whoops, it missed the boundary," become, "whoops, the integration was complete garbage and now the ship is on trajectory drastically different than what was shown in the planner." It takes it from annoyance to completely unplayable. Granted, you could apply shorter time-step to ships under power and go for coarser steps for anything ballistic - and you can even do continuous collisions to avoid some of the problems from KSP, but this is all very far from trivial. Simply increasing time step under high warp is not going to be a good solution for KSP2. I'm not saying Intercept isn't going to throw in a towel and simply do that, but a good solution requires a lot more nuance, and I hope they at least attempt it.

[magnemoe]

17 hours ago, SciMan said:

For a long time now there have been mods for KSP that increase the maximum time warp rate allowed. Most of the time what they do is get rid of 5x and 50x and add 1,000,000x and 10,000,000x warp rates.

They don't really cause any big issues other than the odd "whoops the time step where the periapsis was in the atmosphere got skipped over", but you can already make that happen with stock time warp rates in KSP 1 without exiting Kerbin's orbit, so that's not such a big deal I think.

There will have to be some sort of alarm clock function built into KSP 2 that works (the one now in KSP 1 works fine, if you're having problems with SAC it's either your hardware or you have corrupted software somewhere, I'm not going to go into that here there's threads for that already elsewhere on the forums).

I once managed to warp through Eve  I did the midcourse correction burn and ended on an orbit passing trough Eve, thought I adjusted it then inside Eve SOI, then I pressed the wrong button accelerated to max warp and was past Eve then I managed to slow down. It was an pretty old KSP version and newer might has checks against stuff like this. 

[OHara]

I am optimistic that faster time-warp could be practical because...
The acceleration of a craft under constant thrust, using the SOI approximation for gravity, is fairly smooth when far from the gravitational body
    x''  =  µ/(x_craft − x_body)² − T/m
and we know ahead of time when we need to take smaller integration steps---when the craft is close to the body---and have one reasonable method from KSP1 of limiting time-warp speed when closer to the body.

Now, KSP1 does not have thrust during on-rails time warp, but still limits time-warp at low altitude.  I think the reason was so it could stop time-warp before we enter the atmosphere or hit a mountain (which doesn't always work).  But, the projected trajectory in Kepler form
   r  =  SMA (1−e²) / {1 + e cos f }
could have made it easy to project when the orbit we will cross any critical altitude 'r' such as the atmosphere or highest mountain.  One arc-cosine gives the 'true anomaly' f,  and the two more trigonometry functions and a forward application of Kepler's equation gives the time we are projected to cross the critical altitude, so we know ahead of time when to slow the time-acceleration.  KSP1 seemed not to use altitudes, but instead 3D geometry to find intersections, and I think that historical accident is why we sometimes time-warp through an entry to Eve's atmosphere.

KSP2 would need to convert from position and momentum to the projected Keplerian orbit to show the projected trajectory, and check for encounters with other SOIs, but that need be done once per display-frame, so no increase the computational load at higher time acceleration.

Not all easy, but it seems feasible to me, and worth it for a game about orbital mechanics.

Edited September 23, 2021 by OHara
That being said, my guess of 10'000'000 Gm (1 light year) to the nearest star is maybe larger than a wise game designer would pick.

[K^2]

10 hours ago, OHara said:

and we know ahead of time when we need to take smaller integration steps---when the craft is close to the body

You are assuming only one craft. This breaks down hard when you have multiple craft on different trajectories, each one requiring its own integration step. You can take the smallest requested time step of all powered craft, but what that results in is one ship doing a dive to the star to pick up speed via Oberth would be killing performance for everything else that's out in free space. You can also try to do break-step integration for all of the different craft, and that it's own little nightmare to manage. It's like painting a curve on an n-dimensional grid. And then you have the SoI checks. If you are on the outskirts of the star system, the gravity from primary might be low enough to warrant a long integration step, but what if that step brings you inside of an SoI of an outer planet? So now you have to select integration step, do analytical solution for trajectory within the step, do the sweep of the rocket position against the sweep of SoI running on its own trajectory, repeat that for every craft under power, and then update everything either in break-step or based on the shortest of time steps. And then you still need to figure out where within this time step you are planning to update unpowered ships, colonies, and supply routes, because that also has to be ticking at the same time.

None of it is impossible, but there's a lot going on with many tricky edge cases. This isn't your textbook integration problem. It's complex algorithmically and numerically hard. And solving it poorly will result either in artifacts in navigation or variable performance issues. So you really can't take any questionable shortcuts on this. It has to be done right. And the higher up you go on the time warp multiplier the harder it gets. So I do wonder at what threshold Intercept is going to call it.

[OHara]

1 hour ago, K^2 said:

You can take the smallest requested time step of all powered craft, but what that results in is one ship doing a dive to the star to pick up speed via Oberth would be killing performance for everything else that's out in free space.

Yes.  I was thinking that if a player leaves the thrust on a craft and then switches to other craft, the time-acceleration would be limited by the craft-under-thrust in the highest local gravity.  Given the relatively easy integration, I didn't think the time-acceleration limit would occur very often, and the slow-down would be signalling something the player should know about.  Even at 10-million times acceleration, with a 30fps update for physics, an update is 4 days simulated time.  The Voyager probe doesn't see much change in accelerate during that time, but if you had an ion craft spiralling out of low-earth orbit it would need maybe 1-minute steps, so time-acceleration limited to 1000× while the probe raises its orbit

Probably better, as you say, to let the integration routine use an adaptive step-size, but choose step size internally, presenting an interface that asks for the initial state, the force function, time to which to integrate, and an error limit.  That is how Numerical Recipes wrote their ODE integrators in the 1980s, though it was awkward in Fortran77 without function pointers.  Letting each craft or colony update itself to the next time-frame to be presented to the player, keeps the detail of choosing integration time-step local.  Those integration time-steps look pretty quick, with under 30 floating point operations to figure the 3D force.

KSP2 might choose to disallow thrusting on craft not attended by the player, if it turns out to be frustrating when players forget they left a craft thrusting.  That might prevent micro-g thrusters being practical in the game, but is it not obvious we really want those.

Finding SOI changes does require iteration, because you are looking for closest approach between two bodies, craft and planet, each taking curved paths under central gravity.  Unattended thrust doesn't make that any harder, but even in KSP1 without thrust you sometimes miss an encounter on craft in some tight orbit, while at maximum time-warp.  That does seem to force a choice between (1) computing every craft's trajectory carefully enough to catch any SOI encounter, sometimes limiting time-acceleration (like the yellow clock in KSP1 when physics/GPU cannot keep up) or allowing an SOI encounter with Mun to be missed while watching a craft go to nearStar.  Either would be fine with me.

[K^2]

11 hours ago, OHara said:

Yes.  I was thinking that if a player leaves the thrust on a craft and then switches to other craft, the time-acceleration would be limited by the craft-under-thrust in the highest local gravity.

Oh, so you're talking not only about changing the time step, but also limiting maximum warp? Yeah, that's workable. Though, might still be annoying if you have a craft in elliptical orbit trying to raise it with ions over multiple orbits, and your warp keeps dropping every few days/weeks/months of game time as that probe dips close to primary.

12 hours ago, OHara said:

Even at 10-million times acceleration, with a 30fps update for physics, an update is 4 days simulated time. 

I mean, in the perfect world, if this was written in something that compiles to native with good optimization and by someone who's an expert in numerical methods, we wouldn't be having this discussion. I've made an argument in an older thread that KSP2 should be runnable on a Switch if it was written from scratch specifically to be optimized for that hardware. I mean, that presumption is a fantasy, but if resources were available, yeah, it can be done. Problem is, KSP2 is a Unity game written in C# by Unity devs, most of whom, at best, implemented a Verlet or simple RK4 integrator at some point by copying it from some manual. You only have to look at how bad time warp was in KSP, even without any physics at all, to see why "theoretically solvable" and "practically solvable in given environment" aren't the same thing.

Intercept does have a physics programmer who, hopefully, is a bit more experienced in that sort of thing. Though, I've seen my share of, "We just put it into Matlab and let it do its thing," in academia. But even if we assume that their programmer is actually good at writing optimized numerical code, this is considerable amount of work to implement, debug, and maintain as new features are introduced throughout the development cycle. And the amount of physics-specific work on KSP2 is almost staggering for such a small team. There is the new craft simulation, various optimizations for large craft/stations, physics sync for MP, continuous collisions, etc. There's way more work there in total for a single person to handle in 2 years, especially for someone for whom KSP2 is going to be their first game dev experience.

So the question shouldn't be, "Can you write a 1M+ time warp for a well-written custom engine." It should be, "Could you pick up a Unity game with unfamiliar to you code, and implement a 1M+ time warp in less than a month without breaking anything." And that's the question that is way harder to answer, because we don't know the exact skillset of people involved, how the rest of the game handles time steps, etc. And I don't have certainty that it will be implemented well. So the limitations of time warp implementation can still very much spill into very real constraints they'll have to follow in terms of interstellar distances.

12 hours ago, OHara said:

Finding SOI changes does require iteration, because you are looking for closest approach between two bodies, craft and planet, each taking curved paths under central gravity.

There are optimizations you can take here too. If you take upper bound on curvature of target's trajectory and ship's trajectory, you can inflate SoI and do sphere-line test as early rejection. Most of the time, either the time step will be short, or curvature small, resulting in SoI only slightly larger than original, meaning you can reject majority of checks early and only have to do iterative tests for a few objects. This adds a lot of complexity - see paragraph above - and still isn't free, but it goes back to, "If you had resources to do this proper, it wouldn't be a problem."

12 hours ago, OHara said:

Unattended thrust doesn't make that any harder, but even in KSP1 without thrust you sometimes miss an encounter on craft in some tight orbit, while at maximum time-warp.

Well, that's my point. In KSP, in order for this to happen, you have to be moving fast and encounter either the outer edge of or a very small SoI. In that case, unless your trajectory would have taken you through the body, the deflection is tiny, and overall trajectory isn't altered much. For in-system flight, this is a tiny annoyance that might require a small correction burn somewhere.

In KSP2, for a torch ship, thrust will be dominant force almost always. This allows for a much stronger scattering effect due to SoI encounter. For a worst case, picture a situation where you glance an SoI with trajectory curvature due to thrust being close to curvature of SoI boundary. Instead of being inside SoI for 0 or 1 tick, which won't make a difference, it's now between zero and many. The diversion can be sufficient to bring you even closer to the gravity source, meaning the projected paths between short and long integration steps are going to be very different. But even dipping into the SoI briefly can apply unexpected gravity impulse very early in the voyage.

Now, if you are very careful about applying the same logic to your planning trajectory and simulation, that's fine. A bit of chaos doesn't hurt anyone. But if another ship under power dipped close to its primary, dropped you to lower warp, and that change in time step caused the SoI transition to register, your ship on an interstellar voyage can get deflected from its planned trajectory. It will still likely be a fraction of a degree, but at interstellar distances, that's a difference between your ship going to a nearby star and your ship going into an empty void. And making mid-transfer course corrections for a torch ship is a rather different order of magnitude problem than an in-system mostly-ballistic transfer.

Again, not an unsolvable problem by any means, but a huge thorn that didn't exist in KSP and that KSP2 team will have to deal with.

12 hours ago, OHara said:

That is how Numerical Recipes wrote their ODE integrators in the 1980s, though it was awkward in Fortran77 without function pointers.

There's a C version of that book, btw. Super useful. I don't know if they've adjusted the algorithms for that sort of thing significantly, though. I've mostly been using it as a reference for linear algebra and polynomial integration.

[Francois424]

If they keep KSP's roughly 1/10 scale, that means closest star will be 0.4ly near Kerbol system.

Still a very long way, but definitely more manageable.
I guess well have to see at release tho.