steve_v

Now I know I promised not to complain about the gear any more, 5.0 was sweet. But... skipped 5.1, just loaded 5.2: My previously working craft are *sliding sideways on the runway*. Landing is now an extremely dodgy proposition. Either braking traction is somehow un-even or the runway just got super slippery. Dropped the .cfg from R5.0 back in and all is well. Repro: Launch, apply brakes, watch nosewheel slide sideways Am I doing something wrong, or is the latest round of gear changes heading in the tokyo drift direction?

How about fitting some deployable airbrakes to reduce your airspeed to a safe value?

In the SPH? I take it you mean leaving a part as the default structural? I haven't seen a CTD in forever, & I'm running both... haven't tried the orbital logistics bit yet though - is this what's causing problems? What platform & build? Also, logs & concise repro steps would probably help in diagnosing this.

Actually, this is one of the main reasons I don't like *buntu. I prefer the terminal for most tasks. IMHO one of the advantages of UNIX-like systems is that you can do & automate _everything_ from a console, or a remote shell. The less I need to use the rodent, the happier I am. The lack of a decent command-line interpreter is one of my major beefs with Windows - yes I know about powershell, but this sort of thing should come pre-installed. I would say the same about command-line *NIX @cantab: You know you can mix-and-match window managers, right?

No further information = I'm calling BS on this one Been using USI with B9 just fine.

I(89%)n(75%)t(88%)j(1%) Table shaping up nicely, more samples needed.

So, I noted that the landing gear had been tweaked for the release and removed my dirty MM hacks for R4. Guess what? The gear work just fine, even on craft that previously did the wobbly wheel dance. You will hear no more landing gear complaints from this corner Top notch job. In other news: Assembled a 350T space station with 0 vertical launches, from IVA. Spaceplanes are fun.

Whut? Seriously? Kerbals are awesome the way they are. Besides, injecting a totaly different art style would seriously detract from the 'kerbal-nes' of the game. Of course if you really want it, knock yourself out. EDIT: No, I have to say it. That's literally the worst idea I've heard all week.

Given the choice, I pick KDE any day (though bash is pretty nice too . Enough knobs to set the UI up just how I like it. My pc should adapt to how I operate, not the other way around.

I'm Lifting ~45T at a time with my current cargo spaceplane (B9 HL series parts), not very efficient but easy to fly, landing speed <80m/s - my landing skills suck. The heaviest *rocket* I recall was ~100T payload, but I used FSHangarExtender to build it - This was a space station spine, so it was tallish.

Err, B9 5.0 is out DRE is currently listed as incompatible Bunch of new parts needing a .cfg... hint hint.

So install 7? Or GNU/Linux, and enjoy stable 64bit KSP? While 8 *seems* to be an okay OS, I could stand about five minutes of the new gui foolishness. It's just horrible.

I was refering to the 'cpu clock multiplier: auto' option, not the evil auto tuner FWIW the 'auto tuner' on my board just cranks up the BCLK and applies moar VCore, in a rather ham fisted fashion. "Congratulations! LEVEL UP!".... crash and burn. I tried it once and it performed exactly as anticipated. I generaly avoid adding much VCore, if any, this while watching the actual load voltages like a hawk - what you set is rarely what you get since CPU scaling, LLC and a whole raft of 'better overclocking' "features" tend to interfere. Current OC is with no additional voltage anywhere, beyond the stock turbo mode boost. Therefore nice and cool, nice and quiet. The manual (and I use the term loosely) would be a lot more relevant if it actually had anything in it. Idiots guide pictures and option descriptions like: 'Enable of feature might enhance the overclocking' seems to be about what you get Harsh, but true. Regardless of claims that the 'firmware bugs' have been fixed it's not worth the risk. There's a lot of hype over read/write speeds for SSDS, truth is that even a slow SSD is going to be considerably faster than any but the fanciest spinning disk, and for latency there's no comparison. That said, I'd probably still go for a pair of 15000RPM platters if I can get em.

I'll wait and see then, it may well be something screwey with my install.

So make aerodynamic rockets & save the lumpy bits for later? I started my current career save with FAR installed, 'tis not that bad There's plenty of science to be had in orbit around Kerbins 2 moons, IMHO you don't really need fairings until you start incorporating detatchable landers. Besides, if you go slow enough in atmo some pretty weird shapes are still flyable... just. On an urelated matter, anyone have handy tips for combating landing bouncy-bouncy? (in my case usually bouncy-bouncy-feck-feck-feck-BOOM) Ideas other than not having positive AOA on the runway?

Seeing a pretty strange issue with the current git version. Any vessel with wings on bugs out the 'stability derivatives' window: Mass: 1322.38176092505 S: 3.639336 MAC: 1.31273165166212 (Filename: /BuildAgent/work/d63dfc6385190b60/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at ferram4.FAREditorGUI.CalculateStabilityDerivs (Double u0, Double q, Double M, Double alpha, Double beta, Double phi) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: 4294967295) Numbers do not update. Released version & git as of 08/08/14 do not exhibit this behavour. Git version from 14/08/14 does. - something to do with 'weird control surface bug' fix? For some reason this only happens on ships that have been through a save-load cycle, including stock example craft. Whilst building (and so long as you don't re-load the craft) everything seems to work fine.

You got a 'K', they're a bit more flexible. The partialy unlocked 'non K' cpus don't let you touch the standard mult (the BIOS does, but it won't stick), however you can crank the turbo mult up to 43x (the cpu spec says 44x but again, doesn't stick). Ergo a multiplier OC requires turbo to be on. I too have to take the cpu clock out of auto for anything interesting to happen, but I expect this varies from one mobo to another. I have an ASUS P9X79 and the BIOS menus are convoluted to say the least. Happy with what I got out of it, *any* OC is a bonus, though sometimes I do miss the old 'desolder the clockgen crystal & replace' method. The board & CPU will do 125 ref clock, in fact the software utility reccommends it, but my current GPU freaks out at random intervals - I did put my old GTX560 back in to be sure but it's not worth the hit just for a few more CPU MHz.

Hasn't this been the case ever since the P4/Netburst debacle?

Hmm, interesting. Like I said, it's been a while since I had a Xeon to play with, times appear to have changed. I assume 'can't be overclocked' just means that they're multiplier locked? CPU clock = FSB x CPU multiplier. If I'm right, you would need a board thet can reliably muck with the front side bus frequency to get any overclocking... This is generaly not as easy or as stable as just bumping the multiplier up, since it also overclocks other parts of the motherboard. Want to know more? Google + much trial & error. Overclocking is a bit of a black art, which is why they multiplier lock the non 'enthusiast' cpus in the first place - well that and to get more $ out of those who like to tinker. Example: my i7-3820 is totaly stable at 4.6GHz, but only 'partialy unlocked' - the multiplier goes up to 43x. So the only way I can get there is to bump the FSB up from stock 100MHz. This has the side effect of upping the PCIe bus clock, which my GPU really doesn't like Therefore I can only have 4.3GHz. Still, it's a 'free' upgrade from the stock 3.8GHz turbo clock, plus it runs at 4.3 on all cores.

Disregard, It's something else.

Quick question for anyone out there with a Sandybridge-E (or any other recent intel with 'turbo boost'): Does KSP activate your turbo clocks? I never seem to get my OC'd 4.3Ghz turbo just running KSP, though it certainly benefits from it, I need to have something else chewing on a core eg. 'stress -c 1' to get it to ramp up. @Camacha: Good to see you're still hammering away at that backups nail There are 2 types of computer users: those who do backups and those who have never had a drive fail... If you've got spare dosh in your budget, get an external or a NAS. On a side note, a decent SSD is the single biggest subjective performance enhancer I have seen since the 40MHhz FSB hack for 486 boards. @Baenki, just my 2c, but getting a Xeon on a board that can't OC it seems like a bit of a shame to me. It's been a while since I had one but IME they overclock rather nicely, and KSP just loves CPU cycles.

Ahh, so that's what's going on. I was wondering why SP+ wings always snap off first. IIRC we should be seeing *more* lift at the root not less, I wonder what effect this is having on roll stability... Er... bumpity bump? Anyone familiar with FAR configs care to comment?

I recon it's just a known bug in the Reality Processing Enginetm Maybe this one No, if you hadn't guessed, I don't believe in the paranormal. If you're worried, get a pair of these, then you'll _know_ when something bad is about to happen

Not always, parts will often clip without using the debug window (usually just not how you want them to). Strut clipping for eg. is notorious for creating 'phantom torque' and other strange issues. Often you can spot the offending part by carefully inspecting for wobbling / vibrating parts on the launchpad, If stuff is too close together it will sometimes clip momnetarily as the physics loads, then try to spring back. What's happening in the video looks exactly like a clipping issue, yet I can't se anything that would clip? What happens if you use say, a round tank with 4 radial adaptors rather than the hub part?

Holding that node for 10+ minute IP burns really sucks - I mean I could do it myself, but then I can't alt-tab and play some Doom2 or drink a beer while I wait can I? In career mode you don't get the lazy aids for a while anyway. I recon the 'learn how to fly, then automate the boring bits' mechanic is working pretty well. IMHO rendezvous is pretty straight forward if you use maneuver nodes to get the transfer, do a bunch of tiny RCS corrections on the way, then set your nav to 'target' for the velocity matching. Or just watch MechJeb do it The custom info windows are incredibly usefull, I could happily play without the automation, but knowing eg. fuel time remaining while landing - that is just basic instrumentation in any lander. Sure you can just eyeball it, but Apollo didn't so why should I? RPM comes close on the instrumentation if you like flying IVA, but MJ+RPM is even better