K^2

Yeah, $10M and 2y sounds very close to what I expected the original ST project to fall under. I hope that this at least makes it clear that Intercept was making a very different game than what Star Theory was originally contracted to do. Edit: It was clear to me that development started on a much smaller budget and suffered a disruption that effectively reset the process. But this is so much worse... Watching Shadowzone's investigation, I'm impressed we got Early Access that kind of works sometimes at all.

Well, the question is, do we want flex at all? I'm not sure the community overall would have been happy with rockets that are perfectly rigid in any configuration. No matter how absurdly long and thin you make the beams? It would also be way harder to tell what's failing. When properly configured, flex sort of tells you where you don't have enough structural support. So if your rocket snaps, you usually know what happened. With rigid rockets, you can still compute the stress on all the joints, and it can be done very efficiently. But then the player would have no indication that something's close to breaking. The first indicator you'd get is the parts failing and your rocket falling apart. And the moment you have flex, you're going to have wobble in some configurations. Your options are absolute rigidity or a sometimes wobble. I'm not convinced that it was a conceptual mistake to go for the latter. It might have been wrong for the team's capabilities, which is also an argument to be made, but I don't think we could have known that back in 2020.

KSP1 ships go on rails if you're warping even if you focus on them. That's why people use warp to freeze physics, rotation, and fix other problems. It's equivalent to switching to KSC and warping from there. If you do stay focused on a ship on 1x time, you do still get drift. You just have to have a lot of patience to notice anything significant, since you are in local coordinates and the time step is a fraction of a second. Whether that's a net decay or net boost, I never had the patience to find out. Yeah, I think they ran with what's possible, and not with their team specifically can do. But the game director is almost always a creative, and they always push for more. That's normal and what every game development process will go through. It's the game's engineering director's job to say no, and then you start having discussions about what the limitations are, whether they can be exceeded by hiring more people or circumvented with a different design, and you arrive at something functional. That didn't happen for KSP2, and it sounds like the problem was on the engineering leadership side, unfortunately. So game led by artists wasn't the problem. All indication is that the engineering didn't apply the brakes where needed or supply a solution. And while orbit decay specifically is a deceptive sort of problem, where I can see someone underestimating it initially, there were way too many examples that land the same way for me to excuse it. Technical leadership dropped the ball, and maybe Nate et al. should have recognized that sooner. Engineering director was eventually replaced, but I have no idea what sort of impact that had. The replacement would have been stuck with an absolute mess to untangle, and that obviously would take time.

It's a standard solution. When you're doing floating point math, your sensible options are single precision (32 bit) or double precision (64 bit). And while most modern CPUs do basic operations with double precision floats at an ok speed, a lot of the vector operations aren't built for it, and consumer GPUs are absolutely horrible with it. Your realistic performance penalty from going from 32 bit to 64 bit floats could easily be in 5x-10x range. As a consequence, none of the tools are even built for it as an option, so you'd be stuck with dirty workarounds to have an awful performance in the end anyways. And 32 bit floats are precise to roughly one part in 10 million relative to their magnitude. So if you're dealing in distances of a few km, your precision is sub-mm, and that's fine. Once your distance scale is more like an astronomic unit, the smallest increment you can do in your position is in tens of km, so all your craft parts and geometry are at the same exact coordinate to that floating point precision. Realistically, though, your ship will get krakened to bits long before you make it that far. So instead, you do all your physics and rendering in some sort of a local coordinate system, relative to an origin that you relocate as needed. There is a little bit of a leeway in how you store that origin's position, and I haven't looked at how KSP2 handled it. A lot of open world games that start running up against this simply store origin as a float as well, and eat the complexities of dealing with the fact that the location isn't perfectly fixed, but even that starts getting wonky at interstellar distances. Using a double precision float is a lot more viable for the origin position, since you don't use it in simulation - it's just an offset. So that's pretty common. I would make a case for using a 64 bit integer, though. You could then place an origin anywhere within 1km of where you want to do the simulation, which is close enough, and that'd still let you place objects nearly a million real world light years away from Kerbin without loss of precision. The way Intercept talked about it makes it sound like they were having more trouble with it than I'd expect, which might be just the devs never having to have had to deal with this before, but otherwise the approach is fine. It does look like they had some bugs in the relocation code, and I don't know if they were all fixed, but that in itself isn't really uncommon either. This is just part of a development experience for a game where distances are that huge.

The question comes down to how you update the orbit. KSP1 ran this for ships under player control in Cartesian coordinates. Fast and dirty, and also results in an absurd amount of error. It looks like KSP2 team was doing something very similar. And in Cartesian, just integrating the main body's gravity goes awful immediately. If you are integrating forces in orbital elements coordinates, you're back to doing very heavy math for changes in argument of periapsis and anomaly at epoch. Fortunately, KSP simulation doesn't need to be predicting with high degree of accuracy if a given real world asteroid is a danger to Earth 30 years from now. So a mixed coordinate system can be used as I've mentioned earlier in the thread. So long as you integrate energy and angular momentum change directly, your orbital shape will be correct, and then you can use the Cartesian update to figure out periapsis precession and the true anomaly update. And if these latter two end up a little off, nobody playing the game will notice. That part there are at least standard methods for. You basically have to run a variable time step, with different step sizes for every craft, depending on their local gravity strength and the engine thrust. In most of these cases, the craft is either engines-off and on rails, or it won't be in high curvature area for long, so it's ok to spend more computation there. At worst, you'll have very occasional slowdowns in your simulation. The only special case is low orbit, low thrust. Here you'll have to pull out some formulae from dusty books on satellites orbiting the Earth to see some approximate analytical solutions which will let you apply coarser steps to such craft.

It's really easy to fall into the hole of, "Orbits will be fine, so long as the integrator is good," because gravity just doesn't like that happening. If you are coming into it from perspective of a game developer, velocity Verlet solves basically all your problems, and RK4 is there for the few cases it doesn't. Gravity is a rare exception to that. Likewise, if you're coming in from physics, the understanding of the physics can actually be a little disarming. All of the actual physics that's relevant to a game like KSP I have learned in undergraduate courses, mostly in Classical Mechanics. I've picked up more context, some methods, and just experience using this in the later years studying physics, but if anything, it made me feel like gravity is a simple problem compared to other things I knew. And that can do more harm than good when you start trying to solve a practical problem. The only reason I really know better is because I have tried to write simulations, realized I'm crap at it, and started looking at other ways to do this. And I've done so incrementally over the years, often prompted by something that came up in KSP or on this forum. This is an atypical experience for any given team you'll put together to make a game. I can only guess at the logic that went into the KSP2 sim, but the requirement to warp under thrust was probably what kicked off the chain of bad decisions there. KSP1 didn't need to do simulation. The moment you go into warp, simulation's frozen and everything's on rail. The only part of it that's sim-like is SoI boundary crossings, and as far as I can tell, it would just check if you are in a different SoI after doing a time step. So there was some randomness based on where the true SoI crossing is compared to the step size, but it's nothing that's going to impact the gameplay. I'm sure that even with the on-rails update there were places where drifts could occur, but it's nothing like KSP2's. In KSP2, you had to be able to leave the engine running and go to max warp, because you're not crossing an interstellar void otherwise. So you have to simulate physics somehow. And it turns out, applying a simulated force to an object in orbit is actually really, really hard. We're talking old books, from the pre-computer era hard, because while there are numerical methods for dealing with this, they're absurdly expensive computationally. If you want a good simulation that gives you stable orbits, is fast to compute, and can work across time warp ranges, you have to work with orbital elements, and not simply use them as a convenient geometrical representation, but understanding how they arise from the constants of motion, understand Hamilton-Jacobi equations, have a strong sense for a classical perturbation theory... This used to be fairly common part of physics curriculum in, like, 70s and 80s, back when things like orbit precession had to be computed by hand, but basically as soon as that was replaced by computers, it started becoming a lost art. And it's not that it's so hard to learn for anyone who has been doing other areas of physics. It's just knowing that you need to learn it so that you can do the numerical simulation that KSP2 requires is a very non-trivial bit of domain knowledge. And yeah, it's not like it hasn't come up before. There have been numerous discussions on physics under warp and n-body gravity on this very Forum, plus a number of members of KSP1 modding community have become acutely aware of the problem trying to implement these features as mods. So it's not like KSP2 team wasn't able to discover both the problem and some potential paths of solving it in advance. But they evidently didn't, so that was another rake in the tall grass.

It's a little bit hard to be certain in retrospective. I said a few things about that already, but some expectations we've all had about where the engines are going in 2020 have came to be, and others not so much. The landscape change quite a bit, and it's hard to now talk about it without the benefit if hindsight. In a similar vein, what we know about the project has changed. Even just talking about what is believed to be the scope of the KSP2 plan in 2017, 2020, and 2023 are likely to have been quite different. So there are quite a few blanks to fill in with any number of plausible options. Lets start with a slightly different hypothetical, one that's almost plausible, albeit very unlikely given the ownership chains and realities of the game market. Say the game goes on ice. About a year from now, my boss tells me, "Hey, Kat, <our company> is in talks with T2 to rebuild KSP2 under license. Want to take this one?" In this hypothetical I have a pretty good picture of what sort of resources and budgets we'd be operating with, as well as have specific people in mind for some of the work. And unless I have to be very scrappy with this, like I get only a skeleton team and just need to make the best of it, I would scrap the code and rebuild everything in Unreal. This is despite the fact that I have access to some amazing Unity engineers in our organization. The mid-2024 reality of Unity vs Unreal is that this is a better route. In part, I'm taking into the account the disaster areas of the KSP2 and that a lot of the code would have to be scrapped anyways, but it's a little bit bigger than that. The advantages of Unreal for KSP2 are quite enormous. I'm not usually this generous towards Epic Games, but they have made several bets and investments in tech that have payed out. Crucially to KSP2, the three areas that are important are the physics engine, procedural placement, and large worlds. Chaos physics is good right now. It is better than Havok and quite a bit easier to use in your flows in Unreal than importing Havok as a middleware. That last part's just the advantage of it being already integrated, of course, and not a dig at Havok. Going with Chaos in 5.4 would eliminate a lot (not all!) of the problems with simulation stability and networking. If you were to start building KSP2 code base from scratch today in 5.4, there is zero reason not to have multiplayer enabled from the go and do all of your testing in server-client configuration. In a similar vein, basically all of the work that Intercept did for planet tiles, painted procedural biomes, and origin relocation for interstellar scaling comes out of the box with Unreal 5.4. We are talking probably the past four years of Intercept's work, about half of their team, possibly more, were building stuff that just comes packaged with 5.4. And it's better. The performance is better, the stability is better, there are more features and options... Note that this all hinges on some assumptions I'm making about the content, and that we'd be able to port over the art and tech art work that was done on planets and rocket parts over. I'm prepared to scrap the code, because in about a year of development we can be fully caught up, and have almost all of the problems fixed "for free" because they are already fixed in the engine. But I'm not prepared to scrap the art in general, and there's a lot of fiddly planet-building work that's gone in, much of which we haven't even seen yet, and throwing that away is a much more expensive proposition. So if we were just starting KSP2 clean today, no contest - Unreal, if we're trying to salvage parts of KSP2 (which is more realistic) I still want to say Unreal, but I'm making some assumptions which might change under closer examination of what's there in the dev folders. Alright, sorry about the long preamble, but that is to set up the question of what would be the correct choice for Intercept in 2020. With hindsight in mind, still Unreal - no competition. Without, there's a lot we didn't know back then. Unreal 4 was well established, and we have seen a lot of 5.0 previews to know what Epic is promising us, but there were a lot of undelivered promises in 4, so grain of salt. I started evaluating Chaos in late 2020, and it was raw then. I think in early 2020 when KSP2 dev work started, my realistic options would have been Havok or Havok. I sort of understand why "Lets use Havok in Unity," wasn't the go-to for Intercept, but I think I would have been prepared to take the risk on ECS and DOTS even if decision was made to go with Unity. PhysX just comes with way too much baggage, and Intercept has rather predictably struggled with it. The only choice besides Havok was building custom, and as fun as that would be, I don't think I'd get a sign-off on the extra budget. So Havok it would be. Now the actual choice of Unreal vs Unity would have been a little tougher back then. The team had experience with Unity and the advantages of taking parts of KSP1 that do work fine or work well enough as temps to bootstrap some parts of development are pretty clear. So it looked like a decent enough choice on the surface but. The big tipping point is what we didn't know about the scope of KSP2, but that was clearly in Nate's mind back then. I'm pretty sure that one meeting with Nate about the art/design direction of the game would have made it clear that scalable, procedural environments for the planets with modern visuals was a big part of the 2020 pitch. And with that in mind I would have pivoted hard towards Unreal. The reason is that the proc gen stuff was already in 4. In a somewhat early form, but we've seen it in shipped games by that point. Unreal 4 also supports tiling and virtual texturing out of the box, which I know are major boons to large world development. One thing I absolutely had in my bag in February 2020 is a year of working on building these features for an in-house engine and I would feel like shaking anyone who says, "We're going to build all of that in Unity." To Intercept's credit, and part of why I'm probably less critical of them than most people here, they made that part work, and it's a monumental amount of effort. Just that alone would have probably freed up2-3 engineers and a tech artist to work on other things in KSP2 for 3 years until EA release. And even Unreal 4's implementation of these things is a bit better peformance-wise. So you'd have better framerate, Havok out of the box, and all the things that would get fixed/built with the extra technical people freed up from that work. That would already put KSP2 in a much better place, and this is just from things that would have been known to me in 2020. Looking back, it's clear that going with Unreal 4 in 2020 would have led to a switch to Unreal 5 in late '21, early '22 and make things even better. There are still a lot of things that needed to be done differently in KSP2 in terms of architecture to make it stable and performant as a game overall, but the engine choice would have been a leg up. If you look at the speculation we've had around early 2020, you might even find some posts from me unsure on whether Unity or Unreal is a better option, but a lot of it was coming from our best guesses on the art/design directions back then, and a lot of that came from by-then outdated articles and previews. tl;dr, a well informed and competent TD in 2020 should have chosen to go with Unreal. Going with Unity was a big mistake, and likely caused by the narrow experience of the technical leadership at the time, who knew Unity almost exclusively. Do keep in mind that I am saying that with the advantage of hindsight, as much as I try to compensate for it. Rolling back to 2017, we're in a completely different world. Not only is the tech different, with a lot of the features that would make Unreal a clear winner still very early in development or even entirely as unannounced plans on the roadmap, but also the scope of the game was different, as far as we know. I'm not going to spend too much time going over this. Assuming that I understand correctly that the pitch for KSP2 was, "Take KSP1, make it look shinier, add a star system, and do some cool colony-building gameplay," Unity was the right call. You'd be able to reuse much of the work that KSP1 team did, both under HarvesteR and later with new tech team at Squad. And while at the time it would have meant steaking with PhysX, we're also talking about a smaller game where a lot of KSP1 patches on top of that would have been adequate. Especially if multiplayer wasn't planned at the time. So I think Star Theory's plan for KSP2 was fine and probably would have panned out if the scope didn't expand so much. We'd probably get KSP2 in 2020, and it'd probably look like KSP1 with some visual and interstellar mods and colony gameplay. Hopefully, with some loading issues addressed, since ST would need to improve on them for interstellar. It'd be fine, and most KSP1 players would probably jump over to it. In terms of general changes I would make compared to how KSP2 seems to have been developed across both iterations, I'm just going to run through bullet points. Introduce compound rigid bodies. It'd be exposed to Chaos/Havok/PhysX as a single rigid body, but we'd be able to compute the stress on implied joints between the actual component parts of it. So if any limits are exceeded, it can still break, and if it crashes into the terrain, parts of it could be destroyed rather than all of it at once. I've mentioned advantage for colonies, but you can also use it for physics LoDs and crucially for things like a tank with a decoupler or docking port on it. The latter parts are very light compared to the tank, making the joints flimsy. Turning this into a single rigid body would make all the joints so much more stable even if we're talking about KSP2 2017 and we're doing this in PhysX. So many physics problems would just not. Don't rely on game physics for any part of orbital motion simulation. The CoM of every ship should be on its orbital element rails, with any external forces (sum total of all engines or a binary planet situation) added together and applied to the ships in this bespoke simulation. So even if you're focused on a ship, yeah, it should be simulated for any rotation, part flexing, joint stress, etc. But the net force applied to it should go to the external, bespoke orbital mechanics sim that just moves the ship's CoM. And in your local view, the ship's CoM should be reset to that position on every frame to nulify drift from any Kraken forces. Energy and momentum should be conserved, full stop. Build the data representation incrementally, testing along the way. Playtesting, QA testing, and unit tests everywhere. The KSP2 data mess looks like the team that worked on saved games, editor, and actual simulation never talked to each other. I don't know how that happened, I wasn't there, but I'd like to think I can avoid that kind of a disaster. It's just bad. There are also performance considerations that are graphics related. I'm not a graphics engineer, though. And I don't know how much of what we've seen in KSP2 is really a tech problem, and how much is just tech art not having had an optimization pass. It's very easy to make a quick and dirty shader that does the job but is awful on rendering performance, and you see a lot of that in early alphas. Given that EA is pre-alpha, I'm not sure how harsh I should even be on this. But the bottom line is if there were tech issues, I don't know if I'd know how to fix them. But I also don't really need to. The most important bit is knowing how to find people who can do these tasks. I think a lot of bad calls in that regard were budget restrictions, but it also seems like tech leadership at Intercept hasn't done an ideal job of it. So that's sort of the final part of it. And as a final note, a lot of what I wrote here is criticism, but I know where some rakes are hidden, and I don't know how many rakes Intercept avoided that they knew about that I don't. I think I could have made a much better KSP2 from the purely technical perspective whether I was given the TD on it in 2017 or 2020. Would KSP2 be a better game overall? I don't know. It'd be less broken, but would less broken KSP2 that looks like garbage and has almost unusable UI and editor be better? (Not saying as a necessary cost, but purely as a hypothetical, knowing that these are areas where my own expertise wouldn't be enough.) I don't know. So don't levy all of that against ST or Intercept. This is purely a list of ways that would have been available to make things better if somebody with the right talents was on the team, but everything's an opportunity cost.

Or at least, it will! You just need to put a little bit more into it, and then it'll definitely pay out! But seriously, it's a complex topic. Someone's always getting the blame for the losses at a corp, so while the company overall is going to steer clear of doubling down on losses, whoever thinks they'll get the blame might very much be willing to bet everything on it working out eventually. That can lead to some bad cycles. I don't think any of that applies to KSP2, though. T2 is both happy to cut any losses there, because it's a fairly small percentage of total operating expenses and the leadership will look on the net performance of the game as something to adjust for, and to re-invest into restarting the project later, because it's still an untapped revenue source.

Formula that is too advanced for a particle physicist, but NH4Cl managed to unlock its secrets after thinking about it for a while. Not at first glance, of course, it's way too advanced for that, but on the second try. Forget integrals of motion. Comparing too ratios, that's the advanced mathematics that needs more than one look at it to wrap your head around it. They'll crack quantum gravity any day now. I honestly expected nothing else. Thanks for making my point. I've nothing further to add.

I'm pretty sure I aged from reading this,.

Did you really have to drag Heisenberg into this?

Oh, we can't have that. You Spin Me Round is what we call Dirac. That will get confusing.

Just call him the dead cat guy. He would have appreciated it.* * That part is a lie.

You probably think that every document request under the Freedom of Information Act is a demand to speak with the president, right? Inside trading laws exist to avoid, among other things, situations where the board makes decisions to benefit their own portfolio, rather than the investors in general. This is why they require the board to disclose any information relevant to persons who are invested or considering investing in the company, in so far as it can influence the worth of the company. Board, generally, doesn't want to share the information and will often try to dodge the responsibility. You have recourse against a company you believe not to be sharing relevant information even without owning any stock. SEC investor complaint system is simply a streamlined option that lets you obtain the information that the board wanted to be dodgy about. And if it goes through, no, you're not going to get to speak with the CEO, or even having the CEO publicly share the information. You'll get some sort of a statement from the PR branch, which they were totally going to make anyways, regardless of any SEC complaints, they swear, that just so happens to contain information relevant to the complaint. It's a standard way of applying pressure in a bureaucracy. It's exactly the same process as writing to your senator if your paperwork is stuck too long in some federal agency. Your senator's going to do jack, but some staffer somewhere will send a standard form e-mail that reads, "There was a complaint about the case #. What's the status?" To which they'll get a standard e-mail saying, "We just processed it this morning, so there isn't a problem, here's the new status," and a day later you get an update that your paperwork's moving again. It's a crap system, because it means nobody does what they're supposed to until there's a complaint, but at least you have a way to get it moving again, and this is the basis for everything in US from your local city council, to the federal agencies, to corporations that have their HQ here. If you live in US or plan to and you never had to deal with this, take notes. Nobody in the gov't/corp is going to tell you that you have these options.

Honestly? Somebody could probably apply pressure via an SEC complaint, but I'm not sure their investors care about that. Some of the "We will not elaborate further," replies during the Q&A session of the earnings call can probably be argued to be in violation of the insider trading laws. The argument to be made is that it is information that would impact stock prices, and T2 leadership being stock-owners themselves have an unfair advantage in regards to trading compared to the general public, since they do know the true situation of these studios and the projects they were previously in charge of. If anyone has T2 stock (possibly as part of your 401k), you can try filing an investor complaint with the SEC, but the details are entirely over my head, so maybe run it by somebody who understands the regulations a little better first.

Kugelblitz

Plenty of games available on PC and other platforms have sold more across the platforms, but I haven't been able to confirm anything over the PUBG's 42M on PC (75M total), which is a somewhat outdated stat, but the game's also free-to-play, so I'm not even sure if that should count. Minecraft and SIMS games definitely have fewer than 40M on PC, but again, easily surpass the mark across all platforms.

You say that, but the best selling 8 bit game of all time came out in 1996 with 46M copies sold, and no PC game has yet reached these numbers. 8 bit games continued to be made and sold very successfully well into the 16 and even 32 bit eras.

Oh, gods, that's a blast from the past. Although, I think a more exciting way that code came from magazines was using flexi-discs, typically known as vinyl data. Speaking of which, while in US people usually think of C64 when they think about BASIC listings and games from tape/vinyl, in Japan this was yet another Famicom expansion. Family Basic came with a cartridge containing a BASIC interpreter and sprite sheets, a keyboard expansion, and the keyboard had the audio jacks to connect to a tape recorder. And yeah, they had magazines with game listings which you could type out and play on your Famicom system. It's kind of upsetting that neither the FDS nor Family Basic ever came to the NES. But again, Nintendo were terrified of another games market crash, and avoided anything that could let US studios make more games like fire.

Is it strange that of all the ET-related flashbacks, I had this one? Yeah, I remember when G4 was actually airing this on TV. Is this really what early 2000s TV looked like? I'm always surprised when I look up older footage I remember seeing live. It's part true! They unearthed the landfill in 2014, but some more digging (both literal and metaphorical) revealed that it wasn't Atari trying to buy-back and literally bury the E.T., but rather they just dumped the unsold stock from a Texas plant that had to be closed, which included a mix of games, but E.T. was a fairly significant chunk of that. About 10%, reportedly, and given how many titles Atari was pumping out at the time, the fact that 10% were just E.T. is frankly an impressive statement. Investigation was part of the Atari: Game Over documentary. Atari 2600, from where it came from, to its hardware, to all the absolutely wild games, from timeless classics, to garbage, to games that one does not mention in a polite company for a list of awful reasons, is such an amazing arc in the history of video games, that I think any end less dramatic than the 1983 crash would have felt anti-climatic. And the sheer wide-eyed panic of Nintendo you can still see in the elements of the NES design, both external and on the board, is absolutely awe inspiring. To fail so hard as a gaming business as to bring down the entire industry across two continents, and to force Nintendo who were releasing games on floppies in Japan , literally letting people to "rent" games at a kiosk by writing a new game to a floppy, to invent the CIC... All with a piece of hardware that released the same year as Star Wars. Some failures are so epic as to become their own legends.

To be fair (and pedantic, and as a joke, and just so that we still have a topic,) this doesn't answer the question of where is Nate. Personally, I'd go on a vacation. Layoffs suck. If you can afford to take a break after one, you should. And I know a lot of the former Intercept employees had to start applying for other jobs right away, but I hope they'll at least have some time between the interviews to decompress a bit. It's most definitely not the shiny part of the game dev career, but being able to use the quiet times between interviews to relax, despite knowing a limited runway on funds before you need to have a job or face serious problems, is kind of a skill we end up having to acquire. So if you're wondering, why nobody's talking, yeah, NDAs, but also, they were just laid off. Last thing they want to think about is KSP2 or Intercept.

To which you replied: So you have accepted that quote as the definition, and were simply confused to why that is the definition. Going back to what you're asking of me: There is the definition, and that is the definition, as accepted by you already in this thread. Since you are now telling me that "why" isn't the issue, the question is answered. So now we're just waiting for this part, right? Right here, as previously quoted. This appears right below the numbers providing the range. Make sure to follow to the full post for the context. I stand by my summary.

I think there's more than one thing that's going on. Modern approach is to use velocity constraints with Baumgarte stabilization for drifts. Baumgarte does work a bit like a spring coefficient, but the velocity constraint already has damping built in. So with a sensible choice of coefficients, any perturbations should naturally decay, rather than lead to more oscillation for any single joint. Unfortunately, systems of joints can still misbehave. The worst case is usually a light object sandwiched between two heavy objects. Unfortunately, I just described every single stage separator and decoupler, which immediately becomes a problem in KSP if you don't add additional joints to stabilize it (such as multi-joint connectors, autostruts, etc.) A very good read on the topic is Erin Catto's GDC presentation from 2009, Modeling and Solving Constraints. Every modern physics engine I've seen goes back to this talk. At a minimum, Havok and Chaos do, as well as Crystal's and Blizzard's internal engine implementations because Erin Catto worked there and was instrumental in making sure these engines worked. Now, not every engine uses impulse exchange as their iteration method, but all iterative solvers are going to behave similarly. I think Erin really likes impulse exchange mostly due to its logical simplicity compared to pure linear algebra methods. Crucially, the PhysX version that ships with Unity predates the industry's switch to this as the main method. So their constraints handling might be a little different, and I haven't looked at the code for that specifically. Though, it might be interesting to try and dig up the source for a relevant PhysX engine and to make sure. In general, even the older physics engines had to solve the same fundamental problem of enforcing constraints. And even if you start with position constraint (rather than velocity constraint) and work your way from there, you are still building a damped harmonic oscillator, but your coefficients might be less "magical" and require more careful tuning. So we're still dealing with what's ultimately a damped harmonic oscillator for each individual joint, but what can still fall into some sort of a bad feedback loop between multiple joints. And we know that mass ratios are a problem for the PhysX joints as well, so whatever the solver is iterating over, it's not that far different. So that's one part of it. Even with a good solver, there are bad configurations that you need to learn to avoid, and for something like KSP that means either merging some rigid bodies together (e.g., if you made decoupler and whatever it's permanently attached to into a single rigid body) or doing what KSP1 does and adding additional joints in a way that avoids the unstable configurations. The second part is, I think, what muddled the situation for KSP2. And here we're back to logical connection vs actual joints. I have seen a number of times when a ship spawns in (either at the launch site or from a save) with some parts detached. And it's one thing to just watch some part of your ship drift away, and another is if it's some internal part with collisions that ends up doing a ragdoll-spaz inside the ship. I don't know how many of the KSP2 physics explosions are due to bad joint configurations and how many are due to a part getting loose and spazzing out. I've definitely seen both, but I wouldn't be able to identify each particular case. And I think that might have been why Intercept kept having these issues creep back up, because there are several different bugs they're trying to fix that can be reported as one bug: rapid disassembly without any obvious cause. All of this is kind of self-inflicted, but I do sympathize. Again, it's a hard problem, and unless you happened to have worked on these exact problems before, it takes time to catch up on all the terminology and required reading.

The solver approximates tension in joints iteratively. To avoid iterating many times per frame, the result from last frame is used as a starting point, and only one-two iterations are done to correct for changes. If you reloaded a scene, these tensions are set to zero, and if that's far from what it takes to keep the rocket together, for whatever reason, first few frames will over-correct, resulting in excessive forces. Have you noticed how big rockets do a bouncy-bounce when they spawn in on the pad? And how if they survive that, it's probably alright? Same principle, but for a complex enough build, you don't even need gravity. Something somewhere is probably under a bit of tension just due to how the distances work out, and that will ripple out. With the unfortunate enough configuration of the joints and joint strengths, insta-kraken. Still happens even in KSP1, albeit, rarely.

Except that we have a concrete case with concrete numbers. If the number you claim is "close" doesn't fall within the confidence interval even when expand it to 99.75%, trying to substitute another meaning for "close" is the real slight of hand here, making this entire response the very definition of demagoguery.