FleshJeb

I would disagree with the usage of "pretty good"--In a plane whose wings have AoA, you're going to end up very far off course if you walk away from it for a few minutes. Wings have AoA and zero dihedral. I don't find that dihedral works very well on mid-low-winged planes with wing AoA. SAS set to Prograde. A portion of the tail has zero AoA, and is fixed (not a control surface, or a locked control surface) for passive pitch stability. This configuration will result in SAS Prograde giving the plane a slight nose down attitude relative to the velocity vector. With the above in mind, I give the zero AoA tail 5 degrees of ANhedral, which will passively correct the roll.

First off, great documentation of the problem. I noticed you have Friction Control set to Auto. It's almost always beneficial to set those manually, because otherwise they auto-adapt on the fly--When your rover starts getting sideways, it's going to want to continue, because the friction gets automatically lowered with the angle of the drift. It's supposed to prevent overtipping, but in practice it just makes driving "icy". For rovers I like to use friction 1.7 in the front and 2.3 in the back, although experimentation is very worthwhile. I do it that way so that the rover understeers a bit, and is less prone to tipping. I also turn Traction Control off completely because it impacts hill-climbing ability. For really good hill-climbing, I'll also temporarily max out the friction on all the wheels. You can also set all your reaction wheels to "SAS only". This way, the reaction wheels just attempt to hold the direction without responding to your steering and acceleration inputs. You probably know most of this already, but I like to leave breadcrumbs for anyone else with a similar problem.

If you aren't able to get a quick solution, I can temporarily share my Steam library with your students. I could probably round up a few other people who would do the same.

What's really staggering is that you're ignoring the level of food insecurity that exists. Pre-pandemic, the percentage of people in the U.S. that experienced it was 10.5%. During the pandemic it got to 23%. If you're going to get into politics-adjacent territory, be thorough and correct.

You'll know which one was mine. (Even though I tried to be more constructive than vituperative.)

I think this would be even more interesting if you included round trip time including reloading for the next trip. This would either require dropping off/picking up full ore containers or jettisoning/draining/fuel-transferring the ore.

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.

Part of the issue is that it fixes something that didn't need fixing. Making it too easy makes the problem much less interesting. There were already several workarounds to the problem; Use a mod that gives precise attitude hold. Get good at docking. Multi-docking. Build interlocking alignment rails/keys around each port, The last two being the most interesting and educational. Secondly, if one MUST fix a non-existent problem, don't make the ports move, just give an SAS mode for aligning the ports prior to contact. Leave the decision as to when it's good enough up to the player.

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.