MarcAbaddon

It had also been in development for just about 6 months at that point, with a lot of transparency about what the game had and what it didn't have working.

I'd agree the foundations are pretty shaky at the moment, with the way that even basic orbital mechanics are bugged right now and you have your AP and PE change without any thrust. There's really not a fundamental system which is fully working at the moment. The maneuver node editor is a lot worse than in KSP 1 - definitely a lot worse than 1.7 version and even the earlier versions had at least the option to skip orbits which helps a lot in waiting for a good intercept. Say what you will about KSP 1 bugs, but orbital mechanics worked as intended for most of it after the initial test versions. It's also strange to state that KSP 2 having some of those systems at the start is somehow proof that they are more effective than Squad was, when Squad pioneered all those systems and options in KSP 1 and all Intercept had to go was take them over and take inspiration from some mods. Still, the maneuver node usability (it is technically a bit more accurate, but much less usable from an UI perspective), the delta-v engineer and vessel stats are all worse than we had in KSP 1. Finally, I am not sure you can say the game is 3 years old. That would indicate a full reset when Intercept took over, which seems unlikely. It's worth noticing that Intercept took over ~February 2020 and the next delay to the game was only announced in May 2020 citing "development taking longer than expected". This doesn't seem like the full reset people like to depict it as. Fact is, it was under the same leadership of Nate Simpsons who is still responsible for the game that we were told in 2019 that the game would release in early 2020. Of course, Covid and losing a lot of your team are huge setbacks. I'd easily credit them an extra year for it. But it's still been in development longer than 3 years. I know people don't trust big publisher (I don't either), but there was something very fishy going on at Star Theory. To say a few positive things because I still hopeful about the game: I think it is good that we now have some Squad developers more involved in the game. And I agree that the loading times improvement is great, though we also need to see how it will scale with more parts. KSP 1 without DLCs and mods has ok loading times for me, it just scales very badly once you add more parts and mods.

Sure, those are standard part, but NASA and contractors also do not simply stack the same fuel tank multiple times to get the amount of fuel they want when they design a new rocket. If anything the procedural + tooling approach from the realism mod is the closest to reality.

The discussion about KSP 1 design choices is pretty OT here. So I'll leave it at one point, because I thought the response to this one was honestly pretty rude: This statement is wrong, but it is a very reasonable assumption to make for someone with little background of internal game working to do, and just posting a dismissive picture in response isn't ok. Why do I think it is a reasonable assumption? We have a load of KSP 1 bugs return in pretty much the same form, basically from noodly rockets to buggy wheels. However, the reason is not that the devs copied the KSP 1 code base over, but that they use a slightly newer version of the same 3rd party game engine (Unity) which has a physics model, which both KSP 1 and KSP 2 use (for local physics, not for the orbital mechanics). While the team should have the level of access to modify that underlying engine code, it doesn't seem like they did so too any significant extent so far. Now on the terrain rendering: I also expect the devs are able to use a profiler. But I have been surprised what kind of performance screw-ups just went by solid dev teams. The thing is if you work a long time on the same code at some point you have a hard time seeing it's flaw. I'd also point out that this remark from the devs (launch notes) points to other sources: This wouldn't help much with the one complex shader. But to be completely fair, at least in the 2nd post on the system requirements also points toward the terrain render system as the culprit, so I would hope that the responsible part of the team is well aware If anything this statement here is more worrying (emphasis mine): Simple because as we have seen the fuel source system is one of the most buggy parts of the game with crossfeed rules being disobeyed when certain parts like landing legs are attached to the tank. But then, who knows? Maybe this bug got added in a last minute attempt to improve this system. Not sure any of the pre-launch streamers had that bug and I don't have the time to check.

Agreed, there are exceptions for most rules. Most critically for it to work out like the publisher needs to be 100% behind the game and continue funding it. What I see here is people both blaming the bugs on Take Two for pushing the devs to do an early release, while at the same time being extremely confident that they will continue giving the devs more money and time to get us finished and polished product at the end of the road. I doubt that both these narratives are true at the same time.

It was also updated on Monday. Doesn't really tell us anything except that they are working (which isn't exactly a big surprise).

I think it was tracked down to one fairly complex and large shader used for planets. Since it seems to do a lot at the same time, it might not be easy to optimize. Let's face it - either it is fairly complex or they would probably have done it earlier.

Question, what would I use that indicator for? I readily believe it's useful for real pilots, but how does it help me in KSP?

I don't really want to turn this in another general concerns thread, but I doubt that every central gameplay loop that currently has issues was just simply thrown together for EA. And yes, that is somewhat troubling. Anyway, I agree it's the first year that counts but I also think the first patch/more detailed communication we receive will give us a good indicator how the first year will go. They need to be fairly clear on their priorities.

Maybe they have culturally typical male names though? I'll need to take a loot at the Kerbal generator myself

Exploration is not shown on the roadmap either: https://www.kerbalspaceprogram.com/games-kerbal-space-program-2 Unless you count 'explore with friends' which seems more of a reference to doing things together (it's under multiplayer). Resource gathering is mentioned on the roadmap though. EDIT: I mean it is mentioned as a heading, but only in reference to having a 3rd solar system and resource gathering, not really as a full game mode. But I guess that's when it will come.

My only remark here is that I don't really want Lagrande points patched into the SOI model. It'll lead to weird situation at the boundary, and has most of the drawbacks of full n-body (for the player in terms of predictability, I can see it is easier to implement from a dev perspective) and little advantages. Considering that currently even the SOI orbits aren't working without issues, n-body physics isn't something I want added at this stage either. Let's just fix the basics please. Missing n-body has great advantages from the gameplay perspective, so it's not the same kind of issue as with the wobbly physics.

Speaking of persistent rotation, I miss that too, and I think the lack of rotation in time warp will hold back the non-impulsive nodes. The lack of being able to keep your direction pro-grade makes burning in time-warp problematic. Right now you can enter a pro-grade burn with a low TWR engine that will lead you into crashing into the planet from a stable orbit (since pro-grade becomes retrograde at some point into the burn). It's still one of the biggest draws of KSP 2, but the usability in low orbits will be limited if it stays like this. But that's a different topic.

Honestly, I think few people are putting the games side by side and just comparing the feature list. I am not miffed about any of the missing features or parts myself. What concerns me are the bugs and flaws in core mechanism (just to name some: unstable orbits, staging, fuel drain and finnicky maneuver node) and little progress in terms of physics. That the physics bugs from KSP 1 are still in the game was extremely disappointing to me. Orbital mechanics and local physics are the core of KSP, and it was really here I was hoping for a better foundation than we have in KSP 2. Orbital parameters like AP and PE can't be allowed to randomly fluctuate. And that they do make me worry about how they set up fundamental parts of the game. You'd expect movement along an orbit to be programmed in a way that's it stable (e.g. by only directly adjusting the phase and have the actual physical world space coordinates as a function of the phase).

That suggestion seems reasonable. The issue with making the time shorter without a 2nd button click would be that people may not have their vessel aligned to the maneuver node yet.

Just to start with, this is not the vessel is in docking mode issue. I just built a pretty simple craft, a control pod with Valentina on it on top of an ion stage, followed by a poodle stage, followed by a mammooth stage. The vessel launches fine, but on my first flight the Kraken hit after pausing and unpausing in atmosphere (also a bug, but not the one this report is about). When reverting to launch I got a warning message that I don't have control of the vessel since it is lacking a resource for my control pod. The vessel still had Valentina in it and had electric charge, so I have no clue what that was about. Still, when launching the vessel I was indeed not able to steer the craft. Reverting to VAB and re-launching fixed the issue, but it was reproducible, e.g. if I reverted the vessel to launch the problem occurred every time.

It's hard to tell. It depends on how fast the Devs start tackling the problems and whether they listen to feedback. It's also possible that the game will be a mess but has enough redeeming features hidden in the mess, that modders will fix most of it. It being Unity based means it is pretty amenable to wild changes.

Don't want to discuss the reasonableness, since that is very subjective, but dispute it being an outlier opinion. There's a 50% negative review rate plus generally negative critical voice such as Rock, Paper, Shotgun or the German gaming magazines I follow. You sometimes get the negative review rate even if it is an outlier (but then it is usually due to being dragged in the culture war), but then the critical voices are usually more positive. Or to complete the latest analogy of yours, sure, a coffee shop can sell much scalding hot coffee and tell the customers that they should have checked in advance. But it's not good for business. Regardless of whether there's moral blame there.

You are basically discussing something entirely different that the most of us. What you are talking about is managing your own expectations, for which what you suggest might be a good approach. Most of us are much more interested in the questions: What does the current release tell us about the capability of the dev team? How do the long term prospects of KSP 2 becoming a great game look like? Which fundamental improvements have there been over KSP 1, especially in areas that have always held it back like the issues with the physics engine? For the first two questions small vs large company is entirely relevant in terms of what is in EA, because it impacts on whether there's a way for KSP 2 to make a profit down the road. As for the 3rd question, it's relevant because there are systems which are very hard to touch later in the dev process.

Those estimates are often not working well just after release, depending on the methods used. The site you link even has a disclaimer to that effect.

As I mentioned it's more towards my upper range. But we have 10k reviews on Steam, a 1:10 review rate is already very high. Also, the peak was 25k according to SteamDB, not 12k. A 25000 concurrent player peak with 100k sales means that 1 in 4 buyers was buying at the same time, which is also high, but maybe possible on a release day.

I think there's a huge uncertainty in terms of sales, since it was sold in 3 different platforms (I'd bet on Steam being the most common one though), and we don't even have solid numbers for Steam. There were also refunds, so who knows where they ended with - I could see sales being as high as very low 6 digit numbers myself, basically scratching 100k. But I agree that they definitely didn't get ROI on it yet.

You are probably thinking of my post, but I wasn't asking, but instead stating that there are things between indie and triple A. And I agree with your description, I was very surprised to read some people here consider KSP 2 to be an indie game. That's why I pointed out there are games in-between.

That sounds a bit condescending. A lot of people aren't following every dev interview that closely and there not being any money wasn't discussed as much as things like having colonies or there being interstellar travel. Anyway, we still know very little about adventure mode, so let's hope it will be less half-baked. But it's worth noticing that while it was mentioned, it does not even appear in the roadmap, nor have data miners found much on it - unlike colonies, interstellar or multiplayer where they did find plenty. So it doesn't seem to be in focus for the foreseeable future.

I don't think it meaningless, and pointing out the difference is very fair. TBH I think most people had forgotten the exact context of the statement instead of arguing in bad faith though. However, I still think there is a very valid criticism even in proper context. And that's that from my perspective we don't see Intercept even try to slay the kraken. They seem to be using exactly the same Unity physics engine, with exactly the same bugs as in KSP 1 from buggy wheels to noodly rockets to docking/undocking explosions. If you want to use the Kraken you don't reuse the exact same messy joint system and don't even add something like autostrut to at least tame the kraken a little. The first time I suspected there would be trouble with this part of the game was when Matt Lowne off-handedly mentioned the planes veering to the side issue and that he told the Devs what settings to use for the wheels (friction) to avoid that. As weird as it sounds if we had at least different physics bugs this time around, I could believe that they tried to really work on that part and it just turned out harder than expected.