Search the Community

That statement alone tells me he was the absolute wrong choice to lead this project. I'm all for realism with joints; some flex, breaking under intense strain, maybe a slight jarring here or a minor shift there if you are being too overzealous. But to just have a wet noodle flying through the atmosphere, and then try to sell it as both necessary and fun? He has no clue. Which a lot of us in the community have been saying since day 1. We were told continuously that they wanted our feedback, and that the bug reports were good, and that we were important to the end product. And then they clammed up and just pushed out whatever they thought was great, the community be damned. Bugs be damned. Heck, the game itself be damned, so long as the art and marketing departments were happy. I think this actually boils down to "How much of the code itself is salvageable, and how much has to be tossed and redone". And depending upon your personal preference for how much code you think it takes to make the game salvageable, it could go either way. I guess that, without knowing what the code itself looks like, and only looking at what the game is today...:shrug:? I have no words. Hard agree. Because I'm a software person myself (automation jockey mostly, but I dabble), I've actually downloaded and fired up Unreal. Followed a small tutorial, and I've got a planet rotating in space near a star! Hey, that's big news for me! Anyhow, from what I understand Unreal is far better equipped to handle some of the physics than Unity is. I just wonder how much of developers avoiding Unreal has to do with it being from Epic? That was probably the most eye-opening thing I learned from this video. I've seen my fair share of management imposing stupid rules on their teams in the name of business, but to be told you can't even talk to the former developers? Don't look at the previous code and learn from their mistakes? That alone should invoke firing of the entire board.

"You cannot NOT communicate." The long silence was in itself a way to communicate corporate's disdain for our community. The silence also made people more willing to talk to me because they wanted the story to be heard. Had PD/T2 decided to be super open and transparent and honest, we would not be at this point.

Thank you very much Shadowzone. No empty buzzwords, no hate, no half truths at all. But all the haters will feel confirmed by now. No statement after WARN, no statement after earnings call, not even a hint after you gave Nate a chance to talk over Zoom. Too bad. Yeah, I still wish it's best for it's completion. At this point I also hope there won't be any violence happening to them. That's quite possible for developers these days.

Writing as I watch so this is more a disorganized stream of consciousness: He should not have said the "you won't feel validated if you think the devs suck" and only 10 minutes later state how they were forced to hire juniors with no experience that didn't even play the first game. It's also very funny to see how it indeed was prohibited to ask the people that knew, much less consult with someone like HarvesteR. This also explains why they hit pretty much the exact same walls. It's HILARIOUS to me they might've pitched a re-engineering of the original game code with none or little knowledge of it and much less asking the people that worked on it about it. Talk about overpromising and underdelivering, something Uber was known for from previous titles. It was also really easy to guess that T2 really did see Kerbal as a golden egg goose, good to have confirmation. I still believe it was... until they absolutely ruined it by believing overpromising amateurs on their bid and then placing the dumbest restrictions upon them. Add Nate being a serial overpromiser, and them banning scott manley! It's like they took every step and precaution to set themselves up for failure. It's no wonder some of us saw them as completely arrogant when they refused or were prohibited to consult or ask anyone with a smidge of knowledge of the franchise, and then proceeded to make the same or worse mistakes. Continuing with hilarity. "This focus of visuals resulted in more fundamental design and gameplay decisions to take the back seat" AHAHAHA, as if the game looked any good. Yes, it has some modern fx and shaders, but to be a mess just to look like that? Incredible. "Nate believed the difficulty introduced by wobble would be necessary to have a fun game." Absolute clown. At least ShadowZone understands wobblyness in real rockets, even if he uses that to make a dumb case about "teaching engineering". No, enabling parts to clip into each other or otherwise exploding out of the blue does not teach engineering, it teaches cheesing. Couple that with the statement saying he was actively steering stuff away from realism specifically to dumb it down... yeah... no wonder. At this point (16 minutes) we arrive to the public reveal, yet there's no mention of any feature being complete even by the original Uber Entertainment, so either they did believe they could finish before the release, or they were already in the cycle of misleading that they had a full game when in reality they, at this point, had a bad frankenstein of KSP1. This is also known to be the point where the revolving door starts at, even after the transition from ST to IG. A revolving door filled with amateurs and juniors, hired under secrecy and now, we know also hired for minimum price. At last we also have confirmation that they were working with the original codebase ST was using, so pretty much another "I told you" to the clowns stating they magically started a new game from scratch after the merge. To further pile up on this, it seems I also was right on pointing out the "multiplayer build" we got screenshots from was indeed the original one, and not some magical new build they started after the merge. By minute 28 we get a second confirmation of this... They really didn't, at any point have a single one of the features developed. It's also a good warning story that, with multiplayer engineers being fired so early on... the long term product was dead long before these current days. My key takeaways, in comparison/opposition to SZ: Read the forums. It was impossible to miss what the community wanted... yet somehow T2 and then IG/PD/Nate did horribly. Early Access is for customer integration and feedback. If you don't care about feedback, then don't do Early Access. It seems we'll never get that font changed now... Dumb down accessibility, not the game itself. Games are hard because systems are most times loosely explained, or in the case of KSP1 have literally no explanation. Fix onboarding and you don't need to make everything inconsequentially easy to the point your game is a mediocre mess that elicits no emotional response. You can't make a product this complex with amateurs. You can't work on someone else's code without the ability to consult them... specially if it's the mess we know from KSP1. Stop using Unity. Unless you come out with something revolutionary, the public perception is always negative when you announce your project is in Unity, specially from a fanbase that's been dealing with its limitations and misuse for 10 years. Stop listening to Nate. KSP2 is dead.

Amazing video, thank you. I always thought there was a huge imbalance between the KSP2's presentation and playability - the bit about the creative lead focusing on the art clears that up a lot. I really liked the "We need to talk about Nate" section - it was necessary given things that people have said here and on Reddit. Banning the developers from speaking to Squad still has me in disbelief. Did the the people involved in the KSP2 project provide any input on what they thought was the future of the game?

This. The code would be dead simple (relative to "rocket sim"). Further, if you remove game physics for anything not in the physics bubble and, keep track of orbital parameters and not coordinates, then you don't even need to know where anything is until it needs to be displayed. You could have any number of bodies in elliptical orbits and give them 0 computational effort until you needed to display them. Perfect for high timewarp, and orbits cannot decay, or for that matter wander due to cumulative FP rounding error. As you say, SOI-crossing orbits are a matter of setting a timer (which they should be getting right anyway to support Alarm Clock in the base game.). For high timewarp, I'd certainly start development with treating the boosting ship as a rigid body. Modeling joints under boost at high timewarp seems like a "nice to have" at best. Until you mentioned the Risk twins, it didn't occur to me why you were discussing 3-body sim. Wow, talk about starting with an overly ambitious dream. Man, talk about stuff to defer until after everything else is working! That was the tail end of the roadmap, and it seems like they started with it. Upthread you mentioned the problems in KSP2 with save data and live data diverging. Is there some common problem with saving/restoring full physics data for the public engines? I've seen small indie teams using both Unity and Unreal just treat that as an unsolvable problem and just not save physics state despite being physics-heavy sims. I'm curious whether that's actually difficult with stock physics engines, or it's a case of buying some game save tool off the store without understanding it, so they're stuck with the positional-only information it came with.

Some more of Bruvell, this time with the various landmark buildings outside of the Downtown. One issue I have with these drawings is that they're lacking in detail though, unlike the last ones. Erie Bank Stadium, home of the Bruvell Team! Why are they called the team you ask? Well, when Bruvell applied for expansion team, they were unable to turn in a proper name before the deadline. So the NFL ended up naming them the Team. They have won no Super Bowls. The stadium is mostly inspired by Lincoln Financial Field (Philadelphia), but also takes a little bit of inspiration from Highmark Stadium (Buffalo) too. "WKYS, the sound of Bruvell! Tune into 88.7FM for Sports, Music, News, Talk, and more! Everything you need for your commute to work, or to relax too at home. WKYS, Bruvell's go to radio station since 1941!" A little bit of history and radio knowledge is involved in this one. Firstly, the way radio works in the U.S. is that every station east of the Mississippi begins with W, and every station west begins with K. Afterwords is a random assortment of digits from 2-4. In the world Bruvell's in, Erie, PA simply doesn't exist. Bruvell's taken its place. However, both share a history. 1941 is when the first radio station came to Erie, and 88.7 is between the frequencies 88.1 and 107.9, the frequencies of FM radio given to Erie. And, WKYS is an actual station in D.C., but in this world that radio station also simply doesn't exist. Bruvell Central Station, the main hub of all rail activity in Northwestern Pennsylvania! The main transport companies that operate here are Amtrak and Bruvell Regional Transport, and is a connection point between the Northeast corridor, Pittsburg, and Ohio. It's mainly inspired by 30th Street Station (Philadelphia), but also takes a bit of inspiration from Newark Penn and New York Penn. As you can see, this drawing's still a WIP.

It was said that they will talk as soon as they can, but bureaucracy can be quite a torture at times. If they don't talk within 48 hours I begin to believe we will hear something end of June at best. The team has a heart. I believe in them. Something will be said. They just can't talk now and they feel the pain too.

That one really falls in with the things I was wondering, so that was great. And thank you very much for the detailed answer! I've seen so much talk about how Unity was the wrong choice, that it makes you wonder why they used it in the first place, but the change in scope after starting in a place where it had advantages, does make sense, and seems like it certainly led to problems when they ended up at place where they were making something with an engine that no longer made sense for the project, but were likely in too deep, and probably couldn't get the time/budget/manpower approval for an engine change, even if that was on their minds as something they wished they could do. By the by, what do you think of their solution for precision at the scales of distance being dealt with? There was a dev diary about the problems with necessary floating point precision being impossible at the distance scales being dealt with, without resorting to methods that increase computation cost impossibly high, so essentially they had a little bubble of higher precision simulation around the craft being controlled, in order to get the precision necessary for things like docking. Judging from the explanation, and the overall logic of the problem, it seems like this would be necessary, and your answers would lead me to think you would go in a similar direction, but curious about if you think that's one they got right, or if there was a better alternative.

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.

Building with FAR 101 – Barebones Basics First off, I''d like to thank tetryds, both for advice and corrections he provided in the course of writing this tutorial, as well as the awesome BAD-T tournament he is running that led me to write this tutorial in the first place, that it might be of some use to those who want to enter but might not be familiar with FAR . With that out of the way, lets begin. Ferram Aerospace research is a mod that aims to bring real-world aerodynamics and aerodynamic principles and mechanics to KSP. As a result, building an aircraft is now a bit more complex than in the rather more forgiving stock aero model, as planes must now be built to take into account various real-world aerodynamic design considerations. This will not be a comprehensive overview, it won't tell every trick in the book on how to make a competitive performance dogfighter, but it should adequately cover the basics sufficiently to build a successful subsonic aircraft that avoids plowing into the ground seconds after launch. Lets start by building a basic airframe: This consists of a KAX D-25 radial engine, a structural fuselage, an inline cockpit, a liquid fuel tank, and a tail adapter. Now, before we add some wings, we should first know where the Center of Mass (CoM) is. This is important, as it will greatly affect wing placement and aircraft balance later on. On the sample craft, the CoM is here: Also activated are the Center of Thrust and Center of Lift indicators. Now, the CoL indicator here looks different from stock; there's no arrow. In FAR, the CoL functions similarly, but not identically, to Stock. In stock, it indicated the net direction of lift provided by lift forces from the wings and other lift surfaces, in FAR, its simply the Aerodynamic Center. It can still be used to get a rough approximation of craft balance, but for learning precisely how a craft is balanced requires the FAR editor readouts, covered later. So lets add some wings: With wings on, it's looking more like a plane, but there's still some work to do. Control surfaces need to be added, and the plane balanced – as seen the CoL is slightly ahead of the CoM; this plane will want to pitch up, potentially leading to a stall and possibly crash. For a successful, easy to fly craft, the CoL should be behind the CoM, the aircraft should want to naturally pitch slightly downwards while in flight without control surfaces. To correct the imbalance, there are a few available courses of action: The mass of the craft could be shifted forward, the wings moved farther back, or the empennage lengthened to shift the tailplanes back and offer better leverage on the craft once control surfaces are added. A quick craft re-arrangement later, and : A bit unorthodox, perhaps, but serviceable. The wings were moved back, and the structural fuselage behind the engine was moved to behind the fuel tank, which puts all the heavy things at the front of the craft. As a bonus, the main wings are now on the CoM, which will help with performance, as the main wing is the point the craft will want to pitch up or down; the closer the CoM is to this axis, the less leverage needed to affect pitch. Additionally, the main wing is also located on the fuel tank, which means as the craft files and the tank is drained of fuel, the overall CoM of the plane will more-or-less remain where it is. Knowing where the Dry and Wet CoM on the craft is good to know. If the CoM shifts too much as fuel is used up, it may result in the plane becoming unstable. To control the aircraft, control surfaces are needed. Lets add some: The craft now has a pair of ailerons, a pair of elevators, and a rudder. The ailerons are located at the main wing tips, and provide Roll authority, the elevators are on the horizontal tailplane and will control Pitch, and the rudder on the vertical one will control Yaw. keep in mind the principle of leverage; ailerons/elevons (control surfaces that control both Roll and Pitch) that are located near the fuselage will be less effective at rolling the craft then if they were placed further down the wing, likewise, the further from the CoM the elevators are the more efficient they are at pitching the craft. Elevators placed inline with the CoM won't have any effect at all (i.e. if the ailerons in the picture were set to control pitch, they would have negligible effect due to how close to the CoM they are).. By default, a newly placed control surface will be set to respond to Pitch, Roll, and Yaw commands; while leaving control surface inputs default generally speaking won't keep you from flying, it may cause the craft to do weird things, since the rudder will be trying to pitch or roll the plane, the ailerons will be trying to adjust the craft's Yaw, and so forth. To adjust the control surface's inputs, right click on it to get a context menu: Std. Ctrl is the control settings needed here. Flp/splr controls flap and spoiler settings, covered later, and curWingMass is how much the wing weighs, with Mass-Strengt... 1 is the wing/control surface structural strength, also covered later. Clicking on the Std. Ctrl button opens a new menu: A few more options than in stock, no? Pitch %, Yaw %, and Roll % are pretty explanatory, these control that respective input. The 100 means that at present this surface will fully deploy in response to an input. This number can be changed from -100 to 100. having a Pitch at less than 100 means the surface will only deploy partially in response to an input, and a negative setting will have the surface deploy upside down, useful for things like front canards and so forth. AoA% is the Angle of Attack percent. Instead of reading a P/Y/R input, it reads the crafts current AoA while in flight, and dynamically deflects the surface in response to it. This can be set from 200 to -200; useful for things like wing slats or having a plane that could automatically pull out of a dive, that sort of thing. Brake Rudder sets if the control surface can be used for affecting Yaw like an A.I.R.B.R.A.K.E.S. part – perfect if you want to make a Ho-229 /B-2 type flying wing, this lets you maneuver without vertical rudders. Ctrl Dflect is important. This determines, in degrees, how far a control surface deflects. The lower the number, the less deflection, and the slower the pitch/roll/yaw effect propagates in flight. Because FAR models aerodynamic stress failures, or in other words, too aggressive a maneuver and the wings rip off, being able to adjust the control surfaces so they don't result in a 15 G turn and Rapid Unplanned Disassembly of the craft is vital. The other, less immediately fatal thing adjusting Control Deflection will do is help prevent stalls from overaggressive maneuvering. Too much control authority for your elevators and you risk pitching the craft's AoA too far from prograde, resulting in at best higher drag, or worse, throwing the aircraft into a stall. A lifting surface stalls when its cL falls too low; in other words, when a lifting surface stalls, it drastically reduces the amount of lift it generates; too little lift, and the craft falls out of the sky. Now, what about the Flp/Splr setting? Lets take a look: Clicking the Flap setting will designate the control surface as a Flap; flaps are useful for take off and landing, when extended, flaps provide greater lift at lower speed; they also cause more drag. Flaps shouldn't be extended much or at all in normal flight. When a control surface is a flap, extending/retracting can either be done via right click menu while in flight, or via action groups. Clicking the spoiler button actives that surface as a spoiler. In KSP, spoilers are basically airbrakes; they are automatically added to the Brake action group, and when the brakes are activated, the spoiler will deploy. Be careful when placing spoilers; place a spoiler in the wrong place or upside down, and you may discover that rather than a brake it is instead acting like a flap or an elevon and affecting the craft's flight differently than intended. Now, lets talk about Mass-Strength. Mass strength adjusts both the mass and the strength of a wing. The stronger the wing, the more aerostress it can take before catastrophically failing. The slider goes from 0.05, for a wing that is basically made out of paper mache and prayers to 4.0 for a wing made out of adamantium. For a a spaceplane, a wing setting of 0.4 or so should generally be sufficient, for a subsonic stunt/sport craft doing acrobatics at low altitude, a higher wing strength is recommended, something like .6 or so for a light weight craft. Keep in mind, that a wing strength that works for turns at 100m/s might not be sufficient for puling out of a dive at 240 m/s. While there is nothing wrong with a higher wing strength, keep in mind that stronger wings are heavier; the standard Wing Connector A, with a strength of 0.05, weighs 15 kg, the same wing at 4.0 strength weighs 1237 kg! With a basic plane built (yes, it still needs things like landing gear, but those are unneeded for now), its time to see how well it will fly (theoretically). To do this, open up the FAR editor window in the SPH/VAB by clicking on the FAR icon in the toolbar. When this is done, it brings up this: This is the Flight analysis graph, which will display some information on the flight characteristics of the craft in various flight regimes. Currently here it is set to AoA analysis, which will show how the craft will handle at various angles of attack. It can also be set to show how the craft will perform at various mach numbers by clicking on the Switch to Mach Sweep button. The numbers at the bottom adjust the parameters to be tested. By default it is set to examine the craft from 0 to 25 degrees AoA, at an airspeed of mach 0.2 The side bar buttons are craft and environment settings. Want to know how the craft will fly on Laythe? Select it from the celestial bodies menu. You can also see how the craft will fly when flaps and/or spoilers on the craft are deployed. Lets see how the example craft will fare: The mach value has been adjusted to 0.35, (around 120m/s), and the upper AoA limit has been increased to 50 degrees. The graph displays a number of lines: The green line what the craft's lift/drag ratio is as the craft sweeps from 0-50degrees AoA. Looks like the craft will get the best lift for the lowest drag at around 5 degrees AoA. The Blue line is coefficient of Lift – how much raw lift does the craft generate. The blue line goes steadily up until about 35 degrees AoA, and then starts falling. As the line goes up, the more lift the craft is generating. The tip of the cL curve at 35 degrees is important, this is the point the craft will begin to stall. The red line is drag. As AoA increases, more wing surface area is exposed to oncoming air, generating more drag. Here, the line increases until about 40 deg. Of note is the area around the intersection of the red and blue lines. At 35 degrees, L/D increases slope slightly, and at 40 degrees it begins to plateau, combine that with the the correlating decrease in cL and it shows the aircraft stalling at 35 degrees and coming to a full stall at 40, pitching the aircraft that far up should be avoided. With stalls, main wings are the easiest to stall out, other lifting surfaces like tailplanes are a bit harder. The final line, the yellow line, is a measure of craft stability. The lower the line, the more the craft will want to return to a neutral state. Here it steadily goes down, looks like the craft will automatically recover from an AoA induced stall of the wings and bring the nose back down to a prograde vector. The value of the line factors into this; the steeper the slope of the line, the more aggressive the return to a neutral state. the more aggressive this movement, the higher the G force the airframe is subjected to, the more G's, the stronger the wings will need to be. The second page of the FAR editor window that is important is the Data/Stability Derivatives. This page can be access from the drop down menu in the upper left currently reading Static Analysis going to it, and: A bit scary and technical, isn't it? Lets walk through it. At the top there is a planet selector (again, if you want to know how the plane will do on Laythe/Duna/Eve, or for the suicidally insane, Jool). The next is altitude, in kilometers, from sea level. As atmospheric density and temperature change, so to does aero performance. The last is speed, in mach, for the same reason; higher mach results in different aerodynamic considerations and fun engineering challenges like dealing with the trans-sonic region supersonic drag, which won't be covered here. Lastly, flap/spoiler settings can be set. On to the numbers. The Calculate Stability Derivitives button has already been clicked, so the stats have data to them. The first set of numbers at the top are technical data about the craft. Of note is the wing area, which can be used to determine the craft's wing loading. The higher the wing loading, the more mass per square meter the wing is supporting, and the stronger the wings have to be, but higher wing loading also means less drag. Lower wing loading means the craft has more drag, but is also potentially more maneuverable, dependent on control surface settings. Also of note is the level flight numbers,which tell the the chosen mach speed in m/s, AoA, and the coefficient of lift for level flight at the selected planet, altitude, and speed – in this case, the craft needs to have an AoA of ~2.4 degrees when flying at ~119m/s (the input mach 0.35) for level flight at sea level. The coefficient of Lift can also be used in conjunction with the static analysis graph, go back and look, and the cL of .157 shown here will correlate with the blue line on the graph. Next up are the Longitudinal and Lateral Derivatives, each of these reference a particular type of movement about an axis. These should be green, any numbers in red indicate the craft will exhibit an unwanted behavior, and the higher the green number, the less that particular kind of negative craft behavior is a concern. In particular, lets look at Mw. This number tells how much a craft will pitch up in neutral flight. The number is -.114, which means the craft will very slowly pitch down in normal fight, which is to be expected with the CoM head of the CoL. But what if we moved it? Lets see what happened: Mw is now red, with a value of 0.08. the craft will now want to pitch up in normal flight. It wont pitch up very fast, but it is still a motion that will have to be actively corrected through trimming the elevators or applying active inputs to them every so often. As with higher numbers being good when green, higher numbers when red is bad, the higher the number, the worse the detrimental effect. When a number is red and very low, it isn't the end of the world, and can easily be corrected by the control authority the plane has. For numbers bigger than around 0.5 - 1.0, a redesign of the craft is suggested to reduce the number, or even better, make the value in question green. In many cases this will be minor tweaks to wing and control surface placement. In the case of large numbers (3.0 - 4.0 and above) major structural redesign will be necessary.

I've got my ticket for the long way 'round Two bottle whiskey for the way And I sure would like some sweet company And I'm leaving tomorrow. What'd you say? When I'm gone, when I'm gone You're gonna ban me when I'm gone You're gonna ban me by my hair You're gonna ban me everywhere, oh You're gonna ban me when I'm gone When I'm gone, when I'm gone You're gonna ban me when I'm gone You're gonna ban me by my walk You're gonna ban me by my talk, oh You're gonna ban me when I'm gone I've got my ticket for the long way 'round The one with the prettiest of views It's got mountains, it's got rivers It's got sights to give you shivers But it sure would be prettier with you When I'm gone, when I'm gone You're gonna ban me when I'm gone You're gonna ban me by my walk You're gonna ban me by my talk, oh You're gonna ban me when I'm gone When I'm gone, when I'm gone You're gonna ban me when I'm gone You're gonna ban me by my hair You're gonna ban me everywhere, oh You're sure gonna ban me when I'm gone When I'm gone, when I'm gone You're gonna ban me when I'm gone You're gonna ban me by my walk You're gonna ban me by my talk, oh You're gonna ban me when I'm gone

People do not like to admit culpability in a situation like this & Nate is ever the spin master. Anything taken from Nate will always be "We did an amazing Job. Things were out of our hands" or something similiar. Where I personally do not think that the responsibility lies with the individual developer. Even if it did, No one will come out and say "we did a bad job" .. "it's our fault" The game WAS pushed out in a rather poor state and could support the Parent say this outcome and was preparing for it.. but I'm just saying.. Nates literal job is to talk a good game.. and he's good at it.

Out of curiosity, especially since you clearly have, likely, the most (and most relevant) experience in game physics programming out of everyone who frequents this forum: if this were your project and you were in the position were you got to make the decisions, what game/physics engine would you use (for sake of relevance, say, both if it was started now and for if it was started in the 2017-2020 range, like ksp2 was)? Since all we can really do now is talk about what ifs, and I (and others, I think) always value your insight, it would be quite interesting/educational to read. Also, If you want to go into what your overall approach would be if you were engineering and/or game lead, too, please be my guest (it would be quite interesting, I imagine). I know, though, that you've given aspects of that already (though putting it all together would still be of value), and it would easily be mass wall of text that you may or may not feel like like writing, so do what you feel like. (for a given value of force). But, if you genuinely WANT to, please do.

I have seen Satire of this very situation on television. It is a trope I feel has been displayed enough to have been immortalized. Random individual conveys some sentiment with simple arithmetic to emphasize a general feeling of disappointment. Then a figure emerges from the back of the room. Crowd parts & a shadowy out of focus frame slowly center on the individual. Long well oiled mustaschio twirled idly between for finger and thumb... " weeeellll... seems we have a misunderstanding. Let me educate the poor farmers" proceede with circular talk to convince *farmers* some unrelated point in somehow relevant to their disappointment.

This discussion reminds me too much on my time in World of Warcraft. I spent almost all my teens on that game. Was it part of my life? Clearly. Did it teach me something? Certainly something about progress, motivation and goals. But is something lost because I don't play the most recent patches since many years now? I didn't play as much KSP as some of you guys - shameful 2~ years to be accurate - but a big take away from my gaming experience is that the biggest slice of any game teaching or telling you something is always achieved in the first steps. Most things happening afterwards are reiterated over and over again until the player is mastering his skills to meet some kind of end goal proofing you're a specialist. There is only one problem: Some games have no end goal. KSP is just such a game. The deepening of some skills might be fun and such but there is nothing obvious you lose. If you can talk about life altering things you probably have learned it already. You have taken it and nobody can steal it from you anymore because it's in your mind now. The only thing you really lose - and that's very precious for many people - is your passion. I understand that. Passion never really falls from the sky at any time. It's like a rare moment in life where you make the right decision and hit the point and now you ride a wave for a longer period of time. But at the point where you only feel pain or think your life depends onto it you should try to rethink whether you still ride this wave or not. Maybe you're on the surfboard, thinking you have a safe stand these days but in fact the sea is just dry and your board standing still on the sand. Maybe -and I certainly don't want to judge - you just don't want to see it like it is. If you play this game for so long it makes sense to me. Nothing holds up to eternity. It didn't do it for me at least. I see it like this: If I hadn't stopped WoW, I would never have played KSP. Maybe there is the next best thing around the corner waiting to be found. You just don't know it yet. Endless missed opportunities because you play KSP for so long. Oddly, no one is talking about that.

The title is pretty self-explanatory. On the anniversary of a milestone of aviation and spaceflight history, post about it here. It can't just be events you think are significant; the name of the game is "This Day In..." The event in question has to share the same month and day as the current date. e.g. if it took place on December 17, 1903, you'll just have to wait until December 17, (whatever year it is now) to post about it. Replies discussing events already posted DON'T have date limits; just the events themselves. In other words, you're free to talk about any events mentioned on here as far long or as late as you wish. Links to sources are highly encouraged. Even if you first learned about it from the Air Force Museum calendar, we would all benefit from some corroboration. It can be as significant as a first test flight or a shuttle crash to something not-so-well known - such as the Army Air Corps delivering mail for the first time or the first successful V2 rocket launch. The choice of event is yours, but the "Anniversary Posting" rule still stands. Have fun, and I can't wait to read what you all come up with. I'll start us off. October 14th, 1947 - U.S. Air Force Captain Charles "Chuck" Yeager becomes the first man to break the sound barrier using the X-1 rocket plane. Source: https://airandspace.si.edu/stories/editorial/breaking-sound-barrier-75th

Well... I just learned something about medieval history. Probably can't teach it at my school, even though I do talk about some of the crazy shtuff the Normans got up to back then.

Yes. Big part of that is the handling of non-owned vessels in multiplayer, to make the physics of N-parts aircraft manageable in a game that allows you to shoot off every single part individually. The solution they found "sacrifices" wobble (lol) amongst other stuff, to make offloaded vessels a single integrated part, but keeps the capacity to calculate hits and damage to individual parts. It's very probably an iteration of the KSP1 proto-vessel method. Mind you all vessels are still able to grab fuel/battery from their containers correctly. Like really, at this point you're just throwing vitriol around with zero knowledge of what you talk about. You hate HarvesteR and KSP1? fine. But don't try to pass your hate as anything more but your personal views.

Im pretty convinced at this point they'll leave that roadmap on the steam page after firing everyone until there's a lawsuit more threatening than the sucker-sales of people who don't know its abandonware--which is never. I will never buy a product from PD or T2 ever again and I'll warn off everyone I talk to about games. These are trash people.

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.

Vitriol doesn't make this argument any more sound, not that it had any substance to it to begin with. We can talk about which game you like all day, but if you wanna talk objective stuff like the technical side, there's no place for opinions there. KSP2 is a broken, unplayable, badly designed mess, left incomplete and wincing painfully on the ground after being unable to gather interest, sales, or any sort of trust in whatever might come out of it long term. This is not to say that KSP1 is perfect, far from it, but hey, one is still being played by thousands, with a myriad more playing hyper modded saves, making vessels in the thousands of parts, adding planets to it, clouds, obscene levels of detail, gigabytes worth of parts, mission packs, entire mechanics, and it refuses to break under all of that except for some very specific cases.

I feel there was a balance they failed to hit (talking about direction as in the general sense of the finalized vision for the game). The heavy work on tutorials already tells you they were going for "we take this niche game and make it accessible to even more people, it'll definitely sell more." FS! followed on that by simplifying and linearizing the tech tree and having science be a single magic button, where you can absolutely skip even the timers so long as you hit it every time it flashes. Lastly, they also wanted to tell a semi-linear storyline through missions, discoverables and their lore. That part was really good, the new user onboarding was a magnitude better than KSP1. On the other hand, the game really required a strong technical foundation because by the time the difficulty curve of rocket launches and SSTOs is over, almost every player just goes big. Here is where to me they completely failed, by making a game that doesn't support this second bit. Of course now it'll all be woulds and coulds, but it's not hard to see that even without colonies we were already still finding the limits very easily (another example, another one, another). 8000 parts might sound like a lot on that bug report, but that's about a constellation of satellites, a couple rover missions, and a Jool 5 vessel. Meanwhile the game was supposed to allow you to do that on multiple star systems, whilst supporting trust under timewarp... and just no, the game could never be able to do that with the foundation it has. Also, as a last nail in the coffin, they forever handwaved the explanation of how Rask & Rusk (the binary system) were going to work. So yeah, we have a game built on flimsy foundations that they just outright refuse to talk about (remember the promises of HDRP and the system that'd replace PQS? I do), we have only the most basic stuff (yes, science and a tech tree is very basic, deal with it) implemented and none of the complex problems, and not just that but whatever little we have is already making those foundations quake... That's why you can google me saying "technologically bankrupt" multiple times. The balance they failed to implement in game by only including stuff for new people and nothing for veterans, was the same thing behind the scenes: they were doing only the easy stuff whilst completely neglecting the complex stuff and much less having the stones to talk about it. At this point I doubt they even had a plan past "cut everything down as manageable as possible", which is what net us all in one parts, gimped heating, the horrible coordinate reset on ground vehicles, and so on. I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.

Like the majority of the community, I am sickened by what is happening. I feel like we got bamboozled, even worse now than when TT put the game on sale 3 months after selling it at a premium price. I was pretty vocal then that it smelled fishy, and that it reeked of greed that the company would sell it at $50 to those of us who wanted it right away, but then decreased the price as a "sale" to get more buyers. It sounded like they were fishing for more revenue to justify keeping the lights on, and some of us were pretty loud about that. Couple that with the complete lack of communication we had to go through. EA, at its core, is supposed to be a way for developers and consumers to interact while a product is being developed, right? They push out an incomplete game, we buy it, we give feedback, they communicate that they've received feedback and are implementing x fixes, we get the updates, we give more feedback, they talk to us, round and round we go. Right? Not here. Not with KSP2. We begged for the company to talk to us. Tell it to us straight; we aren't going to be upset if you have to delay or come back and say that things aren't going the way you wanted them to. Just talk to us. That's all we asked. And they refused. They got our money and then left us in silence. Sure, we got a dev blog about this lighting issue, or eclipses. We had, at one point, the KERB to tell us what they were working on...but then they took issues off that list before stopping it altogether. All told, we were taken for a ride. And we paid for that privilege. The company said "Hey, we've got this thing that isn't done yet, but give us cash and we'll call it EA and you'll eventually be rewarded". And like horses to water, we lined up and shelled out our hard-earned money. Which they took, and then gave very little - if anything - in return. We paid for the right to be ignored and shut out of development news. We paid to have the community fractured, friends yelling at each other, and the company laughing at us the whole way. We paid to go through this. This exercise is exactly why I didn't get into EA releases with other games that are in my library. I only 1 time before entered EA or a beta-playing phase of a game before, and that was for Harebrained Schemes' Shadowrun. Which went off without a hitch, by the way. But even with that good experience, I had read too many times where things just fell apart and didn't work. Heck, I was close to going in on Cyberpunk, and I'm glad I didn't. But KSP? I couldn't resist. My better senses were telling me to wait, but my heart over-rode them. And Take Two broke it. All told, and to finally respond to what you wrote (I took long enough to get there, didn't I?), I doubt anyone gets a refund. Doesn't matter if you went Epic or Steam, the refund "rules" are pretty clear: less than 2 hours played, less than 2 weeks after purchase. And TT will hide behind that as a way to make sure they don't have to fork the cash back over to Steam or Epic. It would be a nice gesture if they did...but it won't happen. That money is already pocketed and spent (so to speak). So what can we do? Nothing. Not a damned thing. Sure, we can post and protest. Sign one of the petitions going around right now. Take up coding and try to create your own game if you must (even I downloaded the Unreal Engine last night and am going to give it a whirl). But nothing we do is going to amount to anything. We aren't going to change their minds, we aren't going to get our money back, we aren't going to be able to save the franchise or the studio or the employees who are out of jobs. Nothing we do in the end will matter. Where does that leave us? Hopefully being cool to one another. Perhaps talking about KSP1. Maybe finding other games to enjoy. But KSP2? Gone before your time, and we barely knew ye.

Sounds like management wants to keep the product page up and just not have to talk about it again. It got full funding for as long as it was going to. It just isn't worth it anymore compared to other places to put money. So unless the cost of carrying financing drops to nearly zero again, I'd say they've put their money where their mouth is by firing the developers. They just want it to stay on the books to pad the portfolio for investors.