IronGremlin

No, no it was not. This is clearly not commentary on the state of the game. This is commentary on Nate Simpson's conduct, specifically. And yes, I would qualify berating the Creative Director of a video game for being excited about the game he's spent the last 5 years on as abuse - We get it, people aren't happy. I am also not happy. We don't need to re-litigate launch for the next 5 years of KSP2 development. You people have said this crap already I have said this crap already, and Nate has obviously heard it. If you have new critiques, by all means, make them, but this horse is dead and we all need to stop beating it.

Disappointed, yes, shocked, no. It's obviously a fairly subtle bug with an incredibly core chunk of the game, it seems somewhat reasonable it'd take time to fix, and that one would want to proceed carefully when doing so. But more relevantly, take 10 seconds, step outside your own concerns, and think both about being the person on the other end of the keyboard who is going to respond to the question, and also what the likely scenarios are. Scenario A: They've done nothing at all, it's de-prioritized. Necessary answer: "We're aware of the issue and are still working on it." Scenario B: They're actively working on it, but haven't fixed it yet. Necessary answer: "We're aware of the issue and are still working on it." Scenario C: They thought they had a fix, but it regressed something else, and they had to roll it back before release. Necessary answer: "We're aware of the issue and are still working on it." Are you seeing a pattern?

What, you think people are just leaving it on the floor? Like what kind of answer do you expect to this question?

Yeah I think this basically explains more or less everything about the current state of KSP 2. It is a vertical slice demo that got hijacked into an MVP and then pushed to EA launch. To be fair it's not a bad strategy for developing a piece of software - In a lot of domains that basic story is considered best practice. And case in point KSP 2 got to "skip" a lot of the fine tuning and design iteration that made sense for KSP 1 - it seems self evidently true that it could've used some more polish prior to release, but it also seems pretty evident that most of that polish was already in flight prior to release. AFAICT the 'culprit' here, such as there is one, appears to pretty clearly just be that schedules either slipped, or were victim of 'deadline acceleration' - I don't see a whole lot of evidence of mismanagement of the project as far as "where they're putting energy." I anticipate you and I will disagree on this point, but I can understand why terrain performance is where it is - It's a massive problem to solve and they were way too late to hold release up on it. Reading between the lines it seems clear to me that they prioritized unblocking the art department over polishing performance - which is IMHO just a smarter business decision. The choices were: "fire half the art staff and then maybe re-hire them later but probably not" vs. "hold up the release AGAIN in the middle of a pretty serious recession" vs. "release now and pray" - Even considering foreknowledge of how bad this release was, if that was my set of choices, I would've picked the last one and ate the consequences.

No, what Nate said was that PQS+ added a lot of capabilities that PQS did not support, and that the effort as a whole was large and required extensive changes. Triplanar mapping was included along with a laundry list of other new requirements out of the terrain rendering system as a whole. The conversation does suffer somewhat from "PQS" simultaneously being the name given to the terrain rendering system of KSP, and also being a more general technique for rendering terrain, but given that you're not using "PQS" that way either, I don't think you can authentically accuse Nate of misusing the term.

I was unaware parallax was a part of stock KSPs terrain rendering system? I get where you're coming from as an engineer, but it is actually totally legit to overhaul and expand a system with new capabilities that the old system did not have any then make the claim that the old systems did not have those capabilities - that is a perfectly logically consistent statement that is in no way false.

I feel like this is a point that doesn't get made enough. KSP 2's launch was enormously rough, and the game is in a pretty terrible state - but when it works, it's still Kerbal. The bones of the awesome game we all loved are still definitely there. Essentially the only actual design flaw I can think of is not showing projected AP/PE altititudes/other data while editing a maneuver node, which is an extraordinarily solvable design problem. Literally everything else I have heard anyone complain about is a straight up bug or a QOL feature that the original KSP didn't have 9+ years in. I think there are a lot of very valid complaints and fears being expressed here, but if the question were as simple as: "can this group of people eventually make the game they promised if given enough time to do so" - I don't really see any evidence that they couldn't, and FWIW I personally have very little doubt. I do, however, see evidence that it's going to take them a really long time to get that done - and so I think it's valid to call into question whether or not the community goodwill and publisher interest are going to hold up for that process. To echo the OP, I think the first patch is going to be an extremely valuable data point there - right now whether or not they can recover the community goodwill is going to hinge almost entirely on how quickly they can knock out some of these bugs. Hopefully, they can do so decently quickly, and hopefully sales and publisher interest can recover along with community goodwill, but predicting the decisions of economic actors is even sketchier than trying to predict the performance of software development.

Yes, one NAME, anyway. As of right now there doesn't seem to be a way to give separate assemblies separate names. I'm not 100% sure, but I -think- this system is partially implemented. Like all the bits where you can "merge" workspaces together seem to more or less function, you CAN build multiple vehicles etc. in the workspace and only launch the ones that are selected, but you don't seem to be able to save individual assemblies with different names yet - so you get one name for all of the craft/bits & bobs that are in the workspace, which means you also don't get to "pick them out of" a workspace individually / move them around. At least for now I think you're stuck saving what is essentially a multi-craft file as a single craft, which is still more flexible than what we got in KSP 1 at least. Based on some of the drama you get when you dock / undock right now, I'm guessing they still haven't fully sorted out how to handle handing off / assigning the new root part when one craft becomes two, so it would follow that being able to do similar stuff in the VAB isn't quite ready for prime time - EG, if you wanted to have an apollo mission, with the launch vehicle, the command module, and the LEM, I don't think they've finished working out the logic that would let the game know when the launch vehicle "hands off" to the command module, hence naming them all separately wouldn't really do a whole lot aside from making the glitches even more obvious.

Because it's a good idea to test the build/distribution system as well as the software, and leveraging Steam solves some logistical challenges too, so it's a win/win. You always want your QA interacting with an 'authentic' end user experience as much as you can for final testing and approval, so working that kind of thing in is a good idea when you can.

What we're seeing right now in other places in Tech is rounds of lay-offs due to pressure from investors to lay people off. It's almost never really a business decision - but then again, neither is hiring more people, which in software / tech you ALSO do primarily to send signals to investors. The number / quality of people you employ is in no material way connected to how much revenue you produce, and so more typical types of relationships that you'd see in more traditional firms with actual measurable output and real industry standards just aren't present to normalize this kind of thing. That kind of game plays out pretty fast in a market where your share price isn't connected to any tangible numbers - nobody knows what the hell they are doing, they're all just chasing trends, and so quarterly moves are just as good as annual ones because everyone who you want to sling dollars your way is critically brain damaged by FOMO. I don't know if game dev works the same way, that's not my field, but I would assume that because it's still about software at least some of that works the same way - you get laid off because Zuckerberg laid people off, and so that seems like a market "signal" that your company is going to need to follow suit.

I think the thing when freezing and weather management is that these types of changes create cascades. Like Eelo is cold - so include a heater. Which needs batteries. Which need energy generation. Which all adds mass, which needs more fuel, which needs a better engine... You can see this a bit in life support mods, where you'd think it just "adds a chore," but by including another cost calculus you end up changing the mission profile quite a bit because now you care about things like "well how long are we on the surface?" because that lets you cut corners elsewhere. The other massive change to gameplay is that omnicraft are now drastically less practical - you can't just fly a Duna probe down to Eve and expect it to work. I can see pros and cons to that, but I think largely it would add to the game.

Hiya! Tried using my best Googlefu, but couldn't find an answer - Is there a way to "cheat" with this mod and just "have" the planet biome/terrain info automatically available? I sort of burnt out on the probe/scanning gameplay way back in the day, and I'm looking for a more 1.2 ish experience, but without the hassle of none of my mods working anymore.

It's dated, but check out realistic progression lite - that mod did solve interesting things with experiments

http://www.nasa.gov/jpl/ldsd/pia18424/ NASA is developing this technology currently. There are some engineering challenges to overcome in the construction of the chute, but this is possible. It's not really a cure all by any means, but it's a valid methodology. I'm not 100% sure why this hasn't been attempted on previous mars missions, but I suspect that intended delivery mass is a factor - the less you weigh, the easier it is to enter the atmosphere, so it may have just been that it was easier to engineer an effective lightweight heat shield than a parachute for the relatively light payloads we've sent to the surface so far.

Yes. I've been waiting my entire kerbal career for this.

Honestly the fact that kerboscript does not tell you which variable is undefined is a far more important issue to address - if you fix that then this whole problem and many like it disappear.

Not sure if it's worth the trouble, especially considering how crazy ksp is with it's coordinate system, but it might be worth checking out the vecdraw stuff they've made for the KoS plugin - it renders properly in the map view independently of camera angle

My experience worth RO and KoS was km_gimbal that was preventing kos from working properly with prior RO installs - KoS autopilot wouldn't invoke gimbal control. Aerodynamic, RCS, and pod torque worked fine. .24 RO has removed km gimbal as stock has added roll control to default. This isn't definitive or anything, just my observations.

How is the list pulling the completion criteria? Will this work worth nodded contracts?

I think the real question is whether or not we have telemetry data accurate enough to make an inter-stellar orbital transfer... We're all Kerbal players here, we know it's not just a matter of pointing at your target and hitting 'go.' You have to take into account orbital mechanics - What's the center of gravity or respective stars are orbiting? The galactic center, but not exactly? How are we going to fine tune our escape trajectory so that we don't spend absurd amounts of DV on mid-flight correction burns, when we're close enough to see how horrifyingly off-target we are? Granted, we are pretty good at extrapolating telemetry data, but we're talking several exponential leaps past distances we've dealt with before - This is a non inconsiderable navigational hurdle.

This made me laugh.

I think it's unquestionably true that modders have created more gameplay content than Squad at this point. Which I will point out is utterly unsurprising, given that modders outnumber Squad by at minimum a dozen to one, and that they are focused almost completely on providing content, and not any of the rest of the million different things that go into being responsible for developing the core product. I still remember the first time I pegged a solid Mun landing, or how the light-bulb really came on when I started understanding which directions to burn to have a given effect on my orbit. I remember how much I learned about space travel, and how much of what I already knew about the history of manned spaceflight made so much more sense because this game gave me the chance to play with those concepts, and presented them to me in a simple, easy to understand manner. Mods didn't do any of that. That was the core game all the way. I think that you're also SEVERELY underestimating how much more difficult it is to make this game from the ground up than to mod it after the fact.

Indeed! RO is excellently done.

Video? Please, before it gets patched! :-P

Please tell me this mod is still alive.... I love this concept so much and I really hope it keeps going...