steve_v

Though I've never owned an Apple product, that malloc failure combined with the graphical corruption reek of hardware issues to me, specifically bad RAM. The error is coming from the kernel so it's probably not KSP, though it may be doing something to trigger it. I'd suggest running some RAM CPU and GPU stress tests, I could point you to some but I don't know what's availabe for OSX... Also, check the obvious: reseat RAM & GPU edge connectors, check for heating issues etc. I'd agree that an OS upgrade probably won't do squat. You might just be running out of memory, but that *really* shouldn't crash the OS (I assume that's what's meant by "beachball of death") more likely there's a bad memory region or a crook chip in there somewhere & KSPs excessive RAM usage is pushing into it.

Um, let me see... 40 manually installed mods and all working just fine. Not seeing any issues at all here, unless you count the new restrictions due to the facility upgrades / kerbal training mechanics. The log file will generally provide a heads up on mods that are having issues, possibly even before thing go wrong in game. Other than that, . Works for me.

As far as suggestions go, this gets my vote I've been using the "trim adjustment gadget" from the Firespitter mod pack for this & binding trim+ / trim- to joystick buttons. 'tis still not optimal though, as you only get steps of +-1 or +-10. OTOH, I remember long ago I had a joystick with physical trim wheels alongside the stick axes... why can I not find one now?

The best option if you want to run many mods with no recompiling... for now. Then it's a race: better OpenGL performance vs. stable Windows x64

How would you do it with a mod? Way I see it you've still got to grab / compress / send the output of the renderer over the network somehow if you want the power of the servers GPU. NVIDIA Shield does it in the driver, VirtualGL redirects to a pbuffer. I suppose you could do it client - server from in the game, but then you'd need a rendererer on the client & tablets etc have gutless GPUs. this also sounds like a lot of work.

Can one not see the target orbit in the map / tracking station view?

Not for some time, & it may have been the beta. It should work with anything OpenGL... in theory. Should work (securely) over a sufficiently fast WAN connection too, if you tunnel it with ssh I have no idea what qualifies as "sufficiently fast" though. 0.25 runs but I can't speak for performance, as I have only tried it over a very slow link, using TurboVNC 'slow mode'. Might have to try it again sometime, once I have retrieved my netbook from work. Also a keyboard. - Note: 98% sulphuric acid and laptops do not mix

I have done this with VirtualGL + TurboVNC over WIFI. Dunno about a WAN connection, but it should work if you have the bandwidth. Still prefer to play it on a real machine though.

Um, yeah. That. Please?

Yeah, I'm seeing it too, no clipping either. Just add some mass to the pod or come in a bit too steep & you'll miss the 'chute safe zone

Yeah, but I hate space junk and that's what they become once the contract's completed.

1. Pretty much, mostly ubuntu repo compatible. 2. Almost, MATE ~= GNOME 2

Looks like RealChutes is a veritable beehive at the moment, I'm seeing a bunch of other, far more serious issues. Probably a good idea to drop support, for a while at any rate.

Sure does, you can probably reduce it's quota of ablative for most re-entries too. That said, I have noticed stuff not slowing down as quickly as it used to... no big deal, but a mk.1 pod with something heavy (i.e. an engine) on the bottom and no other drag inducing parts crashes into terrain at supersonic speeds.

Seriously, I have been living with the bliss that is Adblock + NoScript for so long that I have forgotten what an aggravating experience filehosts can be I'd love to disable adblock for sites I support, but nobody appears to know how to make non-annoying ads anymore...

The closer to FAR + DRE (or something better/more closely integrated into aero) the happier I will be. IMO it's fairly 'all or nothing' if you want to fly realistic aircraft. Overheat explosions during re-entry and aerodynamic failures could well be in the difficulty settings though.

Fair enough. The issue with stock 'chutes is mainly that insta-deployment + DRE g-force damage = splat. Recon you could set your 'chute up with a sane DeploymentSpeed? ATM it's faster than stock...

Erm... stock parachutes suck pretty hard, what do you plan to replace it with?

Can anyone confirm this is working okay with the latest FAR? Im getting no flight data window and a bunch of: NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:GetComponent (System.Type) at UnityEngine.Component.GetComponent[FARWingAerodynamicModel] () [0x00000] in <filename unknown>:0 at ferram4.FARWingInteraction.WingInterference (Vector3 rayDirection, System.Collections.Generic.List`1 PartList, Single dist) [0x00000] in <filename unknown>:0 at ferram4.FARWingInteraction.UpdateWingInteraction (System.Collections.Generic.List`1 VesselPartList, Boolean isSmallSrf) [0x00000] in <filename unknown>:0 at ferram4.FARWingAerodynamicModel.UpdateThisWingInteractions () [0x00000] in <filename unknown>:0 at ferram4.FARWingAerodynamicModel.StartInitialization () [0x00000] in <filename unknown>:0 at ferram4.FARWingAerodynamicModel.Start () [0x00000] in <filename unknown>:0 when I launch any parts from this pack (Stock is OK). Seems to fly alright though...

Yeah, this. DL a fresh copy of 0.90 from the store. The multiple parts issue is probably because the updater adds new files without deleting the old... much has changed this time around. YMMV continuing an old save...

Not a bad suggestion. I've never much liked Ubuntu myself, but if you want 'simple' and 'easy' it's probably either that or Mint. The biggest impact is going to be the desktop UI rather than what's under the hood anyway. Have a play with the various Debian/Ubuntu/Mint live discs and work out which desktop environment you like best. I prefer a slightly stripped down KDE, but it's personal preference. Your RAM never "goes to waste", what's not in use by the OS or apps becomes disk cache & buffers, speeding up disk access

Unity calibrates its joystick axes on startup, so you need to set your throttle to *exactly* 50% before starting KSP

That's a question with at least 283 answers, define "full advantage"

First & foremost: Welcome aboard I haven't actually played 0.90 yet but the editor got a major overhaul, it's possibe a bug or two crept in... Can't say I've seen that issue before, but some logs might shed more light. Meanwhile, I suspect it's time I tried out the beta. I'll see if I can replicate the crash here. Edit: Runs fine for me, FWIW. Also, check out the linux thread, if you haven't already. How are you launching KSP?

Install TweakableEverything, specifically 'TweakableEVA.dll' Right-clicking your Kerbal will now show a nifty slider - I recommend 15% for general maneuvering The brake pedal analogy is terrible, automobile brakes are analogue - the harder you press the pedal the more braking force is applied. 'Tapping" the brakes is a recipie for disaster, unless you intend to lose traction...