steve_v

I'd say much the same, but I'd replace "check it out" with "actually fix the known issues". The crashing was raised during pre-release, either the "fixes" were not tested properly, or for some unfathomable reason it wasn't considered worth the effort to fix before release. And there it is. Why, after 2 rapid-fire patches, does this thing still crash to desktop? Sure fiddling with wheels was important (note they are still lousy), maybe even important enough to warrant a couple of patches. Was it more important than game-engine crashes... I think not. That this instability has persisted through two patches already does not inspire confidence in a timely resolution. What I would like right now is some assurance that 1.1.3 will actually fix the crashing. Regardless of when said patch is released, CTDs should be priority one. Or one could just mess around with the wheels some more I guess, it's probably easier.

My gripe has very little to do with 1.1.2, rather that 1.1.whatever was released at all with outstanding critical bugs. Minor post-release patches to deal with minor bugs, cool. Post-release patches that still don't fix (IMO) release-blocking critical issues, not cool at all. If 1.1.1 / 1.1.2 had actually fixed the crashing, I would be playing rather than complaining. Whether that was 3 weeks ago or yesterday is beside the point.

Crashing to desktop is a critical issue. Critical issues warrant single-issue patches. Again, 1.0.5 == zero crashes, ever. 1.1 may well be a 200% performance improvement, but on GNU/Linux it's also an ∞% stability decrease. Stability > performance > features.

I'm just keeping my pitchfork nice and sharp for when <consults crystal ball> 1.1.3 doesn't fix the (probably Unity related) crashing... I would love to be proven wrong about this, but I'm not optimistic. Pretty sure game engine instability is going to fall into category 3 and/or 4... Because it isn't fixed yet? Or perhaps because the hyped performance improvements are, as far as I am concerned, irrelevant in light of the instability? Seriously, the game won't even start on some AMD graphics hardware.

Pre-release was for testing (supposedly), to find bugs (which it did), so they could be fixed (which they weren't). I was keen to get the prerelease only for this purpose, as I expected bugs - particularly in the Linux build. IMO it should still be in pre-release and everyone, not just steam users, should still be testing it. Release is for playing, which I won't be, due to bugs not fixed during pre-release.

Yeah, that. I don't use Windows at all if I can help it, and TBH the post 7 UI changes infuriate me after about 30 seconds... but it's the obnoxious upgrade nags that are properly disturbing. I've been around MS products long enough to recognise the odour of rodent, and I certainly smell a rat here. IMO MS has an agenda all right. Computing-as-a-service here we come. --- I blocked all known Microsoft addresses at my firewall some time ago... so I wouldn't know. But I wouldn't be surprised either.

Unless you are running GNU/Linux x86_64, in which case we have gone from completely stable at 8+GB RAM usage / 100+ mods (I have never seen 1.0.5 crash) to crashfest / window geometry roulette / graphical glitches etc. etc. Performance improvement perhaps, but stability has gone down the toilet. Nevertheless, no point in officially "rolling back" to 1.0.5 now... Though that's what I'll be playing until this mess is sorted out. I don't think it should have been released until random crashing fixed. And it still hasn't been.

Native crash in libmono.so... looks very like the (new for 1.1) crashes many are seeing. If you had ptrace debugging enabled I expect that stack trace would be just like the dozens I have collected. AFAICT there's something properly borked deep in Unity, probably a race / thread safety problem. Still waiting for news from those in the know / with access to the sources... You say you were seeing crashes in 1.0.5 too? I take it these were the (known Unity bug) "attempted to use memory addresses from more than 16GB" crash, and therefore not the same as what you are getting now? Say what? I see nothing in that log that points to graphics drivers... care to explain your reasoning?

The thing about error messages is, even if they mean nothing to you, they are there to convey a message... If you want help with such things (in any software) you really need to post exactly what the message says. There are several options here, the two that first spring to mind are TAC Life Support (been around forever, but no greenhouses etc. included) and USI Life Support, which is part of RoverDudes collection of awesome mods, and can be extended with off-world kolonisation and other goodies. Kerbalism is another I have been keeping an eye on, it looks pretty cool so far. There are more of course, check the thread Trigger1112 linked and/or check out SpaceDock (be aware though, it's unofficial and not all mods are hosted there). With great choice comes some confusion... but many choices are kinda the point when it comes to KSP mods.

Yup, don't make changes like this just before going on holiday. Nice to see some progress getting to the bottom of it though.

How about: They've been doing this with every release since KSP went live on steam... The thing they are not doing right now? Avoid doing this: Yes, it's now too late to fix the 1.1 release... It's not too late to stop doing this every damn release, and that is something that can be done right now.

Right now, fix the damn bugs. In general, not make grandiose promises and commit to unrealistic release schedules. This was said repeatedly around the 1.0 release too, Squad has apparently learned nothing from that experience and here we are again in torches and pitchforks land - due to yet another over-hyped under-tested "release". That post 1.0 release quality has fallen so far from pre-beta standards boggles the mind. Prior to 1.0 we had incremental releases with little new content and very few serious bugs... this continuing trend for "more features, more bugs, less testing" is somewhat concerning.

This is clearly a manifestation of a bug that was raised during prerelease - I'm too lazy right now to go find it, but it was generating sudden large forces when kerbals walk into landing gear/wheels... That one wasn't properly fixed before release (though it's way better than it was) and it's pretty obvious that the same is going to affect landing legs, as they use the same over-simplified collision detection. Combine this with the new load capacity mechanic and presto, exploding legs. In light of this, I find the "how were they to know" argument pretty ridiculous TBH. My suspicion is that it went more like: "Ok, wheels are sort of fixed, landing legs probably do this too but players don't tend to walk into landing legs as much, so we'll deal with it later... Lets get this thing released already." ---- Indeed, and here is my gripe with 1.1: It's not that it has bugs, nor that it crashes randomly... My problem with 1.1 is that it was released with full knowledge of these issues. If it's still full of nasty bugs and weird behaviour, don't call it a release.

The log will grow proportional to the length of a play session, and be overwritten when you restart the game... but 400MB is pretty huge, considering it's a text file. Sounds like something may be spamming errors into the log constantly. Take a look over it shortly after starting KSP (when it should be smaller) or install ExceptionDetector and see what crops up during play. Searching for the word "exception" and reading a few preceding lines may allow you to triage your own bugs, or at least narrow them down to a particular mod.

We had an opportunity for constructive criticism - the pre-release. The game was released anyway, the issues raised through constructive criticism remaining addressed. Therefore pitchforks.

Huh, guess this explains the effect of part-only mods on editor performance I have been seeing. Confirms my hunch as to the cause too, thanks.

IME all legs are somewhat explosive at the moment - but they shouldn't be that explodey, I have landed similar things just fine. Might be time to go through the standard debugging procedure and see if you can narrow it down to a specific mod. Worth posting mod list & logs anyway, someone may spot something.

Not entirely sure what you mean by this (is ckan in the ubuntu repos or something?), but one should never run CKAN as root / with sudo. Same goes for most applications in fact. Doing so is a security nightmare and will probably louse up config file permissions too. Well, STDOUT is just the standard output to the terminal, STDERR much the same - i.e. the text output in the terminal window from which you started CKAN. Adding --debug or --verbose should increase the detail presented here. All-in-all, this does sound like CKAN/mono can't connect to the download location, verbose terminal output should tell you why. That this (among other things) makes the GUI un-closeable without killing it from the console is on my "why I don't use CKAN" list.

Not as far as I am aware. There is a compile-time option to enable partially ("mark" phase) multithreaded GC in mono, but it's turned off by unity with the comment "causes crashes"... Which indeed it does. Not sure what Unity has done to the GC in their mono fork, this works just fine in vanilla mono.

First thing to check : does it produce any errors on STDOUT/STDERR when started from a console/xterm? Is it only the GUI that is screwey? i.e. can you update with ./ckan.exe update on the command line? What about output when starting with --verbose or --debug? I'm no expert on CKAN, as I don't really use it extensively for various usability reasons, but it's generally fairly verbose in it's terminal output when something goes wrong... if it doesn't crash outright that is. Also might be worth asking/searching around the CKAN thread - there are a couple of known gotchas IIRC (ssl certs?) and more knowledable users over there.

I'm not going to get sucked into an argument re. who is trolling here, as that in itself would be troll-feeding. This post is getting dangerously close as it is. I have a very simple test as to whether landing has become more difficult since 1.1... I take craft that have performed flawlessly since pre-beta, update them for 1.1.2 compatibility, then try to land as I have always done. Result: Wierd, unrealistic behaviour and unexpected explosions. Aside from the fact that real gear does not explode violently when overloaded (tires will, but not the whole assembly), and I now check wheel loading before takeoff, there are a whole host of problems with the new wheel physics. AFAICT all stemming from oversimplified collision detection and physics jitter. Firing my aircraft into the air when I hit the bottom of a slope is one, excessive bouncing and inexplicable yaw on landing for a couple more. That Squad had to resort to ugly band-aids like invisible struts and spent so much effort fiddling with suspension makes it pretty obvious that there are fundamental problems with wheels in U5. IME this "fixing" has not solved the problem, to the point where landings are effectively too dangerous to bother with. Takeoff is bad enough, and bizarre things are happening even while taxiing, FFS. I like building aircraft, and I am trying to get to grips with the changes to landing gear... but too many completely screwey things are happening to say "wheels are fine" - they are clearly not behaving like wheels ought to.

Interesting. TBH I can't recall my original source either, that particular tidbit has been floating around in the back of my head for a long time. It's possible I'm confusing it with another aircraft. Regardless, that wikipedia article claims turbulence from jet exhaust as the reason... assuming this is true it still has nothing to do with exploding wheels or landing. KSP doesn't model this kind of ground interaction anyway. Whatever this is supposed to be, I suspect MadOverlord means vertical velocity... which is entirely believable. I've certainly seen the fixed gear explode suddenly when touching down at <1m/s vertical velocity, in fact I've written them off as too broken for use, as they seem to explode if you look at them funny.

Pretty much what I was about to say. By the time the player gets to designing monstrosities that will confuse a dv calcultor, they are likely to have aquired a pretty good understanding of why it gets it wrong... at which point it becomes a non-issue. While a lot of KSP is about trial-and-error, doing dv calculations by-hand every time you change something is only adding gratuitous grind. Learning that you need to do this by having missions fail (possibly hours into said mission) is, IMO, artificial difficulty, and borderline wanton cruelty to newbs.

Indeed there is: It's not a great idea to point hot exhaust from low-mounted engines at the tarmac. Many runways are asphalt, and asphalt burns rather well. The The V1 through V4 prototypes all had conventional gear layouts and got off the ground just fine. The redesign was due to excessive runway damage from jet exhaust. Aside, the early prototypes pretty much had to be taildraggers - they had a conventional jumo engine (with prop) in the nose for reliability reasons. The landing gear in 1.1.x are bung, especially the small fixed gear. It was all over the bugtracker during prerelease, and the (not particularly successful IMO)"fixes" implemented in 1.1.2 are accepted to be workarounds for Unitys broken wheel implementation.

While I haven't seen that particular list before, I have encountered many like it, many times. It's pretty close to my own mental crackpot filter too. I guess I did grok your point, to some extent anyway.