Tiberion

You are indeed speculating and you are wrong on a lot of it. I also object to the statement that 1.0 is "laden" with bugs - having tested MANY versions of KSP this one is not in any way abnormal; several releases have included issues far far worse than anything you're experiencing now. I posted in the public feedback thread that I didn't think this release should be labeled 1.0 because there were a lot of changes and things to test. I always always want more time (and I would be a terrible QA manager because of that) I haven't really changed my mind, but in the end the only thing different from all the other releases is a special version number, this release is not especially bad in any way and things are being greatly overstated to fit in the narrative. More straight talk: Something required this specific launch schedule to happen, the reasons are not known, not even to testers and may never be. It doesn't matter now, move on. (end of part directed at Kerbart) I'll restate it again: what people consider very important and glaringly obvious inside the echo chamber of the forums is completely different than what we're dealing with after a couple of weeks and hundreds of instances of feedback being logged. It's your OPINION that we should have changed 're-entry/parachutes/aero' instead of ****ing around, but we *DID* submit bugs and feedback on those multiple times, and they were tweaked and changed over many builds as well. So the end results may not be perfect or what you want; time to deal with it and offer proper feedback for future versions rather than assigning blame or whatever. Also, without getting too much into how the 'sausage' is made - we tested through the weekend, but there is always a point in testing where things begin to get locked down, major changes won't happen unless critical, so that the last period of time is spent just making sure none of those critical bugs make it in. (one or two usually do anyway though) And something I didn't mention earlier; a very important part of testing is confirming that an issue that was published in a new build was fixed and that no new issues are caused as a result. This is a criticial step and also one where a lot of "whoops, how did that happen" comes from. I can't and won't explain individual issues (not my job) but its very likely that "unintended consequence" is the reason for most of them. Hundreds of issues, dozens of builds, lots to retest - you do the math Also re: adding more testers. Probably would not have moved the needle on the amount of bugs that were addressed, the more people you add, the more feedback there is to sort through and prioritize. There's a "sweet spot" where you have the right amount of people on each specific team and I think ted has it just about right. (Final note: Q&A means Question and Answer - We're talking about Quality Assurance - just 'QA')

This is not going to work, sadly, because the fairings are multipart and can be variable in length, there's no way the module can know the bounds required to protect whats inside of it.

There's really nothing different about this release (other than the number) than the dozens that have come before it. I've tested a lot of them at this point. The testing team is bigger than ever, but also more organized and provided with better tools and much more defined testing goals than we had more several years. Have no doubt that Ted transformed the QA and Experimental testing into a very capable organization. The testing team was not "overwhelmed" or "unprepared" - More time might have let us catch a few more issues or get some more feedback addressed, but that is ALWAYS true of any release, not just this one. There are certain realities about the process that will never change. We test a LOT. Dozens of people, 50+ builds, hundreds of bug and feedback issues logged in the tracker. There's less than 10 devs including special mod contributors. Guess what that means? All of those issues have to be prioritized. That means some of them get fixed immediately (and receive multiple builds to get it just right) while others have to wait until the end during "polish" or sadly even don't make it on the schedule during the testing period We can still miss things. Hundreds of thousands of people play KSP, and no two players have the same exact PC or play the game in the exact same manner. So when a version gets released, someone is going to push buttons in a different order or do their special thing and find a bug we missed. This is the reality of software in general. It's also entirely possible we didn't "miss" something you think we did. Maybe we saw the issue and decided it was unworthy for now. Or maybe we reported the issue in an earlier state and the current state is the best solution that was available (this is especially true of delicate balance issues, which we ran into often and spent hours upon hours testing changes.) So even if "the forum" thinks something is super obvious and we must have been blind.. we probably weren't. A lot of feedback is subjective. The testers don't always agree on an issue. We'll all way in on something and then its the devs job to process the feedback and make changes if appropriate. So if you're having a discussion about a balance issue out here, we probably had the same one (multiple times) We're never completely satisfied. Well, I can't speak for every tester, but I personally am never completely satisfied at the end of a testing session. There are always things left that we want to see changed or something we'd like more time to test but there is always a point where you need to move on. (Straight talk, we may never know why 1.0 was scheduled the way it was, I certainly have no "inside knowledge" about it either. It is what it is.) But every release has a finite testing period, and this one was no different. "We could use more time" will always be true, but life doesn't work like that. So its very easy to jump on the bandwagon for 1 or 2 issues that are the hot topics here on the forums and generate some indignant snark about how it should have been fixed. But takes those 1 or 2 issues and multiply them by a hundred and you're closer to the amount of things the testers and devs sorted through since testing was announced. There will never be a perfect release, and thats a fact. I can honestly say, as a veteran tester this version was probably bigger than any we've had, and it included fixes for a multitude of longstanding issues. It also changed a LOT of things, and part of what you're experiencing is dealing with those changes. it is skewing your perceptions. There is certainly more work to do for next time (as there always is) but there are good ways and bad ways to get your feedback heard. What you can do to help going forward: Skip the outrage; Don't proclaim the testers ineffectual, the devs sloppy or uncaring, or frankly worry about what "should have been." Don't buy into the hype that this release is somehow much worse than usual or flawed or anything like that. Plenty of actual things to be outraged about if you look around (hint: probably not KSP related) Go read the last paragraph of Kasper's original post, it has the details on how to properly report bugs and give constructive and helpful feedback. Keep things in perspective; Things are almost never as bad as you think they are. Have fun; It's a game after all

okay so today I did a rough draft of the new Isp numbers and other tweaks for all LiquidFuel+Oxi engines. It was 9/10ths witchcraft and 7/10ths mysticism but I think they'll work out. For those curious about what i did: Multiplied Vac ISP by 0.85 Multiplied Sea Level Isp by 0.8 for lifter and radial engines and 0.3 for orbital engines. For orbital engines I divided the maxthrust by the ISP Ratio (VacIsp / SeaLevelIsp) - this has the effect of weakening the engines in the lower atmosphere while leaving them mostly unchanged out of the atmosphere (with regards to thrust) - for lifter engines I left the old thrusts in place for now since the Isp Ratio is usually between 1 and 1.2 (whereas it can be 3 or 4:1) Then for all engines I added a new key at 0.8 atmospheres with the Isp set to the midpoint between the upper and lower Isps. This has the effect of nudging the Isp curve up so that more of the in-atmosphere time is spent at the lower Isp, allowing me to limit efficiency inside the atmosphere without destroying it in space. In theory anyway; it should make it easier to tweak engines that are "upper" stages as well, not really orbital but not sea-level launchers either. We'll see how it goes I guess. For reference, thrust is calculated as thus now: current thrust = maxThrust * (currentIsp / SeaLevelIsp) (or MaxThrust * ISP Ratio) I also added the "3rd" key to the engines; its used for EVE mostly as is a representation of Chamber pressure. The "key" is basically the engines internal pressure, which counters EVEs native pressure. So if an engine has a pressure less than EVE, it won't produce thrust; otherwise the ISp and thus Thurst falls off along the curve; the result is basically high-pressure engines will work on EVE, at least some, and low pressure engines won't. For now I am going with the powerful Sea level engines having high pressure and the orbitals having lower pressure, with the others somewhere in between. The aerospike will have excellent eve performance just as the stock one does. We'll see how it goes I guess. LORDPrometheus: it might be somewhat close to FAR in difficulty (not especially) but it doesn't function in the same way; FAR had a very forgiving way of finding nosecones and such and reducing drag based on that, stock aero works differently and there's no easy way to know how "tall" a faring-covered section is using the current style of fairings, so anything FAR related won't help. I really try not to add plugins to Novapunch, and I think I can make a good enough set of stock clones for now anyway.

I think it was either $7 or $8 when I bought it

No I mean there's likely no way to make the Novapunch or KW style multi-part fairing systems work as a cargo enclosure to shield parts from aerodynamics, since they are by default not of a standard size. haven't investigated it too much but people smarter than I didn't think so. The main issue with fairings should be fixed I hope, and they are pretty flexible so I should be able to config some that work pretty well. This evening I got all of the bottom nodes tweaked in the config files so they work again, and all parts seem to be attaching. All parts/textures do load fine, so converting to dds isn't going to be mandatory right away. I'll hopefully still do it (and if anyone else wants to do it they are more than welcome to contribute ) I also started playing with thrust and Isps. The old settings are... amusingly overpowered. So todo list - Major stuff: Engine reconfig (new curves, rebalance, config tweaks) Parachute fixing (not sure how they'll need to change) Resetting temperature tolerances for all parts Do something about fairings See if the auto-fairings for Odin payloads will actually function Minor stuff: Maybe convert to DDS Probably a lot of other things.

Yeah lots of work to be done here, and I didn't get a chance to work on it much during testing. Engines and tanks are going to need total re-balance. Given how 'quick' launching from Kerbin is now its going to be a delicate matter to balance them. I'm not sure we can make the clamshell fairings work properly. Might have to abandon them for stock fairings only (perhaps some alternate textures, for now the stock ones should scale enough to work with NP) DDS textures should be pretty swell though. Though a bit tedious to make the change over. More info later.

This is absolutely not true for the launch phase, it is so much easier (with regards to power/fuel requirements, not stability) to launch now than in 0.90. If you're having trouble launching, its probably a design issue (pancake rockets are not a thing anymore) so make sure you build with aerodynamics in mind (tall and thin is good, add nosecaps to boosters, etc) Also on the general topic; having criticisms is good, so is discussing them. I don't know that discussing the entire release being underwhelming is really helpful because your level of "whelm" can be determined by many things included being overhyped, having incorrect expectations (reading bad info or speculation) and frankly, reading "I am underwhelmed by 1.0" threads here. So, focusing on specific feedback is probably going to be better and more useful to everyone in the long run. Also, give it some time. Change is scary!

The same rocket you used to launch in 0.90 should be more capable in 1l0 despite the Isp nerfs, because the atmosphere is way different and you accelerate much faster through the lower atmosphere. Don't get stuck on the numbers and build rockets, getting to orbit is pretty easy. Since Vac Isp went down, that does mean that planetary exploration craft will need to be slightly beefier.

Stability: its hard on early rockets because you don't have stability parts. Static fins at the bottom and a gimballed engine (T45) will help. You also have to learn to adapt to more realistic aerodynamics, getting a rocket unstable is bad news. deltaV readout: it was one of the features that got pushed to 1.1 external camera: not sure what you mean, they're mostly unchanged. What artifacts? The new thing is camera shake, which can be disabled in options, or by going to chase camera. Not sure why you expected orbital data and such on the flight view hud, it was never announced. They never promised to implement every mod's function. its still in map view (once you unlock it via the facilities upgrades) Re-entry is still pretty forgiving, especially from basic launches/orbits. In the end it was probably a pretty good idea for this release to give people some time to learn, and it can be tuned harder in the future. You CAN still burn yourself up though when doing higher level stuff. I wouldn't say its polished either. They DID fix a lot of things and tweak a lot of things that needed it, but they also made huge changes to major things, so it feels unfamiliar. A lot of it will feel better as you learn it, and some things you liked from mods will still have to come from them.

Arr! Good to see ya, Capt'n And because you didn't say it.... Happy Launching!

Not sure how its going to work, the wings and the cargo bay will need some big updates for 1.0, as well as setting up reasonable body-lift for the fuselage. And that is before a complete re-balance of engines and fuel tanks as well. I want to get it done, but I'll have to see if its easier to do something else shuttle-wise

It's not like NASA has had a huge choice in the matter. The Constellation program was a result of the Bush administration's mandate to go back to the moon. Which would have been fine except Constellation itself ended up having some major issues with its hardware design (it wasn't quite up to it, and it was trending expensive. It had some sourcing of shuttle parts, but not enough to make it 'too big to die' So Obama prompty finished it off and decided we're going to Mars now. And we started over on a new giant rocket. The space industry, not wanting to see another project evaporate really tied this one to that pork spending, so it's likely here to stay. We're not ready to go to Mars anyway, so there isn't any hardware being designed for that yet. That will likely start being developed in the early 2020s, hopefully before the end of the iSS and not after it, or a Mars mission is likely 2035 or beyond. For now, NASA's plans for the SLS are definitely only for Orion and the service module, making flights around the moon in the interest of human spaceflight duration who maybe asteroid fragment studies if anything ever comes of that. It is going to be baby steps, because that is what they can afford to develop. On a related note, they just announced that they're going to piggyback some science on the next SLS flight in the form of a dozen Cubesats. Now Cubesats aren't that amazing usually, but these will be launched beyond Earth orbit, which is something that class of payload doesn't have much access to. it isn't exactly clear if all of the Cubesats will be made by NASA teams or if some will be from partners, but they have announced the 1st three selected: A Solar-sail moon probe that will explore the dark side of the moon. A Solar-sail asteroid probe which will slowly sail out to an asteroid and take readings in preparation for future asteroid-adjacent missions A radiation experiment to measure rad exposure to organisms in space beyond Earth Orbit. You can read about that here: http://www.nasa.gov/exploration/systems/sls/space-launch-system-to-boost-science-with-secondary-payloads.html?linkId=13309559#.VR5g0pMe1ik So, I think its pretty good news that they're going to utilize that huge rocket even a little more efficiently by sending along some pretty cool science. None of them will likely be Earth-shattering in scope, but it at least hints that they have a plan they are working towards, and aren't just sitting and waiting for money.

Err which old fairings? It has the same fairings in it that it always has. If you mean will I update those to work in 1.0... I don't know. I'll have to see how the fairing/aero system works and see if its possible, or even worthwhile given the stock fairings - I might just be able to roll some upscaled configs for those. Also a little worried about the functionality of all of those new Odin-thor fairings. So all of that... To be Determined.

Oh man I am green again. Aaaaaaaaagh.

Well, all of those engines have multiple thrust transforms, one for each nozzle, so if one of them is a fraction off of "square" compared to the others it'll show the imbalance. The only fix will be to open them up in unity and re-rig the transforms. They actually updated the engine/thrust system a few updates ago so that thrust and FX aren't tied together, so I can actually go back and make one thrust transform for the whole "part' with the separate FX trails for each nozzle. The tradeoff would be loss of gimbal control, since it takes 2 or more thrust transforms along an axis to enable gimbal for that axis, having just one transform would stop that. I'll put it on the list to fix. I'm not really working on much right now though, pretty much waiting to see what 1.0 breaks before I continue.

Please go vote for Zeus or Vulcan. Vote early vote often Vulcan is interesting because its Leonard Nimoy's birthday, and of course we recently lost him. May the power of social media be used for good, just this one time. xenomorph: paper rockets don't get to keep their names.

KSP 1.0: Beta Than Never

And it really doesn't matter what they have or haven't done, or how much it has been tested. QA and Experimental testing will only get you so far, and with the major fundamental ways that the game is being changed for this final release, the chances of catastrophic-level issues getting released is very high. I have history back all the way to 0.11 or so and it tells me that the big changes always need a followup patch to fix things or make changes that aren't quite right. Before, it was just another beta release so it wasn't a big deal. But if you 1.0 patch lands with a giant thud and needs an immediate patch then you have a problem. Even if the patch was just: New Aero model and attending features (Heat, Fairings, etc) Total part re-balance because of Aero Career/Science Tweaks as described by Harv Then that is a massive amount of things to test or go wrong. I can't think of any possible reason why they would want to risk that in a "launch" situation instead of dealing with it in our newly minted beta period, which won't actually see any releases within it as it stands (Beta Than Ever being the Alpha/Beta Milestone)

I just don't understand this. The community made this thread, with the exact same feedback, 2 months ago, right here: KSP 1.0 Discussion Nothing has changed except 2 months of work on an update and a lot of press about games that were released before they were ready, to bad reviews. The answer is still the same as it was: KSP deserves an actual beta period, where the focus is on polish and bugfixing. The fact that you're still talking about adding new features (at this point, it feels like 6 or 7 discrete new features, more than any other update) means we have never actually left Alpha. If leaving early access because you feel "uncomfortable" about it is more important than either of the choices you presented (not finishing the bug/polish pass, or postponing the new features) then I guess you should press on with your plans. I just wish you guys could be truthful with us about why 1.0 is mandatory at this point. If its a business thing, we'll understand. If its just pride, we won't, and you'll come to regret it someday. It's been said hundreds of times at this point, but I'll say it again: Release more beta versions (0.9x) and let your experienced community members test the MAJOR changes and balancing passes THOROUGHLY so you can have confidence that your 1.0 release will be something to be proud of. It's just sad to see years of hard work get kicked out the door so unceremoniously, for reasons no one seems to understand.

Just the M50? And only when directly below a pod? That is a weird one. I'll have to look into it to see whats what. Can anyone else reproduce this?

I would say that it was likely the download if it was only that one part/ Glad its working

Hmm, weird. If you want to try something, reinstall it and open that folder, then open and re-save shield.cfg in a text editor compatible with your OS - it could be a weird encoding issue. Specifically it seems to have errored out when loading the parts Cost parameter, which should be: cost = 1995 Not sure why that would error out other than a file format issue. Maybe retype the line as well, add a proper carriage return from your OS to see if that makes a different. Also, Might be a bad download too, so you might try downloading it fresh 1st.

I also have a reasonable facsimile at 2.5m diameter in Novapunch, there's actually a few different segment lengths of it, with a separate nosecone.

You need to look in the output or crash log and see the cause of the crash. I am going to guess its an Out of Memory error, B9 and Novapunch together is a lot of texture memory requirement. If you can post the log file we can be sure though