• Content count

  • Joined

  • Last visited

Community Reputation

873 Excellent


About Ted

  • Rank
    KSP's Tednical Producer

Contact Methods

  • Twitter @zedsted
  1. I'm glad to see you're still visiting the forums. You've done so much for the game.

  2. 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.
  3. Given that many studies have shown extended periods of 'crunch' or at least overtime for a team leads to more than a 50% drop in productivity, I should think that the team not only deserve significant time off, they require it. That's not even mentioning that those receiving time off (the majority of the team) have been working non-stop tirelessly for over a year, before 1.0 to really do the best job we can and give you guys the best version of KSP. Of course, it also goes without saying that we're people here, we're not machines, we need time to recharge, maybe power down a bit, do some updat- maybe we are machines? Anyway, we'll be back soon enough, we'll refine 1.1.2 to a tee with some help from newer versions of Unity and some of the plugins we're using. And with fresh minds, we'll be able to squash those bugs that are pestering you so!
  4. The issue here is not that we don't have the necessary wheels (or "cars, suspension and the like") knowledge to approximate wheel physics, but that the middleware (both Unity and VPP) are making implementing this in KSP cumbersome and unfortunately challenging to balance currently. We've looked into PID systems for the wheels, and those can work for wheels for sure, but KSP is a game where you can make little to no assumptions about how the player has designed their vehicles - something that car manufacturers can take with certainty and something we'd need for a PID system to be fully capable. Thus, as I'm sure you can see, it's not really car expert that's needed. Going forward, we have solutions that can mitigate this and plans to solve the problems we're seeing, but this takes time and a lot more hard work from a team that has been pushing to the limit on that. I completely understand that it must be frustrating to see this as someone who is passionate about wheels and cars. And I welcome your suggestions, they make a lot of sense if you're building a system from the ground up, but at this point we're unable to implement those in the short-term. Hopefully that has resolved some of your concerns, if you have any further ones, I'm always available via PM (though sometimes can take a few days to reply as things get busy!).
  5. Apologies there, I was hoping we'd made it clear in the article that there would be no key and that it was just opt-in. So to be clear, you won't need a key and there will be an announcement when the prerelease goes live.
  6. I know it's bad Forum etiquette, but +1 to this. I've received 30 - 40 PMs in the past week asking this very thing.
  7. If your looking for testers, hit me up with an Email. I bought the game through steam and have plenty of free time for testing the game for bugs.

  8. If you are still looking for testers for 1.1 let me know. I bought the game through steam.

  9. I have over 500 Hours in KSP but not counting the other 1000 hours i play on a modded version, Sign me up I found a couple bugs my self in KSP :).

  10. The Experimentals builds are still internally tested, it's the prerelease that will be publicly available. That takes place after Experimentals.
  11. OPT me in !! i have more than 1000 hours playing/tweaking and make ksp play with a lot of fps >https://www.youtube.com/watch?v=KM-tIHT_5nY  . TKs

  12. I have 2280 hours in KSP now, so if you need another Experimentals tester, I'd be glad to do it. If you have a bit of space.

  13. Please consider me for the Pre-release 1.1 testing.  I'll be more than happy to do some testing.

  14. hi im a modder with quite a few mods that are going defunkt with the next update, i would love to get the headstart on redeving them for 1.1 but i do not own the game on steam. y mods include the martian rover, the space x lander barge, kerbal cities pack and i am the current developer for retrofuture. thanks for any hep you can he in getting the mods ready earlier.

  15. 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!