DStaal

About the only place I use pure ballast is when I'm using the Kerbal Flying Saucers mod. They have a built-in ballast tanks to allow you to keep the saucers balanced despite using different sections, and basically need them unless you're flying a purely symmetrical craft. The next closest I've come is balancing vertical-landing rovers - but I almost always can use fuel or another meaningful resources to do that.

separate fWell, my construction station was declared a failure - KSP freezes whenever I try to finalize a build on it. (Worked fine for a bit, but as I got enough storage in place to actually operate as a construction station, it reached some limit. KSP completely freezes up now, requiring a force-quit. Nothing appears to be being written to the log.) So... Next plan: Modular design! First off, I checked when the transfer windows were, and noticed I had one *immediately* for Jool. There wasn't time to set up a full mission, but I did send off a probe to collect what science I can. It was fairly pretty during the transfer burn: Primary power is the engine itself, which can operate as a nuclear reactor when not thrusting. However, it doesn't have enough nuclear fuel to run for the entire trip, so there's a small RTG as well to keep the probe minimally powered. The concept for manned missions is a modular structure. First launched was a science command pod - the pod itself, a large science lab, and some life support experiments: Next up was a backbone truss - it includes some solar power, some large radiators (currently retracted) and some relay antennas, however mostly it's got a lot of docks: Plans for a lander, science experiments, a rover (if separate from the lander) and a propulsion system are currently on the drawing board. However, the next launch is likely to be a tug to making docking components easier.

Two reasons why Intel went with more cores: First off, your computer is doing a lot more than just running the program you're interacting with. Having additional cores for background processes, OS process, etc. makes sense. Secondly - from Intel's side: There's several ways to improve the performance of a CPU. You can add clockspeed, you can make each instruction (and therefore clock cycle) more powerful, or you can add cores. Each of these allows the CPU to perform more work per unit time. Making instructions more powerful at this point is only marginal effects (and several of Intel's latest attempts have backfired - SPECTRE comes to mind...). We're near physical limits for clockspeed - so adding cores is the easiest and most straightforward way to make more powerful CPUs at present. I believe current KSP (in just the last few versions) has gone multithreaded for physics - in the 'one thread per ship' method.

I’ll admit I'd be more interested in smaller-scale deformation. In the introduction video, we see the landing gear deform the surface - I'd like to see that in the game, and footprints, and rover tracks. I'd be nice if they're persistent, but I'd settle for just lasting until the next scene load. I'd be a minor thing, but it would make a major difference in feeling like you're actually interacting with the world.

Hanger can also do it - While in MKS the kit is smaller, in Hanger the hangers have to be big enough to hold the vessel, as they're fully assembled.

This is why I've rarely made it out of the Kerbin SOI - by the time I get around to it, I've got enough other things going on that my space program is running in slower-than-realtime overall (because I have to keep jumping to something else and can't run in timewarp for long), and then a new version of KSP comes out... I fully expect to build a Daedalus-powered interstellar ship in Minmus orbit, send it off, and never have it get further than Duna before I restart careers.

There are AAA-games that use Unity, and there's shovelware that uses Unity. It's a platform - and I don't even think most of KSP's performance problems are related directly to Unity, rather they're in how KSP was implemented in Unity. And experienced team of developers could quite likely get a lot more performance out of the same platform. (And I'm guessing your 2008 old PC was a high-clock, low-core system, while your 2 grand gaming PC was a multi-core and graphics monster - because of what KSP is doing, it's performance is largely CPU-driven, while most games are easier to parralize and are often GPU-limited.)

RemoteTech is basically full realism mode, from what I understand. Commnet is just enough networking to notice - you have to worry about what types of antennas you have where, but that's about it. There's also CommNet Constellation which is somewhat in the middle - it adds 'channels' to CommNet, so you can have vessels only talk to others on the same channel, but it doesn't add all the rest of RemoteTech.

I assume he's using this mod: And something about the change in the model that restock makes is making the calculated volume of the model different. Probably needs both @allista and the restock team looking at it.

This is what I think could be solvable, if they wanted to. You don't need to be super-precise - my intersecting-lines based on tick locations would be good enough. And yes, all that would happen is that the ships would be destroyed - but that's valuable as well: You can actually hit something at speed, and not just 'phase' through it. It's a minor hole in the reality of the game, but it's a hole that could be addressed. Whether they want to, or if it's important enough to spend the effort on - I'm not sure. But if they're beefing up timewarp, it's a related system that would become more noticeable and prominent, so I can see them spending some time on it. Computing intersections of lines based on two points each is a relatively well-known problem, so it wouldn't take that much.

Counterpoint: I don't see a reason to assume they couldn’t change that either. It would take a bit more processing, but it's not that difficult to put in checks which would allow even fairly small parts to reliably impact each other at even high timewarps. (A quick idea would be to plot a straight line between the center of mass of objects between time steps, and see if those lines intersect. You might only do it for objects inside the physics bubble.)

Sure - go ahead.

Honestly, from your categories and what I've seen come out of them - I think it's going to be trivial. My impression is that it won't be a full life support system (for the various reasons people have given about how that could quickly turn tedious and/or confusing) but instead be a way to manage and measure colony progression that's life-support-like.

Right. As for overall status: MKS went through a rebalance soon after we finished part 1- nothing major, but enough that we'd need to revisit everything. Given that I haven't been playing as MKS-centric recently, and the large amount of work which would be needed for the minor update, I haven't had the interest to spend the time to come back to this. There have been a couple of suggested patches, but they've been fairly major reworks - when what is needed is a minor update. That said, the patches should work at the moment I believe, even if they're slightly unbalanced.

Kerbalism is basically going to be your only option for background processing, I believe. And note that other mods may or may not be supported in conjunction with Kerbalism - since they change so many core mechanics of the game, it's basically up to them. Parts mods should be fine. CKAN still works, with varying support via mods. Note that many mods haven't bothered to update their .version files in the last couple of releases, because no changes were needed in the mods - so set CKAN to allow back to at least 1.6.

Nope. Here's a good read on it: http://www.projectrho.com/public_html/rocket/enginelist2.php#mif Basically, it's in the structure of how the drive operates - but it's just a fusion drive: High ISP, moderate to decent thrust-to-weight. The type of thing you need for realistic interstellar ships.

This is not true at all, at least if the space elevator is realistic. A realistic space elevator gets you off at geosync - at orbital velocity.

I’ve never done one intentionally. I've had a few cases where it was 'oh, the transfer launch window is *now*' at my circilization burn.

Two ways to solve that, depending on what a mass driver is to your game: If it's an alternate mode of launch - packaging falls nicely into the player's lap, as physics will get applied to the payload as it launches. If it's a method of automating resupply - then you can't launch arbitrary payloads using it, only what the system provides, so only have it allow launches of resources to designated locations. Mods for both of these approaches have been seen in KSP1 - approach 1 would give you something like Netherdine Mass Driver: Supply the parts to build the mass driver, and leave the rest to the player. Approach 2 would be something like the mass pipelines in Pathfinder: Full-featured mass driver models, but launches are entirely virtual.

Steel and titanium are not strong enough. Nanotubes are - but we don't know how to make them at macrosopic lengths. Therefore, unobtainium. Space elevator orbit is Geosync.

Space elevators are physically possible in real life - but currently require unobtanium to build on Earth, though the material strength requirements is within what is known possible. Mass drivers are current tech (at a smaller scale) - but not really useful on Earth. They would be great on the Moon however. My biggest problem with a space elevator on Kerbol in KSP is that the Mun would interfere - While KEO itself is within Mun's orbit, your counterweight would be getting very close to Mun's SOI, and I'm not sure such a device would be stable if we were using N-Body physics. There's also the materials issues above. Mass drivers for colonies make perfect sense, especially for smaller airless worlds.

There's a couple of rocks on the bottom right that are definitely jutting up and therefore have an overhang in the Duna wide-screen shot. They look fairly big - but they're also *really* close to the camera, close enough that their size is largely a result of the field-of-view, not their actual size. They're definitely scatters, and could well be small enough for a Kerbal to pick up by hand - it's just that they're *right* in front of the ground-level camera.

I agree with you Stark - what's seen is just scatters looking like overhangs. However, for discussion sake I grabbed a screenshot and circled the two most likely overhangs: I do note that there are a lot of *near* overhangs - places where the terrain looks like an overhang but actually goes vertical.

The way I would put it: I like hints at lore questions. I dislike lore answers.

I'd be a bit disappointed if you can't get it on Kerbin itself - it should be super expensive, and Kerbin wouldn't be good place to launch from (even in orbit...), but if you really want to, it should be possible. (Note: I'm not saying mine it on Kerbin - just that you can launch with full tanks.)