steve_v

It's CRP that's still got the conflicts flag, but: So should be good to install with CKAN soon.

Curious. I'm running 4.5, and don't see this, I was running 4.4 (prior to 2016-05-03)... and didn't see it there either. Indeed, most peculiar. SSHing into the machine to see what's going on (or kill KSP) might be worth a look.

Officially, no. Unofficially, the few parts I nicked out of it work okay, assuming you have a working version of BDAnimationModules... which is also an official no, but unofficially can be nicked from here. Aside from that, don't pester modders for updates, it's too soon to tell if this one is dead or just sleeping. The "Dev paused" in the title might be a clue.

Nice. On that, er... logrotate?

Indeed. This was a dig at said management, not the devs per-se. Just like the 1.1 wasn't ready bit. No kidding, which, aside from it being a pointless exercise anyway, is why I haven't. Like? As I don't have the requisite level of access or source code, I can't fix this.

As someone who rather likes building atmospheric VTOLs, this is indeed irritating. It's also somewhat counter-intuitive as the slider can be moved to intermediate positions without a corresponding change in fuel quantity. But for me, as far as whining goes, bugs>stupid "features". So I'll stay quiet on this one... for now.

No kidding. However: This issue has been reported by many different people, on a range of hardware configurations and operating systems. Assuming this is all the same bug (and from the stack traces I suspect it is) I seriously doubt that a) Squad has never seen this in their test environment, and b) it's as hardware specific as you claim - do you have any data to back up that claim? Again, communication from Squad would clear this right up. ---- Having tested a "rover on eve" save posted (yours maybe?), I can say: IME, yes. Rovers are indeed a non-starter on Eve, or any high gravity body. That likely includes RSS.

Let me fix that for you: ^^knows patcher been broken for a year... still tries to use it. Spends more time investigating issue than Squad does, apparently. Is getting tired of Squad releasing obviously broken software. Good idea. I'm thinking a script that runs the patcher continuously and emails on every failure though... that would be more like 1 mail per minute. Not a solution. A workaround perhaps, but not a solution, especially not for those on slow connections. Solution: Squad fixes patcher, or removes bait from launcher. Squad starts properly testing software before making available to customers.

While I understand that elusive bugs are difficult to fix, this does not make them go away. There are enough user-reported unexplained crashes by now that "cannot reproduce" is beginning to sound rather lame. If this is a memory-management or thread-safety issue in Unity/mono, you likely won't find any reliable reproduction steps. The best bet in this case would be to write a small project to intentionally thrash these systems, then take the results to the Unity devs. If they tell you (as I suspect they will, there are a lot of "crash" related notes in the changelog) that there has been progress on this in recent releases, then you need to port to 5.3 ASAP. I'll ask again: Who is working on this, and what progress been made? Are you communicating with Unity, and what do they have to say about it? I realise this is probably not going to be an easy fix, but a little clear communication would go a long way towards calming your customers.

Of course it is. It makes technical sense, and it looks nice.

Well it's not me (yet), but I can certainly understand the motivation.

What else can I say. Oh, I know: http://forum.kerbalspaceprogram.com/: Availability: 63.20 %

Last minute "band-aid" fix for dodgy wheel physics (craft exploding on load): Wheels will be disabled if clipping other parts. The collider used for this clipping check does not match the visible wheel model, and AFAIK there's no indication in the editor that a wheel will be "blocked" Awesome "fix", no?

Well, the most obvious commonality between scene-changes / reverts and docking / undocking would be... lots of threads to spawn / despawn. If this is a thread-safety issue in Unity, I'm not surprised it's hard to reproduce.

If by "that dll" you mean ntdll.dll: Argggggh. One more time: ntdll.dll is a core part of the Windows OS. It's not causing anything. If there was something wrong with ntdll.dll, do you not think some of the millions of other windows applications out there would have revealed it by now? I'm sorry if I come across as being harsh, but wild speculation based on a line in a stack trace you don't seem to know how to read is not helping. On the other hand, confirming that KSP crashes randomly on mac too is mildly helpful. Note that there is no ntdll.dll on Mac or Linux, yet the game still crashes. The apparently random nature of this issue would explain the variation in frequency, but the fact is: It shouldn't crash at all. ---- And earlier: Are you claiming my PC is a "potato"? While no longer top-of-the-line, I can assure you it exceeds the minimum requirements by a hefty margin. I see stock crashes. Prior to 1.1 I saw zero crashes - even when running 100+ mods and using 10GB of RAM. For the record: Intel i7-3820, 16GB quad-channel DDR3, Nvidia GTX680 (x2). If that's a "potato" I assume you have a Cray on your desk, no?

While you are entirely correct.... This leads me to a rather baffling conclusion, and a question: Why, for the love of Dog, is KSP even querying network adapters when loading files from a local drive? This is pretty bizarre behaviour - network adaptors, connected or otherwise, shouldn't have anything to do with it... Unless KSP is doing something properly stupid, like using URI schemes to load local files.

AFAICT, the patcher is bung on all platforms. Try downloading a fresh copy from the store. For the record, I run GNU/Linux, and I'm not impressed with this BS either. That a professional studio (>20 million copies sold) can let such a simple task as an rsync patcher outfox them is beyond bizarre.

Gets my vote too. My problems with the "Barn" were not a comment on how many upgrade levels there should be, and I agree that more granularity here would be good. I'm not a fan of the "redneck" vibe, but more seriously, those pictures looked like a high-school project, not a professional game studio. Whoever released them in that state has no-one else to blame for the reaction they received.

a: I don't have NovaPunch installed. b: This also occurs in the stock game. c: If part mods (or any mods for that matter) can cause native memory-managemant faults, there's something horribly wrong with the CLI runtime. Isolating managed code from this kind of thing is the whole point in having such a runtime. It's not mods causing this. Mods might be exacerbating it, but if that's the case then they are simply revealing a flaw in the underlying system.

So it's perfectly reasonable to put a giant "Update" button on the official launcher that does nothing but corrupt your install? Dunno about you, but this strikes me as more than a little unprofessional. Even more unprofessional than leaving an "Update" button in the launcher when it does nothing - which is what we had for the last year. Like I said, there's nothing wrong with using rsync to update the game, it works just fine when done locally. How Squad could fumble this one really boggles the mind. Leaving it in a state where it practically begs to be used, and with no warning that it will bork your install is either incompetence or outright laziness. Squad: <places candy in front of child> "This is official Squad candy, go ahead, perfectly safe" What, exactly, do you expect to happen here? It's only us cynical old codgers (who have seen Squad screw this up before) that will approach this with the requisite level of suspicion. For everyone else, it's just "Your patcher broke the game, WTH?" I use rsync on a regular basis, not only do I use it to clone copies of KSP, I also use rsync to back up and restore complete operational servers, including terabytes of data. By comparison, patching the game should be easy. Give me access to the sync server and auth system and I will gladly fix this mess. --- Again, as far as I can tell, there's nothing wrong with the patcher. It's the sync server that's dishing up the wrong files.

http://bugs.kerbalspaceprogram.com

IME, it worked for 1.1 -> 1.1.1, but it chokes on 1.1.1 -> 1.1.2, it's not transferring all the changed files, or the source is not actually 1.1.2. Snipped from patcher.log: [INFO ]: Detecting if OS-resident rsync is present... [INFO ]: rsync present in PATH, residing at: /usr/bin/rsync ...auth stuff... [INFO ]: Opening connection to kerbalspaceprogram.com:873 with transport RSYNC... [DEBUG ]: /usr/bin/rsync -zrav --progress -p rsync://[redacted]@kerbalspaceprogram.com:873/kerbalsp.production/KSP_linux/ "/home/steve/Games/KSP_linux" ...bog-standard rsync progress output... [WARNING ]: rsync process has exited normally. <-- Why is this a warning? [INFO ]: KSP was patched successfully, click the ok button to close this application. Sure looks like rsync to me, but I could just be trippin. ---ed. Invoking rsync locally (and adding checksum comparison, it's silly not to) like: "rsync -zravc --progress -p ./1.1.2/ ./1.1.1" works just fine, so rsync is likely not the problem, rather the files at kerbalspaceprogram.com/kerbalsp.production/KSP_linux/. Based on what the local run finds, (far more that needs syncing) the issue is on Squads server.

Err, you're seriously suggesting this to an outfit that, apparently, can't figure out rsync? Good luck.

This yanked my chain too TBH. Particularly because the excuse was "we have no way of distributing daily patches" - this is total BS. Squad had a patcher, but they dumped it about a year ago and though it's now back, it still isn't working properly. IIRC the dude that wrote it left (or was fired) but don't quote me on that. My point is that this situation was entirely avoidable. As it tends to do with any commercial software project. Can't say I like it either, but what can you do? Likewise, I also suspect it's some internal marketing drive (greed, probably) setting deadlines that are driving the devs to the ragged edge and pushing for releases that clearly aren't ready. If Squad had come out and said "sorry guys, we've got unity bugs here that we can't fix in time, this is going to be late" I'd be quite satisfied. Bugs happen, but buggy releases should not. Head-in-sand "release anyway" mania just annoys everybody. This is getting a tad off-topic, but I just couldn't resist a quick stab at our lords and masters over this SNAFU.

I guess you could say that, Let's say the OS is giving mono the paycheck, and mono is spending it on running KSP. When I say "KSP" I mean squads code in KSP_Data, not the KSP.exe / KSP.x86_64 executable - that's actually the Unity player in disguise. Confusing I know. I hate this Unity/mono BS and I'd prefer to work directly on the host OS, but that makes multiplatform support much harder, and game devs like easy these days... Hence the popularity of Unity. I'm not particularly articulate explaining such things in layman's terms, and my own knowledge is somewhat limited, but here goes my take lengthy ramble on this bug: Mono abstracts memory management for the code it runs, it asks the OS for a bunch of memory, then parcels it out to managed code. If managed code running in the mono runtime, lets say KSP or a KSP mod, wants more memory than mono has already obtained from the OS then mono will ask for more. When the managed code stops using that memory, monos garbage collector comes along, notices it's not being used any more, and frees it so that mono can give it back. Side note: The garbage collector "stutter" that some people (me for one) are getting liquidy about is happening because the garbage collector temporarily pauses execution of managed code (KSP) while it does this scan for unused memory. Result: sudden lag spike every few seconds. The more unused memory there is to free the worse this gets. The error that accompanies the crashes I'm seeing is: "*** Error in `./KSP.x86_64': double free or corruption" This is followed by a stack trace, and KSP dies with "aborted" printed to the console. Those errors are coming the from the OS memory management functions (Glibc), free() is the call that mono/Unity will be making to the OS to "give back" memory it doesn't need any more. Doing this free() twice for the same bit of memory is a very, very bad idea as free()ing will wipe whatever that memory contained. If mono has already told the OS that it can have it back, then goes and nukes it again, strange and unpredictable things are bound to happen. In normal operation mono will ask for memory, put something in it, free it, ask for more (probably getting the same memory location it just freed because that's convenient for the OS), put something in it, and so on in rapid-fire fashion to meet the needs of the code it's running. If it frees some memory that has already been freed and reused elsewhere the contents of that bit of memory are now going to be either nothing or garbage, depending on the order of operations. There's no way to tell, and chaos (and random crashes) ensue. Glibc has a "memory police" function, and it will kill ("abort") anything it catches doing this. This is a good plan as crashing immediately is generally better than letting it get away with corrupting it's own memory - otherwise it's going to crash sooner or later anyway, and in a way that's really hard to debug. Figuring out exactly where mono/Unity is doing this double free(), without source code and/or help from the unity devs is not going to be easy, if it's possible at all. Compounding this is the fact that Unity is multithreaded - multiple instances(threads) of mono will be running at the same time, and if they step on each others memory things will go boom sooner or later. Note for any coders that read this and are horrified: I realise this is not entirely accurate, I'm trying (and failing) to simplify.