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!

Up until now, and including 1.0, KSP development was for the most part horizontal, predominantly adding in features for sandbox and then post-0.18 adding in Career mode features. While there was vertical development in a number of major areas: the VAB/SPH editor, parts, contracts, etcetera, we are now at a point where that becomes the sole focus of KSP development. In other words, we're at a point in KSP's development where we're building upon already existing features to give them even more depth! This brings us to update 1.1. While there is still a fair chunk of 1.1 to design and plan, we do have a good idea of what we want it to include. While HarvesteR, Mu and Romfarer continue to work on the Unity 5 upgrade, RoverDude, Arsonide and Porkjet have already started planning, designing and developing a few of KSP 1.1's new features. RoverDude, specifically, has been working on two features that we've been quite eager to tell you all about. Note that these features are still in development and are pending QA playtesting, balancing and feedback as well as community feedback. Additionally, the more challenging aspects of these features will be off or reduced on the lower difficulties in KSP. The first feature is probe telemetry. With this, a probe must establish a connection back to Kerbin or another 'control point' via an antenna part in order to operate - be controlled by the player, or active in any way. These control points are the planet Kerbin, or a craft with an antenna, a pilot Kerbal, and optionally a large probe core. An example of using pilots as a control point would be a mission over Duna where a piloted command module serves as the remote control point for a landed, unmanned rover. If the player has a non-pilot Kerbal on board, they can still fly the ship, but they would lose access to the probe's piloting capabilities (i.e. a ship where a player uses a probe core for control, and crews it with a non-pilot). However, given the length of time a player would have to spend on simulating a relay network around Kerbin in order to ensure that the KSC is always reachable would be significant, we felt it would be better to have Kerbin simulating a Deep Space Network. It's a ground-based network of relay stations that attempt for complete coverage of Earth. In KSP this is translated to the Tracking Station. As a player upgrades their tracking station, the range of Kerbin's Deep Space Network will increase, eventually allowing it to receive signals all the way from Eeloo's closest approach to Kerbin - similar to New Horizon's range. In this design, the player then only has to send the signal to Kerbin, saving the triviality of waiting for the KSC to be on the facing side and breaking gameplay flow. At this point, you may be wondering what the second feature is, you may have forgotten about it or you may have figured it out. If it's the last one, well done! RoverDude's second feature for 1.1 is antenna relay networks. It extends to range, network pathfinding and soft occlusion of celestial bodies. In gameplay terms, this means that if you want to send data back to Kerbin, or control your probe while you're out of range from your control point, the probe will attempt to use relay satellites you've set up to communicate with a control point and the pathfinding model will simulate celestial bodies being in the way. Additionally, there's no direct pointing of antennas, meaning you won't need to have it pointing at the control point for a connection. The occlusion is slightly fuzzed or 'soft' to make it a bit more forgiving, for example Minmus won't stop you from being able to control your probe around Duna as it passes between you and Kerbin. To go along with this we've also modeled three new advanced antenna parts to serve as relay dishes. They're heavier than existing antennas, but offer the feature of automated network relaying. However, relays are not always required due to the nature of the Kerbin Deep Space Network we mentioned earlier. In the current design, it will be completely possible to shoot a signal directly from, say, Duna to Kerbin - with a sufficiently large antenna on your vessel. Though you will likely want to set up relays to deal with occlusion issues mentioned below. One possible use is that you may want to set up a relay network in a Duna polar orbit to allow continuous control to a landed rover. The relay/signal occlusion is present only for celestial bodies - not vessels or asteroids - and is implemented via analytic geometry. A probe in a low Munar orbit would be blocked while on the far side of the Mun, but a probe sending a signal from Jool would likely not be blocked by Minmus - the soft occlusion angle is fully configurable on an antenna by antenna basis for modders. We've focused on designing these features to be simple and approachable, using inspiration from some of the plugins that have implemented similar features. For example, we opted to have no flight computer, signal delay or antenna pointing. However, there is a clear distinction between the lightweight antennas used for direct communication, and the heavier, more complex antennas used for building up relay networks - the extra mass comes from the hardware required to store and forward data onto the relay network.Another area we've made more approachable is the default implementation of a built-in deep space network, where Kerbin has an ever-increasing inferred relay network, similar to what we have on Earth. The range of this network will be decreased if the player is on 'Hard' mode, effectively requiring the player to set up their own deep space network. On 'Easy' mode, relay, and antennas operate as they do today, with your only limitation being the power constraints and packet size of the antennas themselves. Furthermore, the settings will be exposed in the difficulty settings so they can be toggled in Custom Difficulty. Of course, science will also be subject to the antenna transmission and relay rules as well, using the same pathfinding rules and access to Kerbin's Deep Space Network as probes. With the exception that science must trace a control path all the way back to Kerbin. And there we have it! That's two of the principal features for 1.1 that will change the way you play KSP, but how much so is very dependent on how you play, what difficulty you play on and your game mode. We're pretty excited about these features and looking forward telling you more about 1.1 as development progresses; hopefully you are too! Please feel free to leave comments on any questions and the like that you may have.