hermes47

Ok, lets try explain these OS X specific changes (given it's my fault they happened). There were two OS X based default key changes. First was default remapping of fine controls, from Caps-lock to Return (Caps lock doesn't register for some reason). The second was exposing the shift+scroll wheel to zoom in editor (it used to be hard coded to shift), and then giving LeftCommand as default for OSX. With external mice, Shift+scroll never worked to zoom in editor as OS X uses shift+scroll to horizontal scroll, and so Unity never picks it up (and just uses it as normal scroll I think). With track pads and Magic Mouse, it worked fine, because they don't have the shift to toggle horizontal scroll thingy. LeftCommand was chosen because a) I'm right handed so I like it on the left of the keyboard, b) LeftAlt is the mod key (eg alt+F12 etc), c) LeftShift only works when using trackpad/Magic mouse (maybe some others with special drivers or something) and d) Control is used for OS level zoom to cursor by default. From memory (can't check currently) normal scroll in flight zooms in/out, middle mouse pans up/down. Until the focus camera 'tweakable' was implemented, there was no stock way to move focus from centre of craft. You just had to fiddle with zoom and pan to get the view you wanted.

Are you using macOS Sierra? In Sierra, there's a new security measure called AppTranslocate or something. It basically shifts an unsigned app to a temporary folder before executing it. Currently KSP is unsigned. However, if you move or copy the KSP.app executable out of and then back into the KSP folder, it should work fine again.

The mac build is a universal binary. Meaning it's 64bit by default (assuming your mac is less than 15 years old or so)

It's module manager

That's from Module Manager

Bugs. Lots ans lots of bugs. You're all welcome.

The only people paid by Squad are those with yellow names on the forums (though some of the senior moderators may get paid too, but not to my knowledge). Most of the QA team and all of the experimental team are volunteers. In fact, it was only very recently that two of the QA team got hired as full time testers.

Kerbal EDU is effectively a paid mod. It's not produced by squad (it's produced by teacher gaming or something), squad just support them

With your first point, it already does. In your settings file, there's a VERBOSE_DEBUG_LOG option that when set to true, does show the full stack trace. That, and then click on any line that you want to look at more to expand it out.

There are two things with science stuff, eg crew report and mystery goo and the like, situation and biome. Situation is what sort of 'orbit' the vessel is in, eg landed, flying, low space, high space etc. Biome is what biome the vessel is over. Each science experiment is set to work in each situation either not at all, once, or per biome. Crew reports are set per biome while flying, but once while in space. Mystery goo and materials bay are set once per situation while flying, but per biome while landed. So what you're seeing is totally as expected.

Click and drag with the scroll wheel/middle button somewhat works for me. It's got rathe low tracking speed so doesn't zoom much per stroke.

This is because some of the parts got shifted around the tech tree see http://forum.kerbalspaceprogram.com/threads/138802-Kerbal-Space-Program-1-0-5-New-Issues-Repository

Magical QA powers. I'm not actually sure what the general public perms are like in regards to editing bugs. For that you'd have to ask Ted probably.

Dropped it down to normal for you.

Select file. File >Get Info (or command + I, or right click and get info). In the Name & Extension section, make sure Hide extension is not checked, then change the .craft.txt to .craft. Press Return. A pop-up will appear asking to keep .txt extension or use .craft. Click the use .craft. Doing it without going through the get info window just hides the extension, rather than renaming it

@inproceedings{hagberg-2008-exploring, author = {Aric A. Hagberg and Daniel A. Schult and Pieter J. Swart}, title = {Exploring network structure, dynamics, and function using {NetworkX}}, year = {2008}, month = Aug, urlpdf = {http://math.lanl.gov/~hagberg/Papers/hagberg-2008-exploring.pdf}, booktitle = {Proceedings of the 7th Python in Science Conference (SciPy2008)}, editors = {G\"{a}el Varoquaux, Travis Vaught, and Jarrod Millman}, address = {Pasadena, CA USA}, pages = {11--15} }

Probe cores a slight innate power usage requirement, even when not doing anything.

I can assure you, QA on Mac occurred. I'm one of the QA Mac team. Though I didn't spend the hundreds of hours testing I normally would (being a volunteer means real life takes precedent sometimes), overall I probably spent a hundred or so hours testing. A lot of it in 3-5 hour stretches. Not once did I get any memory leak crashes specific to OSX (any leaks were reproducible by the Windows and Linux guys, and fixed. Hope Ted doesn't tase me for saying that.) And I've never got them during 0.25 and 0.90 either. I'm not saying they don't exist, I've just never seen them. I can only report what I see. Perhaps my testing process isn't conducive to having this leak occur, perhaps it's triggered by a specific sequence of scene transitions that I've just never performed. Maybe I should hunt it down one day, on all the systems I have. But please, don't call me and the others lazy. One answer to this would be something like "Well then make the QA team bigger". My answer to that would be there's no need for it. Experimentals team, perhaps, but not QA. I don't know the relative KSP OSX player base size, but based on the 3% steam community size mentioned earlier, the QA team has a far better OSX representation. There will always be these sorts of things. Even within the the fairly narrow product range of Apple, there is a vast amount of different computer software and hardware combinations. It's impossible to cover all possible combinations. And don't suggest making the dev builds available for everyone to test. It used to be like that, when the community was much much smaller, and it just didn't work. The shockingly bad and useless bug 'reports' were so overwhelming Squad created the experimentals team. Even with warnings and disclaimers everywhere, it just wouldn't work. Trust me, things work a heck of a lot better the way they are currently. Not saying certain things can't improve; there's always room for improvement. Just that the general structure of the process is perfectly adequate.

There is a way. http://forum.kerbalspaceprogram.com/memberlist.php?s=&sort=joindate Should work.

I'm sure you do get the funds back. There's just no notification that funds have been returned. Try comparing before and after funds amounts when recovering debris.

The inability to launch is from within the VAB/SPH. i.e., when you click launch there, you can't get it to the LaunchPad

The other way is to put struts 'over' the decoupler, like from the lander to the rover. Last i checked, this cancels the decoupling force.

I thought it could. In the knowledge base… Maybe I'm imagining things.

From a 100 km orbit, the ∆v required, assuming a perfect suicide burn to 0 m ASL, is 929.79 m/s. SO something around 1 km/s is probably a 'safe' bet.

We're all over the show