Search the Community

It's pretty hard to manage expectations after a huge hype campaign followed by... hummm... a somewhat less than expected initial release. There's a lot of promises (as well tons of plain statements taken as promises) made in the last years that are probably going to be broken, and without a viable release to use as a trade-off (ok, A is not going to happen, but look! B & C were implemented instead!), at least in my book, the less technical details (or any details that can be used by technicians to infer the state of the game) you publish, less work you will have on managing a new loot of fallen short expectations. It's kinda of a catch-22 situation: you talk about, you get screwed. You don't talk about, you get screwed. Finding the less bitter spot in which you get less screwed is the trick. (don't look at me for answers - I'm on the "talk too much" spectrum)

Those who only come on the forums to talk smack about KSP are cheating.

Just catching up after having been away for a while. Amazing video. I do think Nate deserves real blame, because of his role as creative director. When you're in charge, it's on you. But as far as his direct actions, other than wobbly rockets I'm not sure what to blame him for; the font maybe. Wobbly rockets were bad though. I've been the lead on a project to fix an unsalvagable code base inherited from people you can't talk to. While we were eventually victorious, I have to say firmly never do that, unless there's really no other way. Our excuse was that we knew that some of the worst, most bizarre bits of code represented behavior that had been negotiated with customers, but in hindsight it may have been better to risk losing those customers than the expense of continuing with that code base. It still seems to me that the deeper problem with the coding side was the lack of best practices. There were bugs in core functionality they shipped with that never should have been allowed into the daily build, let alone production. The worse your code bade, the more important this sort of thing is.

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?

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.

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.

This was my worry, that we'd see a repeat of for science, dropping a milestone every december-ish. Mathed out a similar prediction earlier, in another thread, actually. On the specific topic of communication, I do think its just as much of a substance issue as it is a cadence issue. We've spent the last year and change being told there's plenty of work going on it the background, things are progressing great, our internal builds are so much fun - And then the community asks to see it, and we get crickets. And while I totally understand a reluctance to show off anything you're not dead certain you can deliver, it doesn't add up to a lot of people, because the trend of it actually happening hasn't been there, even before the game released at all. Lemme break it down here. The game is announced, the community goes wild. we're shown a bunch of cool stuff. Crickets, corporate drama, some date shuffling, and we don't really see much of anything. For the most part the community understands this, as we're being told that we're getting a full release of KSP2. Nearing the dates, it becomes an early access, and most of the stuff we've been talking about for the years between announcement and now is pushed out to roadmap. The community is disappointed but understanding, and takes the reassurances that what is launching will be absolutely solid as solace. The community then gets the first release of the game, and its pretty bad. We're told it'll be fixed up right quick, and the launch window features will be coming shortly. Then its not fixed up quick, and the launch window features are pushed out almost ten months. When asked to explain this both along the way and afterwards, we're more or less told that its because of parallel development in various features that'll speed up the content cadence. But we're given at most some extremely surface glances of this parallel content, and its extremely difficult to actually identify any signs of meaningful progress. The community requests more information and expresses discontent with what is being provided so far, and is promised some level of improved and expanded communication, but with no commitment to any specifics. At the same time, existing communication avenues dry up, providing even less insight into the active progress of development. This triggers another round of communication concern and inquiry, to which the community is told that all the work time has been put into planning out the next levels of work, and therefore communications can't be prepared just yet. This is followed up by information that suggest the patch cycle is stagnating, not accelerating in its timelines. Those last two parts is where it starts to fall apart, because its a bit of a leap for someone to accept that "We have multiple parallel development streams making content" and "We have nothing to talk about because we're planning what we will be doing next" are both true at the same time. If you've had a year of parallel development streams, it doesn't make sense to the average person that you have nothing to show for it across all the streams - While corporate communications is reluctant to talk about anything meaningful that might end up not getting added, the people who already paid just want to understand what the development team is doing and where it might be going, even if they hear that a thing is later cut for non-viability. But if you can move past that and accept that first combination condition, then the patch cycle appearing to be on the same timeline as the last one doesn't add up, suggesting that at a minimum, the parallel development chains aren't going to yield any meaningful increases in patch rates. Effectively, and likely with no malice, the community now has years of being overpromised and underdelivered to, and the scope of those overpromised and underdelivered situations have been coming in smaller and smaller - First it was the entire thing, then parts of the thing, then update cadences, now patch cadences, now communication cadences - Every step feels like its been backwards to many. And I do want to be clear that it is "Many" and not "All" - I don't speak for the whole community, but discontent doesn't have to, not on its own. This isn't an element of the community being told "You won't get this" and then being mad, this is that element being told "We'll do better" and then not getting anything better, over and over and over - Even if the rest is fine, that group is entirely in their rights to be angry about it at this point, because they're feeling lied to. And I think it shows in the cancellation of the KERB and its reception - People for the most part agreed it wasn't working and were ok with it going, the discontent was that it was the only remaining reliable communication path, and that's the thing we keep asking for. Most of us salty folks don't care if we get communications every week, two weeks, month, or even three months - Within reason, we don't want the game to reach that 2028 date in my quoted post . But what we do want to know is that if you come out and say "First of every month, meaningful update", that I can swing in on May 1st and see something that's actually of substance to the game. Not a filler dev article though, I guarantee you that we'd prefer 2 paragraphs and a screenshot of one singular colony feature sliver or a long piece that ends with "None of that worked so we went to the drawing board" over 10 paragraphs and math diagrams about how clouds in gas giants work IRL but why Jool doesn't do it the same way. That might be cool, but its completely irrelevant to the roadmap we want to hear about. The last thing I want to hear is "We'll provide updates on our plans to provide updates two weeks from now" and then come back in two weeks to hear "So we've discussed the initial plans to create a cadence for communications that'll provide details, but we're pushing out that information a few more weeks, check back later". KSP2 is in a bit of a do or die scenario - Not the game as a whole but its communications. You need to decide publicly and vocally, whether you will actually provide more meaningful information and details on a meaningful schedule, or will you prefer to work quiet and just roll in whenever you feel your ready. Trying to play the middle ground of "we'd love to we're totally working on it and doing it" without delivering is just making the whole thing look worse and throwing a lot of doubt on it. You're setting yourself up No Mans Sky style, nodding along to nice sounding things that people ask about without the seeming ability to deliver. You can look at is as "Look how much damage a single comment about development streams has done to expectations" as a reason to clam up, or you can look at it as a reason to speak more to explain what context was missing from that comment as to the actual development streams. But you need to make a decision. And that's the end of my rant from a community perspective. From a personal perspective, I find it disappointing and frustrating that a fully funded and well staffed studio full of professionals are struggling to meet the standards that indie early access games set in the early 2010's, before anyone even knew how to do any of this. There was this indie game called Kerbal Space Program managed to make frequent and meaningful communication updates to its users, while also having frequent and meaningful content patches and enhancements. These updates were relatively small, simple, not particularly heavily edited, and even included stuff that ultimately didn't come to pass that still informed the community as to what the focus at the moment was, and where things might be going. I am getting more and more of the feeling that our "Communications" are being treated as investor statements and press statements rather than being intended for us.

I'm going to say something contentious. Now that manned flights are growing closer, we have to address a fact that isn't being spoken: space travel is dangerous. The Artemis program, or something connected to it, may have the first death in space in over a decade. Maybe not in the first launch, not in the second, hopefully never. But for all the talk about commercialisation, this is space exploration and it is not safe. This isn't pronouncing doom. As Chris Hadfield says in his TED talk on fear versus danger, NASA has considered risk, reduced it where possible. He also said that the Space Shuttle was a complex flying machine and the chances of a catastrophic event was, when he flew, 1 in 38. He still went. SLS and Orion is less complex, we have far better robotics than Apollo ever did, and an honest-to-Oberth partially-reusable 'space truck' in Falcon 9. However... we cannot fully design out the chance of death, nor pretend that we are not putting people in harm's way. SpaceX makes it look easy. SpaceX also has "Stay Paranoid" emblazoned on the desks of Mission Control. Even the Apollo 9-like mission proposed in tandem with SpaceX could result in deaths. What brought this on? A blog post by Wayne Hale on the laser-focus on monetary cost as the be-all, end-all of space exploration: https://waynehale.wordpress.com/2019/06/19/blood-and-money/ If in the future something does go wrong, I have a polite request for the few people reading this: don't go mad. Do not argue yourself into the hole that all exploration should be done robotically. That you knew this would happen and humans should never have left the ground, never mind Earth. Do not let your fear control you. If you see someone else who likes space falling into the same trap, I request - because I can't make you do a damn thing - that you pull them out. Wayne Hale thinks the risk is worth the reward, that it is brave to take on this risk, and so do I.

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.

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.

You can count me as a hard skeptic on this. I've seen a number of analyses of the 'go-fast', 'gimbal' and 'flir' videos and I remain unconvinced there's any actual hard evidence there. The recent testimony is really bizarre and interesting. Still, without like actual instrument data to back this stuff up I can't help but feel unconvinced. Anyone else been following this? https://thehill.com/homenews/4118340-ufo-hearing-live-updates-lawmakers-former-officials-strange-sightings/

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.

Respectfully, The post did talk about them working on each of these problems: And even more he talked about fixing one of the main annoyances that come with the problem. While this doesn't necessarily fix the Delta-V calculator, It shows that they are committed to fixing the issue and making sure that the game stays fun while they work on it: I don't mean to disregard your concerns but I think if we are asking for more quality communication we should keep a positive attitude when they deliver, especially when it's specifically acknowledging what we have been saying for a while. I'm not saying anyone HAS TO be happy with where we are but I think a positive outlook is always better especially if one main complaint was asking for them to talk about what they are working on before it's here.

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.

Gotta agree to disagree then, that was a painful read. Whilst you're free to like what you like, I fail to agree on any of the things you like, and some other things are plainly not a matter of personal opinion, like not being able to read the fonts on the UI, or loading times, or "potential" and so on. For loading times, on a new and clean game, the loading speed difference between KSP1 and 2 is minimal. Sure, the initial load is faster, but at the end of the day, a game made 10 years ago loads a whole *checks notes* 15 seconds slower from startup to flight. And that's with KSP2 still being in its incomplete infancy. Potential does not define a foundation. Foundation is a word reserved for how well the codebase and the game systems are put together. If "what I believe this game can be" was a metric, then every game in development has infinite potential and thus the strongest foundation. That's just not how it works. In reality KSP2 has the same engine as the prequel, the same middleware for some features, but a much heavier save system, and also a much heavier inactive-vessel simulation. KSP2 will be thwarted by that in the future. It also still builds and saves vessels as a tree, it still calculates fuel flow mostly the same way (something something "inspiration" from the code of the previous game), it still handles the atmosphere like the previous game, but thanks to that passive simulation and bad saving system, vessels popping into range still kill your game, orbits change randomly, and the game grinds to a halt with vessels and partcounts much faster than the prequel, to the point systems (like heating) have to be "streamlined", and part-counts have to be hammered down with new, revolutionary "all in one" science modules, station modules, and in the future colony modules too... or having the logistics layer be abstracted to numbers instead of seeing your vessels come and go. Right now, saves are just a couple vessels for 99% of players, let alone making any vessel in the hundreds of parts for maybe the last couple missions, and most people play serially too (fully complete one mission before launching the next). So really, KSP2s limits haven't yet applied to most people and thus it's no wonder they really think the game is better off. When colonies and interstellar arrive, along with more resources to keep track of... it's gonna be a mess, yet devs refuse to address it and have let the bug report sit unattended, and only mentioned the problem once in the K.E.R.B. and that's... the opposite of potential. So yeah, you might slowly start to realize why people who talk highly of the foundation, potential, and what not don't seem completely grounded in reality to me, and why the lack of proper technical talk in devblogs is worrying. I don't care at all for how they failed to replicate eclipses, or how they had to tesselate a line to draw a circle, I care to know why we're still stuck on something as primitive as tree based vessels, and how they plan to deal with high part counts, or even something as basic as what their target is.

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.