cantab

I chuck a magnet at the plasma boltEric, causing ithim to destabilise and dissipatego on an insane rampage, coincidentally just above the head of the next poster.

I'm not sure it's essential. Mine has it, but I'm not sure I've ever used it. To an extent it depends how often you want to rotate the station. I'm happy to leave mine with the central fuel tank oriented north-south, and dock to ports however they're oriented, but some people might prefer to be able to orient the station so the target port for a given docking is oriented in a desired direction. To an extent it would depend on size and type of engines compared to the station. One LV-909 isn't going to make a hundred-ton thing not a space station, but a big cluster of LV-N's or a KR-2L might. Then again, there's not a huge amount of reason to put an engine permanently on a station anyway.And seeing it, I think yours qualifies as massive. And a really nice aesthetic design.

It's 1440x900. In firefox you can right-click and choose "View Image" and the dimensions will show in the window title. And in my experience reducing resolution didn't help much. It can have an impact if you're graphics-limited, but for many players KSP is physics-limited.

I don't know how I first learned about it. If I had to guess, I'd say xkcd. I'm not sure if I'd watched any videos, but I knew roughly what the game was about when I downloaded the demo, then played it a couple of weeks later. (Compared to numerous games I've paid for, that's pretty quick from acquisition to playing!) I started by doing the VAB and launch tutorials, then set about designing my own rocket to reach space (which I considered as the real-world 100 km), then orbit. I got hooked pretty quickly. Then I turned to the Wiki to try and get better, and found the single most useful page was this one: http://wiki.kerbalspaceprogram.com/wiki/Basic_maneuvers In the demo I did an SSTO rocket (badly, and couldn't get back down), an orbital rendezvous (to rescue the guy in the SSTO rocket), and a Mun orbit and return, then I decided to get the full game already a few months back (was version .23), and have been playing way too much since.

For planetary surface area, it's bigger than the USA and Canada combined. It's far larger than many games with a reputation for big maps, but in turn dwarfed by Minecraft which has a map the size of several Earths. In case anyone's interested, here's how the planets compare in surface area. Kerbol and Jool excluded, considers all area including water along with land.

Currently Kerbals don't require life support, while probe cores do require electricity to function. Therefore manned missions are simpler, and since the tech tree in career is meant to introduce players to game elements gradually, they come first. As for sandbox play, well there are no costs to either failure or over-engineering. If you consider your main goal to land Kerbals somewhere, there's no penalty in just going straight for the manned mission. The main reasons to send an unmanned mission are if it's your main goal (and not just a rehearsal for a manned mission), or if you're trying to avoid both quickloading and killing Kerbals (like I do in my current playthrough).

I'm trying to intercept an asteroid in Kerbin's SOI, but having trouble doing so without using a load of delta-V. The asteroid is coming in on about a 30 degree inclination and has a 20,000 km periapsis. This pass will then send it on to Duna (I already arranged that assist with a tug) and I want to send up a ship with more hardware for the Duna mission. The ship I'm sending is currently at my space station, in a 255 km equatorial orbit. I'd rather meet the asteroid during the Kerbin flyby so I can return the current crew and science while I'm at it. My first idea was a prograde burn opposite the ascending node to give me an intersect at the ascending node, to make the plane change as cheap as possible. Unfortunately by the time I get to apoapsis the asteroid will be well past the intersect, making this not an option. My next idea was this: A plane change in my current orbit, then a prograde burn to get an intersect at the asteroid's periapsis. This will work, but gives me some huge burns - 1500 m/s for the plane change and 600 to raise apoapsis, and that's not even counting what I'll need to match speeds with the asteroid. I have something like 5000 m/s of delta-V, so I could go this way, but I can't help feeling I should be able to do it more efficiently. Plus I'd like to keep my fuel for pushing the rock around when it gets to Duna. I've not been able to figure out a specific approach though to get said hoped-for more efficient intersect. Any ideas?

Boring realistic answer: try and figure out why the celestials are so dense.

With coarse controls, watch the RCS. That's my approach usually. Still get them mixed up sometimes.

Despite being opposite to the technical meaning, I'd say a "massive" space station is one that's large in size, preferably in two or three dimensions. (Ie a very long stick wouldn't "feel" as massive as a cube even if it had the same parts.) Mine is about a VAB long, so it's pretty extensive, but I wouldn't call it "massive". Maybe "massive" for me will always mean bigger than mine. Docked by cantab314, on Flickr The hardest thing, indeed the thing I've failed at, is controlling the part count. Using the long SRBs for beams helped, but having each module be autonomous with its own RCS propulsion really pushed the count up. Next time round I might try using a tug for module placement instead, but then I'm not sure how I'd sort RCS balance out and docking with off-balance RCS sucks.

Use [ and ] to switch between nearby vessels.

I'm written in pen. Which I stab the next person with.

A void cannot hold folks such as I. I shoot who posts post this post.

Ah right, nVidia driver then. Which Linux distro are you using? If it's Ubuntu (any variant), look for a program called "Additional Drivers" or something similar. That should let you install the proprietary nVidia driver. It's better to do it that way, which will use the package manager and repository (broadly equivalent to the "app stores" on smartphones), rather than using the download from the nVidia website.

Both Latis look pretty good to me. But for making your own parts, well that's modmaking itself. Meanwhile in my playthrough, I found that my Duna lander-rover is entangled with my space station. When I docked it part of the structure clipped into the station and once undocked I couldn't free it by application of RCS or rocket thrust. On the bright side I did demonstrate that my station can handle rough treatment, I had it spinning about like nobody's business and everything held together. Now to cheat by exploiting timewarp to free the thing. Hey, a bug got it there, a bug will get it out.

A fair point. If you're severely out of focus and not looking at a very bright object you may well see nothing, the light from faint stars getting blurred out so much it's invisible. Hence looking at the Moon since it's so bright you can't not notice it even miles out of focus. Poor collimation (alignment of the optics) will generally impair the detail visible on planets but wouldn't account for seeing nothing though.

If the game performs really badly on Linux, as in slideshow at the main menu badly, you probably don't have the proprietary graphics drivers installed. You'd have the same problems on any OS if you didn't have the proper drivers for your graphics card.

In career you get the girder at the start, so use that instead.

I couldn't reproduce that just now. Are you sure you haven't either got a mod that's doing this, or remapped the keys for RCS translation forwards and back to Shift and Control?

Gigantors, right? Record using a signal splitter on the monitor cable to a separate device, then speed it up to normal pace.

My slow internet connection causes youtube to buffer, giving me time to get away. I then come after the next person with a Cat5-o'-nine-tails.

Place them one at a time as the root part - the first part placed - in the VAB, and take screenshots. That will I believe get you consistent lighting and camera position. (For parts that can't be the root, obviously do something else first, but keep the subject part central).

000_Toolbar CrewManifest EditorExtensions Engineer Kethane ModuleManager.2.0.5.dll NASAmission NearFuture PreciseNode-0.11 Squad ThunderAerospace ToadicusTools TomSwift toolbar-settings.dat TriggerTech VOID is mine. Pretty much all usability stuff, for parts I just have Kethane and NFP, both on account of joining the Jool collab. I like both (though I think Kethane's only really useful beyond Kerbin's SOI) but I still find myself shying away from their parts a bit. For example I'm loathe to put a battery from NFP on a ship that's otherwise going to be stock.

Is this thing even going to fit in physics range when it's done!? Also, nearly 20 minutes to fly just 10 km...da-yum that's some lag. Have you ever checked the physics time ratio in your launches?

It's a tiny mass excess though, 3% at most (for making fuel with the large converter). For liquid fuel and oxidiser the mass ratios are near 1:1, so if you're mainly using kethane to produce LFO it makes little difference whether you refine on the surface or in orbit. This chimes with info second-hand from majiir (kethane dev) that he wants to disrupt optimal strategies. If you're producing significant amounts of monopropellant or xenon, on the other hand, they have conversion ratios significantly worse than 1:1 so you're better off refining them on the surface.