FleshJeb

It's a VERY thorough tool. Last I checked, Arrowstar is a professional astrodynamicist and works for NASA.

Mining asteroids: https://bugs.kerbalspaceprogram.com/issues/25730 From what I read on the tracker, there are no permanent fixes, only ones that work temporarily. Underwater props: Not user-fixable as far as I know. I believe it's hard-coded into KSP. AutoLoc: For some reason, the localization fails intermittently on game load. It doesn't appear to be a consistent, and rebooting and/or reverifying KSP fixes it. I can verify those last two by finding the relevant threads if you want the help.

This would be true if the acceleration due to gravity were a constant, but it's not. g_h is proportional to 1/r^2, but a_c is proportional to 1/r This is why space is a counter-intuitive business. I can derive all this further if it helps.

This applies strictly to rotations, yes? One of the reasons I liked the least squares solution is that it also handles telescoping segments. What I left out of my initial post is that I also measure distances, so that provides another error to play with. Again, the error my software is able to handle is rather small (typical value is 2mm + 2ppm for an infrared laser).

For a circular orbit, the acceleration due to gravity is equal and opposite to the centripetal acceleration from your motion. You get a net zero. If you want to have fun with the concept, you can calculate the acceleration of gravity at a particular altitude: Plug in 9.80665 m/s^2 for g0, 600km for R_e and something like 80km for h g_h = 7.63 m/s^2 Centripetal acceleration is: So, the required velocity to stay in orbit is: v = sqrt(a_c * r) Substitute g_h for a_c, and (R_e + h) for r. In this case r must be in meters and not kilometers. v = sqrt[g_h * (R_e + h)] v = 2278.5 m/s for a circular orbit at 80km above Kerbin. You can verify this against the orbital velocity on the navball. If you like, you can use the cheat menu to put your craft into various perfectly circular orbits and see if it lines up with the calculations.

I did some investigation into writing a least-squares solver for IK. As a surveyor, I realized that it's functionally the same as minimizing the error in a survey traverse with fixed starting and ending points. So, I modeled a robotic arm in my domain-specific software (STAR*NET). As it turns out, the software refuses to solve anything when you set the error range to +/- 90 deg instead of a few arcseconds. So, no proof of concept there. Not having any further expertise, I gave up. As it turns out, someone came up with the same idea a couple decades before I did. IIRC, it was the Buss & Kim paper referenced in this paper: http://www.math.ucsd.edu/~sbuss/ResearchWeb/ikmethods/iksurvey.pdf (Introduction to Inverse Kinematics with Jacobian Transpose, Pseudoinverse and Damped Least Squares methods)

Thanks to @InterstellarKev(EDIT: And the helpful Kerb in the comments) for introducing me to this one: Original artist version here:

If you're a hotkey user, you can switch modes with 1 through 4 on the keyboard.

Yes. I'd love preset modes focused on performance. I think that would help out a lot of people. I don't want to get this excellent thread off track, but it prevents KSP from calculating the dV at all, and it costs me 5%-10% of my framerate. Separately, the stock maneuver node editor opens whenever you make a maneuver node, and it makes my computer hiccup about half as badly as destroying a building. I don't want stock features enabled that cost me performance when KER and MJ already do it better and more efficiently. FYI: i5 mobile, 2.53GHz, 4GB RAM, integrated graphics. For reference I get about double the framerate in 1.3.1 as I do in more recent versions.

I expected horrifying bugs with this release, but this is beyond my wildest, most pessimistic expectations.

DELTAV_CALCULATIONS_ENABLED = False And any other poorly-implemented, performance-hogging "features" that can be crippled for those of us with low-end machines. The stock maneuver node editor / orbital info gags my machine as well, but I don't know if there's a way to turn it off.

First, I'd fix the bug that doesn't reduce asteroid mass when it's mined. It's only been 12 months since it was identified. https://bugs.kerbalspaceprogram.com/issues/25730 [Snip]

\GameData\Squad\Parts\Misc\PotatoRoid\part.cfg crashTolerance = 160

How did you hold Snark down to 1000 words?

Yes. It's not an overly precise method, but it works. It's just a coincidence of physics, BTW--I don't know any other planet/moon combo this works for. Also, quoting or pinging people is how you get them to notice you responded: To quote, you can use the button at the bottom, or highlight selected text and a "Quote Selection" menu will pop up. To ping, you type "@" followed by the username. It has some autofill capability. @MetricKerbalist Feel free to use my name or text here if you want to experiment with the features.

It's much easier to set the Mün as a target. It's not necessary, but it's super-handy. The other easy method is to just burn prograde as the Mün is coming up over Kerbin's horizon (from around 80km). No maneuver nodes needed.

@wrappy Fine-tuning with Radial In/Out can help with timing issues. Due to physics (this is my short answer), orbits are less sensitive to those inputs, so you can get more precision out of them. As a bonus, the extra dV cost is negligible (blame Pythagoras).

Open /GameData/BDArmory/Parts/sidewinder/sidewinder.cfg in your favorite text editor (such as Notepad). Try commenting out these lines by putting two forward slashes "//" in front of them. exhaustPrefabPath = BDArmory/Models/exhaust/smallExhaust boostExhaustPrefabPath = BDArmory/Models/exhaust/mediumExhaust boostExhaustTransformName = boostTransform Restart KSP. This will probably cause some errors, but I expect the missile will still work as normal. Good practice would be to make a copy of the file first, and store it outside your KSP directory.

https://wiki.kerbalspaceprogram.com/wiki/Asparagus_staging

Thoats and Zitidars

Patreon, PayPal, and Kofi exist, and many of our favorite modders and content creators have payment methods. I've already paid LGG more than twice what I paid for KSP and the DLCs, since he makes an otherwise unplayable game, playable. However, the list of people that donate is rather small, and perhaps formalizing it could increase their revenue streams. This may also benefit the console players, who otherwise have no way to mod their games. There are several logistical, legal, and other pitfalls involved, but that's above my pay grade. It's not a terrible suggestion, but I don't think it will happen for KSP 1.

There are a number of good answers to this, depending on the exact numbers involved, your skill level, and your patience: High delta-V maneuvers are practically begging for a gravity assist (or multiple), so you may wish to plan a flyby of Eve on the way down. If the solar orbit is sufficiently low, a https://en.wikipedia.org/wiki/Bi-elliptic_transfer may be cheaper. This would indicate transferring out to Jool and doing a powered flyby to lower your solar periapsis. This is probably your cheapest, single-grav-assist transfer. Periapsis-kicking will let you split the burn into multiple sections: https://forum.kerbalspaceprogram.com/index.php?/topic/174895-periapsis-kicking/, mod to split burns: https://forum.kerbalspaceprogram.com/index.php?/topic/194881-18x-19x-110x-maneuver-node-splitter/ A rule of thumb developed by Red Iron Crown (IIRC) was to not do burns of more than 60 deg of your orbit. So, for 4 hours, you'd want to be in a 24-hour orbit. Hopefully I did the math right, but that would be a circular orbit of 8140km (altimeter-indicated--8740 km semi-major axis). https://en.wikipedia.org/wiki/Orbital_period, mu found here: https://wiki.kerbalspaceprogram.com/wiki/Kerbin

And we have excellent taste in avatars.

Slightly off-topic, but I'm deeply amused: https://twitter.com/torybrunosteeth

Mün is pronounced "myoon", not "muhn". Every time somebody says "muhn," a kitten dies.