Maxsimal

Glad Dean is spilling the beans on this.

I think it'll be faster than 5 years

When I worked on KSP1, every design was vetted by the leads group as feasible, and I had a strong understanding of what was reasonable even before I began, both from discussion with engineering leads and having been a former systems engineer and being a lead & systems designer on multiple previous projects. Beyond that, I also considered the needs of a variety of different player types, trying to envision features that would please them best without breaking the bank on dev costs. When the design was written, it included various amounts of scoping at the level of the entire design - what features could be cut if we didn't hit them - and within each documented feature - stretch goals that I'd hope we meet that even if they were not met, would not invalidate the entire feature. I tried to include features where if the engineers were behind, the artists could just work on something that did not need engineering time to inject into the game, and vice versa if the art team was behind, to introduce a level of elasticity to the scheduling. Of course, this was coupled by great effort from the dev team, and them working with me to understand the scope & effort behind each feature involved. This is a good general principle for any level of work on building a game - not putting the cart before the horse, validating assumptions on what you can and can't do, and building off of work you've decided is a key early priority for technical and/or gameplay reasons and then moving on from there. This is something I learned to do from working in the industry for a couple of decades and seeing the good, the bad and the ugly on development processes at a range of studios. You can introduce huge inefficiencies to the overall development process when you deviate from good game design & development practices. You can have developers complete work that needs to be thrown away or heavily modified later because you put the cart before the horse, or bet on something being finished and had your art team work on it while the engineering team didn't get to it. You can create designs that please a small portion of your target audience, or just yourself, that don't work for a broader audience and can't be tested until the last minute when its too late to adjust them. Beyond that - you can burn out your staff by whipsawing them between different targets or making off-the-cuff adjustments due to poor design & planning. You can drive engineers up the wall because while as a designer you work in a realm of possibilities and and aesthetic ideas, engineers have to work in a realm where no amount of grand viisionary work changes 30FPS into 60FPS. You can lower the morale of your art team by having to throw away assets they spent man months making because they end up not making it into the build. When you do introduce those morale problems - then you can either address by adopting better practices and fixing root cause. Or you can try to address them by shoving aside 'trouble makers' who raise the why are we doing this concerns in favor of staff with a more positive attitude - even if they're not as talented - often because they're less experienced and don't know where the source of the problem comes from. People to whom you can just say 'Hey, do what I want because I'm the leader here, I have way more experience than you.' As KSP's lead designer - I felt responsible for helping the team hit sprint milestones on time, even if I was not the person writing the code or creating the assets, and I was proud that by and large, we constantly hit those targets update after update - a 3 week slip was afaicr the largest slip we'd done - about 10% of our average version update time. Even if I wanted bigger and better things - the list of what I would have added just to the breaking ground DLC if I could have done anything I wanted by itself would have consumed years of additional dev time - knowing what was good enough and could be done efficiently was a key part of my job. This is in general what the person at the top of the design hierarchy should be doing - and if they're not doing that, the production staff and technical leadership should be empowered to push back and set those goals right. Further - it's about hiring & mentoring competent staff to work under and with you - people who push back against you when you get something wrong so you can correct it at the easy 'I fixed this in a document' stage vs at the very expensive 'it's been built and QA is telling me it sucks' stage. It's not about having your personal vision of each feature making it into the game - it's about getting the best possible game into the hands of the fans. Of course, I am not commenting WHATSOEVER on what happened on KSP2. I'm talking about my experience on KSP1 and on other work at other studios. I'm just saying that the job of design leadership isn't just bluesky visionary work, and building my own personal vision of a project - though having a good vision is important. It's about making sure that the game as envisioned matches the resources available, and that those resources are best utilized efficiently, both to make sure the eventual product is as good as possible for the broadest range of fans, and that the project makes its development costs back and then some, and so the whole team can be proud of the work they've accomplished without feeling burned out by the experience. I feel proud of the work I did on KSP1 even if I didn't get every I idea I had into it - and I hope my former coworkers do as well. This is true for every level of designer as well - one of the most negative things I've seen in the industry is when the top of the design hierarchy - whether they're titled as design director, creative director - heck, sometimes the exectuve producer arrogates this priviledge to themselves - when they decide they're just the blue sky person, the idea person, the person who drops a little nugget of creativity onto the team and expects them to execute around it, and where they don't want their creativity bounded by the earthly concerns of lesser mortals. Again, not saying this happened on KSP2, just saying that someone at the top like that doesn't get to not have responsibility for a project just because they're 'the idea guy' and its other people's job to build their vision or not.

Unless T2 lets go of it, I don't think that's the case for the KSP franchise. For other projects that - yes. And I was not referring to other projects when it comes to letting go of the KSP franchise - I do think there are interesting things on the horizon for a KSP successor.

As much as I loved the Kerbal franchise - and wish it had succeeded and live on, I feel like the best thing is to put it all behind me at this point.

Man it's unfortunate it went down this way - but I gotta agree with SZ, a lot of this was very predictable from an early stage. The conflation of issues that generated problems on KSP2 was the reason I bowed out at the end of KSP1.

I have control points on everything - the plane has a cockpit, the sounding rocket has a probe core. Jumping back to the sounding rocket works fine if I do it while the plane is still in flight, its only after recovery that there's no way back - is FMRS supposed to have a toolbar icon while in the KSC view?

Hey been playing with this recently in the context of an RO/RP-1 game. Been having a few issues with something I was trying to do. Wondering if someone knows what might be up? I have a plane with a sounding rocket attached. The sounding rocket is meant to complete some contracts, the plane just return to base and land. Case 1: - Plane cockpit is the root part. I detach the sounding rocket and it flies off fine. I land and recover the plane, I cannot jump back to the sounding rocket at that point, I'm back to the KSC view. Is this is expected behavior? Case 2: - Plane cockpit is the root part. I detach the sounding rocket and switch to it after I level off the plane. I complete the contracts. I switch back to the plane. FMRS shows some 'fmrs completed contracts' in the message window. I land and recover the plane, but those contracts are not recorded as completed once I've recovered the plane, and the game state doesn't recall that I've passed the Karman line. Case 3: - Sounding rocket core is the root part I detach the sounding rocket. Upon detach, the plane rips itself to shreds, seems many B9 wings are insta-destroyed, maybe an issue with FAR at that point? Not sure. This is true when I jump back to the plane, not just from the sounding rocket's perspective .This is a show stopper so I don't really follow up on this case. I'll try it again with stronger wings soon. I'll play with this a bit more but I'd like to know if there's anything I've done that's obviously wrong, particularly with Case 2 since that seems to be the closest to successful, I'm not sure why FMRS is forgetting the contracts that were completed. Would a log at any point be helpful?

Nice work guys, you fixed a lot!

Thank you! I'm very proud of the updates we did, but it was a team effort, both from the people who worked on these versions, and from the people who built Kerbal up into the awesome game we could add on top of.

Thank you, I'm just glad I got to help move forward Kerbal for a while.

That's amazing! And now we have some insight on what's in a Kerbal's head!

It's not impossible, but it might be improbable.

Thank you so much, it's been a pleasure working with you !

See you on stream in a few hours!

The adjustment is applied automatically to all modded parts, based on their crew capacity and whether or not they're a command part, and the modder has the option to turn it off if they don't want it, so unmaintained modded parts should generally be just fine.

Or maybe I was hungry while I wrote this post

It was an oversight in the change log. As JPLRepo says above, it doesn't apply to landing legs/wheels/landing gear. I believe it doesn't touch Kerbals either, at least not in the case we know about them sliding in, that's a separate issue. Not sure we've got anything for an issue with jittery landing legs, but there may be knock on effects from the ground anchor there anyway that we'll have to look at.

The ground anchoring system is under the hood. The game now anchors parts better to the ground to deal with some sliding issues that would happen, especially when you had light parts contacting the surface w/heavier parts attached to them, and was kind of an artifact of how things worked in PhysX.

Yes, everything is reflected in the dV readout in the VAB - loading/unloading Kerbals, changing their inventory, changing the craft's inventory, etc.

Basically this yes. I don't know why, when the Mk2 parts were added to the game, a nosecone wasn't added. Before my time. There might have been a good reason, it might have been an oversight. We do as many parts as we can manage, for each version, given our capacity and other goals we have for that version. In a world without those restrictions, I'm sure we'd have one. All I can recommend is doing your best to enjoy games as they stand. Continue to make recommendations, try to get people's buy in, but making a case that says anything like 'we need X, X is a huge problem' etc, when clearly that's a bit of an exaggeration, is unlikely to get you much good will from any dev team. Not only can it be a bit personally off putting, but it can get actually do the opposite of what you want, as noone wants to signal to a fan base that the best way to get something added to a game is to make posts like that. The best way to get changes is to make reasoned posts, with a moderate tone, and to get the community to agree with you.

That was mean to read 'now'

Now I don't feel so bad I can't go out to the cinemas, something to look forward to! Can't wait!