cantab

Well KSP currently has four terrestrial worlds with atmospheres that can support flight (Eve, Kerbin, Duna, and Laythe). Our own solar system also has four such worlds (Venus, Earth, Mars, and Titan). So I think KSP isn't going too badly. What's missing is good propulsion for those without oxygen in their atmospheres. 1.0 sent ion gliders extinct and penalised rocket planes too. Many players, myself included, want to see an electric propeller to fill the gap. For the time being there's the KAX mod.

It's not going to go away for the forseeable future. Even with perfect multithreading you could still build a ship that would bring a 5960X to its knees.

It's a really nice approach, having all the stars close together in wide orbits around a galactic centre. Presumably by ensuring the orbital periods are similar the stars will stay close together over relevant timescales. I'll probably look into it a bit more myself and see how the travel times would compare with my own concept for a similar goal. As for how to handle different planet packs, I'm not sure cloning the stock planets is ideal, it would feel a bit odd for me. Many planet packs will stand quite well on their own, others could be grouped together, and still others might remain in the stock system. To give specifics for some planets packs I know: Outer Planets Mod and Trans-Keptunian - I would pair these together around their own star. Said system would have a scarcity of inner planets, but that itself adds some interest. New Horizons - I think this would stand rather well by itself, minus the stock planets, since it has a lot of additional planets and moons of its own. A few moons would be left parentless, they could be either promoted to planets or relocated. Alternis Kerbol Reloaded - I would leave this to rearrange the Kerbol system, since it focusses on rearranging it and doesn't add many new bodies like New Horizons does. It does overhaul some of the stock bodies, so perhaps their original stock versions could be relocated to another system such as the OPM+Trans Kep one. Asclepius - Keep it as an addition in the Kerbol system. Kerbol Plus - Could be tricky, since it has a lot of extra moons for stock planets. If it stays in the Kerbol system you'll want a custom config to combine it with Alternis when both are installed. If it's made its own system you need to decide what to do with the planetless moons. Any planet pack that includes stars - Simple enough, give the stars new positions complete with their retinues of planets. Real Solar System - Including the real Sun and planets as another star the player can visit would be cool. Something like Venus or even Earth would make a serious end-game challenge for the Kerbals. The needed solar SOI may be tricky though.

Great tutorial, this really helps understand one of the "game mechanic" aspects of the game. Does this mean that, for example, if I use a lab in Mun orbit to process results from the Mun, I can't then land that same lab on the Mun's surface and process the same results, but I can put a new lab *anywhere*, even in Mun orbit again, and process the same results?

Yeah, there's all sorts of intermediate possibilities. For example we could have poor multithreading for the mechanics but good multithreading for the thermodynamics.

It fits somewhat with how I see the Kerbals at KSC though. Yes, they're decent pilots and engineers, but they're not above making their rockets out of whatever components they get. While the game would benefit from some unity in "art style", the components aren't all coming from one manufacturer so they shouldn't look like they do.

As I suspected, it's an engine test rig. "The fifth engine, Pratt & Whitney’s new Pure Power® PW1200G series, was mounted on a specially designed stub wing. Normally, the test engine replaces one of the inner (#2 or #3) engines, but because of the smaller size of the tested engine, it could not be mounted to the under wing pylon." It's the real life version of a part test contract

Good to hear the next update will be 1.1, none of the 1.0.5 nonsense that was being bandied about. New parts are good, but redesigning the Mk1 cockpit seems wholly unnecessary. And yeah, another couple of months until the update I think.

Not only does this look cool, it can also improve roll stability, for the same reason dihedral angle does.

Something to keep in mind is that with the real Space Shuttle the Orbiter weighed about a hundred tonnes, while the entire stack was two thousand. So it was a small payload on the side of a big rocket. In KSP you often end up the other way round, making life hard.

New Lave looks good. It comes across as an art pass rather than a redesign, which is something I like. Also makes it look slightly less like it was separated at birth from Boris. Though I still plan on making them a double planet in my own install.

The Crew Cabin is nice, but updating the Mk1 cockpit seems unnecessary. It was revamped only a couple of versions ago. While the game would benefit from some common artistic elements, we don't need everything looking exactly the same, and there are other parts (and planets) much more deserving of an art pass. The situation isn't the same as with the Round-8 though. Squad proposed making the Round-8 not an LFO tank, that's what got people up in arms. The Mk1 cockpit will still be a cockpit. And there's still a void for a two-Kerbal command module. In fact, maybe the new cockpit could be made two-Kerbal, and keep the old one as well? It would look a little goofy on rockets, but hey, players can make it work. As for the mini-jet, neat enough, but for plane engines I think the game really wants two things: A 2.5m airliner engine for big subsonic stuff, and an electric propeller for Eve and Duna.

I very much doubt it's possible with stock parts. They're heavy and inefficient compared to Realism Overhaul parts.

4 GB of physical memory here. My motherboard won't hold more. And yet I still benefit from 64-bit KSP! (On Linux). That's because the 32-bit limit is on the virtual address space. Said address space has to include not only what KSP needs in system memory, but also the memory used by any system libraries it needs, and crucially the textures in the video card's memory. In normal 64-bit usage my heavily-modded KSP install has VIRT (virtual address space usage) north of 5 GB and RES (system memory usage, excluding the other bits) around 3.2. Trying to play the 32-bit version I crash after a few scene changes when VIRT tries to go above 4 GB. I also benefit from running KSP under OpenGL, which reduces memory usage. Running KSP under DirectX 9, which is the default on Windows, results in textures being duplicated spiking the RAM usage. In short, even you have 4GB of RAM you can still benefit from 64-bit KSP, and from official DirectX 11 or OpenGL support (eliminating that texture duplication issue).

Unfortunately Kethane has to be seen as end-of-life now, having received only basic compatibility patches for the last few KSP versions. It can't even be distributed as a single download. That is the consequence of restrictive "All Rights Reserved" licensing, which applies for Kethane's models and textures. The plugin and configs are under more liberal licenses, so somebody interested could work with the code if they desired.

Have you thought of changing the asteroid spawner, or is that not easy to do? It seems weird to have them popping up around Sonnah all the time.

I think they'll just have to thicken the wheels a bit for the next one. Yes it will add some weight, but it's probably still not much compared to the whole rover, and can probably be saved elsewhere by using more modern lighter science equipment. As for Curiosity, NASA just don't want to drive over any stones. Which is a bit of a problem on Mars.

What makes you think there won't be a Wii U port too? That console supports Unity as well.

To tell whether your control inputs are being registered or not check the pitch/roll/yaw indicators in the bottom left. If they move when you push the WASDQE keys then your inputs are being registered. As mentioned you might just not have effective control over your craft. Also don't forget to check your power demands. Some of the ScanSAT sensors are quite electricity-hungry.

I stand corrected.

It isn't, not buy much. A Steam Machine will cost around the same as a gaming PC that offers similar performance. Comparing a £500 Steam Machine with a £5000 "dream PC" is like comparing a Ford Ka with a BMW 7-Series.

Yeah. Expect rockets in the demo to be harder to control and more wobbly than they should be, because of the short fuel tanks and lack of engine options.

If the orbit stays circular the seasons will still be quarters of the new, longer year. If on the other hand the orbit is elliptical things get interesting. When the axial tilt dominates you get seasons that are no longer equal length because of the planet's varying speed in its orbit, and the seasons in the northern and southern hemispheres cease being mirror images. That is the case on Mars. If the orbit is elliptical enough that that dominates the seasons you get summer and winter and the same time everywhere. The planet spends most of its orbit far from the Sun and is only close for a short portion, again due to varying orbital speeds. That means if summer is normalish winter will be very long and cold, whereas if winter is normalish summer will be scorching hot but brief. Either way it's likely the ecosystems of Earth could not survive, though life in general could. And if the axial tilt and orbital eccentricity were balanced just right you could get one hemisphere having strong seasons and the other having virtually none. Now that would be an interesting world. The high latitudes in the season-free hemisphere would have ecosystems combining the cool temperature adaptations of Earth's high latitudes with the non-seasonal features we only see in our tropics.

Simple starts at the payload. An extra ton on the payload means an extra ten tons on the launcher, so take only what you need. In the demo you'll probably only be taking a 1-Kerbal pod with a parachute and maybe a couple of Mystery Goos anyway. It continues with the launcher. Simple generally means a small number of stages - three at most for getting to Kerbin orbit - and little or no use of fuel lines. Simple launchers are also typically "rocket shaped". My light launchers have tended to follow the following general design: Payload up top. Core using a T45 engine, providing most of the delta-V to reach orbit but lacking enough thrust. Small fins on the bottom of the core help stability. In the demo you'll need to use a T30 and maybe add reaction wheels. Pair of solid boosters on radial decouplers on the core, thrust limited appropriately. The launch is done at less than full throttle with all engines igniting. After the boosters drop I go to full throttle, and the core has already burned off some fuel so it has enough TWR.

It doesn't interest me directly, but a few possible benefits I can think of. Making the big assumption that Flying Tiger do a good job, and that improvements from the console version make it back into the PC version, I expect Better performance on all platforms. The PS4 and XBone don't have masses of CPU power, so the game will need to run well on what they have. Even with the possibility of a hard parts cap on console to keep lag under control there, the unshackled PC version should get a boost too. A more feature-rich and higher-quality stock game, since modding will be more limited on console. Good gamepad controls, that can be an option on PC too. With the PS4 Flying Tiger might have taken the lazy way out and over-relied on the PS4 pad's touchpad, but that's not an option on the XBone. I'm absolutely confident that both building and flight can be made excellent with a controller (though that doesn't mean Flying Tiger will make them excellent!) And frankly the keyboard and mouse are rubbish for KSP. We have to build vehicles in three dimensions using a cursor that moves in two, then fly them with controls limited to straight on or full lock. Fewer bugs, with any luck. Console players are I believe less tolerant of them.