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.

Use control surfaces. Airbrakes. In Eve's soup it doesn't take much to give you a couple thousand meters of crossrange capability. Here I'm doing a pretty accurate landing using asymmetrically deployed droges (which give me a tilt, hence sideways motion) and rolling the vessel to get to my preferred spot.

Looks like the Launchpad on Kerbin. Your math is right: on Eve, this tales me to a pretty flat area at 2700m elevation. That's a wide plateau and IMO a good site, but if you're looking for higher elevantions.... hold on. Remember the Eve Rocks challenge? Submission with recognizable coordinates have been marked, but all the links are broken. Anyhoo, this one might be just what you're looking for: @astrobond landed on a tall peak, took a glider down to the beach, then dropped the wings and drove all the way back on a tiny rover. That was rad, and even today the submission is worth a look. I just checked, the place still exists: Lat -25, Lon -158.45 will be good enough to have a look, though you may want to refine it a little before landing anything tall.

Check in the tracking station, after it's updated to lvl-3. You see Asteroids? Great. Now just wait, a comet is bound to show up. Space objects pop up, and if you don't track them, they will disappear after a while, making room for new objects to turn up. Over a timespan of years, you can expect to have a comet on the radar more often than not. By default, you will at most see one comet. Setting up Sentinels anywhere for object tracking will increase the number of objects that can be seen at the same time, but the number of comets doesn't scale linearly. You get ten objects from the tracking station, and another ten for every Sentinel. With eight sentinels you can see 90 objects at a time, but at most three of them will be comets.

Huh, round 3? Visiting many? I thought this was about redirecting one...? Be that as it may, have my upvote. And a thousand thanks for taking the time and converting your pictures to jpg.

It's really quite easy. There is 60 minutes in a degree, and 60 seconds in a minute, or 3600 seconds in a degree. 2° 49' 35" -> 2 + (49 / 60) + (35 / 3600) -> 2.8263888 With that example, I trust you can compute the longitude yourself.

In this particular case, eyeball precision goes a long way. I'm only looking for Kerbin's AN with Moho, after all.

The easy, reliable and repeatable method of getting to Moho: leave Kerbin when it is at it's AN with Moho. set up a transfer orbit around the Sun so that you vessel's solar PE touches Moho's orbit Important: fix inclination already at departure from Kerbin! at solar PE, burn retrograde so you encounter Moho the next time you come around. That's reasonably fast, you usually get to Moho within less than a Kerbin year. More often than not, it's even economical: Proper transfer windows that require less dV only crop up once every couple of years. However, I keep forgetting the date. I've written it down somewhere, lost the notes, can't find an old forum thread, and every time I want to go to Moho I have to figure it out almost from scratch. Q: is there a method to quickly determine the date using in-game tools? Quicker than lining things up in map view and fast-forwarding until Kerbin is in the right place? (BTW, using the above method I get a departure time late on day 82.)

Excuse me quoting myself, but interesting tidbit: the more Sentinels you have, the more objects you can track. With the tracking station alone, you can expect to discover perhaps two comets a year, but if you place a number of sentinels, anywhere really, you can track more objects overall and hence are also more likely to turn up a comet. I'm looking for a comet that's just right, so I though this would be useful... Very quickly, I had veritable clouds of asteroids both near Kerbin and Eve. Some of these would receive the weirdest gravity assists, tossing them to Jool and beyond, giving me a lot of false positives on my quest for comets. I'll try putting the sentinels below Moho next. If that still doesn't work to my satisfaction, I'll look into editing the cfg... but no sooner. I also consider readying several redirectors, and parking them in the Asteroid cloud that is soon to engulf Moho. Just to have a craft on the ready when and if a suitable comet shows up.

To stay in your picture, it's really Realism Overhaul that corresponds to Lego Techniks. Reenactment Progression 1 is the career mode for RO and last time I tried, there was way too much busywork for my taste. Not my idea, and please do not believe that this is just a crummy workaround: that's how it's done, period.

It's been a while since I last did this in RSS/FAR. I don't think I ever managed to return to KSC (at least not without several retries), but IIRC reentry wasn't all that difficult. The key point I remember was that I needed RCS for control until quite late in the entry (that was RO, not SMURFF -- you may get similar results by just adding reaction wheels). Control surfaces didn't provide much authority until I was pretty low and slow, 30km and Mach 6 or something along these lines.