Jump to content

Laie

Members
  • Content Count

    2,934
  • Joined

  • Last visited

Community Reputation

1,407 Excellent

4 Followers

About Laie

  • Rank
    Periapsis Kicker

Recent Profile Visitors

4,782 profile views
  1. 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 d
  2. 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 prograd
  3. 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 t
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. [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.
  13. 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
  14. 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
  15. Yes, ony any given Kerbin year, day 82 is Leave for Moho Day. Or perhaps Day 83, zero hours.
×
×
  • Create New...