RocketRockington

@DakitessYes you can parent rigid bodies such that there is no physics joint, it's just rigid bodies who's mass and inertial tensors are calculated from the combination of parented parts. It's not even difficult in Unity. You do get some weirdness where, for instance, every part of that combined structure will be jolted equally by an impact - what's nice about physics joints is that if you slam into a light piece of tail section, that part could fold first, for instance. But you could write a workaround for even that, a bespoke joint stress calculation and detach parts when a joint stresses exceeds a threshold. But doing that would have required more forethought than just copying what KSP1 did, and might have forced them to spend more money on programming earlier, so there would be less money for trailers, movies of developers, and animated cartoon tutorials. KSP2 had to prioritize thier budget and allocate it to more key features than improved rocket physics - after all KSP 0.23 rocket physics was good enough to sell Kerbal 1.

That's not the case though. A Falcon 9's fineness is about 20 to 1. (3.7m diameter/70 meter length) Unless you make it out of just one SRB, you can't make a fineness 20 to 1 ratio KSP2 rocket without making it a floppy noodle. Now, you can argue that real world rockets do not ever hit the angle of attack that KSP rockets do - and that's generally correct (unless you consider something like pegasus) because real world rockets have carefully controlled ascent profiles to minimize drag. But I absolutely doubt KSP2 will ever make Mechjeb ascent guidance a stock feature, and therefore - just like with planes - KSP rockets should be more tolerant of aerodynamic forces, not less - and especially not less in such a goofy manner. Further much of the time the goofiness can occur in places real rockets actually do fine - like pogo rockets that do weird oscillations when you're hitting 5,6,7g's. Real world unmanned rockets, especially on the orbit stage, do hit those g figures near burnout.

I have mixed feelings about this. On the one hand - I kind of wish they did, because they've messed up KSP2 so badly, and I'd rather Intercept's version of KSP not be canonical. On the other hand - what I liked about KSP was the realistic tech and realistic orbital physics. Which they're sticking with, currently. Now I imagine KSP2 is going to bork up Interstellar as well - they're going to add some sort of ridiculous resource management gameplay where you have to move materials between stars that would be literally cheaper/faster to make in a mass collider, in a realistic setting. Unless the resource game consists entirely of shipping antimatter to other stars... and even then that's a dubious use. But ehh, they don't have it out yet so I can still pretend that's not going to happen. Anyway, there are other options if you want just an interplanetary or interstellar colony game. Plenty of them.

Lol no. Look at the sons of the forest patches. New content, more frequent patches.

I'm not disputing that drastic measures seem necessary to get KSP2 performance up to snuff - I'm disputing whether its 'too late' or not. And in that context - I don't think KSP2, in its current nose dive, has the sort of time that Satisfactory did. Satisfactory, after all, was fun and well reviewed right from the start. I can't get a historgram chart for Satisfactory from steam from its first days, since it was exclusively on Epic for about a year, but you compare the review from RPS of Satisfactory vs KSP2. Performance wasn't even mentioned as a concern for Satisfactory - the only negatives brought up was the fact that multiplayer could be glitchy, and that the game felt a little grindy. As I recall, Satisfactory ran just fine on middle-range hardware right from the start, and now runs on pretty well on integrated graphics. Compare that to KSP2 that doesn't even have its promised multiplayer, and there's literally nothing to grind as the game only has its sandbox, and runs badly on anything except the absolutely latest gen, top end machine.

Nope. It's rigid body physics and stock Unity (PhysX) physics. None of the parts deform, which is what soft body physics would entail. If we saw things like flexing wings (along the span, not just at the root) that would be soft body physics. Vs reality, completely rigid rockets are a better approximation than the current wet noodle approach. Rockets deform but not much. While they are thin walled, they are held up by internal pressure and clever isogrid reinforcement. Any rocket that bent like a KSP2 rocket would RUD, as the structure would be massively compromised. Even if it didn't RUD, the structure would remain permanently bent, rather than continuing to flop around. If you 'bend' a soda can it doesn't snap back into place later.

@didkodidkodidn't say they were promised just that's what they wanted And KSP2 did set a lot of expectations with respect to slaying the kraken, that physics would be enhanced beyond KSP1, that there would be n-body physics. Did they make an iron clad legal promise? No. But then again, they don't make iron clad legal promises that the game will ever run on your hardware, that it won't be cancelled tomorrow, that they won't take code from modders and resell it as DLC, that they won't revoke your license to use that software, etc etc etc... If you only go by their 'promises' I think no one would buy T2 software ever.

What I expect from the patch: ~25% of the bugs people actually care about will be addressed. Mostly the easiest ones to fix. ~10-15% of performance issues addressed, but no significant change in flight performance. No feature additions of any note. A list of 100+ minor issues that almost no one cares about addressed, itemized in excruciating detail to make the patch look like a bigger deal than it is. KSP2 hopefuls pointing to this as signs of amazing progress and heaping praise on Intercept for being 10-20% of the way to what an extremely bare bones EA launch looks like.

Mostly what other people have said. The only thing I'll chime in is not to be worried about the price increase - even if it goes up to 60-70 and the extra money matters to you, there will likely be a sale on it within 3 months, this isn't a game like Factorio which will not do sales, Sales on KSP1 are constantly happening. If you're willing to wait for a 1.0 release anyway - which is likely 2024 at the earliest - waiting for a sale is not that much more

That didn't work for the EA release, hopefully it works for the patch. I don't expect miracles - I don't even expect standard EA dev progress where small content and QOL fixes happen relatively rapidly alongside fixes. I expect them to function on Intercept time, a sort of reverse-timewarp that the diehard fans seem to accept.

Yes but a development process that was already too slow and already far behind where it should have been doesn't need a detour that's going to require significant rework. If they don't improve performance on their flight gameplay for 6 months, for instance, a lot of people will have tuned out by then.

That means that any changes to the game may incur an even bigger development cost because a tutorial may need to be validated or even updated to match it - another reason not to do your tutorials too early. Also I seriously doubt they did all thier tutorials before 2019, when they couldn't even hold their studio together to ship a game.

Whatever they've said, having a functional game is more important. They shouldn't have put so much emphasis on the tutorials given that they've failed to deliver a game with reasonable performance and low bug count - better tutorials could have waited till the 1.0 release - which is really when they should have advertised to a broader audience, instead of doing a marketting push right at launch. Anyone who wasn't already excited by KSP2 and full of hope for the future certainly must have bounced off the terrible reviews, or refunded and left with a terrible impression. This was not a release to expose 'new users' to.

I think you're misunderstanding something fundamental here. You're.imagining they tried to do a more realistic simulation and got it wrong. That's not what happened. They only decided to stick with simulating things exactly as KSP1 did - with tuning that makes it even floppier. If they wanted a more realistic simulation of the factors you mention, they would use a soft body simulator like beamNG. Or they would have used KJRs solution- fuel tanks don't have 1 structural member that runs from a point in the middle of one tank to the middle of another tank and have all forces transmitted on that one beam, they're welded all around the wall, more similar to how KJR works with their multipoint attachments. Fundamentally, KSP2 mostly tried to replicate KSP1's physics, either be a use they thought that was ideal, or because they didn't know or think they could pull off a better solution.

We'll see if the patch moves the needle. Based on the preliminary list of bugs, I don't expect much change in trajectory, but of course there could be additional fixes making thier way in.

I knew this argument would come. No. This implies that the project management who staff the project focus on hiring people who can develop core features before hiring people that develop secondary features. That's why good project management includes a staffing plan. You don't get handed a random group of workers like some kind of MTG draft and get told to make what you can with them, you hire specifically for what's needed, when it's needed.

Disagree here, as you suspected. They put a lot of time into tutorials, UI, and random polish (eg: sparks when you attach parts in the VAB) than in core fundamentals, like save load. I'm not saying those aren't important - but because those things are leaf node features rather than things other parts of the game directly build on, they should have received less polish at this point - someplace much less than a finished product - than they clearly did.

Sure. Some people aren't launching KSP2 with the launcher and invisible as well. I imagine there's more invisible KSP1 players vs live on steam, than the case for KSP2 because of ckan, but I don't know. The data is more the trend line rather than the specific #s. One things that is incredible about KSP1 is how high its attach ratio is though - peak vs daily players even after 8 years released - not even updated for a long while - is very high.

Per steamdb, KSP1 has seen a noticeable bump in daily players roughly since the launch of KSP2. Could be the advertising, could be what happened with you.

Maybe a modder will add that. Or make paint affect heating from insolation. Doesn't seem like something that should be part of stock, but fun idea.

I think you're right about most people's opinion. But fwiw I think based on what I've read and heard most of the issue lies with KSP2 project management. Take2 isn't an extra-evil publisher. They actually weren't that bad with KSP1 compared to what most publishers would have done with it. And I expect they would fully keep Kerbal going if KSP2 had been doing ok. Thier primary sin is trusting KSP2 to Uber entertainment. I wasn't in the room when they made that decision, but I expect they were sold a bill of goods that Uber failed to deliver on. And they gave KSP2 more chances to succeed despite that rocky start. They started a new studio up to do it - but unfortunately they kept the same project management. I wish they'd let Squad continue working on KSP1 rather than shut it down, but I see why for business purposes they'd clear the decks for the sequel to take over. I don't blame the devs in general, of course. But the project managers who got carried over from uber/star theory, everything I see smacks of people who's optimism and passion far exceed thier competence. I can only hope that T2 realizes this and still has faith in the brand...but I doubt that will happen.

Some discussion has happened here.

I think the Parts Manager is there in its current form only because its a more console-friendly UI. For PC, it's just awful by itself. In addition to part menus, it would be ok - but not as the primary way to access the functionality on a part.

So - it can vary quite a bit. I realize that's not a satisfying answer so I'll give some examples. For instance, some friends at Turtle Rock let me test the Alpha build for L4D way back when. It was the best Alpha game I'd ever tried. They only had the one level working and maybe one special zombie type, but it was amazingly fun, worked great in multiplayer - but it had limited content. There's a reason Valve partnered with them soon after. I genuinely wanted to stay and try it more afterwards. (This is the sort of impression you'd have of KSP2 if you only listened to Nate talk about it) Almost all Alphas are not that - most projects I've worked on, needless to say, are in worse shape than that. First, there's a question of 'even though you're calling this alpha, is it really'. I'd say most games, especially less well managed projects, tend to do some sort of sliding alpha where management is calling it alpha but actually you're still in production on some/many features. Those projects tend to be the worst to deal with because often management is trying to pretend things are further along than they are, and the notion of having a feature-complete but content-incomplete game that you can start tuning, testing, and iterating as part of good game development practice has fallen by the wayside in favor of arbitrary management milestones (guess which style of Alpha KSP2 is in? ) Second - how buggy are you. Most games in alpha are not constantly crashing bugfests as you'd suspect, but there are areas of the game that may be 'here be pirates' - places that only the dev(s) involved are navigating successfully. But still, the core of the game is stable, on a project that is doing ok. Because what you want as a developer is stability to be able to work, rather than a bunch of side-issues hampering you. Core stuff like, for instance, save-load is often made as bullet proof as possible so QA can hand you a save that points to an issue, for instance - games that are properly managed aim to be stable enough in the feature set that - especially for the content team who don't run the game from a local dev build, aren't losing time. Of course I've been on projects where the alpha IS a crashy bugfest, and those are painful to work on, and usually get delayed a lot, at best. In a well managed process though, even if the bleeding edge of the build is unstable, the content team is still working with a stable version that may be days or sometimes even a week old. Third - on game balance - typically what is missing from alpha is the overall fun. The content hasn't been tuned, designers haven't managed to iterate on things, features maybe work in silo'd isolation but need to be integrated. Alpha is often when the design team gets to see just how well or badly their predictions on things coming together really works, you can't hand wave things anymore. But that said - there are typically pieces of the game that feel fun - if you're not seeing at least sections of it being fun, especially the 'core loop' you're probably in trouble That's another reason Alpha being feature complete is important. And as Alpha progresses, if the design team knew what it was doing, the game as a whole gets more entertaining. If you don't have the full feature set that you expected to have to support the gameplay pillars, though, designers can say 'oh, that parts missing, if we just had that it would be fun' and a project can limp through alpha still sucking. Fourth - on visual fidelity - It varies. Often you'll still see a bunch of missing assets. ut you'll also see parts of the game that are at full fidelity - especially if you did your proper due diligence through the stage gate process, at least one 'vertical slice' of your game has remained functional to show the game in a close-to-final state. This can be difficult with games that are more sandbox than level based, but I'd say, for instance, in KSP2's case, one full-fidelity planet working at expected frame rate would have been a reasonable vertical slice for that. Also the game is not fully optimized, but it's usually 'close enough' - within a factor of 2x (this is a rule of thumb of course, not a law). If you're outside a factor of 2x of your target frame rate on target hardware, that means something needs more than just tweaking to reach it. v Fifth - how does this compare to KSP2. Well, KSP2 is in a weird state. Pieces of it I'd call Beta - buggy but finished essentially. The VAB, for instance. The flight UI. And some aspects of it - like the terrain rendering performance - should have been addressed earlier in the process, as they are fundamental to the game. Pieces of it are missing completely from the release build. In many ways what the release version of KSP2 is now is more like a vertical slice than an alpha product. Depending on who you'd ask, I don't think it's even an 'MVP'. KSP1 of course followed a similar course - it was developed in the meandering process of many indie games - a process that can yield good games, but more often than not its through Darwinian methods, rather than the less-failure prone structured processes that professionals typically try to use. Professional studios cannot afford to have the failure rate that indie developers do, after all. Hopefully this gives you some insight, let me know if not. I'm never quite sure anymore how familiar people are with certain terms, but I'm trying not to use too much jargon.

Half the community also says they like it - should @Moons be berated for at least checking it out and keeping an open-enough mind to view it? I don't understand the people in this thread who are often the ones who most excuse the state of KSP2 also getting on Moons' case for at least trying it out and drawing their own conclusions, saying 'well you know about the bugs, what did you expect.' Maybe the sheer # of bugs surprised them - maybe Moons thought there's a chance that people like me who say its a dumpster fire are exaggerating.