Jump to content
  • Opt-in Prerelease for 1.1!


    Ted

    KSP_logo_full.png.99743e7d63a15357cde91d

     

    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!

     

     


    User Feedback

    Recommended Comments



    4 hours ago, Coolstorm10_ said:

    I wasn't talking about 64 bit, just KSP 1.1 in general. Sorry if I didn't make it clear :wink:

    ??? um did you mean to quote me?  or did you grab the wrong one of my posts to quote. ???? confused:confused:

    3 hours ago, Bizz Keryear said:

    I wanna be in. I wanna be part in the next step beta test. Can't wait for it...

    I know I wasn't that active here lately but I lost my PW ... and I come here mostly for gathering information.

    BTW: I already have some suggestions for improvements for 1.1.

    1. Make sure pinned windows stay persistent even if switched to map view temporarily (pinned window goes away when going to map, but comes back when switching back).
    2. Would be cool if I additionally could pin them in a way so that they stay on screen even when switching to map mode (e.g. for thrust limiting while in map mode)
    3. Really cool would be if the pinned state would be saved, and next time I switch to that vessel it goes where I last placed it.

    Some cool ideas may be a little late though for 1.1.

    1 hour ago, pipercarman said:

    Does anyone have any news on when the beta will start as this post was made on March 2nd. I'm guessing it's soon as the streamers/youtubers experimental versions look complete. Just wondering if any one knew anything that I do not.

    Soontm

    I expect it to happen this week though but still...

    Link to comment
    Share on other sites

    17 hours ago, Coolstorm10_ said:

    Nope. Unity 5 introduces Multithreading WHICH DOES let the 7 processors also hop in and help. Make sure ya know what you're sayin before you correct someone :wink:

    You are confused. 64 bit generally refers to 64 bit addressing or data. It determines the largest number that a computer can represent with a single X-bit word. a 32 bit word can represent 232, or a number from 0 to 4,294,967,295, and thus can access about 4 GB of RAM per application. A 64 bit application can access 264, or values ranging from 0 - 18,446,744,073,709,551,615, and thus can access up to about 18 EXAbytes of data... Not Gigabytes, not Terabytes... Not even Petabytes... EXABYTES. No computer touches that...

    The largest (that I am aware of) supercomputer in the world is the Chinese Tianhe-2 (天河-2, or "Milky Way 2"). It is a 33.86-petaflop supercomputer with 1,375 TB (1,000 TB CPU and 375 TB coprocessor)... The world's largest super computer is still 13415 times smaller than the max memory 64 bit addressing is potentially compatible with. 64 bit addressing basically makes it so computers will be able to allow apps to access ALL their available free memory, for decades to come... Some people don't even think we'll achieve memory density that compact in personal devices.

    It has been theorized, but not 100% sure if it is confirmed, that Unity 5 may allow separate vessels to have their own separate physics threads. I do not think this has actually ever been confirmed. I repeat, it MAY ONLY be a rumor, as far as I am aware. This fixes the problem of the game slowing to a crawl if you have a large station and a large ship trying to dock... well, till they successfully dock. Then they'd be one thread. Appears to be a limitation to synchronizing the parts of a vessel. Running parts from a single vessel across multiple threads would call upon the kraken. Hard. I do believe that non physics elements of the game engine are now possibly running their own threads. UI, and such. Again, i'm unaware of the exact details of what they did under the hood, but they have made GREAT strides in performance enhancement, and any attempt at multithreading, even if limited, is welcomed!

    Edited by richfiles
    Link to comment
    Share on other sites

    7 minutes ago, richfiles said:

    You are confused. 64 bit generally refers to 64 bit addressing or data. It determines the largest number that a computer can represent with a single X-bit word. a 32 bit word can represent 232, or a number from 0 to 4,294,967,295, and thus can access about 4 GB of RAM per application. A 64 bit application can access 264, or values ranging from 0 - 18,446,744,073,709,551,615, and thus can access up to about 18 EXAbytes of data... Not Gigabytes, not Terabytes... Not even Petabytes... EXABYTES. No computer touches that...

    The largest (that I am aware of) supercomputer in the world is the Chinese Tianhe-2 (天河-2, or "Milky Way 2"). It is a 33.86-petaflop supercomputer with 1,375 TB (1,000 TB CPU and 375 TB coprocessor)... The world's largest super computer is still 13415 times smaller than the max memory 64 bit addressing is potentially compatible with. 64 bit addressing basically makes it so computers will be able to allow apps to access ALL their available free memory, for decades to come... Some people don't even think we'll achieve memory density that compact in personal devices.

    It has been theorized, but not 100% sure if it is confirmed, that Unity 5 may allow separate vessels to have their own separate physics threads. I do not think this has actually ever been confirmed. I repeat, it MAY ONLY be a rumor, as far as I am aware. This fixes the problem of the game slowing to a crawl if you have a large station and a large ship trying to dock... well, till they successfully dock. Then they'd be one thread. Appears to be a limitation to synchronizing the parts of a vessel. Running parts from a single vessel across multiple threads would call upon the kraken. Hard. I do believe that non physics elements of the game engine are now possibly running their own threads. UI, and such. Again, i'm unaware of the exact details of what they did under the hood, but they have made GREAT strides in performance enhancement, and any attempt at multithreading, even if limited, is welcomed!

    according to the stream this is the case, this causes pauses when splitting large stages and probably when joining them too, but atleast there is low lag till then

     

    Link to comment
    Share on other sites

    54 minutes ago, tyler45455 said:

    Why can i not find where to opt in on steam for this?

    You need to restart Steam.  Then use the instructions here:

     

    Link to comment
    Share on other sites

    1 hour ago, tyler45455 said:

    Why can i not find where to opt in on steam for this?

     

    4 minutes ago, CliftonM said:

    You need to restart Steam.  Then use the instructions here:

     

    I didn't need to restart Steam. Comparing the time of his post to the time of the announcement on Twitter, he may have just bin a tad early looking for it. It is there now... I'm 18 minutes from having it downloaded.

    Link to comment
    Share on other sites




    Guest
    This is now closed for further comments

×
×
  • Create New...