Mako

At this point, I think the only thing I want to know is what is the plan for 1.3? It seems like Squad might have plans for announcement with the 1.2 release on Tuesday, so I guess the only thing for now is to be patient. I think some, and possibly many, of the doubts could have avoided if Squad had said a little more than: (paraphrasing) We're fine and we have more devs than ever. I dont think providing names and biographies of the current team with detailed plans of 1.3 is necessary; I think a head count of number of coders, number of artists, etc. currently at Squad along with a very general idea of what 1.3 is intended to be (since Squad mentioned it's already in development) would satisfy many of the concerns people have expressed. I'm not demanding this information, or arguing that we deserve it or don't deserve it, I just believe it could help the situation without hurting Squad. From my seat in a comfy armchair where I can quarterback, it seems like a win-win proposition to me.

@Camacha I'm not entirely sure why you think KerbalEDU is a Squad-made expansion. It was developed by a company called TeacherGaming which has previously developed a teacher-focused modification of Minecraft as well. It is sold by TeacherGaming, not Squad, and licensed for use in classrooms. Obviously Squad receives a portion of the purchase price when a copy of Kerbal EU is sold. The closest thing I could compare it to is if I made a mod and decided to start selling it for money bundled with a Steam Key for KSP. For $50 you get my mod files and a key for the game. Would Squad have an obligation to make my mod available to you? I'm not sure if it is legally possible for any moder to do without negotiating a deal with Squad first, but it's essentially what TeacherGaming is doing. I believe TeacherGaming owns the mod they have created. They could probably sell you a copy of their mod without bundling KSP in with it, if they wanted. I don't see how another company's work is the property of Squad just because Squad build the base. In this case TeacherGaming has no obligation to Squad customers and Squad has no obligation to TeacherGaming customers. So far Squad has made all updates and Squad-made mods available for free to all customers. As of right now I don't believe they've broken their promise, but we'll see what the future holds. And as with everything in this world: things change and life isn't fair. Maybe Mars will be different.

KSP has been using multiple cores for a while. Until the 1.1 update, however, it could not split the intensive physics calculations between cores. Since 1.1 KSP has been able to split the physics calculations by ship. When you separate stages or undock, the game will start processing physics for the separate vessels on separate cores. When you dock it moves everything for that vessel to one core. I know it's possible to set the specific cores available for specific software to use. Have you tried limiting KSP to using only one CPU?

I can't find anything to confirm or deny my initial reaction, but I feel like a double cpu setup could potentially hurt performance rather than help in a multi-threaded game. I'd guess that there is potential for one cpu to be waiting on the other cpu to catch up, so to speak. I wouldn't be surprised (but I could totally be wrong) if there was more overhead or latency involved with keeping both cpus in sync. Also, -- while I'm not sure if it has a direct impact on what you're experiencing -- the single core performance of those cpus seems to be 2.6ghz, which is not generally considered a fast speed for a game as cpu intensive as KSP. However, I'm guessing (and hoping) that 2.6ghz would still be sufficient to prevent the freezes you're experiencing and allow for an enjoyable game with reasonable part counts. Having never really used server hardware myself, this is all just baseless conjecture on my part. I'd love to be completely and utterly misunderstanding the hardware and find instead that there is some simple software-related thing that will sort this out quickly for you. One last thing, and sorry if missed it, but have you tried any of the 1.2 Pre-Release builds? From the Dev Notes/Changelogs and what I've seen around the forums, it would seem like the 1.2 update will bring some improved performance.

You mention using mods. KAS/KIS specifically. Have you tried doing the same mission plan with the same number of ships/number of parts in a completely stock game? I haven't played with KAS in quite some time because of the bugs I encountered (it was a while ago and I'm not familiar with recent performance), but it is possible that is exacerbating your issues. Think of KSP as a car. I know the gas milage my car usually gets. Think of a mod like KAS/KIS as an accessory such as a car top carrier. Now, the shape of that car top carrier depends on who made it. Some people make it more aerodynamic than others. In the same way some mods are more efficient than others. Regardless of the aerodynamics involved, I'd be foolish to think that adding this accessory on top of my vehicle, which adds additional weight and drag, won't negatively impact my average gas milage. Each mod you add (that is more than just a parts mod) is like adding another accessory to the outside of your car. If you expect performance to be just as good as stock, well, I would say your expectations are unrealistic. And some mods have more of a performance hit than others. One other thing after rereading your posts. You mention connecting the vessels with hoses. As I said, I'm not too familiar with the current state of KAS/KIS, but if the game treats vessels connected by hoses like it treats vessels connected by docking ports, that could be part of the problem. KSP is capable of multithreading now. It handles separate vessels in separate threads when it can. However, once you dock two or more vessels together, they become one vessel which is now being handled by one thread. So with mods installed you may be reaching the single vessel part limit that your machine can handle once you connect everything together. If you undock, or in this case unhose, you may experience a small pause while the game splits vessels unto separate threads, but your frame rate should improve. Also, you really need to check the log for errors. Either error spam or just a mod having an error period could be a potential performance hit. Or just wait for 1.2 to be released and then wait for your mods to be updated and hope that is enough improvement for you. And remember, there may be no hard coded limits to number of parts in the game, but there are very real practical limits. I haven't seen any physics based games with user created objects handle large creations without either performance issues or slowing the simulation to allow accuracy.

WRT the entertaining videos he produces I think theres an argument to be made that what he does could well be called finding undocumented features. I, too, would love it if Squad could find and fix all the bugs - both known and unknown - because someone, someday, might do something unpredictable that breaks the game, but I also want new features. As with most things, it seems we must take the good with the bad. And in this case I think the good is really good, and the really bad is often predictable and avoidable.

The first rule about hype train: tell everyone about hype train. I think this update is looking pretty hype-worthy.

Thanks! I had a lot of fun doing this. I made the rover just for this after knocking the engine off of Jeb's plane and being to impatient to cover 2+km on foot. I was very happy with how it turned out. As for the sunrise/sunset, there's shots of both. The rover is always facing west in those shots. I got on site in time to capture the sunset (wish I would have installed Scatterer first), then time-accelerated to the next morning to plant the flag. Thanks for letting me know the imgur album was okay, first time I've uploaded images for KSP.

This was fun. It gave me a fun new mission and sparked my interest in exploring more of Kerbin instead of always trying to fly away. So, here is the gang taking a trip to see what I would see from my window if my home was on Kerbin... Edit - Well,I guess the best way to view this would be to click through to imgur, since it's not showing the full image here.

@Andem I probably should not have post that in this thread since it's only tangentially related, but in response I want to say that I completely agree with you and anyone else who says that KSP's current state does not match the traditional use of the word "Released." If it were my decision to make I would have chosen a different way to market the game since people do have expectations tied to that word. I also want to say that Squad or anyone else could use the word "released" or "Version 1.0" or they could have called it "extended beta" and Version 0.95 and so on (or to be extra dramatic and hyperbolic since that's the reason for the internet they could have called it "Popsicle" and Version Eleventy.One), and it wouldn't change a thing about the actual software or Squad's intentions. It might change your perception of the software, but really you're the only one who has any control over your perception. What we see right now we'd see no matter how they referred to it. Ongoing development means major changes for good AND bad (gotta take the good with the bad), and completed development, traditionally "released," means no more major changes or features. Obviously we can see that Squad labelled it "released" which traditionally means no more major changes, but they are not limiting themselves to the traditions of the label. I'm glad for that. And in this case the only reason I can see for even sticking that label there, since they obviously had no intentions of keeping with the tradition of that label (again, I'm thankful), was so they could begin console development. The early access release model is only now becoming available on consoles, and I'm sure it's a lot more difficult to deal with than with the PC environment. It would likely be far simpler to say 1.0 and then provide updates, and it appears that Squad chose that route. I don't know if they had many options if they wanted to pursue a console release. To try to be as on topic as possible I'll just say that whatever the case may be, I'm glad for continued development, I'm glad for bugs being so thoroughly investigated and fixed, and I'm glad for the discussion and insight into this bug and others. Anyone could have said "well, it wasn't broken before, and now it is," but that wouldn't be accurate. It was broken before, for a long time, and the quick fix turned out to be a fix that broke things in a new and interesting way that happened to be more noticeable and problematic than before. And the quick fix shall soon be properly fixed. So I really have no complaints.

I've been seeing this sentiment a lot regarding the 1.1.x releases. People seem to be getting hung up on the word release, and I'm not sure why. It's just a word; it doesn't mean that much without context. And in this case the context is that KSP is still an ongoing project with all the good new improvements and features and all the bugs big and small. "Consumer release" are not usually still under active development and don't usually receive new features without DLC or expansions (which usually, but not always, require additional purchases). KSP is still being actively developed with new features and major improvements continuing since "release," so I find it hard to compare KSP to traditional game development. So maybe reevaluate how you look at KSP. It is unfinished as defined by the development team's own actions. Why not just think of it as you would if the magic word "release" was never used? The fact that it was used hasn't changed the reality of what KSP continues to be. The word release and the 1.0 version were only ever really used to allow the game to begin console development; those things never changed how the development team has treated the project. In fact, you could argue development has been ramped up even more after 1.0 with the addition of several new devs, NathanKell included. This game has not been "released" by traditional standards, so why get worked up over a word that doesn't really apply. Play 1.0.5 as the current stable version; play 1.1.2 as the beta, bleeding edge version; or wait a while and play the last version Squad puts out (whenever that comes). I do understand the frustration. We all want things to just work, but when software is still under active and major development and you're getting your hands on the latest version there will be bugs and broken mods. Because of this I've taken to waiting for final or close to final release for early access games. I've discovered I both enjoy and dislike the roller coaster ride early access comes with thanks to KSP, and while I'm glad I got in on it when I did, I've decided to be patient when it comes to other titles. This is just my perspective on the matter. I'm loving the deep development discussion we're getting from @NathanKell. I really miss the old dev posts about development.

Since redundancy when not mission critical can be considered excess, I'm going to have to say the word "bug" in your quoted text is the excess word. Based on the last several weeks of Dev Notes alone, reading your quoted text with the excess removed as "Lots of fixes" seems incredibly accurate. What do I get as a prize for playing your game? You'll provide my ticket for the Hype Train?

Today I installed additional RAM in my computer. I broke my overclock while getting the BIOS to recognize the new sticks. Once everything was running (mostly) as it should, I ran some limited stress tests. Then I ran KSP to throw some part-heavy crafts at my system to get an idea of my favorite game's performance. I decided to ramp up the tests starting with some stock ships I've never flown before. I got to the Learstar and managed to fight it to orbit. Then I decided to see how well it handled gliding unpowered in the atmosphere. I time warped until atmosphere and then physical time warped. Physical time warp did not agree with the Learstar (specifically the Mk2 Inline Clamp-O-Tron), which exploded and sent the cockpit on ahead. Having not played too much with body lift in the 1.0.4 atmosphere, and seeing as how I had taken Jeb's and Bill's lives in my hands when I set them on the suborbital trajectory, I figured I'd see if I could get them home safely in a ship that now consisted primarily of a Mk2 Cockpit, Mk2 Crew Cabin, and two AV-R8 Winglets. I have to say that I surprised myself by managing to touch down in the water at below 25m/s and lost everything but the cockpit. So today I saved Jeb and Bill from having a very unpleasant day that I admittedly caused by being impatient.

So, I admittedly have not read through your whole post, but from the bit I skimmed through I have to say you make good points. My first thought is that the newly announced, seemingly in-game, wiki would be perfect for explaining the addition of such numbers. So if there was ever a time to add this it seems like the wiki addition would be perfect.

I don't believe anyone is honestly demanding they change company policy to begin censoring personal social media accounts (though as a business operating in the social media age I'd be surprised if they didn't already have some sort of policy regarding just that). What I, and I believe others, would prefer is for information that is worth sharing be given a "press release" type of treatment and posted here on the forums. If an employee is that excited about it that they wish to put it on their personal social media then a headline and link to the forum posting should suffice (even if it means waiting a day or two for the article to be written). What happens now with these 140 characters or less posts eventually makes it back here and just causes a stir and doesn't really tell anyone anything; it is just a tease that isn't always followed up by official, accurate information. I'm happy to see that the latter part of that statement isn't true in this instance. On topic: I'm looking forward to finding out more about the 64-bit build and the 1.1 update when the article is posted.

I agree with what you're saying. Good Console-to-PC ports aren't impossible. I was only attempting to highlight the apples to oranges comparison of developing Console-to-PC ports versus PC-to-Console ports. My post is from a worst case scenario point of view, and yet it doesn't even begin to reflect the gameplay issues (such as control schemes) one encounters when porting either direction. On the technical side only, my post reflects the difference in work, time, and money involved in the porting process. I am not claiming it is cost prohibitive or unachievable to produce a Console-to-PC port, but rather discussing where the incompetence, negligence, greed, and time constraints you mention are bound to hinder a good port job. It can happen when porting either way, but one way is technically simpler and less expensive to get near perfect at launch.

Absolutely. Porting from PC to a single console all but eliminates the worry of getting software working on multiple hardware configurations and operating systems. I say "all but" because I'm sure a hardware revision over the life of a console could potentially mean you have another hardware config to worry about. This is extremely different from porting a console game to PC. Even if you're only targeting Windows operating systems there are at the very least 3 different versions you need to focus on (7, 8.1, 10, and you could potentially count Vista and XP to make it 5 versions). That's not even considering Mac or Linux playability. Then you need to attempt to make the thing work on a theoretical infinite number of hardware configurations ranging from several years old to bleeding edge parts. Apples to oranges. Now that's not to say things go perfect, but from my point of view (based on extremely limited programming experience) it must reduce a ton of the variables that can make developing and testing software difficult.

Beautiful. I can't wait to fly this mission. I've done it before with a version or two of Mulbin's Munbug. In fact playing with the demo and browsing the forums and seeing Mulbin's version is what convinced me to buy this game. I'm a sucker for this mission and I love all the as-accurate-as-possible recreations. Thank you.

http://forum.kerbalspaceprogram.com/threads/116729-Stock-Payload-Fraction-Challenge-1-0-2-Edition The results in this thread would appear to directly contradict your thread title.

It works for me. I'm using FAR, Deadly Reentry, and Procedural Fairings. The only big issue I've had is in the VAB when adding the Structural Wing part to an existing ship. The game freezes and has to be stopped via the Task Manager as soon as that part touches the ship. Other than that I haven't had any issues aside from the graphical ones noted by pretty much everyone else.

Here's my Duna craft. It isn't pretty but it'll put a Kerbal on the surface of Duna and bring him home with a bunch of science. It has 3 Goo Canisters, one Science Jr., one Thermometer, and one Barometer. All science comes home; no need for transmission (other than crew reports which gives full value for transmission). When I did my mission I decided not to get any science from around the sun and only do science within Duna's influence. I did not attempt any interaction with Ike. It got me enough science that my next mission was a Jool and Jool's moons flyby (I botched that with overzealous timewarp but still managed to make it home with over 3000 science). It requires the following tech nodes (from left to right and top to bottom): Start Basic Rocketry General Rocketry Stability Survivability Advanced Rocketry General Construction Flight Control Science Tech Heavy Rocketry Fuel Systems Advanced Construction Advanced Flight Control Electrics Space Exploration (only for Thermometer) Heavier Rocketry Advanced Exploration Abort Action Group is set to save your brave Kerbals (Leave thrust at Full and clear the rest of the ship, then cut throttle and press 1 for Landing) Action Group 1 is Landing Mode (Lowers Landing Gear, Turns on Lights, Deploys Chutes) Remember to repack Chutes for Landing at Kerbin and it should have ample fuel for less than perfect flying. https://www.dropbox.com/s/w2e73auu3ffpy4g/Duna%20Lander%20Mk1.craft Please let me know if it works for you or if you have any issues. If you're missing certain tech nodes to use the craft I can attempt to edit it and reupload. Edit: I just totaled up the science received from this mission. I was able to get 16 different science reports and bring home a total of 1246 science points. I also wanted to add that this was the first time I'd been to Duna in a vehicle of my own design and only the second time I've been to Duna.

I have a manned Duna ship from right after my Minmus and Mun missions. I'll take a screenshot or two and post a craft file in an hour or so. I'll try to catalog the parts if I can so you can see if you have the tech unlocked. I don't think it hass all the science you're looking for on it, but I minimized it because Duna doesn't have biomes yet. All science can be returned to Kerbin for maximum gains.

Not a problem. It was the first thing that came to mind when I saw the question. I've flown a version, Munbug X I believe, and managed to get the free return trajectory exactly as Mulbin describes it. It's an amazing craft and I highly recommend it. It was a very fun, very difficult challenge to attempt and it took me quite a few tries to carry it out without any auto-pilot. I'm currently working on an free return trajectory Mun flyby on my first 0.23 Career save. I think it really illustrates the impressive skill and ability of the Apollo scientists and astronauts. Good luck!

Mulbin achieved it with his Munbug with a burn of 878 m/s

Good luck! I for one am interested to hear how it turns out. Having the Plan B of getting out and pushing is good, but getting the hang of the orbital manoeuvres necessary for rendezvous is far more rewarding.