Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Ted

  1. 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.
  2. 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!
  3. Ted

    1.1 wheels:

    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!).
  4. 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.
  5. 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.
  6. The Experimentals builds are still internally tested, it's the prerelease that will be publicly available. That takes place after Experimentals.
  7. 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!
  8. I was about to post something replying to a few of the most recent comments but this really hits the nail on the head. I'll just say the following though. We like to provide you with a mod repository that we can provide with as much efficiency as possible to allow us to continue to focus on the game. If you would ever like to use an alternative, please feel free to and I encourage you to develop your skills in the process by perhaps even making your own! It can be disheartening when these projects come to an end, for whatever reason, but I thank everyone who has ever helped make them happen. And in the wake of them, everyone who has the time, resources and knowledge can chip in - that's what makes the KSP Community so fantastic. During these times, we'll carry on to provide the official repository for you to host your mods on, but completely understand if you choose not to. I look forward to seeing what you guys come up with next. Also, while I haven't seen it here much, I have seen people post up on reddit that we never publicly acknowledged KerbalStuff. I've discussed it in the past in IRC, in person with people when talking about where to get KSP mods and in many more situations. It was great to see such determination and community from someone, why wouldn't I talk about it in public? If anyone had any questions, please feel free to buzz me with them.
  9. My computer here has the following: Intel i5-3570k at stock clock. Overclocked Nvidia GTX770 32GB RAM 1TB SSD Running KSP at 1920x1200. It's a pretty high mid range setup here these days, the GPU doesn't keep up with recent games. However, it provides a very good testbed for KSP. My other machine here I regularly test on is a mid-2014 Retina Macbook Pro with the Intel Iris integrated graphics. It's considerably lower end on the performance, but does play KSP well enough to test with. The rest of the QA Team have pretty varied setups - I'll pass them this thread and I'm sure they'll share their setups.
  10. Not really sure why you would have seen that, Steam Workshop is not a service we're currently using or planning on using.
  11. Woohoo! I think we all owe Kasper a round of pats on the back for killing it this weekend upgrading it all. It's definitely a stick in the mud, but Google should update its indexes soon enough and other sights will cache them soon enough.
  12. They will be in a later update. We want to give them more time for design and overall fleshing-out. Note: This is in no way a confirmation of VTOL engines.
  13. New look? The maintenance didn't go ahead due to technical issues that our server provider was experiencing. They are planning on doing it at a later date.
  14. Essentially it boils down to the IVA models would need to be constantly rotated along with the vessel if they were to share the co-ordinate space. However, it's a lot easier for a computer to simply transform the co-ordinate spaces. I wish I knew that off the top of my head, HarvesteR explained it to me a moment ago.
  15. 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!
  16. And there's one of the problems that one has to work around with an optimisation like this. How are you to skip "physics calculations" if you are calculating whether any forces are applied to the vessel to evaluate skipping them? Those themselves are the physics calculations you mention. It's not an impossible process to optimise, there are just many factors and unexpected outcomes that one encounters that might not be immediately obvious which makes it significantly harder than you might think.
  17. I'm going to entertain this train of thought, just while the cleaners scrape together the dead horse guts that's being so gleefully smeared everywhere after yet another dead horse beatfest. You're completely right that we didn't put much weight on the alpha/beta status as we never followed the development model that those terms apply to. We didn't do it out of some sort of PR move that was aimed at creating fog between the player and the development process. We follow an iterative and incremental development methodology with each update to KSP and the overall methodology for KSP borrows from Agile, but not by much. We've always done that and it's something I've discussed before. I urge you to read up on iterative/incremental and you'll find that there are few, if any, places where Alpha and Beta are the canon terms to use to internally discuss a product's integrity with that methodology. So where do those words come from and why did we use them? Because they're largely used to inform consumers (and at times non-developers) about the integrity of a product from the developer's point-of-view. In other words, they're largely a marketing term now. While they are rooted in software development and still widely used there today, in games they're usually just a label for "We're not close to completing the vision we had, still laying foundations" and "We're close to release and working in a manner that reflects that". I hope that explains the reasoning behind the decisions we made. Furthermore, I hope that the transparency helps alleviate your anxieties about KSP and its development. At the end of the day, you speak absolutely about what me and my coworkers believe about our own project. A project we endear with all the passion, energy and skill that we have in us. A project that we want you to all enjoy. A project that we will continue to work on and refine until we feel that it is done, in an order that we deem to be the most efficient with the resources we have. If the biggest issue that you have with that project is that the version number on it is different from the one you would put on it and the way you choose to discuss that is by making sweeping statements about what I think, then so be it. But do try to take another tone, that one is getting old and it doesn't make me feel as though I can discuss KSP as candidly as I once did. As peachoftree pointed out, that is to compile code and build assets, not to play the game. Development machines are rarely an accurate reflection of the system requirements to play it.
  18. Please see my previous reply to this sort of thing - http://forum.kerbalspaceprogram.com/threads/101289-What-is-the-point-of-the-Suggestions-subforum?p=1566451#post1566451 TL;DR we read it but don't have much time to spare in replying to threads and even when we do, we're hesitant to do much other than agree it may be a cool idea. Usually, adding something suggested would be too far down the line to commit to in a post. Additionally, we're not really at the point of exploring new ideas, so aren't following the suggestions forum as much as we usually would - Unity 5 takes a lot of our attention!
  19. We're in the process of updating to it and evaluating how well 1.1 works on it.
  20. There are a fair few people saying they feel distanced from the development team from the new dev notes. I can't speak for the rest of the development team, but personally I'm often available in #kspofficial on espernet and will usually be up for a chat if you're interested. Similarly, I'm very reachable on Twitter and of course over the forum's PM system. The dev notes are a great way to keep you all updated on the game's development and ins and outs, but if what you're missing is the informal communication between us, there's plenty of other places you can easily achieve that.
  21. The processing for the applications is taking longer than anticipated, not all successful applicants have been notified yet.
  22. Firm deadline is in place now, please don't PM any applications to me. All successful applicants will hear back by the 23rd August.
  23. Midnight isn't the same moment around the world, midnight UTC+1 is indeed 7PM EDT. For future reference I'm over in the UK and didn't fancy staying up till 12AM EDT to close the applications! Please feel free to PM me if you'd still like to apply - a gradual deadline would be nicer than this strict cutoff, but I can't think of a simple way to do that. That does go for everyone, if you'd still like to apply and have notable experience please PM me. Your application will be given equal and full consideration.
  24. Yupp, feel free to do that as I do search for duplicate entries and check for people half-submitting and redoing it etc. Additionally, the applications will be closing at midnight tonight (UTC+1), so apply now if you're on the fence!
  25. Unfortunately not, sorry. And yepp, Starwhip, TriggerAu and Vanamonde hit the nail on the head
  • Create New...