Pyritin

Out of curiosity is the occlusion logic an on/off sorta thing or does the model allow for partial occlusion. For example if the nose cone was placed on a rocket normally, and then translated up to create a gap between the two parts. Would the occlusion model partially occlude the top of the rocket (because the cone would then create a gap for air to pass through), act similar to as if the cone wasn't translated, or not occlude at all?

I am glad to see that @Nate Simpson and team can recognize when they've erred and are willing to correct course. I appreciate the more detailed update and hope it continues. I look forward to you all finding a way to track bugs in a continued transparent manner (even being able to see the last part of those sentences saying what stage of the bug resolution the issue is in would help a lot). While I still think the team has a lot to go to regain the trust of the community and player base as a whole, this update is definitely a step in the right direction and it is much appreciated.

Are you seriously trying to say that a proper bug reporting tool that can be used by not only the developers but the community that does the following things is the WRONG way? Consolidate bugs reports into a central location Allows easier discoverability for said bugs for users and devs to follow up with Inform the devs and community which bugs have been replicated or need more information at a glance Provides proof of progress to management and the community Bad enough a MODDER had to build an in-app report solution because the dev's couldn't bother.... Now we got people trying to act like the standard way of bug management that has been a standard for ANY software solution for over a decade is "bad"... I understand that in any games official community section you have to accept that there is going to be a large number people who have "drank the kool-aid" but this is getting a bit overkill...

Really am curious what the reasoning is for these updates. They are never good news, and are typically Nate backpedaling on a statement he made in a previous one. At this point we get it... You're not focused on providing the game at the level you promised in the first place, and despite the fact that not a single aspect of the core loop of the game DOESN'T have a game breaking bug in it you all feel the need to move forward with adding new content on top of your shoddy foundation. There is no need to remind the community of it weekly... We are already living it... You're not actually addressing the community's concerns so why address the community at all? Even radio silence wouldn't stir up the drama and resentment within the community as hard as these posts do...

I though the wings being asymmetrical from top and bottom ARE what caused lift. Having symmetry on top and bottom WOULDN'T provide lift if on the run way (unless perhaps it was angled)

Thanks for the help, because I admit I'm pretty muddy on it. So am I correct in that the basic summary is: Wings - Only parts that generate lift Stabilizers - Allow fine tune control of directionality Control Surface - Allow larger control of directionality

There is the Wing, Stabilizer, and Control Surface subgroups inside of the Aerodynamics group. They are all extremely similar visually (if not completely the same) and their settings in parts manager match as well. It's incredibly difficult to be able to tell what the difference is between parts in each group. To my knowledge there is nothing in the UI that explains it either. It'd be nice if the game did a better job at explaining why you'd use one group over the other, and what the key differences are between the 3. Would make for a decent tutorial video as well.

I understand the need to push forward and deliver on the feature set, but I'd lying if I said I wasn't a bit disappointed. Still have pretty critical bugs in every aspect of the core loop of the game that's in which makes the game pretty hard to enjoy (and many endeavors flat out impossible). The thought that more content is then being built on this shaky foundation doesn't really leave me with a great feeling either. Have to wait longer to have fewer bugs corrected and then have even more added to the pile via new content with even longer periods between improvements for the ever growing pile is a bit of a hard pill to swallow, especially given how terribly large that pile has been since day 1. I have no doubts in the teams enthusiasm to see this through, but I am concerned whether the community and the publishers have the patience it's going to require to see that enthusiasm produce results.

I have been (and still am) pretty critical of KSP2 and the job Intercept Games has had done thus far. That being said I'm more than willing to give credit where it's due. I wanted to thank you @Nate Simpson for taking the time to personally respond and address some of the criticism directly. Many individuals in your position would have simply routed any messages through the PR team or Community Managers (ala @Dakota) and made them deal with the brunt of your decree's (for better or worse). While I don't completely agree with a lot of the decisions made regarding KSP2, it's release, and how things were done I do appreciate you being willing to stand behind your decisions for better or worse. Many in your position would be more than happy to "pass the buck" or let the filth roll downstream. I appreciate your more hands on approach and hope it continues in the future. While I'm not thrilled with the job you and you're team have done up to this point, I do hope things get better not only for the community (and selfishly myself) but for you and your team. I'm sure morale has hit a pretty significant lull do to this release and I hope you all get the chance to complete this product in the way you've envisioned and can be proud of.

Well there's your issue... You trusted Bill to keep his hands off the controls...

All they'd have to do is spin up developer VMs and make the people remote into them. You act like remote development work for corporations is some new concept never done before. That being said the game is written in C# using Unity. Anyone who wants the source code has it already and have since the day the product released.

Miss the crew reports oddly enough. Being able to read what the Kerbal thinks about their surroundings really helped keep the setting in perspective and were fun to read and kept you immersed in the Kerbals.

Outsourcing development work isn't a new thing for a company of any size. In fact the larger they are the more often it occurs typically. At this point I doubt the community cares about how they get the results, only that they see them. Having to a wait a month to see only some of the pretty egregious issues with this release solved is a pretty hard pill to swallow. I'd argue it's probably larger than finding out they had to outsource some work to get the results the community expects.

UI elements being pixel art / sprites is ok, but only if you scale them using the correct scaling algo's. You can't use the same algo's as you do for non-pixel art or it makes the elements blurry. Typically for Pixel you want to use Nearest Neighbor scaling methods, it's clear that right now the UI doesn't and it makes several elements fuzzy and hard to see.

Given the number of developers that play this game I was curious if Intercept was considering offering code bounties to help correct issues? There aren't too many aspects of the game that don't have glaring issues and given the slow turn around you all have committed to (and shown thus far) it makes it seem like we will be in this state for a very long time. I was wondering if you all have considered code bounties to offset this. Many issues in this game at the moment are junior dev level issues (like localization not working correctly) that just take time, but are pretty simple to do. Outsourcing those tasks to a bounty system would allow Intercept to focus on bigger issues and core functionality, greatly improve how quickly issues can be resolved, and frankly cost less than full-time staff.

Yeah, this would be nice to see working. Though at the moment almost nothing inside of the tracking station works. Can't rename vessels, can't destroy debris, can't see flags....

Not being localized to other languages this early makes sense, especially if a lot of strings are going to be changing. But having debug values in the menu's or not falling back to English localization when set to a culture that is missing it's localized value is pretty unacceptable for any product placed in an end user's hands.

The way the inputs always fire makes little sense to me. It'd be nice for you all to make your input system work like basically any modern UI framework does it and add a "handled" argument you can use to consume input so that it isn't fired on multiple events. For example pressing Delete in the VAB changes the docking mode thing (or sometimes the map is opened while typing 'M' into the name of something). This leads me to my next criticism... Why are inputs being processed for actions that can't be taken? If I'm not flying a craft why does that key even do anything? It'd be nice to see this stuff resolved soon as having to have input be set all over the keyboard to counter this just isn't an acceptable option in my opinion.

Many items towards the bottom of the settings windows are still displaying the name of the code behind property (camel cased) instead of the localized display string. Even English language doesn't have strings for several items.