Murph

IPB is simply such dreadful software, with so many visible complaints, so many aspects of the user interface and general functionality that I detest and consider to be terrible design, that I find it inconceivable that there are not a significant number of people who are simply silently very unhappy about it. That leads me to conclude that there must be a significant number of people driven away from the forums by it, both presently and in the future. No, foolish is giving out a positive review when you have major concerns about the entire product experience. When the primary support mechanism is no longer a good user experience, and the community forums are no longer a good user experience, and I see strong evidence of bad management decision making around those areas, then I can no longer give a public positive recommendation. I have a high standard before any game gets a positive public review, and KSP no longer meets that standard. It is still a good way above getting a public negative review, at present, but I can no longer give the positive review, so after some consideration it has been deleted. You may, and should, consider this a "vote of no confidence" in the web/online side of KSP and the staff (the employees, not the volunteers) responsible for it.

Included in that big majority are, I believe, a significant number of people who have been driven away from participating in these forums, and will continue to be driven away from them, by this truly dreadful failure of software and user interface design. I've been periodically looking back in to see if there's any sign of the terrible interface improving, or if it would become less objectionable over time, but I continue to be profoundly disappointed by it to the point of having lost nearly all interest in any form of active participation (and I'm not even really passively participating any more — I've almost entirely stopped randomly browsing the forum due to the new software). Honestly, if the forum software had been this terrible when I first heard of KSP, it would very likely have had a major negative impact on my decision to buy. I have now, reluctantly, deleted my positive Steam review, as I am not able to recommend a game in good conscience when the primary support mechanism uses this software.

Honestly, I'd rather pull out my fingernails with rusty vice grips, than use this garbage format. I don't care that there's hoops I could jump through to get a marginally better presentation, that's too much effort to have to keep doing for every visit to the forum, every thread opened. Historically, I've drifted in and out of levels of activity, but I'm not willing to deal with this new software on a regular basis. My days of frequently browsing the latest questions and occasionally trying to help a newbie out are over, and never likely to return as long as the current horrible software and default discussion inhibiting format remains. I hate the new software, I hate this new format. I've come back to it repeatedly to see if I could warm to it, and I end up absolutely loathing it every single time. Bad forum software, badly managed migration to it, bad user experience, just bad all round. Overall, I'm mostly done with these forums because of the new software, I'm no longer interested in being an active part of them.

Comms network which was more or less designed to be a distributed, chaotic, anarchistic free for all descends into chaotic anarchy. Film at 11!

In one word: dreadful! This terrible software could be a perfect case study in gross inefficiency and failure to learn from decades of past experience. The index pages fit about half as many forums/threads per screen page, and with far less information than is typical of good forum software. There is an elegant simplicity, highly developed efficiency of layout, and a maximising of visible information with phpBB, vBulletin, etc; and that is entirely missing in this dumbed down nonsense. Overall, it just puts me off wanting to read the forums and contribute to them. It is a huge step backwards.

They say first impressions count. My first impression is that I hate the new look, it feels very awkward to use compared to vBulletin, phpBB, and others. Everything seems to make horrendously awful use of space, with zero effort to actually maximise the amount of information which can be on screen (far too much white space on index pages, feels like considerably less than half the information presented per screenful/page). This looks like a huge step backwards to me, piling on a bunch of glossy but entirely unnecessary features and junking the elegant simplicity and optimal/efficient layout. Overall, I detest the look and feel of it, it really puts me off using it. Thumbs down, 1/10, poor effort!

It's an ancient bug. I've encountered it more than a few times, but overall infrequently. It appears to be something about the way the KSC loads when it comes into physics range. My guess would be some sort of race condition with the creation of the colliders, where they come into existence before all of their parameters (e.g. position and size) have been set correctly.

[quote name='UmbralRaptor']The migration was finally finished on October 26. (As mentioned on the front page of the wiki)[/QUOTE] Yes, although there are still multiple outstanding issues. The only thing fixed at that time was the file uploads.

[B]Squad, please break everything with 1.1, if you need to. Don't compromise making the game better, or being able to fully embrace the new features provided by Unity 5.[/B] Yes, I fully expect 1.1 to break stuff for a lot of people, and that's just fine. I want 1.1 to break stuff widely for most people, as long as every breakage is due to an improved or refined feature (or an unfortunate side effect of Unity 5's behaviour just making it unreasonable to maintain some old behaviour). It is trivial to keep a 1.0.5 install around, so everyone is quite able to continue with current saves for as long as they want to, so there is no serious problem when (not if) 1.1 breaks stuff. That said, chances are that you'll be able to import saved craft from 1.0.x, and just modify them to work with 1.1. New versions breaking stuff DOES NOT mean that your old craft are all trash and you have to completely start over. It just means that you need to get over it and move forward by adapting them to the new version. To everyone who throws a tantrum at new versions breaking stuff: If Squad listened to you, development on the game would stop years before the potential was properly fulfilled. In some cases, your demands are extremely selfish and foolish. Squad have actually been very good at maintaining compatibility across the versions, and none of the tantrums have ever been appropriate or justified.

Looks like the same bug exists on OS X with an ATI Radeon GPU, no mods installed. Just FYI, I'm not particularly looking for support.

1.0 has never been any guaranteed indication of "end of development" or "finished". It just indicates that it is feature complete for the first full release (i.e. contains everything they feel it needs to be a full release). Every developer gets to freely define exactly what 1.0 means for each of their products. Squad were quite clear that 1.0 was in no way the end of development, before they even released 0.90. Not once did they get anywhere close to suggesting or implying that 1.0 would not be followed by tweaks, fixes, and general polish, or that there would be no more issues with older saves breaking. Given the complexity of the product (due to the literally infinite possibilities for use cases), it was entirely expected and predictable that there would be a few minor releases after 1.0 to put some polish on it. They did the right thing, as taking it out of "early access" has some sales and marketing benefits for them. Be glad that it's an excellent developer that actually wants to properly squash every last bug, complete every last bit of polishing, and actually gives a damn about customers. Many big developers (e.g. EA and all of the names they have assimilated) slap a 1.0 label on any old incomplete barely functional crap and shovel it out the door with a price twice that of KSP; then publicly demonstrably outright lie about things to customers; then ignore major problems until everyone loses interest in it and gives up. - - - Updated - - - Nobody is forcing you to run the latest update. You can carry on with your existing save for as long as you like. It's your choice to use the latest version or not. You can play 1.0 from now to the end of time, without ever starting over, if you want to. Please, Squad, KEEP BREAKING STUFF! When there's something in the product that isn't quite right yet, and when the product gives everyone the trivial ability to keep using the older version, there's absolutely nothing wrong with breaking stuff to improve the product.

Nope, you're dead wrong about "they do need to stop". They need to keep going with the changes and tweaks, and not let existing saves tie their hands. Over time, each feature will naturally mature to the point where it doesn't change much (i.e. doesn't cause anything to break) over versions. Squad, KEEP BREAKING STUFF! Break it as often as you need to, as long as the overall result is pushing forwards towards perfection. The approach so far is just fine, I wholeheartedly endorse and support your development practices, and do not see any major problems with them.

I'm not sure exactly what the best fix is, whether it's to completely remove certain explosions, or just revisit the effects generated by each part and add some sanity. What I am sure of is that some work is needed, and what we currently have is not correct. The example that is bugging me right now is very early career mode, putting a 1.25m stack decoupler and modular girder segment as launch supports below radially attached RT-10 SRBs (needed because the centre column of the stack extends below the bottom of the SRBs). Doing things that way because the launch clamps are too deep down the tech tree (another thing which is quite stupid). On launch, there's a HUGE screen filling explosion from the modular girders and/or decouplers being torched by the SRBs, and it's just plain stupid and quite annoying, as there's nothing about either the decouplers or girders to justify such a huge visual explosion. It just makes no sense, and detracts from the game.

You can already do that for 2.5m using stock fairings â€â€.they work as both interstage and top payload fairings.

This whole OpenGL vs. DirectX thing is entirely moot and the above responses really make little sense. Unity provides both of them (it has to, as it is multi-platform), and it is Unity that controls if/when either of them are updated to a newer version. Squad's only real say in it is when they update to a newer Unity version, and the versions of graphics code that ship with the version of Unity they have chosen. As for the magic massive performance improvement theorised above, that's quite unlikely. Updated OpenGL and DX support will likely provide some improvement, but KSP simply does not push the graphics hard to make the massive improvements theorised likely. KSP performance is mostly limited by physics and simulation computation, not graphics, so updated graphics libraries and drivers are far less likely to deliver a big impact.

I might be missing something, but I think you can do this already, with no need for new parts. Just use the standard cargo bay and configure the doors for zero opening with the new opening config thing? If you need to attach something externally to them, it should be possible to use the editor's offsetting feature to attach a wing or whatever lower down and then move it up to the desired location. Or have I missed a gotcha with that?

You can report it to Google for violating the ToS of 2 different Google products: Google Blogger: https://support.google.com/blogger/answer/42577?hl=en (then paste in the blog's URL in the form near the bottom of the page) Google AdSense: At the top right of any Google advert, there's normally 1 or 2 buttons. Click the one that looks like an arrow pointing to the right, and has a "AdChoices" tooltip if your browser shows you a tooltip for it. That will take you to a page where you can report the site serving the advert as a probable ToS violation (Google prohibits the use of their adverts on sites which are pure spam content). I have no idea how good Google are at processing those reports, but that's how you report a Blogspot/Blogger site and/or a fraudulent AdSense site. Please do not report sites based on someone else asking you to do so. Form your own opinions on whether a site violates the ToS of one of Google's products, and only submit reports if you personally conclude that the site is a problem. There's probably very little Squad can do about it, as the site does not seem to use significant amounts of Squad's intellectual property. They might be able to pursue it for trademark infringement over the use of "Kerbal".

The basic text content functionality (including MediaWiki's ParserFunctions and similar) has been working pretty much fine all along. All image processing broke completely around the start of May, and we got a response that it was being worked on and due to the wiki being in a transition/migration state, including MathML stuff. Only cached results of historic image processing are displayed, new images, changed images, and new sizes of existing images are 100% broken. Since then, I've identified a number of other broken/misconfigured server things which are detailed on the wiki's "migration issues" page linked from the site notice, which serves as our (the wiki community) master list of problems needing looked at. Personally, I'd been holding off saying anything outside the wiki's internal talk pages and the issues page, as we had been assured that a fix was coming. I've now stuck my head up here since this thread was opened, as it's now gone past all reasonable timescales without any obvious movement. It should be obvious from the issues page, but there's 2 main phases of remedial attention needed: 1) A fast fix to the major visible stuff (i.e. images and MathML), which really should not be difficult to address; and 2) A deeper look at the state of the MediaWiki install to address the more subtle and less visible issues (which are still important), and basically give it a comprehensive health check/cleanup. Beyond that, we do need some low intensity, general server support on an ongoing basis, so that we can get things like configuration tweaks, MediaWiki extensions, etc looked at without too much fuss. I wouldn't expect that to be a significant number of hours per month, just occasional collaboration between server admin(s) and the wiki community to make it as good as it possibly can be, and mostly low urgency stuff. (None of the issues listed have anything to do with caching on the user end, but it sounds like you've already figured that out.)

This isn't really about getting the content up to date, but fixing significant things which are broken on the server (and which are significantly impairing our (the community) ability to update the content). We just need Squad to spend a day or 2 fixing the MediaWiki installation (and it may well be as little as just an hour or 2 needed, in my expert opinion), and then to commit to properly maintaining it on an ongoing basis.

Your analysis is fundamentally flawed, as there is no pure ramjet in the game. The J-X4 is equivalent to the SR-71's hybrid turbojet+ramjet. It functions as a normal low bypass turbojet with optional afterburner at lower speeds, converting into a high bypass turbojet with the afterburner becoming effectively a ramjet at high speeds. We don't need a pure ramjet, as it would be a horrible engine for most practical purposes, for the same reason that the SR-71 uses a hybrid engine, the need to operate at relatively low speed during takeoff and landing. At mach 3+ supercruise, most of the thrust from the SR-71's J58s comes from the afterburner functioning as a ramjet, and the turbojet relegated to basically just being a pump to keep the active intake alive and contributing very little thrust. I.e. for the last 50 years, it has been very possible to have the best of all worlds, of turbojet, afterburning turbojet, and ramjet, in a single package. It is old, proven, reliable, and relatively simple tech (by today's standards); and that is what the J-X4 is emulating. Beyond that, I don't see any problem with the RAPIER beating the turbo-ramjet in certain situations. I don't see anything broken here, so I think your complicated attempt at fixing it is not needed.

No, no, a thousand times no! Keep going with development as-is. Stability of old, long established features will emerge naturally. There is absolutely no need to kill off the inertia of ongoing development. The action proposed here would be hugely harmful to the long term success of KSP; whereas continued significant feature development boosts the long term success and helps both to stretch the long tail of sales revenue as well as generating potential for more short term spikes in sales revenue, i.e. maximum commercial success. Much as I like the wide selection of mods available for KSP, that should have absolutely zero influence on development decisions by Squad (other than to continue to make sure that there's a generous selection of hooks for mods to attach to, and avoiding coding in ways that make it difficult to later mod). If some modders can't handle the pace, so be it. Any mods of significant value which are under proper FOSS licenses will continue regardless of their original creator's feelings. Those with restrictive licenses will die off and be replaced by something else (hopefully something better, and with a properly open license).

Frequent small updates are better for mod coders as well, so I reject that argument as being entirely misguided and without any substance behind it. A small update should be far less likely to need significant changes to mod code. Also, as others have said, there's simply no viable alternative to putting out minor patches after a major update. No matter what any of the various posts claim, it's quite literally impossible for Squad to find all of the bugs in a major release due to the sandbox nature of the game. It's impossible for them to test every valid usage prior to release as the construction mechanics and wide variety of uses creates an effectively infinitely large set of situations to test. So, a flow of around 2–4 minor updates in the weeks following a major release are always going to be necessary to address issues that are impossible to address prior to release and only found once the majority of the user base starts bashing on the release and breaking stuff. Sure, there have been some things which should really have been caught in QA prior to release, but equally many important things which could not reasonably have been caught at that stage. No matter how much they improve QA, these minor updates and hot fixes are a necessary part of KSP. Squad, please keep going with updates as often as you feel they are needed. In my opinion, you should ignore every single demand for less updates or less frequent updates. You know the pros and cons of updates without needing to be told them, and I trust your judgement.

That sums it up very nicely, and I agree entirely. OP, I completely and utterly disagree with your demand that Squad stop breaking your ships. I understand where you are coming from, but your request is completely unreasonable. Squad, please keep breaking stuff, as long as the long term result is improvement. I eagerly await you breaking everything in 1.1, when we get a completely new physics engine as part of Unity 5. I will be very happy when you break it a bit more in 1.1.1 and 1.1.2, to fix the inevitable issues that ship with 1.1. I will continue to be happy when you break it a bit more in 1.2, to put the polish on the major upgrade delivered in 1.1 beyond the fixes delivered in 1.1.x. N.B. To the folks complaining about existing ships breaking: No pain, no gain, get over it! Also, once the dust settles on Unity 5.0, then 5.1, the per-release breakage for "old" stuff will very likely get progressively smaller, as the behaviour zeroes in on "perfect". Frankly, the breakage between 1.0 and 1.0.4 hasn't even been that bad, it's really just entirely expected and reasonable fine tuning. Sure, stuff changes, but it's really not at all difficult to adapt existing >= 1.0 craft designs to the changes we have seen.

It sounds like you're still not quite getting it. There is no end to the game, there is not really any such thing as 100% completion. The game will offer you more contracts from now until the end of time. Failing something makes no difference to that, as it is a single failure out of a literally infinite series (not infinite variety, it will repeat, just infinite as in never ending). It's just near impossible, by design, to reach 100% reputation, as it has a diminishing returns mechanic which is designed to make it near impossible (but it can, I believe, eventually reached).

From my point of view, they are not fixing them because the pods are neither broken nor unbalanced. You might not like it, but there's actually no requirement for the pods to be setup the way you would prefer, and zero downside from them remaining as-is from now until the end of time. They work just fine right now, and it's entirely irrelevant if one pod weighs 2 elephants per passenger and the other weighs 3 whales per passenger. All that matters is if they can be used when stuck on top of a same diameter fuel tank and engine. In the case of every single pod, lander can, etc, they are all just fine by that simple measure; the 1.25m pod/can works just fine on a 1.25m stack, and the 2.5m pod/can works just fine on a 2.5m stack. There are vastly more useful and important things for Squad to work on. Personally, I think it's quite correct for the 2.5m pods to be heavier, as the weight is much more related to volume and not radius. I.e. it would be very wrong for the 2.5m pod/can to be twice the weight of the 1.25m pod/can; it should be a minimum of 4x the weight (yes, 4x would be for area, not volume, but it's a reasonable approximation of the absolute minimum likely weight for a doubled radius hollow cone).