Frederf

Hold Alt+WASD to permanently deflect the control indicators. Alt-X resets to zero.

Canceling inclination is best done by not having any in the first place. Direct launch azimuths to any desired inclination are pretty easy to calculate. To answer the actual question though you want to cancel your out of plane velocity when your position is on the plane of the desired orbit. You can think of an inclined orbit as being two orbits happening at the same time. Your north-south wobble is an orbit around the center of mass. In any case the ring of your orbit intersects the equatorial plane at two points called the ascending node and descending node. At either one burn in the opposite direction of your ascension (south) or descent (north) until your inclination disappears. Be aware that you can only fully cancel your north-south movement as you pass through such a node. If you cancel your north-south motion away from the equator you'll still have inclination because you're still north or south of the center of mass.

Cutoff is 23km so I try to have my final stage stop with a Pe of 22.5km. Anything that gets beyond that point is designed to be controllable and have a planned reentry path. Occasionally I'll have stuff in the upper atmosphere and I roleplay it for a few days and then manually delete it. A mod that slowly degraded debris orbits <100km would be neato.

There's a radial one in stock parts I think. The drag's pretty high so pairs are a good idea. Parachutes are quite lacking even with mods. There was some mod pack that had stackable "disk" parachutes that could be sandwiched below a nose cone.

Long-duration slow maneuvers you must think of as transfer orbits. Short-duration fast maneuvers are "point and shoot." Outside of 50km think transfer orbits. Inside 10km think point and shoot. The difference between the two regimes is what orbiting around a common body does to your velocity vectors. At 1.5km you're well inside direct-path range. The goal in this situation is to "put the thing on the thing." The thing in this case is the direction to target and the thing is the velocity vector. Adjusting your velocity vector can be confusing if you're not used to it. In the general case you are going to have two components to your velocity with respect to the target, axial and lateral. Axial is motion toward or away and lateral is sideways. To travel to the destination we want a manageable positive axial motion (toward it) and minimal lateral motion (sideways). A good first step is to put your nose on the target (pink round) and roll until the velocity vector (yellow, either one) is up. If the anti-velocity vector is visible in the hemisphere around the target direction then you are traveling away from it. Burn toward the target until the prograde velocity vector is in sight. If not, skip that step and proceed to next. After the previous steps we should be traveling toward the target but also missing it due to some lateral motion. To cancel the lateral motion we point opposite and burn to cancel that component of our velocity without adjusting your toward/away part. As an example we're traveling towardish the target with our nose on it and our velocity vector showing prograde somewhere between the pink-round and the top of the navball. We've got excess "up" lateral velocity that we want to cancel. We do this by pointing 90 degrees "down" and burning a little bit. How much is a matter of some math or guess and check. After several iterations of this the velocity vector and the target market should merge. Then it's a question of speed and timings. What's your relative speed? Are you going to get there in 200 milliseconds or 20 weeks? Personally I strive for a relative speed that arrives in 100 seconds. It's easy math and comfortable. If something is 20km away I want to have a closing speed of 200 m/s. For 5km, 50 m/s, etc. Orbiting Kerbin happens once every 30 minutes or so. If your rendezvous takes a significant fraction of this time (1/4 orbit or more) then your aiming gets complicated very quickly and it's better to switch your brain to intercept orbital transfer mode. At 10 seconds I turn around and reduce speed to match the 100 seconds rule again. So 9km, 90m/s. At 900m I slow to 9 m/s. At 90m I slow to 0.9 m/s. Inside 100m I keep docking slow and visual. If you're close in position and speed then the disrupting effects of orbiting are minimized. Once inside 100m and 0.5 m/s you are effectively colocated and static and the fact you're orbiting shouldn't be too bothersome.

A: Yes. Why: When encountering a massive body from beyond the SOI you have net positive orbital energy. Orbital energy is a combination of gravitational potential energy (which is conventionally defined as zero far away and some negative number on the surface) and kinetic energy due to motion (always positive, proportional to speed squared). Transgressing the SOI of a body without doing anything results in leaving SOI at the same speed as you entered. This ignores any slingshot effects and assumes you don't actually hit the body at some point. Anyway, to achieve capture you must have net negative orbital energy. At any given position in the gravity well your speed must be less than "escape speed" or rather you cannot have escape kinetic energy. The way to reduce your orbital energy is to slow down. To that end the most efficient kinetic energy lost per unit fuel happens at the highest speed. The highest speeds happen deepest in the gravity well. And so it's seen that a retrograde burn at the lowest possible periapsis sheds the most kinetic energy per unit fuel.

You can use trim for rovers as a form of cruise control.

Advisable or not, direct-to-moon transfers are best approximated as the transfer to the planetary body with a capture that is sum of the capture speeds of the two bodies. For example: Kerbin - Eve Transfer 1030 Capture 1310 Eve - Gilly Transfer 1650 Capture 210 Kerbin - Gilly Transfer ~1030 Capture ~ 1520

It's supposed to be "g-naught" or g with the little zero subscript. It's a simple conversion value that doesn't depend on the actual local gravity at all much like converting kmph to mph. I seem to recall in KSP g-naught is 9.80000000000000000000000 but I'm not 100% confident.

Just active vessel. Someday the life support will drain in the background but let's burn that bridge when we come to it.

Why doesn't the radial mount drill take 2.0 charge per second while deployed?

Permadeath Crew Manifest makes that a bit distasteful. I'd also have to bring an extra kerbal during tests and waddle them over to their doom. It's all more trouble than closing the program, editing the file, and waiting for the few minutes to reload the program. And that's the level of inconvenience I was trying to avoid. About the fuel flow rules. I'm well aware. Notice I had empty receptor tanks directly above and below the converter in the stack which should by the most compliant to flow rules ever. I think it had something to do with being attached to a docking clamp tower still. Ultimately I want to connect a KAS cable/hose to a tanker and convert directly off the drill/refinery. During testing I seem to be able to transfer across this link but not convert directly to a tank on the other side which unfortunately requires that the source has a "buffer" tank. The smaller the buffer tank the more time I have to manually transfer the buffer over (try 50 LiquidH2 to fill a 50,000 tank). The bigger the more needlessly monstrous the contraption is. It's all so hopelessly fiddly that I'm considering wiping the whole scheme and mining directly into a Kethane tanker and driving to a refinery. It wastes a lot of extra Kethane storage and requires much heavier launch equipment but at least I'll keep my hair planted in my scalp.

One of the typical blunders for me is to let electricity run out because MechJeb or similar happens to always pick an attitude with my solar panel North or some such. If Kerbal alarm clock could warn me when a resource (usually electric charge but oxygen/carbon dioxide too) are getting critical it would save me many a four letter word.

For the life of me I cannot get converted fuels to flow. I've put appropriate tanks above and below the converter and nothin' Had to scrap like 10 hour's work on the surface of the Mun because the resources just wouldn't flow, especially through KAS. Kethane really really really needs a test tank full of Kethane so I can make sure a design works before getting it on a celestial body.

The procedure for getting to Minmus is much like the Mun but with the inclination added: 1. Eastward parking orbit 2. Set target, adjust relative inclination to zero at AN/DN 3. Create maneuver node out to target's orbit 4. Drag maneuver node around your path until intercept 5. Fine tune node and execute 6. Retro burn to capture at Pe (make sure to give yourself a Pe above the surface, lower the more efficient)

Calculation and general description are a far cry from one another. The first thing I would do is calculate the deltaV for a direct burn and keep it in your back pocket. All the fancy gravity assists in the world are useless if they exceed this number. To get a net savings out of the maneuver your free deltaV must make up for the deltaV missed out by not burning in LKO. The baffling thing about the calculations is how the gravity assist factors into the entire mission plan. For example the max gravity assist comes from a pitiful entry into the Mun's SOI so while you get all of it, you don't come out with much more than that. Do you GA to eject in a nice Hohmann trajectory or do you get more dV out of the GA and let the trajectory hit the target at a sharp angle. Maybe you're heading for Duna so the dV to slow down at the end matters much less. No maneuver except in the simplest of cases has a clear best. Each one's gains come at the expense of the other. The calculation's difficulty in seeing which gains outweigh other expenses to get the maximum economy out of the whole series of maneuvers. There is a lot of info to be gained by setting the number of SOIs the conics projection extends through to a high number so you can see well into the future.

I thought about where this leads in terms of tedium but really having to do local scouting isn't simple busywork as it requires a significant change in mission planning. Variable deposit depth unless it involved different parts for different capabilities would be a meaningless labor. For depth though I think that both methods should be possible, anywhere in the hex and "find the motherlode". It would be set up as an acceptable resource rate anywhere and a bonus if one chose to hunt for a rich pocket.

I wouldn't think it would be a mapping task. Covering a whole hex on foot would take forever. Some kind of beepy hotter/colder system so you'd go straight to it.

The buildings are 3D but the sky backdrop is a picture.

A thought for making Kethane drilling a bit more challenging is to make the resources within the hex much more localized requiring close range detection equipment. Basically you know there's X liters of Kethane somewhere in that hex but it all might be in localized spots with areas of varying concentration. Drilling blindly you might get a rich source, a slow trickle, or none at all. Local sensors as on a rover could roam a few km and find the best spots.

I'll try. The issue came up before with part name spaces and I half remember that names with spaces support can't/won't happen with MM FT.

Except practically all MM-enabled mods include a copy of the dll with their mod.

Check post #1716 this thread. It's for creating LiquidOxygen and LiquidH2 re: modular fuel.

It's not that kind of discrepancy. It's more like a 2.0T vessel undergoes 3.5G deceleration and a 2.2T vessel undergoes 0.9G deceleration. When you have the "FAR bug" it's obvious.

Please rename all parts beginning with "MMI.K " to use "kethane_" and change all part names with spaces to use underscores instead. Using spaces in part names breaks a lot of modding functionality.