Ted

For the past four years, I’ve worked alongside the most talented, passionate and dauntingly intelligent people I’ve ever met, on a game like no other. It's come time though, to step back and focus on other things. Four years ago, I successfully applied for a forum moderator position on the forums and spent the next six months helping run every facet of it. Due to the development model that Kerbal Space Program followed, early access to updates was available to moderators for the purposes of testing and I became very interested in that. As the game grew, so did the demand for more rigorous and organised testing, and soon I worked with the developers to expand and invigorate our Experimental Testing Team. Not long after this, around the time we moved to Unity 4, we set up the QA Team and I volunteered for one of the QA positions. About five months later, I was employed as QA Lead and Director on KSP. I held this position through the rest of KSP’s early access and into release. It was an extremely rewarding time and one that presented a myriad of challenges that we overcame as a team. After version 1.0 released, I moved to the role of Technical Producer. In this role I assisted the developers with organising, documenting and communicating development, oversaw the QA and Experimental phases and ran many, many meetings and standups. Kerbal is a project like no other; it’s a game like no other, it has taught me innumerable lessons about software development, game design, QA... the list goes on. I’ve met tens, if not hundreds of absolutely amazing people who have done things that I could only hope to achieve. I’ve watched KSP affect people’s lives in ways I would never have imagined; inspiring them to pursue careers in aerospace and astronomy, enjoying time with their friends on a rainy day or just having fun. In the time since I started working on KSP, the community has grown exponentially through a massive amount of initiative and enthusiasm from you all. The feats you’ve accomplished in-game and within the community are awe-inspiring. Working on KSP has been a dream come true, it’s a game I have always loved to play and loved even more so to work on. Four years is a long time and after all this time, it’s time that I move on and let someone else take the reins. I couldn’t have asked for a better team to have worked with, or a better project to work on. I’ll truly miss the game, the development team and - perhaps most of all - the brilliant community. You’ve all changed my life for the better in countless ways and given me hope, not just for gaming communities, but for the brilliance of people. Thanks and all the best.

Hi all, As I'm sure many of you read, 1.1 is to enter Experimentals this week! It's a significant update to KSP in terms of just how much has changed under the hood. We've done a complete overhaul of the user interface from a conglomerate of interface systems to Unity 5's native system. Aside from that, an entirely new system for the wheels had to be adopted due to the major changes Unity made to the native wheels system, and the list goes on! Quality Assurance is the most bare bone part of the entire testing process and is performed by around five to ten QA testers pretty much constantly. The focussed testing and efficiency mean that instead of going through the motions of the game as a normal player would, QA tends to identify areas of the new content that would usually be prone to issue and hunt for bugs there. This cuts down the time taken to find issues by a significant margin and means that the content is tested more evenly – playtesting can sometimes skip completely past some aspects of a feature. Furthermore, this method allows the testers to work closely with the developers and compare exactly what they intended to occur for specific cases, to what actually occurs – this is where QA becomes more about feedback. QA is a lot more than just finding bugs. It’s about having the knowledge of the game (especially how it works under-the-hood), the comprehension of the ideas behind the features in the game, the understanding of what a developer wants the feature to turn out like and how you can assist them in making it happen. Furthermore, it’s about condensing all of that into concise and objectively written issue reports. The QA process on 1.1 has been going for a long time, but it has been incredibly fruitful: crushing 516 issues in 107 builds! There is still more to do however, in Experimentals we hope to only increase the stability of the game, add polish to areas and carry out some bug fixing as always! The Experimental Team comprises about 100 testers. All of these testers are volunteers who contribute their spare time to playtest the game. They are normal players, sourced from the various communities via a simple application process. Often and understandably they don’t have as much spare time to devote to testing as the QA Testers and thus there are significantly more Experimental Testers ‘signed up’ than we need at any one time. This works in everyone’s favour as it keeps the activity level throughout an Experimental Phase and doesn’t put pressure on the testers while they also deal with their personal and professional lives. After we have an update go through QA, as detailed above, it is hopefully free from major issues and each feature has had any needed major improvements and refinements carried out; the update is in a feature-complete state. However, many components of a feature may still be unpolished, such as part balancing, or the performance of newer UI on different platforms. This is where Experimental Testing comes in and assists the developers in cleaning up the remaining feedback issues. An Experimental Testing phase typically lasts around a couple of weeks, though it is highly dependent on the number of issues that arise and how much further development is required to reach a release state. At the end of the Experimental phase, there are still a fair amount of issues on the tracker that are still open, but it’s important to note that these issues are typically minor ones, ones that aren’t in the scope of the update or simply issues that would take too much time and resources to resolve. This time around though, things will get even more interesting after Experimental testing! Given that update 1.1 will be unlike any update we’ve seen to date in terms of widespread changes to pretty much any significant and underlying system in the game we're planning to provide an optional pre-release branch of update 1.1. This opt-in branch will run for just under two full weeks before the targeted release date of the final update. The nature and extent of the changes in the update mean that many plugins and add-ons will require refactoring, updating and at the very least a recompile. Of course modders cannot do this overnight and on the flick of a switch, especially with an update of this scope. Typically a select group of particularly KSP-savvy modders would be given access to the new update to help us find bugs, but the extent of the changes this time around is such that we feel we should open it up to everyone. The pre-release branch will be opt-in via Steam only, and won't be available via the KSP Store. We really wanted to make the pre-release branch available on all distribution channels but given the frequency of builds, the size of those builds, and the necessity for everyone to be on the latest version for testing it proved to be impossible to facilitate this on the KSP store. To facilitate discussions of the pre-release branch we’ll be opening up a temporary forum for feedback. Additionally, a separate section will be made available on the bug tracker to report bugs on. Please feel free to ask any and all questions you have!

Hi all, It's always a pleasure to bring you good news. We're in a pretty fantastic position where we have developers working to create and develop features, and a behemoth of an engine update going on at the same time. After assessing the work that the team have completed so far, in terms of features, the engine upgrade, tweaks and fixes, we've decided to plan a 1.0.5 update for KSP. We're including the further development of the contracts that Arsonide/Brian has been working on, Porkjet's fantastic new (and overhauled) parts, refinements to the Thermal system that Nathan and RoverDude/Bob have been working on as well as a rather large number of fixes and tweaks that the team overall have been working on. Of course, the pace that we did those fixes and tweaks have been massively sped up by the ever invaluable work of the QA Team in triaging, reproducing and fix-testing bugs. 1.0.5 won't be built off of Unity 5, instead using Unity 4.6.4 which is the same as 1.0.4. We're including the following work in 1.0.5: Arsonide's Contextual Contracts The contracts in KSP up until now have been pretty self-contained and independent of much of the player's actions, and the rest of the game. Contextual contracts aims to remedy that with a new system that detects and creates contracts for existing vessels. Satellites, for instance can be tagged in a contract to adjust orbits into an already existing satellite network. The chance for these to appear increases as the player builds and places more assets, causing these missions to show up more often in place of contracts requiring new vessels. RoverDude's Thermal Improvements Radiators, the ISRU and RTGs are all getting a bit of attention from RoverDude! Notably, the radiators can now be hotter than the parts they're cooling, allowing for active refrigeration, the ISRU's core now heats separately from its skin and the RTGs now generate appropriate amounts of heat.PorkJet's New, and Overhauled Parts Porkjet's parts We've showcased a few of the parts that Porkjet has been working on in the past, namely he's been working on a Space Shuttle Main Engine (SSME) analogue, an overhauled Mk1 Cockpit, overhauled versions of the Basic Jet Engine, Turbo Jet Engine, Mk1 Fuselage, Mk1 Structural Fuselage and Mk1 Intake. You can view these parts in this album, though for now we haven't made a final decision on the Mk3 ramp yet, as it requires a bit more coding. NathanKell's Thermal Tweaks and Fixes EVA kerbals now handled properly. Energy neither created nor destroyed when exposed area changes. Physics constants and ablation tweaked. Ablation rate is now based on the maxAmount always, not the current amount. Heating from engine exhaust improved and rebalanced. Fix engines not resetting throttle on flameout. Add missing drag cube overrides for hollow parts. Flags no longer count as active flights on the Resume Game interface in the Main Menu. Fixed issue with flag resetting to default. Fixed issues where parachutes would cut on decouple. Make crossfeed toggling on docking ports persistent and also available in the editor (and as actions). FXAnimateThrottle can now optionally depend on engine output, not throttle state. Fixed issues with FlightLogger's values not accounting for reference shifts. Fixed Airbrake action group persistence. Ladders now properly have multiple drag cubes (due to their animations). Kerbal EVA drag cube can now be specified in Physics.cfg. If a part on a vessel is targeted, display the vessel label over the part, not the center of the vessel. Make control surface deploy state properly persistent; fix an issue in the editor update method for them. Fixed an issue with localisation and settings.cfg. Offset cargo bay interior nodes so the inside and outside nodes do not precisely overlap, to aid in part placement. Fixed ladder extend/retract failing after a load in the editor. Procedural fairings set part mass in the editor as well as in flight. Fixed issues with intake logic and display airspeed. And more... Work is still progressing just as quickly as it was on Unity 5, with 1.0.5 serving as our way of releasing the work we've been doing around that to you all. Felipe and Jim continue with their UI tasks, Mike and Dave plow on with KSPedia, Bob continues with the Probe/Antenna Relay feature (he took some time out to improve the ISRU, radiator and thermal features) and much much more that you can read about in this week's Dev Notes!