Eric S

Not exactly. They said they didn't like the way resources as handled by their resource implementation worked. Given that their system was similar to Kethane but more complex, I think the same criticisms they had would apply to Kethane. On the other hand, they did say that if they could figure out a way to do resources that they liked, they'd do it, and that they still occasionally try to think up a resource gathering mechanic that their issues wouldn't apply to.

The bugs involved need to be fixed, and this isn't the only one I've heard of. Have you filed a bug report in the support forums on that? Not being argumentative, just making sure someone has. I'm fine with this change as long as the bugs are worked out, though I'd like to see "z" for full throttle be stock.

That may be the case. I know that in order to deal with the precision, things are done within a sliding window so that they can still maintain high precision within the window, but I don't know the details about how that's done.

As I understand it, the devs are watching Unity 5 and will probably evaluate it for use. It's not drop in compatible with Unity 4, however, so it's not a sure thing. Also, while 64 bit is a selling point of Unity 5, I wouldn't count on them having found and fixed all the 64-bit bugs in all the clients (that we care about).

It is possible to land on Duna parachute only, but I don't recommend it as you'll need the equivalent of a pre-0.24 radial parachute per ton of craft, and you'll probably need less mass total if you take a little more fuel and quite a bit less mass in parachutes assuming you don't fire up the engine until the parachutes are fully deployed (ideally, you want to do a suicide burn). As has been pointed out, you want your periapsis to be as high as possible without leaving the atmosphere again (even that may be acceptable) as doing so will maximize the amount of time the atmosphere has to slow you down. Also, (and the above advice may make this more difficult), you want to make sure that you're landing in an area where the surface elevation is low so that you have more time with your parachutes fully deployed.

Another way to look at it is this. Imagine you have a craft with an acceleration of 2 m/s, and local gravity is 1 m/s. If you thrust straight up, you lose half of your thrust to gravity, so only half of your thrust goes to increasing the energy of the craft's orbit. Now, instead of thrusting straight up, thrust 30 degrees above the horizon. Your 2 m/s of acceleration now results in 1 m/s of vertical acceleration and just over 1.7 m/s horizontal acceleration. Gravity will kill the 1 m/s of vertical acceleration, but the horizontal acceleration, which is greater than the remaining acceleration of the vertical launch, is untouched, resulting in 70% more acceleration for the same amount of fuel. Furthermore, as you increase your horizontal velocity, gravity starts having less effect on the trajectory (as a function of distance, not time), so you don't even need to maintain 1 m/s vertical acceleration in order to continue in a circle. As you might already see, as the TWR of the craft increases, this factor becomes narrower. However, then you start getting into how much energy is required to circularize, assuming you're going for an orbit and not just escape velocity, and the greater horizontal velocity of the launch profile with the more aggressive turn means that it needs less delta-v to circularize. EDIT: Ugh, corrected the percentage, 0.7 m/s is 70% of 1. Yes, it's also 35% of 2 which is what I was thinking for some stupid reason, but that's not the point. ,

Not quite. The force of the fuel entering the fuel line would be balanced by the force of the fuel exiting the fuel line, except for the brief period of time when the fuel line is either filling up or emptying. Note that the fuel lines would probably fill up before the launch clamps are released, which would dampen that portion of the force. As has been mentioned before, the reasons that asparagus staging isn't currently being used in real life boil down to two things. The first is that we don't have the highly reliable high throughput turbo fuel pumps that the kerbals do. Seriously, baring human error, those seem to be the most common reason for launch failure, and asparagus staging would place an even greater dependence on them. Second, since kerbal engines have a lower TWR and fuel tanks have a higher dry mass than their real world counterparts, the benefits of asparagus staging are greater in the kerbin universe.

For you. I'm not alone in seeing more planets as fairly pointless without something to distinguish them from one another. With the features we have now, more planets just mean additions to delta-v maps. We might get something that is somehow different, like a thick atmosphere, low gravity moon, but I don't see a lot of room for celestial bodies that are really different given the current feature set.

You can finish science in just those three locations, so you haven't exhausted the science there. Push on for the negative gravioli detector, it's great for science in orbit as well as landed. Thinks to make sure you get: Crew Reports: Not biome-specific in orbit and not huge amounts of science, but it's science and you're there anyway. EVA reports: Biome-specific at low orbit and on the surface, so that's 31 science reports just from the Mun and another 19 from Minmus. Surface samples: Huge per-biome science rewards, this alone would bring a few thousand science from the Mun, and a few more from Minmus. This is the reason to go to the Mun and Minmus, the other stuff kind of falls into "as long as I'm here." Thermometer/Goo/Science Jr: again, not biome-specific except on the surface. Seismometer: Only works on the surface, but a nice amount of science, at least. Negative Gravioli Detector: Biome-specific at both high and low orbit altitudes, on top of being biome-specific at the surface. Second only to surface samples. If there's a science part that is OP, it's this one. Atmospheric Analysis/Barometer: Mostly only useful around Kerbin, but make sure you have them attached if you drop a probe on Eve. Also useful at Duna. At 15 Mun biomes and 9 Minmus biomes, that's a lot of work, but it will max out your tech tree. Also note that you'll probably want to EVA a kerbal to extract the reports from parts. This lets you repeat experiments at different altitudes or different biomes but still return the results for full science value without needing one part per biome. Note that you're still limited to one experiment per Goo/Sci Jr. as they are disabled by taking the results. Same way you do. I prioritize solar panels, then science parts. I don't even get 2.5m engines until I've got the negative gravioli detector. I suspect that I just know the science system a bit better, including the exploitable corners. A manned mission to Duna (orbit Duna, land on Ike) takes about the same amount of delta-v as landing and returning from the Mun, so that's definitely possible. Landing on Duna doesn't take too much more. You can also do the same to Eve, though don't do a manned landing there. Unmanned missions to Dres and Jool are feasible without the atomic motor, and I suspect that Eeloo is as well, though I've never gone there in career mode without the atomic motor.

No. Whenever you do a manned landing on a celestial body other than Kerbin for the first time, pop back to the mission control building, there should be a "plant a flag" contract available that you can do without doing an extra trip.

Correct, I even thought of mentioning that, but I've never found a reason to do that rather than the apoapsis method. If you're having to shift the main craft between the circular orbit and the resonant orbit, the periapsis method might be more delta-v-efficient, especially if you're launching more than three satellites. I'm not sure as I've never tried it and never done the math, I always have enough maneuver power on the satellites that they can handle their own circularization, at which point the periapsis method is less efficient if you're placing them in orbit of the body you're launching from.

It's actually a bit better than the community hack, but still not even close to the stability of 32 bit mode in my very limited experience. I don't run into memory limit issues, so it really didn't offer any significant improvements.

The easiest way to deploy three evenly spaced satellites in a single launch depends on whether you have any propulsion on the satellites. Basically, what you want to do is put your launching craft into an orbit where the apoapsis is at the desired altitude, but the periapsis is low enough that the orbital period is 0.666 times the desired orbital period. For example, if you're going for a 6 hour orbit for your satellites, the orbit of your launching craft should have a four hour period. Then, each time you arrive at your apoapsis, you launch one of the satellites. If the satellites have enough propulsion to circularize themselves, this is quite easy. If they don't, it means circularizing the launching craft, launching the satellite, then dropping the periapsis back down to have the correct orbital period. Note that a 6 hour orbit is no longer a geosynchronous orbit. 0.24 slightly tweaked kerbin's rotational period.

At one time, the devs specifically stated that they wanted to keep radials a little weaker than the stack mounted engines because it's always easy to find room for more radial engines, and they didn't want there to be no reason to use the stack mounted engines.

They still are platform-agnostic. I'm aware of exactly one mod that embeds native code in the .dll, and other than that, it's all non-architecture-specific intermedate code, including 32-bit vs 64-bit. What you're seeing in that comment is the fact that if a mod has problems running in 64-bit mode, it's almost definitely a problem in the 64-bit windows compatibility of Unity or KSP itself and there just aren't many 32-bit specific bugs in Unity or KSP at this time. If a mod works in 64-bit mode, there's little chance that it will fail in 32-bit mode for any reason other than running out of memory. So, this particular modder has decided to test just in 64-bit mode that rather than test in 32-bit mode then do further testing in 64 bit mode or test in 64-bit mode then do seemingly-pointless additional 32-bit mode testing.

I see one thing obviously wrong, one thing probably wrong, and one that I'm not sure about. Obviously wrong: You've got two copies of ModuleManager loading. Delete the 2.1.5 version. Probably not enough to cause problems since they know about each other and one takes control, but still one easily squashed potential issue. I'm not sure why it's complaining about MMI_Kethane.dll, but it saying that that's an invalid format indicates something's probably wrong there. Finally, the one I'm not sure about, the log is reporting that you're running v 0.10.3 of Interstellar, which isn't the most recent version, so probably isn't the patched version mentioned. Edit: the patched version does in fact report itself as 0.10.3.

I think I'd rather have (instead of, or in addition to), a cumulative delta-v total on the tooltip to make it easier to say "I should have X delta-v left at this stage once I've circularized after launch." Not critical, I'm not afraid of addition, but just convenience.

The turbojet engine still has more thrust in airbreathing mode (by about 15%) and a better velocity curve (drops to 0 thrust at 2400 m/s rather than 2200 m/s). Admittedly, the reduced mass is going to take away much of the turbojet's advantage. Depends on the plane. When the RAPIER came out, I built two almost identical spaceplaines, one using a RAPIER and the other using a turbojet and two small engines. The one using the turbojet consistently got to orbit using less fuel and had more available delta-v. Admittedly, these were fairly small spaceplanes, and I suspect that the balance will change if you're doing larger spaceplanes. With this change to the RAPIERs mass, the RAPIER plane would have less mass rather than more mass, but I suspect that the turbojet-based one will still be more fuel efficient because of it's higher thrust and better velocity curve. This change will probably get me to try RAPIER engines again, especially on larger spaceplanes, but I still don't think of them as easy mode except that you don't need to find as many places to attach engines.

Agreed, and I don't think that's a bad thing. You'll still need boots on the ground to hold territory until they come up with some drone capable of dealing with room to room combat and the very broken terrain you tend to find in those kinds of situations, not to mention the ability to take prisoners, but a lot of the shock and awe of war is going automated. One other thing that I meant to mention, and has been lightly touched on already, is that in space combat, the craft that can make evasive maneuvers fast enough to cause humans to black out will have an advantage over one that can't. Then again, this is all thoroughly sci-fi. Until such time as we can create self-sustaining bases elsewhere in the solar system, surface/air launched satellite killers are really about the only space combat capacity that we would "need" since we can wait out just about anything else. About the only way around that I see would be to envision a robotic craft that goes out and deflects asteroids into a path that brings them down on your enemy. Might be tricky finding asteroids that wouldn't be planet-killers but couldn't be easily deflected/destroyed, which would force some kind of non-LEO counterstrike. I still have to think that anyone that could afford to do that could just buy the land they want, but that could change depending on more cost effective space technology.

Given that the person and basic life support isn't going to be able to do anything without electronics almost as sophisticated and definitely as rad-hard as a drone would require, I'm pretty sure you'd be wrong on that. Furthermore, the person and basic life support will adversely affect the delta-v of the craft, meaning you'd need a larger and more expensive propulsion system to match the same level of maneuverability. While swarms of cheap weapon systems may in fact be the way space war goes, manned craft won't fit that definition. Getting back to the original topic, Scott Manley did a video on space dogfighting and how Star Citizen was approaching it, and he basically said that in order for space combat to feel like atmospheric dogfighting, you'd need maneuvering engines more powerful than your main engine, though I'm pretty sure that only applies to newtonian physics powered drives. If you assume non-newtonian propulsion, anything is possible because we don't have the rules for that. If, for some assuredly stupid reason, we ever do have space combat that goes beyond surface/air-to-space satellite killers, it will probably come down to drones/RPV. The history of the battleship shows that it's easier to destroy than create, and baring technology beyond our current ability to predict, it will be easier to destroy one large craft than a number of smaller craft that sum up to the same cost. The largest craft you'd see would probably be the craft deploying the drones/RPV, and those would stay as far back as possible.

New things: Career Mode (including science, contracts, etc). NASA SLS style parts. The size of a payload for a given number of parts took a big jump when these came out. Asteroids The RAPIER engine (dual mode, can act like a turbojet or a traditional rocket engine) Tweakables (adjust the amount of fuel/oxidizer in a tank, starting position of landing legs/ladders, deployment altitude of parachutes, etc in the VAB) Biomes, though those only matter for science You can time warp in the tracking station Subassemblies available in the VAB. You drop what you want to use, and then can pick up a copy of them at any time in that save. Tons of UI polish, such as changing the planar mode of the map is no longer needed, if you focus a planet, your trajectory through that plant's SoI will automatically be drawn in that SoI rather than where it would happen in the parent SoI. Things that will not behave as you expect them to: SAS got totally redone, it's now softer, so you don't have to turn it off when you change your heading, and it will attempt to maintain the new heading, or something like it. Very nice once you get used to it, especially for aircraft. Oh, and flywheel-generated rotational power now requires electricity. The Mun is a LOT less flat. Procedural craters all over it. Oh, and a 5k altitude orbit around the Mun is no longer safe. That came as a serious shock to one of my in-progress Mun missions. :-) I would suggest reading the version history.

If I was going to model this, I'd be even meaner about it. Won't the interference cause problems if the vector of the communication points at the sun, even if the sun is behind the target? This would mean that you're more likely to want geosync satellites, as you can position two of them so that they're always visible from KSC, so if the sun is behind one of them, you can relay through the other. Using lower altitude constellations would mean accepting a communications blackout whenever there's only one satellite visible from KSC and the sun is right behind it, which would probably happen quite often. As I understand it, the most accurate way to represent this would be to reduce the range of any communications that would be coming from a vector with a retrograde that points at or near the sun, with the effect becoming less pronounced as the retrograde vector moves away from the sun, simulating the fact that the transmitting antenna's signal is getting lost in the background noise. If it's closer, it could still overpower the background noise. Which isn't to say that we need that accurate of a model for this to be an interesting mechanic. Edit: On second thought, this might not cause problems with lower altitude constellations, since those are usually based on omnidirectional antennas, which are already dealing with the solar interference.

It isn't possible to the extent that it is in KSP because in reality, overlapping air intakes aren't going to bring in twice the air as a single intake, and the more the overlap, the closer to a single intake the effectiveness would become. That said, high altitude craft do tend to have huge and/or multiple air intakes, so the concept has its parallels in the real world, as SargeRho pointed out.

Pretty much this. When you have a mod that works in 32-bit mode but not 64-bit mode, the mod is probably tripping over a Unity bug in the 64-bit target that doesn't exist in the 32 bit target. It's possible that the bug may exist in KSP itself, but having seen the kinds of bugs that Unity has been turning up that are 64-bit win specific, it tends to be my "usual suspect."

Polished planets: depends on what you mean. More planets would be content, and content isn't covered by scope completion. Better aerodynamics: not covered by scope completion as I understand it. Scope completion means that all the components used to build the game are there, not that those components are in their final form. We have an aerodynamic system, it's just a rather unrealistic one that has been called a placeholder on at least some previous occasions. Tutorials: The mechanics of the tutorials, yes, the actual tutorials fall under content. I found some of the answers in the AMA concerning, but I don't find the idea that they consider themselves nearing scope completion a bad thing. Yes, I want to see a better aerodynamic model, but from the definition of scope completion that they've been throwing around lately, it wouldn't be covered by scope completion. I'm not at all opposed to more planets as long as there's more to it than just another number on a delta-v map, but again, unless you're looking at something really unusual, it would be content, so not covered by scope completion.