Laie

As mentione, I do it by plotting lots of small prograde-only maneuvers. Start at (guessd) time X, repeat until the desired exit velocity is reached, look where it goes. Discard all nodes and repeat with another start time. That's the solution available to me, with my skill set. I won't promote it as the greatest best solution of them all. Well, I can only tell you what I know... Below is the longest departure burn of which I can still find a screenshot, about 300m/s in ten minutes, for a maneuver that would have taken 270m/s if it had been instantaneous. Note that the nodes don't need to be all that closely spaced to get an accurate prediction. As the trajectory gets more straight, the nodes can be spaced ever further apart. Hmmm. 0.07g really isn't much, 1/6th of what I have in the picture above. Have you considered starting your mission from a high orbit? Within the constraints you set for yourself, it might be a totally acceptable solution: bring the whole vessel into a very high orbit around Kerbin, Mun or beyond. launch a resupply mission to top off the tanks, and bring aboard the crew. then do your long burn there -- with an orbital period lasting 3+ days, even a three-hour burn will fit into a single node. Departure from a high orbit is inherently more costly, but at your meager acceleration, it may not make that much of a difference in the end. And planning / execution will certainly be a whole lot easier.

Well, @bewing called it the "absolute worst case" -- think of something like this, maybe even worse: It is possible to create lots of maneuver nodes in a relatively short timespan if you interface with the API. Both kRPC and kOS will provide convenient ways to do so. The above represents a constant 40mm/s² burn... I think. It's been a while. I'm pretty certain that I didn't account for fuel consumption when making that picture, but you get the idea. I've actually flown missions with that scheme: plotting lots of nodes only to figure out when to start the engines and begin the prograde-only burn. I guess one could also calculate it by other means, but I cannot. I don't think any of my transfers ever took longer than 1/4 orbit, and the extra dV expenditure (compared to a short, high-TWR burn) was on the order of 15%.

All things being equal, you can save a little dV by going for directly for the target altitude and circularize there. Little experiment: you can go from 80km circular to 320km circular in 10km increments, circularizing at 90, 100, 110...km; or you can go from 80km to 320km in one leap. The latter will turn out to be more efficient. In a similar fashion, and for the same reasons, launching to target altitude rather than going through an intermediary orbit is more energy efficient. The difference will be relatively small, though, I'd guess on the order of 50m/s or so. As you say that your launches are far from uniform, it's quite possible that you won't really notice the difference.

Yeah, maybe you shouldn't. The Vector is essentially an ARM engine, those were and are quite OP compared to the other engines in the game. Then again, if you can't compare two engines in the game to each other...? As for it's upsides: for one thing, it looks good on planes. The other: it's compact and has a high TWR for a vacuum engine. Three LV-909s worth of thrust at the mass of two, and the size of one. I find it quite useful on Tylo landers.

As I understand contracts, this may not even help you. IIRC (hope someone can confirm) this kind of contract checks two conditions: have mined the required amount of ore on Body #1 have the same vessel on the surface of Body #2, and the required amount of ore on board This means that the ore itself hardly matters, you can dump or use it, and refill it as often as you like... but you have to bring the "same" vessel to both places. "Same" in quotes because actually it's about the game-internal Vessel ID which can change if docking is involved.

The game shows you the closest encounter during your next orbit after the Maneuver Node. In oder to see encounters in 2, 3, n orbits, you have to lay down another maneuver and use the "+- one orbit" clickies.

Rolling out that old screenshot again... You see two trajectories that will ultimately lead to Duna, their arrival time differs by just a few hours. So they're virtually identical once they leave Kerbin SOI. They're also virtually parallel inside Kerbin's SOI, I guess that is not a coincidence. A munar flyby like that is still pretty easy to plan: just delay the maneuver by +1 orbit until you come across the Mun, then refine a little. if you have a markup satellite with a standard transfer set up (like I do in that picture), this takes only a few minutes. A burn near the Mun may be more efficient, but will be much harder to plan as you need to constantly jump back&forth between two maneuver nodes, one of which keeps shifting whenever you change the other. With stock KSP tools you can easily spend hours refining a flight plan that will ultimately save you very little ( I don't know what's even possible). KSPTOT may make the process much easier, but I have zero first-hand experience with it. I've heard somewhere that 150m/s is the theoretical limit for what you can gain by that kind of assist. Getting 100m/s for an actual, real-life maneuver that's supposed to take you somewhere isn't bad. have you tried Eve? According to hearsay, it's trivially easy to get an AP outside of Jool's orbit from just a single Eve flyby. Ideally you want to line up an Eve + Jool assist.

Wings are great to get around, and even a few wings on your lander will give it a lot of cross-range to take it to the designated landing site. I find that much easier to do than split-second timing on the de-orbit burn. The problem I have with Duna planes is takeoff & landing. I'm already struggling with landing in the wild on Kerbin, and Duna's atmosphere doesn't improve matters. However, I had great success with VTOL designs.

Still torn. The mining bug hasn't been fixed yet, so the comets won't lose mass -- it's still totally possible to do it with the dV you get from mining, but acceleration won't ever pick up. More generally, I don't see myself targetting anything bigger than a F class, or perhaps a lightweight G. Not with stock parts, at any rate -- but if I start scaling up converters and adding big-S nuclear reactors, this becomes just as easy or hard as any asteroid redirect mission.

Many possible reasons, starting with not hitting the CoM to begin with. Flex in the joint and excessive gimbal action is another common culprit. I'd recommend to take it to Gameplay Questions with a screenshot, or perhaps a short video.

For now. They want to have 1500 up by the end of next year, and 12000 are approved (says wikipedia). I'm a city-dweller with a limited field of view. Back-of the envelope, I can still expect to see a starlink every couple of minutes by late 2021, and if they ever get up to the approved number, I'll have a 30% chance of seeing one of them at any given moment. When outside on a good hillock, they will be impossible to ignore.

[citation needed] Do I need to remind you that KSP-as-is doesn't have any anti-piracy measures? Any anti-piracy measure requires the program to figure out whether it is a legal copy or not. The methods to do so are, in varying degrees, intrusive (cf. XPC rootkit) and/or disruptive (enter word from manual, can't play offline). I do not like that.

Maneuvers do not work very well if you go around a bend while doing them. OK, being in orbit means you're always going round the bend... but it's still a matter of degree, quite literally. Over the time it will take you to perform the burn, you original trajectory changes from going steep up to steep down, describing perhaps a 120° change of direction. That's a lot. CBase already mentioned the problem in his very first reply: IMO, the word "period" should be dropped from that rule. The problem isn't how long it takes, but the underlying change of your prograde vector. In your example, the burn extends over about 1/3rd of an orbit.

because of what @Zhetaan point out in the next post, it never occurred to me to try that simple calculation. In principle yes, in practice it's more costly: starting at AN, you can go to Moho's PE (well, close enough) while when starting at DN, you'll go to it's AP. I haven't tried, but expect it to make 500-1000m/s difference. When I first came here, I had forgotten... again. I just hoped that someone would provide the right answer like, real quick. Then again, figuring it out didn't take all that long. This time around I took a few screenshots and put up a tutorial page on the wiki. Trouble with getting to Moho is kind of an FAQ around here, after all, I guess a prefab tutorial may come in handy.

Yes, ony any given Kerbin year, day 82 is Leave for Moho Day. Or perhaps Day 83, zero hours.