cantab

A cloud, maybe?

An umbrella?

It's hardly like paying for online services is alien to PC gaming. Some PC games are good about offering free online multiplayer, but on the flip side the worst excesses of "Pay to Win" gaming on PC leave consoles in the shade.

Keep in mind that although the ascent through the lower atmosphere is a small portion of the delta-V it's a disproportionately large portion of the fuel. This is magnified by the atmosphere reducing the efficiency of the engine; 1 km/s is even more costly at 280 s Isp than at 340 s. So while the gains from an air launch aren't Earth-shattering they're more than you might expect. The biggest drawback is that even with the shaved mass requirements from the air launch rockets are still heavy. So it works well for light payloads, such as are launched by Pegasus, but for anything bigger you'd need a truly huge airship.

My attitude is that sometimes you'll have to go back to your funders, profusely apologise for your inability to complete the contract, and take the penalty. The OP's example obviously isn't that bad since you managed to find a way to complete it But there are even outright impossible contracts, typically something like temperature scans from an altitude above where you can do them. Though I wonder if you can scam your funders by placing a ship worth all your money on the launchpad, cancelling the contract, then recovering that ship. You'll still take the rep hit bit you'll keep your funds.

It couldn't be down to horizontal flight at altitude being round a larger circle than on the surface of Kerbin could it? Since Kerbin's so small, at 20 km your true airspeed would be 20/600 = 3% higher than your ground speed. Although, the OP is reporting more like a 5-6% increase.

I'm in two minds. Yes PCs can offer flashier graphics, and the games are often more competitively priced. But I just seem to spend an awful lot of time faffing about with graphic settings, controller configurations, mod installations, and so on, and then worrying about framerates and whatnot. Whereas with my 3DS - the only current console I own - I can just put a game in and play.

Call me old fashioned but I prefer to truly shut down. Though sleep mode is useful if I want to nap or something.

Episode 15 saw what happens when you don't pay attention to the old adage, Proper Planning and Preparation Prevents Poor Performance. The RC Yes Mun lander and orbiter, so named because the lander is RCS powered, went up on a novel jet-powered lifter. Novel meaning poorly designed, as FAR's heavy nerfing of the jet engines meant the lifter could not deliver the required delta-V. Consequently Jebediah and Geneeny were left stuck in a 7x90 orbit around the Mun. Fortunately I had sent a few Munths of life support, and so the pair were still tasked with completing their contracted observations Episodes 16 and 17 saw us continue to ignore this adage! We designed a robotic Kethane miner, the RC Nope, that is intended to go to the Mun, mine Kethane, then travel to the RC Yes and refuel it. This time I wasn't messing around with jets, but that didn't stop me doing something wrong, and making KER report 3500 m/s of delta-V when in actuality we would only have 3000. This of course I only found out after several failed launch attempts and ending Episode 17. *facepalm* RC Nope lander in the SPH: https://flic.kr/p/r9dhKa Additionally, we made minor improvements to the Dirty Rascal 2, lowering takeoff speed somewhat. The Mk 2 version showed impressive performance, helped by its mini jet engines not being nerfed by FAR and thus running at supersonic speeds unlike their bigger cousin. Fully laden takeoffs and landings are still hairy though, with many reverted crashes. So now the program has a fully fuelled rocket sitting on the pad. We can't launch it because it doesn't have enough delta-V. We can't bring it back into the VAB - well, we could, but that would mean pouring 30 tons of hard-mined fuel down the drain. We may have to try something extraordinary: the addition of Moar Boosters to a rocket already on the pad.

It lets you fly higher. Since the air is thinner the higher your go this in turn lets you fly faster with the same amount of thrust from your engines. For a spaceplane, since jet engines are vastly vastly more fuel efficient than rocket engines this lets you get to orbit using less fuel.

The 4790K is an unusual case - it's stock speed is already considerably faster than the 4790 (non-K). So there's a good case for using the 4790K in a high-end non-overclocked system.

Flew around for a bit. Discovered that clipping a lamppost outside the Mission Control building makes the entire building explode into a pile of burning rubble. Repeatedly struggled to make orbit in a rocket that had "3500" m/s of delta-V, which should be enough in FAR. Realised after ending my stream that it doesn't have anything like that much, I messed up in the VAB somehow. *facepalm*

So far what I've done is added a udev rule to disable the "Osmium interface". This doesn't stop normal use of the keyboard working, although it does disable the volume control wheel on the keyboard.For those in a similar situation, put a file in /etc/udev/rules.d with the following general layout: # Disables the "Osmium Interface". SUBSYSTEM=="usb", ATTRS{idVendor}=="1044", ATTRS{idProduct}=="7a03", ATTR{authorized}="0" To find your vendor and product ids, or whatever else you need to identify the device, run lsusb -v. I recommend having a spare keyboard just in case you do manage to disable yours!

So let's say you've built your rover first. Decide which part on the rover is going to attach to the rocket. Switch to the reroot gizmo and click that part twice. Then make it a subassembly. Build your rocket, load up the rover subassembly, and attach it. As for where to put the rover, you have a few options: On top of the lander. Add small rockets on the rover and a little fuel so it can fly itself clear after the lander has touched down. Alternatively add a big ramp down the side of the lander. On the side of the lander. Add a balance load on the other side - maybe a second rover, maybe some static science equipment. Alternatively, make a lander with more than one engine and use thrust limiters to keep it in line. Underneath the lander. Ensure the engine thrust won't impinge on the rover, and if landing on legs ensure there's enough clearance.

I've traced this problem to my Gigabyte Aivia Osmium keyboard. Linux sees this as another joystick for some reason, dubbed the "Osmium interface". KSP then picks this up, as follows: user@treno:~/software/ksp/0.90-stock$ ./KSP.x86_64 Set current directory to /home/user/software/ksp/0.90-stock Found path: /home/user/software/ksp/0.90-stock/KSP.x86_64 Mono path[0] = '/home/user/software/ksp/0.90-stock/KSP_Data/Managed' Mono path[1] = '/home/user/software/ksp/0.90-stock/KSP_Data/Mono' Mono config path = '/home/user/software/ksp/0.90-stock/KSP_Data/Mono/etc' /dev/input/js0: driver version: 2.1.0 (20100) : Too many buttons; using buttons 0 - 19 and ignoring buttons 20 - 57 /dev/input/js0: fd 3, buttons 20, axes 3, name Osmium Interface /dev/input/js0: axis 0: raw -32767, mapped 0.000000 /dev/input/js0: axis 1: raw -32767, mapped 0.000000 /dev/input/js0: axis 2: raw -32767, mapped 0.000000 /dev/input/js1: driver version: 2.1.0 (20100) /dev/input/js1: fd 4, buttons 11, axes 8, name Microsoft X-Box 360 pad /dev/input/js1: using XBox 360 Controller mappings /dev/input/js1: axis 0: raw 0, mapped 0.000000 /dev/input/js1: axis 1: raw 0, mapped 0.000000 /dev/input/js1: axis 3: raw 0, mapped 0.000000 /dev/input/js1: axis 4: raw 0, mapped 0.000000 /dev/input/js1: axis 6: raw 0, mapped 0.000000 /dev/input/js1: axis 7: raw 0, mapped 0.000000 So now I'm looking for a workaround. Is there a way to make KSP ignore the unwanted joysticks when a system has more than one joystick plugged in?

So I don't know if this is a Linux specific issue, but I'm having a couple of gamepad-related issues. XBox 360 pad. The following affects my stock install with a new auto-created settings.cfg. 1) When I'm holding down a button, KSP seems to sometimes regard it as though I'm repeatedly tapping that button. Very noticeable for things like the lights. Meanwhile for the brakes it seems to regard it as a brief tap, making it useless. Here I'm in that unhelpful boat of "It worked fine before and I don't know what I changed". 2) I just got a mouse with extra buttons, and KSP is regarding them as duplicate joystick buttons. For example the X button and the right extra button on the mouse are treated as one and the same by KSP. A big problem considering I have that button mapped to stage. Neither of these phenomena show up in jstest, which registers button holds on the gamepad correctly and shows no effect when I press the mouse buttons.

Doesn't a 0 reading under AoA just mean it can't fly level at the speed and altitude specified? Go faster and you can fly. Also, I suggest testing at more like Mach 0.1-0.3 to study takeoff behaviour. Remember x m/s is about 2x knots and over-fast takeoff and landing speeds are hazardous. They can be lowered to an extent by proper setup of flaps.

They can be very lucrative. I think I'm looking at 25 grand for each of four line items and a further 150 for the overall completion. And I snagged a flag planting contract to do as well. My approach has just been a standard Kerballed Mun lander, with a small TACLS supply container to support the Kerbals for a couple of Munths. Wait in orbit for the sites to rotate under you. Just be sure to get into a sufficiently inclined orbit, and be aware you may need to do manoeuvres. Quickloads help if available because you may find you pass either side of the target site on successive orbits.

Yeah, I suggest ensuring that the upper and lower fuselages have no fuel transfer between them. Various parts are marked as no fuel crossfeed. Be aware that radial decouplers are not no crossfeed parts. Rather, special coding prevents fuel crossfeed if a fuel tank is attached to them. If some other part is attached to them fuel will flow. This test rig demonstrates the behaviour: https://flic.kr/p/qYvM8m (Structural fuselage, with no fuel capacity, on the right.)

So, more snags with this mod. I can't get trim working how I want it. What I want is to use the D-Pad on my controller (360 Pad) to increase and decrease trim, working as though I was holding Alt and pressing WASD/WQSE. But what I'm getting is: Try to set up to Pitch Trim - : Tapping up immediately moves pitch by the amount set in "discrete action step"rams pitch trim to full down. Holding it down has no additional effect. Try to set up to Pitch - : Absolutely no effect unless I deactivate the pitch axis from the analogue stick. And I'd still need to hold a mod button anyway, which I have to set by manually editing settings.cfg. Try to set up to Pitch (Trim) axis: No effect, as I'd expect. Setting the option to use hats as buttons has no effect.

*grumbles more unintelligibly* Not all fans are for cooling. There's fans for heating, general ventilation, and even for propulsion.

CPU fan?

I did an all massless ship a while back. Octagonal strut, a whole bunch of O-10 engines, and a few struts. I set infinite fuel on then decoupled from the launcher, and I can start and stop the engines by enabling and disabling infinite fuel. It accelerated at around 300,000 g. So not infinite. Now whether that's because there is some small residual mass, or whether it's simply a limit of the game engine, i don't know.

Regarding planes, I dislike SAS for them anyway. You can't do a proper turn with it because when you bank the plane SAS actively fights to keep going straight.

I use the bug fix mod. I generally don't need sepratrons.