einsteiner

If you can truly warp anywhere you want, you can warp deep into the sun's gravity well such that your velocity points away from the sun, and use its gravity to slow down. When you have the velocity you want you warp out to LEO with just the right velocity to be in a nice, circular orbit. To find the optimal maneuver you take the final velocity you want minus the velocity you have to find the velocity you need. You warp to the proximity of the sun with sun's gravity pulling toward that dV vector. To do this fast you want to be as close to the sun as possible. If you can survive being right on the surface you will get an acceleration of 274.0 m/s^2, decreasing as you fly "up" away from the sun. Use the time spent flying up to spool up your jump drive. If you need more dV use it to jump back down to the surface of the sun and repeat until you have the velocity you need, then jump to LEO. You can adjust the amount of dV you get per jump by jumping further from the sun. Your crew won't experience any g-forces since you'll be in free-fall the whole time. You're only limited by how close you can get to the sun. This whole thing obviously violates conservation of energy and momentum, but so does the jump drive.

Not the game itself, but the forums have taught me to be even more annoyed at people who don't know your from you're.

This is pure junk. Whoever wrote this did no research into how orbits or space propulsion works.

Using a setup that looks like the OP's pictures, it takes 52.5 m/s to make the orbit equatorial. If it were in the optimal position (ie. Ap is on AN, meaning Ape=0), it would take only 48.67 m/s. So not being right on the Ap for the equatorialization burn loses you less than 4 m/s. Include a burn to reduce your periapsis to aerobrake (about 100 m/s) and you'll never miss it. This isn't the right asteroid, this one is in orbit around the sun (REF=0).

That's a neat model, where did you find that?

I think you've hit it on the head. It's like trying to use the embers from last night's camp fire to cook. They're still hot enough to be dangerous, but not hot enough for any practical purpose.

Not Kerbin, right? 3 million km is inside Moho's orbit, you're going to have to use so much delta-V just to get down there, I wouldn't worry about trying to get out of doing the plane change. You can probably play some games with Eve intercepts to lose energy and increase your inclination, then Moho intercepts if you can time it right to lower it some more, but you'll need a lot of fuel no matter what you do, methinks.

I just got done working on a plugin to snap a docked joint to the nearest multiple of 45 degrees. It's very rough, I only ever really intended it for personal use. If you like I can PM it and instructions to you.

I called it pop for all my life, then I started calling my dad "pops" and the drink had to become soda.

Count me as a "yes please, that sounds awesome" vote.

It is a compile error to assign an attribute to something it's not designed for. The error says "Attribute 'KSPField' is not valid on this declaration type. It is only valid on 'property, indexer, field' declarations." So it should work on properties. It is possible Squad declared it as applying to properties but didn't put in the code to actually fetch the value. Perhaps this belongs in the bug reports?

I second this. It would be more realistic in that you would have to include RCS for every spacecraft. Since KSP doesn't include things like gravity gradient torques and solar light pressure it wouldn't pick up stray angular momentum, so it wouldn't be too bad. This could be a nice difficulty option, since Squad is working on more customization in that area.

Small changes in Isp cause large changes in the total mass of your craft, this demonstrates this perfectly. For a recent mission the total starting mass of the craft with a LV-N was 58.5 tons. With a Poodle it would be 580 tons. That's a lot to launch into orbit before your mission can even start. So they are useful. Is it cheating? I say no if you use it with some restrictions. I don't use it as a takeoff/landing engine, to avoid irradiating planetary surfaces. I also don't use it for any burn less than 100 m/s, as I imagine starting and stopping a nuclear reactor is non-trivial.

You would probably need numerical integration to account for the non-uniform gravity during the burn. It could easily be integrated into a scheme like the one discussed here.

0.5 * 6^2 * 5.3 * (275000*0.2 + 300*500*y)/(275000+300y) * 0.008 * (275000 + 300y) = 4600000 0.5 * 6^2 * 5.3 * (275000*0.2 + 300*500*y) * 0.008 = 4600000 275000*0.2 + 300*500*y = 6027254 300*500*y=5972253.7 y = 39.82 The right side of the original equation really should include the weight of the parachutes themselves, but it only changes the answer a little (41.57 vs 39.82)

Anything in orbit that high and "loose" is going to get a lot of perturbations from the Moon too. I wouldn't bet on something staying there for long.

I vote for synthetic fuels. The technology to create them is already well developed, it's just that natural fuels aren't expensive enough yet. They also don't require any modifications to engines to be used, so they can be used in the existing vehicles. Even if they live up to K^2's promises, nuclear isomer batteries aren't going to be cheap enough for Belarus airlines for a long time (not picking on them, I just saw World War Z).

Awesome, thanks!

I am writing a plugin that allows me to list a number of altitude-pitch control points and have Mechjeb's SmartASS fly to the correct pitch interpolated between the control points. The window is handled using a Mechjeb DisplayModule. I got this working well and can change the number of control points dynamically just fine. The window resizes itself larger to accommodate more points, but does not shrink itself when the number of points is decreased (see image). This is persistent across closing and restarting KSP. Looking at the code for custom info windows in Mechjeb there doesn't seem to be anything special to make them shrink, so I'm confused why mine only grow. Any ideas?

I've been working on this for the last week to refuel my transfer stages (which I launch empty). I'm not a great spaceplane pilot, but I can get about 1.4 orange tanks worth of LFO into orbit. It has Procedural Wings and a Mechjeb module. Please forgive the unimaginative name. Craft File Edit: Version without Mechjeb module or Hullcam

Would you mind posting or messaging me the raw data your excellent plots are made from? I would like to calculate the altitude/speed flameout limit for various engine configurations.

This is not true. The Space Shuttle engines had augmented spark ignitors inside the engine. The sparks you see in videos such as are there to burn off any excess hydrogen that may be floating around. Similar ignitors were used in the Saturn 5 engines, where the second and third stages had to start in flight (twice for the third stage).

Is it really that hard to flip a coin?

When you think the game is broken because all your probes stop responding 8 minutes after launch (oh, that's what batteries are for).

If Active Texture Management can compress the textures from inside the program, so can KSP. Then have it save the textures alongside the original files. When it loads it can check to see if the compressed file is out of date or missing, and if so re-generate it. Otherwise it only has to work with the more efficient compressed texture. It's still easy for modders because they don't have to create odd formats (though I don't see why there shouldn't be a tool to let them) and efficient.