Eric S

As someone that is susceptible (though not exactly mainstream epileptic), you're right that I'm going to take whatever steps I feel necessary to avoid the situation, and I don't think I'm susceptible enough to have issues from ion engines. However, until you can show at least some advantage to doing it this way, it feels like you can't be bothered to consider my situation. If you know that you don't have enough electricity to run at the user-set thrust level, you probably know how short you are and could run the engines at a percentage of that level, similar to how a single engine jet works when resource starved. I'll confess that it would take more work than the current system (probably two passes through the parts as mentioned above, one to collect resources, one to consume them, though if that's too processor intensive, remembering how much they wanted to consume last tick might work but you'd have to cover corner cases), but so would the all or nothing method. That said, I'm in favor of the proposal. Intake air has the advantage that without mods, jet engines are the only things that consume intake air, so the process would be simpler for intake air than for electricity. For the difference, you'd want some kind of priority system, either a fixed one or one that the user can alter as discussed.

The last time I saw the devs talk about reentry heat, they were talking about doing it without dedicated heatshield parts, so they're probably thinking of something less severe than even current DRE.

They can, but for artistic reasons, most space-based Hollywood projectile weapons fire projectiles that are often slower than real in-atmosphere projectiles. I think that's the point being stated. To every action, there is an equal and opposite reaction. You might be able to recover/redirect the energy in the propellant that's left over when it's done its job, but the more massive projectile itself still got pushed off at some velocity, and there will be an equal push-back on the firing platform (minus gas recoil compensation). If you want to have space-based weaponry that isn't projected energy based and doesn't disturb the orbit of the launching platform, you'll either need to fire projectiles in both directions, or stick to self-propelled projectiles (rockets).

If you're looking at strictly the amount of delta-v to go from your parking orbit to the planet, then there's a peak efficiency orbit that tends to be fairly high up. For example, for Duna, the orbit is somewhere around 9000-9100 km. This orbit gets lower as you need a higher ejection velocity. For Jool, the orbit is in the 380-390 km range. However, if you're looking for total delta-v from launch, then the lower the better for the most part, as the amount of delta-v you'll save over launching from a low (80-100km) orbit is generally less than it will take to transfer to and circularize in the higher orbit. This is basically because of the Oberth effect. The actual reason that the Oberth effect exists is because delta-v is delta-v regardless of your velocity, but the amount of kinetic energy is based on the square of your velocity, so 1 m/s of velocity means more kinetic energy the faster you go. This is important because escaping a planetary SoI is basically trading kinetic energy for potential energy, so the cheaper you come by the kinetic energy, the less delta-v is required to achieve escape. If your mind doesn't wrap around that description easily, there's another way to think of it. The faster you leave a planet's SoI, the less time the gravity of that SoI has to slow you down, allowing you to keep more of your base velocity. So, if you find the exact velocity it takes to escape an SoI from a low orbit, then add 1 m/s on top of that, you'll escape the SoI with more than 1 m/s left over. The lower in the gravity well you start, the stronger this effect, so the higher the magnification. This is also one of the resons why if you want to change your apoapsis, it's most efficient to do so from your periapsis.

At one time (0.18 and 0.19), the structural pylon did exactly that. I don't know when it stopped doing that, but after it stopped doing that, one of the devs posted a part config for something that would still do the same thing. And yes, I'd like that part too. It's nice for attaching larger probes to craft without throwing the CoM of the probe off.

Yeah, I was just catching up on his stuff, cringing at least every 5 minutes :-) It's still worth watching, at least. Yup, sad, he was the first youtuber I ever saw do KSP and what brought KSP to my attention (and boy did I ever kick myself for not finding it sooner), but he managed to youtube ONE trip to the Mun during 0.21 (to be honest, it was three launches, due to all the refueling). On topic, I'll watch some of Xacktar's videos before voting.

The cone of the interplanetary range dishes is so tight you can't target the planet and expect to have satellites in orbit of that planet within the cone while still in that planet's SoI, if I remember correctly. So you'll need to target satellites specifically until you get a ways away from Kerbin.

He understands that. He's not talking about starting the gravity turn at 50km, he's talking about finishing it there. Personally, I tend to aim at a 0 degree pitch even lower than that. Just a breakdown of communication.

I'll probably do one fresh mostly-stock career mode, then do another one with FAR, DR, TAC life support, and maybe even RT2 once I finish the stock one and the various mods get updated. I'll probably do it in 64 bit mode if it's stable enough, but I won't be going crazy with mods until I finish at least the stock career.

Science and the tech tree, if I remember correctly.

I certainly hope so, and I wouldn't be surprised if that is the case, but I also wouldn't be surprised if KSP manages to find a loophole causing its physics calculations to necessarily be done sequentially. Without having played with PhysX, I'm not sure if a single soft-body physics "cluster" of subparts can be computed in parallel, or they're just expecting any physics-heavy game to consist of multiple clusters. In other words, I'm not getting my hopes up on it until I see it in action :-)

The people that have been playing the user-hacked 64 bit version haven't widely noticed a difference, so I wouldn't expect to notice a difference. 64-bit is more about being able to load more (or bigger) mods rather than performance. KSP's performance bottleneck is mostly the physics engine, which is single threaded. It's possible that an update to Unity 5 may help this, but Unity 5 hasn't been released yet, just announced, the devs have not committed to switching over to it, and it's possible that the updated version of PhysX in Unity 5 will still be restricted to single threaded operations in the KSP environment.

NP, was trying to figure out if I was missing something. Wouldn't be the first time I didn't get what someone meant :-)

Yes, that would be the approximate timeframe. Having spent as much time in software development as I have, any time I hear a dev talk about something that hasn't been released, I hear "It is our intention that..." at the start of whatever they're saying, so I never take anything said about future plans as a hard fact. That would depend on how you define valuable. In a purely number-of-facts-learned-about-our-solar-system measurement, you're right. On the number of scientific papers done to date, the Apollo project and the science it brought back is still the basis for more papers than the rest of space exploration combined, from what I've heard. Not that I'm strongly disagreeing with you, either. I think that any truly productive space exploration needs to have both manned and unmanned elements, and I think that the unmanned element gets the fuzzy end of the lollipop in KSP, especially rovers. For that matter, I can't remember the last time I sent off a mission in a stock career mode that had more than one kerbal, and I'm not sure how to fix that. Maybe increase the reputation reward for multi-member crew results? Without knowing how reputation will work, that's just a shot in the dark. In some cases, true, but not in all cases. The Apollo missions were planned out and using the patched conics method which has no concept of a mass that isn't a point mass. Which also isn't the point, really, just an interesting bit of trivia. I hope that the devs do implement some form of life support, as that will give unmanned missions a bit of a boost, and maybe a stock part that can take surface samples (or two even, one that includes some analysis capability and can transmit the results (at a loss), and another that's only good for return missions). then again, without knowing how the experiments are set up, there may not be an easy way to set up different ways to access the same pool of science points, and robotic return missions should count against EVA sample returns, and I'm not sure the two methods should have the same transmission losses. I think I'd enjoy something somewhere between what we've got and what you're suggesting. Fuzzy pictures for any place we haven't been, less fuzzy for something that we've done a flyby with with the right equipment, and sharp pictures, maybe even with relief data, for something that we've orbited and maybe even scanned (doesn't have to be a full SCANSat type scan, even just something like BTSM's surface scan would probably be acceptable). A similar concept for gravity. Have the kerbalpedia specify a range for the surface gravity, with the range getting more accurate as you get more information. I agree with LeathalDose that we shouldn't be hiding orbital projections or inhibiting the placement of maneuver nodes based on this information, however.

Not sure what your point is. The pages have some visual similarity, but that's really about it unless I'm overlooking something. The structure of the HTML/CSS in the pages resemble each other about as much as any two randomly selected pages that visually resemble each other would, so I'm pretty sure this isn't cut and paste web design where just the graphics and text/background colors change, if that's what you're implying.

The devs have indicated that that is on their wish list, but the list of features they're targeting changes over time and they haven't discussed this in a long time, so we can't be sure that this is still on the list of things they want for 1.0.

Sadly, the only time I remember the devs discussing it was in late 0.18-early 0.19, during the time frame of the great forum oops, so not only can I not point you to them, they just don't exist anymore.

My first moon landing was in 0.18, maybe 0.18.1. I'd say it couldn't have gone better, but that would be exaggeration. It went far better than I expected, and I safely touched down, and probably had enough fuel to get home. I got out, EVAed around a bit, then got back in. I prepped for launch, made sure SAS was on, etc. And then I hit the spacebar. Talk about shock, when I realized that I had just detached the capsule from the engines that were supposed to carry it home. Surprisingly enough, my next two attempts were impacts severe enough to leave no survivors, it wasn't until the fourth attempt that I actually landed and returned.

I think it would be more correct to say that the errors are more noticeable at higher warp. I've had "perfect" periapsis messed by accidentally warping through SoIs at x10, requiring a slight correction after the transition. High warp crossings can be so effected that the craft doesn't have enough delta-v to make the correction. I think this is because at higher warp, you move farther into the new SoI in a single tick.

Exactly not. Err.. ok, the truth is somewhere in between. Maneuver nodes themselves didn't exist until the devs implemented them. Mods added ways to manipulate maneuver nodes, and then the devs added two more manipulation methods to the stock game. So in truth, there's give and take there. The devs are outnumbered by the modders by a significant amount and many, if not most of the modders don't hold themselves to the standards the devs do when it comes to stability of said features. It's no surprise that modders generally implement features first. After all, if the devs implement a feature, why would modders implement it afterwards?

I do think the best way to implement the heliosphere (and oort cloud, if they go that far) would be as additional altitudes for experiments that only stars have, with a high science multipler and possibly even new experiments that can only be done at this new altitude. Not sure how practical visiting the oort cloud would be, the far side of the oort cloud is right up against the hill sphere, and I don't know how thick the oort cloud is. If you're talking about random breakdowns, the devs have no intention of implementing that, and I've heard nothing from the devs about giving parts a lifespan. This thread tickled my curiosity, so I did a little research, and there are in fact comets that come from outside Sol's hill sphere. In fact, there's one passing close enough to Mars later this year that it's remotely possible (1 in 600 chance was the last update I found) that it will impact Mars. There's also a few classifications of comets, depending on how long their orbit is and sometimes on other characteristics. The ones that can repeat at less than 200 year intervals are short period comets believed to come from the Kupier Belt and don't make it back out above the heliosphere, whereas the long period comets are believed to come from the Oort Cloud and have much higher periapse. Short period comets further get broken down into Jupiter class comets (an orbital period under 20 years) and Haley class comets, with orbital periods between 20 and 200 years. There's also a class of comet called main belt comets that mostly stay within the asteroid belt, though more modern theory argues that these are actually asteroids with a dust trail rather than an actual outgassing comet. Exocomets are comets that came from outside Sol's hill sphere and are probably going back there. The Haley comet itself seems to be the only short period comet that's visible to the naked eye, and it's also one of the few celestial objects in a retrograde orbit. Short period comets tend to be close to the ecliptic plane, whereas long period comets can come from any direction (given that, I suspect that the bulk of celestial objects in a retrograde orbit are long period comets).

I think you may be confused on just what an SoI is. It's not some demarcation line between what's in the solar system and what is interstellar space. It's a matter of being the dominant gravitational force within the sun's own SoI. This means that in order to leave the SoI of Kerbin's sun (the name Kerbol is one the players gave it, the devs just refer to it as "the sun"), there would have to be a gravitational force stronger than that of the sun at that point, meaning you'd then be in orbit of whatever mass(es) create that gravitational force. In the case of Sol, it would be the theorized super-black-hole at the center of our galaxy. If a comet were to cross the sun's SoI, it probably wouldn't be coming back within the lifetime of the kerbal race. Comets that come back (all of them that I'm aware of) are in orbit around the sun but completely within the SoI, though many (actually most, I think) of them have an apoapsis outside the heliosphere. To give you an idea of the difference, Voyager has passed outside the heliosphere (currently what NASA is using for demarkation between the solar system and interstellar space) at a distance of 120 AU. One AU is just over 8 light minutes, so 120 AU would be less than 17 light hours. Sol's hill sphere has been estimated to have a radius of about a light year, which is quite a bit more than that. While I have nothing against the devs adding comets to the game, we won't be leaving the SoI of Kerbin's sun until said sun is no longer the center of the kerbal's universe, and even then, it's going to take either a heck of a lot of time warp or some kind of warp drive to leave the SoI.

As for the parachute issue, Duna's atmosphere is kind of thin, so you'll want to make sure you land somewhere close to sea level. You may want to tweak the parachutes so that they fully open at a higher altitude (right click on the parachutes in the VAB to open their tweakable options). All good advice, but just to clarify, you want to cross SoIs at low or no time warp, so you want to do this just before the SoI switch, don't try to turn down your warp in reaction to crossing SoIs.