Snark

Moderator
  • Content count

    6,892
  • Joined

  • Last visited

Community Reputation

8,914 Excellent

About Snark

  • Rank
    E Pluribus Boojum

Recent Profile Visitors

11,715 profile views
  1. Snark

    Save my Neidon mission

    Great, that narrows the scope of the problem. So, this isn't an engineering problem-- it's a navigation problem. So, basically you need to figure the following: When to launch What path to take (i.e. what sequence of burns) How much dV it will need (so you can design your ship) Here's the executive summary of how to pull this off: Eyeball where your target ship will be at intercept time. This is so you know where to aim. It's easy & quick. Figure out which launch window will take you there. This is so you know when to launch. Reasonably straightforward. Figure out what path you'll take, i.e. what sequence of burns. This is so you'll know how much dV you'll need, which is necessary in order to design your rescue ship. This step is the tricky bit, because it's where you figure out most of the navigation. Design and launch the ship. This one's an engineering problem, not a navigational one. So I'll assume you've got this covered. Plot the course. This one's just a verbatim replay of the figuring-out that you'll do in step 3 above, so therefore it's easy. I'll talk you through steps 1 and 2 here, then pause for a breather to see what you think before going on. Step 1: How to eyeball where the target will be at time of intercept Well, that's hard to do precisely, but fortunately you don't need to. For purposes of this step, you only need to eyeball it approximately, and in your particular case that's pretty easy to do. Why is it easy in this case? Because you've got that nice, long seven-years-out-of-a-nine-year flight ahead of your ship. It means that if you open your map view, you can already see where your troubled ship is going to hit its solar Ap, nine years from now. So you just need to visually estimate "where is the ship going to be, around 2-3 years before Ap". And that's easy to do, because those last 2-3 years are going to be when the ship is moving super slowly (because it's waaaaaay out in the outer solar system at the outer end of a very eccentric orbit), so it won't cover much distance during that time. So all you need to do is look at where your target ship's solar Ap is, and then mentally estimate a point along the orbit that's "a bit" before that. It helps that you don't have to get it exactly, because as long as you can get it somewhat approximately, that's good enough for launching purposes. Even though you won't nail it perfectly, the error will be easily corrected by adjusting burns at launch time and won't cost an unreasonable amount of dV. In other words: If you picture the solar system as a clock dial with the sun at the center, all you're trying to guesstimate is "at which o'clock will the intercept happen", and as long as you get it within one or two clock-hours, you'll be fine. (Note: If this kind of wild-ass guesstimate bugs you and you'd prefer a more accurate picture, you could always just do a quicksave and then timewarp ahead 6-7 years to see where the ship is, then go back and reload.) Step 2: How to pick a launch window This also is pretty straightforward, because you have a lot of flexibility here. A digression into why it's so flexible and why you don't have to worry too much about this, in spoiler section. Okay. So, picking a general launch window is pretty straightforward here because you know what direction you're going (having estimated the intercept location in step 1 above). You know that you want to eject from the inner solar system going in a certain direction. So all you need to do is pick where to eject from Kerbin in order to make that happen. There are a few ways to slice this, but there are two main types of path you could follow, both of which probably involve a similar amount of dV, so you should just pick whichever one is available soonest. (Yes, there will be some dV difference between the two, but it won't be a huge difference and you've got a fair amount of dV to play with, and time's a-ticking so sooner is probably better.) Broadly speaking, the two choices of trajectory you could take are direct and bi-elliptic. More wordage below, but the executive summary of these two paths looks like this: Direct path: You eject from Kerbin in the solar-direction, and shoot out to the intercept in a fairly straight (i.e. only slightly curved) line. Bi-elliptic path: The exact 180-degree opposite. You eject from Kerbin in the solar- direction, such that your path takes you down to a fairly low solar Pe. Then you wait until you get down to solar Pe and do a big burn there. In other words, you eject from Kerbin going the "wrong direction" but then use the sun's gravity to make a U-turn. In case you're wondering, "what's the longest I'd have to wait for one of these windows to pop up, some analysis in spoiler. TL;DR: you don't have to wait all that long for a window. Significantly less than half a Kerbin year, even in the worst possible case. Okay. Now that we've established that you won't have to wait too long... let's figure out which of the two path types you want, and when to launch. To describe these, I'll go back to the clock metaphor again. Picture the solar system as a clock dial, with the sun at the center and your target intercept location (i.e. nearly out at the distance of Neidon) as being on the rim of the clock. On that scale, Kerbin is orbiting really really close to the central hub of the "clock". To keep visualization easy, let's rotate our frame of reference so that the intercept location is at 12 o'clock on the clock rim. I'm assuming you're looking down at the solar system from over the sun's north pole, so all the planets are orbiting counterclockwise. So what we're trying to figure out is, "at which o'clock would Kerbin need to be located in order to launch on a direct path?" And same deal for a bi-elliptic path. Got it? Okay, let's look at the direct path first. Imagine the slowest possible scenario, where you're trying to optimize for "minimum dV" and don't care how long it takes to get to the destination. In that case, you'd want to launch when Kerbin is at the 6 o'clock position. That's because your transfer path is half of an ellipse, so you're going through 180 degrees of clock in order to get to the destination. On the other hand, imagine the fastest possible scenario, where you're trying to optimize for "get there as soon as possible" and you have infinite dV to play with. You're shooting the ship like a rifle from a gun, and you'll be travelling in a nearly perfect straight line the whole way. In that case, you'd launch when Kerbin is at the 3 o'clock position, because the target's at 12 o'clock and Kerbin-at-3-o'clock is where Kerbin is traveling in the desired direction, i.e. straight towards the target. So, those are the two extremes. You're going to be somewhere between those two extremes, because on the one hand, you do want to get there reasonably quickly (you have to catch up to the target, after all), but on the other hand, you don't have infinite dV. So, as a broad guesstimate, you'd probably want to launch when Kerbin is somewhere between the 4 o'clock and 5 o'clock position-- I'd guess closer to 4 than 5. Okay, that's the direct-path launch position. What about the bi-elliptic launch position? Well, it's around 180 degrees away, so that would be likely between the 10 o'clock and 11 o'clock positions. Right. So. Rotate your map view so that the intercept location is at 12 o'clock, and look at where Kerbin is now, and picture Kerbin continuing in its orbit. Will Kerbin arrive at roughly 4-5 o'clock sooner? Or 10-11 o'clock? That'll tell you which one of the two main path types will open up to you sooner, so you can pick that one. Sorry... I know that's a whole lot of words. (I tend to do that a lot.) But the actual concept behind it is pretty straightforward, and hopefully it'll be clearer when you actually look at it in-game. Anyway... how's this so far? Does it make sense? Is it useful? Too much detail? Too little? Just wanted to touch base before going on to the tricky bits in step 3.
  2. Snark

    Save my Neidon mission

    There are a lot of ways to slice it-- hey, this is KSP. One of the nice things about a long, slow mission such as you describe is that there's a lot of flexibility in "how much time does the trip take" if you have a craft with a bit of extra dV to spare. Also bear in mind that there are different kinds of launch windows. Simple Hohman's not the only option-- you can, for example, launch a craft solar-retrograde so that it falls down to a solar Pe significantly lower than Kerbin's, and then do a large burn at Pe to go zooming out to the outer solar system. So... why not just launch one more ship, a supply ship? Make it simply a fertilizer hauler. I've never used USI life support, so I'm not sure how much mass we're talking about... but if you build a ship that's basically just a fertilizer container and a fuel tank, how big does it need to be? We're not talking about something really huge, are we? Assuming it's not too giant, just build a special-purpose fertilizer-resupply ship and launch it to catch up with your crewed ship shortly before year 7. The dV to get the intercept should be reasonably modest. You'll likely need a significant chunk of dV to match velocities when you do intercept, but we're not talking something seriously insane, here-- I expect a reasonably designed LV-N ship should be able to manage it. Any reason not to try that approach? Simple, direct, shouldn't be too expensive, doesn't require sacrificing or compromising any of the existing ships or mission goals.
  3. Snark

    Antenna Ranges

    Absolutely, and that was a great idea. So, thank you for doing that. Providing the info about the mod, and linking to it, is a helpful public service. It's exactly cases like this why we don't have a "no necro-posting" forum rule, and why the forum doesn't automatically lock old threads. Sometimes, there's a good reason to post in old threads, such as what you've done here. It's a "righteous necro." Well, let's be careful not to throw the baby out with the bathwater. Nobody said this was impossible to code. Nobody said there could never be a mod that does this. The original comment was purely about the stock game. i.e. "it's too hard for the stock game, so it isn't happening for the stock game". That's a completely different (and much more limited, constrained) statement. And since this was said by a Squad employee, my guess is that the likelihood of its accuracy is pretty high. (Certainly it has stayed accurate up to now, because we've been through a major KSP version update and several minor patches since then and it hasn't gotten added yet and there has been no indication that they have plans of doing so any time soon.) Sure, no disagreement there. Actually, if anything, I'd expect that writing code for the stock game would actually be somewhat easier than writing code for a mod-- because if you're writing code for the stock game, you have access to all the game's private internals and source code (which a modder doesn't), which is a tremendous advantage. Plus you're a Squad employee working with all the other Squad employees, so if you run into any situation you don't understand... you've got immediate access to all the experts and whatever internal documentation they may have, instead of having to rely on trial-and-error and Googling and looking at other mods to see what they did and posting in the forums to try to find someone with an answer. Which is another tremendous advantage. But all of that is completely beside the point I was making. Nowhere did I say this is hard to code, because it's not a fundamentally difficult programming problem, technically. The difficulty has nothing to do with technical constraints, because it's not a coding problem. It's a user-interaction design problem, which is a horse of a completely different feather. For technical coding problems, the developers of the stock game have several big advantages over modders-- e.g. the ones I've described above. But for feature design problems, it's completely the other way around. Because when it comes to feature design, the stock game has to worry about many factors-- really hard, gnarly ones-- that mods can blithely ignore. Mods are free to do all kinds of things that the stock game can't get away with. Stock features need to solve problems that are important to everyone. Mods don't. For example, neither you nor I know what fraction of KSP players even have CommNet turned on at all. It's entirely possible that 90%+ of KSP players just turn it off. Or that a majority of KSP players never leave Kerbin's SoI and therefore don't have to worry much about antenna ranges. Suppose, just hypothetically for a moment, that that's the case. It would mean that spending any time at all enhancing CommNet features would apply only to a small subset of users, possibly very small. Would that be a good use of Squad's limited time and budget? Or, from their perspective, would it make more sense to focus on problems that do affect everybody? Stock features have to be appealing to everyone. Mods don't. Stock features have to be rigorously QA-tested and reliable. Mods don't. Yes, I'm aware that the stock game has bugs and that a lot of players yell about how awful and stupid Squad is. And yes, it's not perfect, and yes, it's buggier than I'd like to see. But overall I think they've done a reasonable job-- and I've had a lot more problems with game-breaking bugs from mods than I ever have from the stock game. By at least an order of magnitude. It's not even close. Mods are free, and mod users mostly understand that and (quite properly) are more forgiving of modders than they are of Squad. My point is... the developer has to invest a large amount of QA time (and therefore budget) for a feature. Mod authors don't have to do this, and can leverage enthusiastic fans to help them find problems, which is a huge leg up. Stock features have to be supported and maintained from inception until the end of time (well, until the end of KSP, anyway). Mods don't. Stock features have to be prioritized and balanced against other potential features (because they only have so many developers, and spending time on feature A means not spending time on feature B). Mods don't. Stock features have a big cumbersome fix-test-integrate-release process to go through in order to fix problems when they turn up. Mods don't. And so on, and so forth. And that's not a bad thing, either. The fact is, the stock game and mods are solving different problems. Each one is a valuable complement to the other, and tends to be good at what the other one's bad at. Some problems are better (or, at least, much more easily) solved in the stock game. Some are better (or, at least, much more easily) solved with mods. In this particular case: the UX design needed to "solve" the antenna-range problem is a much thornier one for the stock game than it is for a mod. That doesn't necessarily mean that it can't be done in the stock game-- and note that @bewing didn't say "impossible". Just, "very hard", meaning "would take a very large commitment of time, resources, and budget to solve in a way that works well for everyone". Which, in turn, would mean not solving some other, more pressing problems-- of which there are plenty. Just spend some time reading irate posts in the forums about them. So this particular issue seems to me like the poster child for "problems that are better solved by a mod than by the stock game". And events would seem to have borne that out: here we are a year later, and the stock game still hasn't added any such feature, and someone came along and produced what looks like a very nice, polished mod that addresses the problem very well, for the particular small subset of KSP users that like this solution. Sure. No argument there. I would love to have such a feature myself. I don't think anyone is saying that it wouldn't be nice to have. But it ain't free, and coming up with a solution that would be appropriate for the stock game is really hard. Making it happen would require the following: Come up with a design that works for the stock game. (I haven't seen anyone do this yet.) Decide which other really vital features to cut in order to allow implementing the feature. (I haven't seen anyone come up with a list... which of course would be difficult for someone outside Squad to do, since nobody outside Squad actually knows the real engineering cost of the various features, or their budget.) So the question isn't "would it be nice to have". Being an actual shipping-commercial-software developer is a hard juggling act that depends on balancing a lot of factors quite aside from sitting down and coding. Sometimes we don't have nice things because they'd be too expensive relative to other things. Which is why it's great that we have mods. Well, it's laughable to you, perhaps, because you have a coping strategy that works for you. It wouldn't work for me. I could go on at length as to why not, and why having functionality and UI like this grafted onto the stock game would be like sandpaper on my soul... but I won't, because the fine details aren't relevant to anyone but me, personally. No point in boring you more than I already have. Besides, it would be a pointless and un-resolvable argument, because it would be an argument over what to like. It would be as silly as getting into an argument over "which ice cream flavor is better, vanilla or chocolate?" (Chocolate.) Suffice to say that I do have reasons-- carefully thought out, cogent reasons-- and therefore I like what I like, and I don't what I don't. It's personal. And therein lies the rub. Different people like different things. You like a solution that I don't. I like a solution that you don't. Ask a bunch of other KSP players, and they'll like still other solutions that perhaps neither you nor I would care for. Players differ vastly about which problems they consider to be important or unimportant-- and also in how they'd like to see those problems solved. Trying to please them all-- or even a significant majority of them-- is a mind-bendingly difficult design task. It's a big part of the reason why commercial software development is difficult and requires a lot of trained professionals working full-time. It's why things that may seem obvious and easy to the layperson often don't make it into the stock game-- because it's actually harder than it looks. And it's why it's such a wonderful thing that KSP is so moddable: because mods don't have to please everyone and can target solving specific problems really, really well for specific target audiences. And there are hundreds of mods out there. So any player can get a highly customized KSP experience by picking and choosing the mods that they like that solve the problems that are personally important to them, in ways that are personally appealing to them. Nobody's opinion is laughable... to themselves. Everyone likes what they like. And that's perfectly reasonable-- no matter what they happen to like.
  4. Snark

    Does someone knows this mods name?

    Nope, not mine-- the only tinker-with-the-arrangement-of-the-solar-system mod I've done is Snarkiverse, which is very much not corresponding to the real solar system in any way. I've never seen anything like what the OP is asking for, myself-- but then, that's not surprising, since it's an area I don't know well. I don't dabble a lot with solar-system-tweaking mods. There are a small handful that I like a lot and use from time to time (OPM, New Horizons, GPP), but other than that, I don't experiment much. Perhaps the one that @4x4cheesecake links to, above, is what the OP is looking for?
  5. Snark

    Antenna Ranges

    What do you mean? A modder did what modders do: write a mod. As you were kind enough to quote, @bewing pointed out, quite correctly, that if adding it to the stock game were easy to do, it would have been done already. But it isn't, so it hasn't. Note that you're comparing apples and oranges, here. You're talking about a mod. He was talking about the stock game. Speaking both as a KSP modder and as a professional developer who's been shipping software for a living for a quarter-century, I can tell you that creating a mod is not the same thing as creating commercial software. It's not even in the same ballpark. Someone making a mod has a much different job than someone adding a feature to the core came, because they don't have to satisfy everyone. A modder can do whatever they, personally, like. They don't have to design something that can address a super-wide audience. That makes the job much simpler, to a degree that someone who hasn't designed software for a living may have difficulty appreciating. Adding a feature to the stock game means that it needs to work for everyone, or at least the vast majority of the player population. And that is an extraordinarily difficult thing to do. Nobody said that adding the feature was impossible, or even necessarily difficult, for modders. He was talking about the stock game. And speaking as someone who writes commercial software for a living myself, I wholeheartedly agree with him. That's not to look down on modders, or belittle them in any way (not least because I am one). It's fantastic that they do what they do. And some of them turn out truly astounding stuff. It's just that they're solving a very different problem than designers of the stock game are. I took a look at the mod you linked. It's really impressive. Hats off to the guy who wrote it, it's a truly amazing-looking mod and looks really well executed, and I wish it every success. I'm sure that many KSP players will love the heck out of it. I wouldn't be surprised if a lot of them end up loving it so much that they consider the game unplayable without it. Many. But not all. Not even most. And therein lies the difference. For example, I won't be installing or using that mod myself, ever. Why? Not because it's a bad mod-- it isn't-- but because it's not my personal cup of tea. For example, it adds UI, which is absolutely anathema to me, personally. I do not want my KSP screen real estate populated by dialog boxes. To me it's clutter and would ruin the game. It's the same reason I will never install KER, despite the fact that it's also an awesome, very useful and clever mod that lots and lots of people find indispensable. The game has to please everyone. A mod only has to please the people who choose to use it. Not everybody wants the same thing. KER is fantastic-- as a mod. This Antenna Helper also looks fantastic-- as a mod. But I gotta say that neither one of those things belongs in the stock game, because they don't meet the "works for pretty much everyone" bar.
  6. Moving this to the "tech support for modded installs" forum, because it's clear from your screenshots that you're running a bunch of mods. Just FYI: when asking for help, it's really important to be clear whether you've got mods installed or not (and, if modded, which mods). That's because, with any technical problem, it's vitally necessary to establish where the problem is, before one can begin to determine the "why" and the "how" so it can be fixed. And if you're running mods, there's a pretty high chance that it's one of the mods that may be causing the problem. So, before anybody goes any further, can you do one simple check? Try running KSP without any mods installed and see whether you still have the problem. If the problem happens even when no mods are installed, then this is a legitimate stock-KSP problem and we'll need to dig into it deeper. If the problem goes away when you uninstall your mods, then it's a mod problem, not a KSP problem. Just use process-of-elimination to work out which mod it is, and then go post your question in the "Add-on Releases" thread for that mod.
  7. Snark

    Any tips for going interplanetary?

    Sure, though unless you're trying to do something that requires high power levels over an extended period of time (e.g. drilling, or MPL research), it just means it takes a little longer to recharge, is all. True, but on the other hand, if it's a crewed mission, it doesn't necessarily matter all that much if communications are always up. Were you using the RA-2 antenna, by any chance? Those things are freakishly inefficient-- they require way more electricity-per-science-transmitted than the other antennas that are weaker or stronger. Not sure if that's intentional or an accidental design goof. If it's intentional, it's not clear to me why that one antenna is worse. When I say "worse", I mean way worse: 2.66x more than the HG-5 2x more than the RA-15 4x more than the DTS-M1 3.6x more than the HG-55. It's just off the charts. Moral of the story: If you need to transmit science and are using RA-2 antennas, carry way more batteries. Well, sure. And that worked, right? So, no problem, then? (That's my normal mode of operation. After all, as long as I can transmit one result, I can transmit all of them. And there's no point in lugging around more batteries than necessary, it's just dead weight. So I generally design my probes by considering how much electricity I'll need to transmit one result, and that's how much battery storage I put on, with a bit of safety margin.) Yeah, that one's a real hog. It's by far the thirstiest of the science instruments. Power needs will vary depending on what antenna you're using, but in general best to have at least 1500-2000 EC storage on the craft if you need to transmit this. (Or double that, if you're using the RA-2.) Yeah, for Jool you'll want the longer-range antennas. You can boost the range a bit by spamming multiple antennas, but that's subject to diminishing returns. Can be useful, though. For example, if you've got the RA-15, spamming 7 of them (e.g. one on top, and two rings of 3) will combine to a net antenna power of about 64G, which is respectable. So even if I don't have the 100G antennas yet, I can make an antenna-spamming relay sat and lob it in the general direction of Jool (or wherever). Doesn't even particularly need to intercept Jool. Then I can send my actual exploration vessel and give it a more lightweight antenna, because it only needs to reach the relay sat and not all the way back to Kerbin. Yep, that can come in handy. Though if you're planning on mining fuel, I've found that Ike is much friendlier to that than Duna itself is. Much less dV, much lower gravity.
  8. Moving to Technical Support. Though I'm puzzled by the problem reported-- I've been running KSP for years, and it's never asked me for admin rights. It just runs.
  9. No idea. I'm not equipped to judge what's broken, because whatever is breaking isn't a mod I ever use myself, and I don't have the bandwidth to investigate / debug. I will say that I'd be a little surprised if Snarkiverse is the culprit. It doesn't *do* anything. There's no code. It's just a set of Kopernicus config, and it's not exactly avant-garde Kopernicus config, at that. It doesn't create any bodies, or delete any bodies, or rename any bodies. All it does is move planets around to different locations from where they are in stock. In short: if a mod has trouble with Snarkiverse, I'd expect it to have problems with basically *any* Kopernicus based mod. And if such were the case, not sure how it would be possible to "fix" it in Snarkiverse. All of that is just guesswork, of course. If it turns out that there's something simple I could tweak in the Snarkiverse config to make it play nicer with other mods, I'd be happy to. But someone else would have to do the footwork to isolate the problem and come up with a solution.
  10. In the stock (unmodified) heat shield, the node_stack_bottom is the lower one-- the one that's floating in space below the shield, and which causes the shroud to appear when used. The node_stack_direct is the upper, "hidden" one that allows for direct attachment to the shield with no shroud. For my own reasons, I've never used the node_stack_direct myself (because its design makes it unusable as far as I'm concerned). So I've been stuck with the node_stack_bottom, which is usable and convenient for building; it's just (to me) ugly and unpleasant. So what I did was to eliminate the (to me) awkward / confusing / unusable node that I never use anyway and only gets in my way, and then take the usable one that I've always been in the habit of using, and change it to make it look the way I want. Ridiculously long part-design rant in spoiler section since it's kinda peripheral to the topic.
  11. Snark

    Show off your drawings!

    Guys, I know it's all in good fun, but please do try to stay on-topic. This is the "show off your drawings" thread, not the "debate the merits of different mecha cartoons" thread. Drawings, and direct responses to those drawings, are what this thread's about. Let's see if we can sort of veer gently back onto the rails, shall we? Thank you for your understanding.
  12. Snark

    Ask the Mods questions about the Forums!

    Answer: As soon as it's dead. Just to add on to @Val's excellent explanation above: There's nothing wrong, per se, with posting in a long-dormant thread... what matters is why, and whether it's the right thing to do. For example: As Val mentioned, it's a pretty common thing for people to post in a many-years-dead thread without realizing how old it is. Such posts are very often mistakes. For example, practically anything in Technical Support or Gameplay Questions should probably be left alone if they've been silent for a really long time. Reason: Threads there are because somebody has a problem they're trying to solve and needs help. If the last post in the thread was a year or more ago... I think it's pretty safe that whatever problem they once had, they long ago got an answer one way or another. So it's not useful to post there. It's not helpful to post an answer (because they almost certainly don't need one anymore), and it's also not helpful to post a "me too!" kind of question (because if you've got a current problem, it's better to just post your own thread). Even if it's not a gameplay question or technical support issue, posting in an ancient, years-dead thread in, say, KSP Discussion is likely to be unhelpful, if for no other reason than that everyone else in the discussion was talking about a very different previous version of KSP, so anything said now is likely to be moot relative to what was said then. On the other hand, there are some cases where it's perfectly reasonable to post in a thread that hasn't had a post in a while. For example, a mod's thread in Add-on Releases. Just because nobody has posted there in a few months doesn't necessarily mean it's dead-- it may simply be that nothing new has happened in a while and nobody had any questions until you came along. So it maybe perfectly reasonable to ask. (On the other hand, if it's been multiple years, and the mod author hasn't logged on to the forum since forever... then it's probably a safe bet that the mod's dead and there's no need to resurrect the thread.) Every case is different, and "is it appropriate to post in an old thread?" will vary on a case-by-case basis. That's why there's no forum rule "don't necro!", and that's why threads don't auto-lock themselves whent they lie dormant for a long time. It's a matter of judgment and etiquette, not strict "correctness". So basically, it's up to you to judge whether you think it makes sense. Just make sure that you don't necro a thread accidentally due to simply not noticing how old it is. That's what that little warning banner is for, as an aid to notice that sort of thing. Don't worry too much about whether you "get it wrong", it's kind of a gray area and about the worst that can happen would be if some moderator thinks "well, this really shouldn't have been necroed", they may lock the thread with a friendly explanatory note to prevent further confusion. No harm done! As avid forum user H.P. Lovecraft said, "That is not dead which can eternal lie." Truth.
  13. Snark

    Any tips for going interplanetary?

    Well, that would save you from lugging them back into orbit and all the way home to Kerbin, sure. But you'd still need to spend all the fuel to launch them to Kerbin orbit and send them on their way to Duna. Plus more mass for the decouplers. Plus (potentially) extra drag from the extra chutes and decouplers. It's mass. Skipping them saves mass and therefore fuel and therefore leaves you with more dV to play with. It can come in handy, is all. If you don't mind the extra mass and have no troubles designing a craft with the dV you need for the mission, then there's nothing wrong with packing on the chutes if that's what you like! By the way, one other thing to be aware of: if you're landing with parachutes, it really matters a lot where you land. Duna has lowlands, and highlands. Both of them cover a pretty big swath of the surface, so you could end up on either one. And the highlands are a lot higher than the lowlands. And Duna's atmosphere loses pressure very rapidly with altitude. The result is that your terminal-velocity-with-parachute will be considerably higher in the highlands than in the lowlands. So, for example, if you're planning a chutes-only landing, then either you need to have the navigational skills to ensure you come down in lowlands, or else you need a lot more parachutes to be able to land safely in the highlands. (That's one reason I like the "skimp on chutes, use engine to cushion landing" approach. Engines work great wherever, so it doesn't matter much whether I end up in the lowlands or the highlands.) Moral of the story: If you do go with a chutes-only landing, and then if you get unlucky and discover "oh noes I was going too fast when I landed and it broke"... check your altitude. If it's high (i.e. thousands of meters), it means you came down in the highlands-- you may be able to salvage the mission if you can revert to an earlier save (e.g. when you enter the SoI) and adjust your approach to land in a different (i.e. much lower) spot. On the other hand, if you go with an engine-assisted landing, then you don't have to care much what altitude you land at.
  14. Snark

    Any tips for going interplanetary?

    EVA chutes, sure. But spacecraft chutes? Nope, only engineers can. And they have to be at least level 1 to do it. By the way, regarding the lander. There are many different ways to design a Duna lander (it's nicely flexible, there are a lot of different strategies), but for a simple "land with parachutes" one, here's what I like to do: Make sure there's at least one drogue chute. Set it to open as high as possible. Then just put a bare minimum of regular parachutes on it to land with. Don't try to add enough parachutes to land safely on chutes alone. Rationale: Duna's atmosphere is super thin. Yes, it's absolutely possible to land safely on parachutes alone... but it means you'll have to spam a lot of parachutes, which means a lot of mass. So what I like to do instead is to just put on a bare minimum, and don't even try to have enough chutes to land safely. Even one parachute will do. This won't slow you down enough to actually land... but at least it gets you to the general ballpark, so you'll be falling at something like 30-40 m/s. Then, use a brief burst of thrust from the engines just before touchdown in order to soften the landing to something survivable. Rationale: the fuel you use for that one brief burst right at landing weighs a lot less than the mass of all the extra parachutes you'd need to land safely. Like I said, you can totally land just by spamming the heck out of parachutes, I merely mention this as one of your options.
  15. Snark

    Any tips for going interplanetary?

    Well, one thing you could do: go ahead and build in the extra dV, and then just hope you get lucky. You might! That way, if you land on Duna with extra safety margin, and you happen to be near a biome boundary, you can give the biome hop a try. Just quicksave before you do the hop, so in case it turns out that you don't quite have enough dV, you can revert and then just go home without the hop. By the way. If your vehicle that's returning to Kerbin is the same one that's landing on Duna, and you're using parachutes, it can be handy to have an engineer along so you can repack the chutes and then re-use them for landing on Kerbin. (And if you do try a biome hop, you'll want the chutes re-packed so you can use them to land after the hop.) By the way: you don't need a heat shield for aerobraking at Duna, assuming you have a good transfer window. It's really gentle, you won't fry anything. You do, however, definitely need a heat shield for return to Kerbin. Definitely put drogue chutes on the lander-- they're really needed on Duna, due to the thin atmosphere.