cantab

I try not to damage the KSC buildings. That's about it

Thanks. I reinstalled FAR and I've had it working as expected now. Might have been a wrong setting. Might instead have been a controller deadzone issue, I noticed that they were too small just now.

There is a "clickthrough" bug in the Tracking Station, that means that when you click the X button it can actually select a different craft in the list and delete that one instead.

I've had that issue. After the first stage is dropped the rocket is much shorter but the same width, and it's often rear-heavy, which makes for an aerodynamically unstable craft. There's also sometimes a coast period when you have no good control. There are a few possible solutions: Decouple the lower stage and light the second stage engine at once, immediately gaining the control from its gimbal. Make the second stage smaller and the first stage bigger, so the second stage flies in higher atmosphere and doesn't flip. Take a steeper ascent profile, giving the same effect. Put fins on the second stage to keep it stable, but watch it doesn't make things unstable on the first stage. Spam reaction wheels on the second stage.

When you load it into the SPH, and the front is so far away it's beyond the render range of the scene. (I did this, it takes a ship several kilometres long, but is possible in stock KSP.)

Did the wing leveller function change recently(ish) or am I just using it wrong? It now seems very bad at levelling the wings. Reposting this. To expand, some versions ago (back in 0.90 and old FAR certainly, not sure about 1.0) I could click the roll button in the FAR GUI and it would hold my wings level just fine, on the default settings with no further work needed. Now the roll button seems to have virtually no effect, the plane will bank left or right and no control input is given. So what am I doing wrong?

A thousand and one posts? You know what this calls for? Puppies.

Rovers are good for moving relatively short distances with high precision. There are contracts clearly aimed at rovers, asking you to take a bunch of experimental readings all on the ground at sites close together. Refuelling trucks for ISRU setups, and indeed ground base work in general, are also jobs for rovers. And there's always running around the KSC buildings scrounging science. They are slow for moving long distances, which makes them generally not very good for hitting multiple biomes on a body because biomes are large, unless you just want to do a long drive for the heck of it.

What KSP wants is a processor with great single-thread performance, which means a recent "proper" Intel processor, not one of their ultra-mobile ones, at a good clock speed. Core count doesn't really matter. It also needs competent graphics, but nothing mega-powerful there. With laptops it's a case of pick two: fast, light, cheap. And even fast light and expensive will never match the performance of fatter laptops or desktops. In the case of the Surface Pro 4 the Core i5 model should do pretty well. It turbos to an OK clock for a laptop and two cores is plenty enough for KSP. (Yes, two cores in a laptop "i5", not four like in a desktop Core i5 - gotta love Intel marketing). Graphically it's competent, I've played KSP on worse graphics. The Core i7 model is a little better on the CPU side (still only two cores though!), and also significantly stronger graphically which is a factor for games other than KSP. The "Core m" model on the other hand is best avoided - that's using one of the ultramobile processors I mentioned, and they're nowhere near as good performance-wise.

The standard KSP settings lets you bind joystick axes to flight control axes. I use a 360 pad and have the left stick as pitch and roll and the triggers as yaw. All fully analogue, makes for very smooth flying. The only thing that's awkward is trim, I needed an external tool to get it set.

KSP now puts a hard(ish) cap on the altitude a jet engine can run at, and I think for the Juno and Wheesley it's pretty low. It's not like the old days when you could get up high with loads of air intakes. A spaceplane with them should still be *possible*, but you're going to need a lot of rocket delta-V.

Took my in-development spaceplane to the edge of space (specifically, about 35 km and 1200 m/s, way short of orbit) then successfully ditched it in the ocean. screenshot290 by cantab314, on Flickr I'm pretty happy with the airframe, but clearly need considerably more fuel. I may also add two more thrust engines, I feel that with my low TWR I'm spending fuel just maintaining my speed and taking too long to accelerate.

Well I thought of what's now called the turboramjet as an SR-71 like engine. So the altitude ceiling is more like 20 km* and the max speed Mach 3.3 or about 1100 m/s. That's actually not far off what the game has. The real SABRE is hoped to be airbreathing up to Mach 5 or so; I think if anything the RAPIER is a bit weaker but game balance is a reasonable factor. * I'm factoring in that Kerbin's atmosphere has a smaller scale height than Earth's, though not by much.

There are various ways to build a UPS, with different cost, efficiency, and quality of supply. https://en.wikipedia.org/wiki/Uninterruptible_power_supply#Technologies

Working on my spaceplane recently, I felt at times it was a bit underpowered, but then realised that two jets on a 50+ ton plane maintained a climb rate of 100 m/s or so much of the time. That's fighter-jet performance from a transport aircraft, albeit test flying without a payload. So the jets are fine compared to real life, it's just KSP's a game and we're liable to be impatient and expect excessive performance. Also, caveat, I'm using FAR. Newstock aero IIRC is draggier than is realistic. That makes some aspects of flying easier, but it means you need more powerful engines to counter the drag which then means you can climb more steeply.

In real life we use spherical polar co-ordinates. One distance from Earth, two angles to give the direction. That could work well for an interstellar civilization I think. At least in the relatively early days the homeworld is likely to be important, and distance from it a noteworthy figure. An alternative I'm partial to galactic cylindrical coordinates. One distance which is how far you go in the plane of the galactic disk, an angle for the direction that distance is in (with 0 degrees being towards the galactic core), and a second distance which is how far you go at right-angles to the galactic disk. This system has a couple of benefits - it's more immediately obvious whether a location is in the disc or in the halo, and an easy-to-understand map can be made by just plotting the first two numbers; not precise enough for navigation but suitable for teaching and general display. Of course any polar system, spherical or cylindrical, has a couple of drawbacks. Giving the angles to a fixed precision means the position is less certain the further from the origin the point is, and calculating the distance between two coordinates is rather harder. Regardless of the details, I think an obvious choice of reference direction is the line linking the homeworld and the galactic centre, and an obvious choice of reference plane is the galactic disc or something chosen to nearly match it.

Definitely sounds dodgy, I've never seen a process named that before. Windows's own processes usually have slightly more descriptive names.

Personally I feel that if EVA fuel is to be made finite, firstly we should have EVA tethers, to prevent a simple click on that button from sending your Kerbal helplessly drifting because you forgot to check the monoprop reserves. Give the player the chance to check their actual EVA fuel before releasing the tether.

"If Xu is incorrect, you have summoned the Kraken and should file a bug report." - https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Notes-on-stability-derivatives This has happened twice recently while working on my spaceplane. I can't reproduce it well enough to meet your bug report standards though, consider this just an informal heads-up that this is happening. EDIT: KSP 1.0.5.1028 Linux 64-bit, FAR "Hoerner", Debian 8. i3-6100, 750 Ti (though if the graphics card affects FAR bugs then my reaction would be What The Heck???), 16 GB RAM.

Dear Kraken I hate this new editor. It does. This is motivated by the elevator having trouble holding the nose up at supersonic speeds, I thought the built-in AoA would emulate an all-moving tailplane as used on some supersonic aircraft and reduce induced drag. I'm not sure what good alternatives there are? The overall CoL can only go so far forward before there's trouble at subsonic speeds, and pumping fuel seems like it'll be a lot of hassle. Do some wing planforms keep the lift more consistently placed fore-aft than the delta I've currently got?

Excessive dihedral effect seems plausible. I did have the wingtips angled up a touch, removing that and slightly enlarging the tail significantly helped, but the plane still wanted to bank over once I hit about Mach 1.2 at 13 km, and I'm also getting red L-beta again at say M1.7. It seems troublesome to fix the derivatives and the dynamic simulation, sorting one breaks the other is what I seem to get, Saying to reduce the wing sweep seems odd, I thought delta wings were good for supersonic aircraft??? Reducing the sweep is something I can try though, though it's one of the fiddlier things to do with stock parts. As far as the nose goes, sure, I can change it, but is it really likely to help stability much? I just tried a 2.5m adapter and a nosecone A and that made things *worse* in the analysis. kcs123 pitch authority isn't directly a problem any more. At subsonic speeds the main wing's Col is already near-level with the CoM, both being around the middle of the payload bay. Of course the tail pulls that back, but in flight it will be making less lift than the wings. It *does* seem like pitching up affects the roll stability, and that's something I don't really understand and if it's a real effect doesn't seem to be covered by FAR's roll analysis tools.

Well I want to take off again afterwards. it's a pretty ambitious plan I'm working on I know. That said there's some room for a fixed ventral fin. I did though have issues with tailfins below the centre of mass sending the L-Beta derivative wrong and destabilising the plane in roll. (I think I understand this intuitively, by considering the lift the tailfin generates when sideslipping and how that affects the plane's roll.) But maybe it's something I can control. That would be the easy way, but it's exactly what I don't want to do. Though I suppose it's *possible* if I mount the shuttle stack below the orbiter like "normal".

Did the wing leveller function change recently(ish) or am I just using it wrong? It now seems very bad at levelling the wings.

The original estimates seem plausible. Here on Earth most water usage is in agriculture and industry, very little comes from our taps at home. And even at home you use far more for cleaning and bathing than for drinking. But water is a renewable resource. In space or on Mars you will be recycling it, so what you need is a water treatment plant that can keep up, not a giant tank. Also the industrial use as applied to a space/Mars colony will have been used to make and launch the spaceship in the first place. As far as Earth goes, it's not the whole story either. An important question is how much of that water is purified drinking water, and how much is not. In many countries the problem isn't so much not having water as not being able to purify it.

Similar setup myself, but the newer i3-6100. On the graphics side the 750 Ti will handle max stock settings easily at 1080p, though I can't speak for visual mods (I won't use them) and I would not expect good 4K performance. On the CPU side it's among the best you can get for KSP, performing about twice as well as my old Phenom II did. Of course an unlocked i5 overclocked to ~4.5 GHz will be a notch better.