[To people that know how to code well] What opportunities have been gained with the farther out release date?

[K^2]

8 hours ago, mattinoz said:

Indeed how do we know they are still using classic rigid body physics?

Footage from as recent as late 2019 showed all kinds of flex and bounce that you get from weld joints in multibody simulation. So it's still just Unity stock physics, and nothing they've said or shown suggests they are moving away from that. They very well might be doing LoD to help handle multiplayer and large stations, but that doesn't help you as far as flying your ship without encountering Kraken.

Edit: Just to be clear, they have every opportunity to tune and tighten to be as good as KSP is now. But for what they're trying to achieve, they really should have been striving for doing much better.

Edited June 8, 2020 by K^2

[DStaal]

I think we're probably getting a bit off-topic - but I do want to point out that in one of the early interviews Nate referred to 'the refactor', and implied that it became much more than a straightforward refactor.  Which says to me that they intended to keep most of the same behavior, just cleaning up the code, but have found themselves going much further than that.

[Incarnation of Chaos]

On 6/8/2020 at 2:05 PM, DStaal said:

I think we're probably getting a bit off-topic - but I do want to point out that in one of the early interviews Nate referred to 'the refactor', and implied that it became much more than a straightforward refactor.  Which says to me that they intended to keep most of the same behavior, just cleaning up the code, but have found themselves going much further than that.

No offense, but duh.

Again you don't delay a year because everything is going smoothly. BUT at the same time that delay shouldn't be seen as a reason to append another 50 things to the end of the wishlist; since it's quite likely they're dealing with real technical issues and just trying to get whatever they have working.

If KSP2 isn't a complete dumpster fire in the coming months; we may see them come out and ask for specific requests or feedback. Or more likely; they're going to be working like madmen up until the final release and won't be able to add anything until much later after development ceases and several massive patches have stabilized the game somewhat.

I don't think people are in the wrong for asking what we could do better/differently with an extra year, but until we know the state that KSP2 is in any requests or ideas are basically speculative at best.

[mcwaffles2003]

5 hours ago, Incarnation of Chaos said:

No offense, but duh.

Again you don't delay a year because everything is going smoothly. BUT at the same time that delay shouldn't be seen as a reason to append another 50 things to the end of the wishlist; since it's quite likely they're dealing with real technical issues and just trying to get whatever they have working.

If KSP2 isn't a complete dumpster fire in the coming months; we may see them come out and ask for specific requests or feedback. Or more likely; they're going to be working like madmen up until the final release and won't be able to add anything until much later after development ceases and several massive patches have stabilized the game somewhat.

I don't think people are in the wrong for asking what we could do better/differently with an extra year, but until we know the state that KSP2 is in any requests or ideas are basically speculative at best.

Is it possible that there was a far greater response to the launch than anticipated allowing the team to bargain for more time to make a more fleshed out release than was intended? I can imagine they've run into snags along the way but going from launch in 6 months after 2.5 yrs of work to launch in over 2 years seems like an unusually long delay even with covid and restructuring to a new studio. From its announcement thats like going from saying "we're 80% done" to "we're almost 50% done". I imagine covid would have a limited impact on the new people learning the codes architecture since you can learn code from home with the occasional zoom meeting and emails, so those 2 problems would have more of a concurrent effect than a consecutive effect. 

Obviously I'm just throwing out speculation from the viewpoint of a layman

[Incarnation of Chaos]

2 hours ago, mcwaffles2003 said:

Is it possible that there was a far greater response to the launch than anticipated allowing the team to bargain for more time to make a more fleshed out release than was intended? I can imagine they've run into snags along the way but going from launch in 6 months after 2.5 yrs of work to launch in over 2 years seems like an unusually long delay even with covid and restructuring to a new studio. From its announcement thats like going from saying "we're 80% done" to "we're almost 50% done". I imagine covid would have a limited impact on the new people learning the codes architecture since you can learn code from home with the occasional zoom meeting and emails, so those 2 problems would have more of a concurrent effect than a consecutive effect. 

Obviously I'm just throwing out speculation from the viewpoint of a layman

Considering the last news we've recently gotten is that Star.Theory was "Bargaining" with T2 Interactive and decided to cancel their contract and poach their developers for a new studio i seriously doubt that's the case, and i have a sneaking suspicion that KSP2 wasn't anywhere close to completion by the original release date either. Also; it's not that uncommon in the software industry let alone game development for a timeline to completely collapse and the development cycle to extend much further than intended.

Also I'm not really crediting COVID-19 with much of this honestly, and i think while it may have been a major factor later on when ST was trying to go their own way after negotiations fell thru if KSP2 development was fairly along they would've had some difficulties adapting but not enough to set the timeline that far back.

Right now based on the current information available my leading COMPLETELY SPECULATIVE ideas for what happened are

Case #1- Development proceeded smoothly until at some point the ST heads disagreed on the direction KSP2 should take going ahead, lower management was forced to keep employees working on demos and prototypes that they ended up throwing away after multiple design decision changes. All footage of KSP2 "Pre-Alpha" came from either discarded or "Vertical Slices" of a now nonexistent game. ST ran out of time and money, then the story writes itself.

Case #2- Development proceeded fairly well until a point, most major systems were implemented or conceptualized in the last few months before KSP2 was even announced and ST was refining what they thought was a nearly-finished product. At some point though, they hit some form of bug that either prevented them from implementing a major design pillar, was gamebreaking or both. While we were seeing "Pre-Alpha" footage of KSP2, ST was chasing it relentlessly and trying multiple workarounds. When none worked, ST nuked the source and restarted from scratch. They entered negotiations with T2 interactive; deciding to wait until then to inform T2 that the pitch they had sold them of a nearly-complete sequel was no longer valid. T2 gets understandably liquided, and considers it a breach of contract and turns the keys.

Case #3- Development had never seen a day without dozens of new bugs to quash, and while it was becoming clear that KSP2 was going to see the light of day eventually it was becoming extremely apparent that they were going to need more time, people and also rewriting significant portions of the source to accommodate the increased scope. T2 granted them the first delay after COVID-19 forced them to work remote, but the transition took longer than anticipated due to whatever reasons. T2 decided to take advantage of this, and played their hand to devastating effect leading to current day.

Case #4- Development had been a mixed bag, and multiple weeks were spent between the leads vigorously debating what KSP2 should incorporate, how realistic it should be, what mechanics should be in place. New information was constantly trickled in from carefully-moderated and filtered posts on the forums, either to support or quash the latest proposals. But by last winter it had been decided that KSP2 was at a point where expansion of the core game could be done without risking breaking (Too many) things, and with COVID-19 beginning it's long march T2 agreed to allow them to work on a moderate increase in scope. Negotiations were looking up, and ST seemed to be on the path to a release. But it was all a farce, and T2 had them right where they wanted after months of essentially empty negotiations intended to lull them into a false sense of security. ST wanted more, and they wanted KSP2 to be more. But T2 didn't want to pay their price, and decided to have the best of both worlds and pulled out of the contract.

Cases 1 && 2 are basically the worst-cases, and essentially development hell. If either of those were accurate; KSP2 is at least a year or more from any form of release. Cases 3 && 4 are better, and would have the new Intercept Games with some foundational elements to work with. Along with a clear design direction, and if either of those are accurate then KSP2 may or may not see an increase in scope in the coming months.

But with the information we have now i do think we need to be pretty careful about our expectations, and pay very close attention to any new information. KSP2's promises aren't worth anything until we see them delivered to our machines in digital form.

[Incarnation of Chaos]

Alrighty, this bombshell just landed.

Spoiler

https://www.kerbalspaceprogram.com/dev-diaries/developer-insights-4-ksp2-engineering/

This section is the one i want comment on from the previous posters
 

Spoiler

"Next, how do we deliver an experience that grows beyond just a single star system? Because of the enhanced scale of the game, we had to update how we handle positioning. To quote author Douglas Adams, space is “vastly, hugely, mind-bogglingly big”, and representing the relative locations of ships, planets, and distant star systems requires a bit of cleverness. Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended!

How do we deliver new spaceflight challenges and experiences? We’re enhancing our physics simulation above and beyond the original Kerbal Space Program to account for some more complicated orbital dynamics. One example that has already been shown in the trailer are the binary planets Rask and Rusk, which orbit each other. One approach to simulating this would be to have an invisible gravitational center point between the two worlds, but this would make orbiting Rask and Rusk just like orbiting any other body, with slightly different parameters for collision, and the side effect that ships would be drawn to the barycenter between the two bodies. We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly). Full system n-body gravity is, of course, not planned for KSP2, as it would be overly compute intensive and also require complex station keeping on all vessels in orbit that, we feel, distracts from the fun of the game. However, we look forward to how players will deal with, or take advantage of, some of the interesting properties of the special cases where physics gets far more interesting than we’ve grown accustomed to in the original Kerbal Space Program."

This in paticular seems like they're taking the concept of "SOI" and extending it much further

"Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended!"

And local N-body confirmed? Emulation layer?

"We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly)."

Thoughts? Opinions? Panicked screams of shame and disappointment?

[shdwlrd]

3 hours ago, Incarnation of Chaos said:

Alrighty, this bombshell just landed.

  Hide contents

https://www.kerbalspaceprogram.com/dev-diaries/developer-insights-4-ksp2-engineering/

This section is the one i want comment on from the previous posters
 

  Hide contents

"Next, how do we deliver an experience that grows beyond just a single star system? Because of the enhanced scale of the game, we had to update how we handle positioning. To quote author Douglas Adams, space is “vastly, hugely, mind-bogglingly big”, and representing the relative locations of ships, planets, and distant star systems requires a bit of cleverness. Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended!

How do we deliver new spaceflight challenges and experiences? We’re enhancing our physics simulation above and beyond the original Kerbal Space Program to account for some more complicated orbital dynamics. One example that has already been shown in the trailer are the binary planets Rask and Rusk, which orbit each other. One approach to simulating this would be to have an invisible gravitational center point between the two worlds, but this would make orbiting Rask and Rusk just like orbiting any other body, with slightly different parameters for collision, and the side effect that ships would be drawn to the barycenter between the two bodies. We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly). Full system n-body gravity is, of course, not planned for KSP2, as it would be overly compute intensive and also require complex station keeping on all vessels in orbit that, we feel, distracts from the fun of the game. However, we look forward to how players will deal with, or take advantage of, some of the interesting properties of the special cases where physics gets far more interesting than we’ve grown accustomed to in the original Kerbal Space Program."

This in paticular seems like they're taking the concept of "SOI" and extending it much further

"Even on a modern CPU that can handle 64-bit math with ease, if we state that our lowest spacial resolution is 1mm (which, honestly, is not nearly small enough for what we do), the maximum signed distance we can represent is 9.2 Trillion kilometers, which is just shy of a Light Year. We could use double-precision floating-point values, but then we start to lose fidelity as the numbers grow larger, which leads to instability in physics and jumpy positioning as we move away from the origin. With interstellar travel being so important for Kerbal 2, we’ve solved this by implementing a Spacial Scene Graph at Interstellar Scales, which allows us to arbitrarily “break off” sections of space and simulate them with a high degree of precision while still fully understanding their physical and positional relationship to the stars and planets around them, and all while not sacrificing compute performance that might slow down frame rates or lead to spaceships that are more wobbly than our Kerbal Engineers intended!"

And local N-body confirmed? Emulation layer?

"We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly)."

Thoughts? Opinions? Panicked screams of shame and disappointment?

It's good to see that. I'm not a huge proponent for a super realistic simulation in KSP. But in the edge cases like Rask and Rusk, where it is actually necessary, it's awesome to see that they are adding the possibility to use advanced physics in a limited fashion.

It also confirmed a suspicion I had. There still will be different levels of detail for the KSP universe. My question is how many levels will there be.

[Incarnation of Chaos]

22 minutes ago, shdwlrd said:

It's good to see that. I'm not a huge proponent for a super realistic simulation in KSP. But in the edge cases like Rask and Rusk, where it is actually necessary, it's awesome to see that they are adding the possibility to use advanced physics in a limited fashion.

It also confirmed a suspicion I had. There still will be different levels of detail for the KSP universe. My question is how many levels will there be.

I'm very glad they seem to have seen or already knew of the issues that were discussed at length about binary solar systems in computer games here xD

But my worry wasn't that there wouldn't/would be different levels of detail; my main question still is where do the maximums and minimums lay?

Basically does it scale up as well as it does down? Can it handle more complexity or does it end up truncating itself into oblivion after a certain point? (And i'm likely not using "Truncating" correctly since we're using decimal data types instead of integer data types)

BUT

A technical piece like this was exactly what i wanted out of them; even if it does seem a bit hastily written. So credit where credit is due, now let's see what else comes from this.

Edited June 12, 2020 by Incarnation of Chaos
Made distinction between Astronomical and Computer Jargon for clarity

[K^2]

4 hours ago, Incarnation of Chaos said:

And local N-body confirmed? Emulation layer?

"We’re aiming for a higher degree of realism. Instead, in the case of Rask and Rusk, we’ll be calculating the gravitational pull of multiple bodies on our Kerbal vessels, so that developing a stable orbit in complex conditions like a binary planet system becomes a new and exciting challenge! In addition, attempting a landing on Rask or Rusk will be a different experience depending on the location of the sister planet in relation to your target for touchdown, and yes, there will be an astable Lagrage point between the two planets (if we pull this off correctly)."

Thoughts? Opinions? Panicked screams of shame and disappointment?

Ooof. I'm not sure they realize how much they've bitten off there. You know how planning trajectories is still a bit unreliable, unless you're doing time-warp? That's because your ship isn't on rails. The multibody simulation that's running on the ship is what's governing the net force on the center of mass. It's been a long while since I've looked at whether gravity is applied to the whole ship or individual parts in KSP. I recall, there were some changes when they overhauled aerodynamics, so that might have changed. At any rate, the projected trajectory of the ship is on rails, while the ship itself is not unless you switch away from it or go to time warp. So while you're not in warp, the trajectory will drift. You might set up a perfect capture, turn to align your solar panels better before warp, and then find that your new projection takes you through your target.

Well, if they're doing multi-body, nothing can be on rails. Everything will have to be simulated forward. Problem is, integrating gravity is notoriously difficult to get right numerically. We don't really get a huge impact of that in KSP, because how much time do you spend not in time warp, really? But now that's off the table. Hopefully, multibody will still be off when you warp, but even simply integrating trajectory forward is hard. Having to do that for all the ships, debris, and satellites all the time? And what if I place a satellite on highly elliptic orbit, hoping it stays there, and then due to numerical errors it drifts off?

These are all solvable problems, and I'm sure I've even advocated for carefully implementing that in KSP at one point or another. But here we're looking at a game that's already going through some schedule problems, needs a lot of love on physics based on early footage, and they still have a vacancy listed for a Physics Engineer. Multibody gravity is a hard problem that takes a dedicated engineer who is an expert on numerical methods and has solid understanding of physics and orbital mechanics, and it's still going to be a long task with good amount of development work and much debugging and polish. I'm not even worried about multibody situation near Rask and Rusk so much. I'm worried that ham-fisted approach will break orbital dynamics everywhere else. Is this even wise to attempt at this point?

If all they're trying to do is get something interesting near Rask/Rusk, I would suggest just faking multibody there, and keeping an SoI system everywhere else. If in KSP fashion, Rask and Rusk are made to have identical masses, there are some interesting shortcuts that can be used to prevent total numerical chaos, and the Rask/Rusk SoI can simply have some special rules to simulate that.

Edit: Looks like Paul Furio's most recent game-making experience, outside of some work on narrative-based games, is from 20 years ago, which is totally fine given that his role is really that of a manager on this project, and he certainly has enough engineering management and consulting experience. But it'd be nice to hear from somebody who's actually working directly on game's code in a bit more technical detail, because this piece only adds to my concerns.

Edited June 12, 2020 by K^2

[Incarnation of Chaos]

1 hour ago, K^2 said:

Ooof. I'm not sure they realize how much they've bitten off there. You know how planning trajectories is still a bit unreliable, unless you're doing time-warp? That's because your ship isn't on rails. The multibody simulation that's running on the ship is what's governing the net force on the center of mass. It's been a long while since I've looked at whether gravity is applied to the whole ship or individual parts in KSP. I recall, there were some changes when they overhauled aerodynamics, so that might have changed. At any rate, the projected trajectory of the ship is on rails, while the ship itself is not unless you switch away from it or go to time warp. So while you're not in warp, the trajectory will drift. You might set up a perfect capture, turn to align your solar panels better before warp, and then find that your new projection takes you through your target.

Well, if they're doing multi-body, nothing can be on rails. Everything will have to be simulated forward. Problem is, integrating gravity is notoriously difficult to get right numerically. We don't really get a huge impact of that in KSP, because how much time do you spend not in time warp, really? But now that's off the table. Hopefully, multibody will still be off when you warp, but even simply integrating trajectory forward is hard. Having to do that for all the ships, debris, and satellites all the time? And what if I place a satellite on highly elliptic orbit, hoping it stays there, and then due to numerical errors it drifts off?

These are all solvable problems, and I'm sure I've even advocated for carefully implementing that in KSP at one point or another. But here we're looking at a game that's already going through some schedule problems, needs a lot of love on physics based on early footage, and they still have a vacancy listed for a Physics Engineer. Multibody gravity is a hard problem that takes a dedicated engineer who is an expert on numerical methods and has solid understanding of physics and orbital mechanics, and it's still going to be a long task with good amount of development work and much debugging and polish. I'm not even worried about multibody situation near Rask and Rusk so much. I'm worried that ham-fisted approach will break orbital dynamics everywhere else. Is this even wise to attempt at this point?

If all they're trying to do is get something interesting near Rask/Rusk, I would suggest just faking multibody there, and keeping an SoI system everywhere else. If in KSP fashion, Rask and Rusk are made to have identical masses, there are some interesting shortcuts that can be used to prevent total numerical chaos, and the Rask/Rusk SoI can simply have some special rules to simulate that.

Edit: Looks like Paul Furio's most recent game-making experience, outside of some work on narrative-based games, is from 20 years ago, which is totally fine given that his role is really that of a manager on this project, and he certainly has enough engineering management and consulting experience. But it'd be nice to hear from somebody who's actually working directly on game's code in a bit more technical detail, because this piece only adds to my concerns.

I know; which is why I'm really interested about seeing more. Since they both acknowledged that they know of the 2-body workarounds and found them unacceptable, but also state they're not going for full n-body.

Which means that something has to be going on in the backend to make this actually work as expected, and they can't just "Unload" the binary system when you're not there either since the previous state would affect all future ones. I'm not even sure they couldn't just store a "Snapshot" of rask and rusk as computed during the previous visit, then use that to continue the simulation upon arriving again.

And having N-body approximations playing with 2-body systems....that just sounds like asking for kracken attacks.

I like that they're opening up more, but i really want more in-depth information at this point.

[K^2]

1 hour ago, Incarnation of Chaos said:

And having N-body approximations playing with 2-body systems....that just sounds like asking for kracken attacks.

I don't think that specific thing is a concern. Depending on how gravity is plugged into multibody simulation of the craft itself, particularly strong gravity and maybe even tidal forces can influence Kraken, but it doesn't matter how many sources of gravity you're summing from. At the scale of a single ship, nothing particularly interesting happens due to multiple bodies generating gravity unless we're talking about flying in a near proximity of a neutron star collision. A binary planet just won't play into the Kraken at all. I have n-body concerns and I have Kraken concerns, but there's zero overlap.

And yeah, the moment you have anything in the orbit of Rask/Rusk, you basically will have to simulate it always which can be fun at 1000x warp.  Now, keeping everything else on SoI rails even as you simulate Rask/Rusk system (we're going to have to come up with a collective name for the system. How about Risk system?) is still an option. But knowing how KSP players are, I'm not sure even that saves you. Imagine somebody deciding that they really want that Lagrangian station, and they just keep sending in ships and discarding tanks in the system. That's not that big of a deal if you just throw a Verlet at the simulation, but Verlet isn't stable even around a single body, let alone two. Handling that correctly requires better, far more expensive numerical methods. So either the simulation will end up being extremely expensive, and some computers will struggle with high warp, or the Risk system is going to be shaking off ships, stations, and debris like a wet dog whenever someone runs high time warp. Remember how in earlier days of KSP you'd sometimes have a ship that nopes out of a system at ten times the escape velocity due to part clipping summoning Kraken? Picture that for the entire system and during warp.

Edit: You know what? I'll see if I can write up a demo showing off what you can get with different time steps and different integration methods in a binary system.

Edited June 13, 2020 by K^2

[mcwaffles2003]

@K^2

It sounds like KSP 2 will use a sphere of influence and fill its sphere with a local N-body system. Is it possible to separate warps between systems? That could allow non N body SOIs to run at faster timesteps and perhaps N body SOIs could continue warping in the background to catch up to the rest of the on rails universe

Edited June 13, 2020 by mcwaffles2003

[prestja]

9 hours ago, mcwaffles2003 said:

@K^2

It sounds like KSP 2 will use a sphere of influence and fill its sphere with a local N-body system. Is it possible to separate warps between systems? That could allow non N body SOIs to run at faster timesteps and perhaps N body SOIs could continue warping in the background to catch up to the rest of the on rails universe

The only instance of n-body simulation in KSP 2 the devs have announced has to do with the Rask-Rusk system. Other than that, celestial bodies and craft will be on rails as usual.

[mattinoz]

7 hours ago, prestja said:

The only instance of n-body simulation in KSP 2 the devs have announced has to do with the Rask-Rusk system. Other than that, celestial bodies and craft will be on rails as usual.

Although it sounds like the system will be place to expand out the zone of influence once the system has been battle tested a bit and no doubt like mod's will find away to push it out to find the point it sends your local hardware to a grinding halt.

It strikes me most of the Dev's post are talking in the past tense like these systems aren't new, even well before the first public showing of the game. Certainly not something they worked on last week. 

[Incarnation of Chaos]

58 minutes ago, mattinoz said:

Although it sounds like the system will be place to expand out the zone of influence once the system has been battle tested a bit and no doubt like mod's will find away to push it out to find the point it sends your local hardware to a grinding halt.

It strikes me most of the Dev's post are talking in the past tense like these systems aren't new, even well before the first public showing of the game. Certainly not something they worked on last week. 

Which is a good sign, and means that KSP2 likely didn't get thrown completely in a dumpster between them changing hands.