Snark

Let's say you're at planet 1, and you want to go to planet 2. The thing you're trying to figure out is the phase angle at launch, i.e. you should launch when planet 2 is how many degrees ahead or behind planet 1. Well, this can be done in a mathy way, with equations and such. I can go into that, if you like. However, here's a relatively straightforward way to do it visually, just by eyeballing things with maneuver nodes in map view: Get into low circular orbit around your origin body. Plop down a maneuver node in any ol' place, and give it some dV. Give it enough that it would put you on an escape velocity with a reasonable amount of margin. (For example, if you're in low Kerbin orbit, you could put around 1000 m/s for starters). Move the maneuver node to the right place. If you're going to a "superior" planet (i.e. one that's farther from the sun than your origin), then you want to position the maneuver node so that at the point you exit the SoI, you're traveling in the same direction as the planet's orbit around the sun (i.e. solar-prograde). If you're going to an "inferior" planet (i.e. one that's closer to the sun than your origin), then you'd position the node the opposite way (i.e. so that you exit the SoI in the solar-retrograde direction). Now zoom out so you can see enough of the solar system to see the sun, your origin planet, and your destination planet. Rotate it so that you're looking straight down at the sun's north pole. Since your maneuver node shows you as being on an escape trajectory, then when you get to this view, you'll see your projected solar orbit after escape. If you're headed for a superior planet, then this means your solar orbit will have its Pe at your origin, and its Ap a little bit higher than that (but probably lower than your target). If you're headed for an inferior planet, then this means your solar orbit will have its Ap at your origin, and its Pe a little bit lower than that (but probably higher than your target). Give your maneuver node more dV (i.e. drag its handle) so that you raise your Ap (for a superior target) or lower your Pe (for an inferior target) until your projected orbit just touches the target's orbit. Note that as you do this, you may need to go back to step 3 to re-adjust the position of the maneuver node, to keep your ejection direction from the origin pointed perfectly solar-prograde or solar-retrograde. This is because as you add dV, your post-ejection trajectory within the SoI won't curve as much, so you'll need to readjust your aim a bit. At this point-- when your projected orbit touches the target's orbit-- the game should be showing you the light blue closest-approach markers. Suppose that when you do this... you see that the closest-approach markers are really close together already! Well, that would mean you just got really lucky and you actually are in the transfer window right now. Launch! Launch! Launch! However... probably you're not super lucky. Probably, the closest-approach markers are separated by quite a bit. In which case, see below. Probably at this point you're looking at something that's more or less like this example (here I'm going from Kerbin to Duna): See, the "lucky case" where I'm already at the launch window would be if the two closest-approach markers were both right there at Ap, where I've got the green arrow pointing in the above picture. As you can see, I'm not so lucky here. Well... look at where the two markers are (red arrows). See that at closest approach, Duna is ahead of where my ship will be, by quite a bit-- looks like just under 90 degrees. So... that means I need to catch up to Duna some more (by close to 90 degrees), before I launch. That tells me roughly how far away from the launch window I am, at least in terms of the relative angle of Earth and Duna. So... at this point, what I'd do is warp ahead by quite a bit, then repeat the above process. I probably wouldn't go for the gusto and advance Kerbin almost-90-degrees in one whack, just 'coz it would be kind of annoying if I overshot the window. So I'd warp, say, two-thirds of what I think I need to do, then re-do the above process to verify that it's looking good, and kinda work my way in from there. Note that the above description is simplifying things a bit-- for example, it's assuming that you're pretty close to coplanar with the target-- but it works pretty well for most cases. (But honestly, what I'd really do is just go to http://ksp.olex.biz and get the answer from there in a couple of clicks.) I believe the term you're looking for is bi-elliptic transfer.

Whoa. Yeah, that's a problem. If you're already going 1000 m/s when you're only 10 km of altitude, that's way too fast-- your TWR is much, much too high. A more reasonable speed would be less than half of that. 300 m/s or 400 m/s at 10 km is typical. You're wasting gobs and gobs of dV to aerodynamic drag by going too fast when you're still too low in the atmosphere. You're also wasting a lot of dV by carrying way too much engine mass as dead weight. Get rid of a bunch of engines. Your first stage off the pad should be no higher than TWR 2.0 at the absolute most, and subsequent stages should generally start no higher than TWR 1.5 or so. When you reach an altitude of 10 km, you should be going around 300 or 400 m/s, and tipped roughly 45 degrees from the vertical. (Plus or minus a bit, depending on your TWR profile).

I'm confused. According to the problem as you've described it, ...By my count, that's 140 seconds of thrust, all at a TWR well over 2.0. How could you possibly still be less than 10 km after all that?

Moving to Gameplay Questions.

That's what the right-hand picture is for. The place where you put your maneuver node (i.e. for the burn) is at the point labeled "Ship" on the drawing. Rotate the map view so that you're looking straight down at Kerbin's north pole, and adjust it so that the direction Kerbin is orbiting the sun is straight up (i.e. at the 12 o'clock position). Put your maneuver node at the place indicated in the right-hand drawing, and give it enough to match the size of the burn that the tool tells you (likely around 1050 m/s for this, depending on the height of your parking orbit).

I'm going to guess that you're talking about the launch window here, i.e. the part where you wait for days or weeks until the planets line up, and you want to know if you've got that right so you know when to launch. Basically, what you do is, go into map view, rotate it until you're looking straight down at Kerbin's north pole, then zoom out until you can see both Kerbin and Duna in the picture. (It may help to re-center the map view on the sun.) Think of Kerbin and Duna as being two hands on a clock, with the sun at the center of the dial. Rotate it around until Kerbin is at the 3-oclock position when you're looking straight down at the Sun's north pole. Where is Duna? You want Duna to be roughly 44 degrees ahead of Kerbin, per the above picture. In other words, if Kerbin is at the 3 o'clock position, you want Duna to be about halfway between 1 o'clock and 2 o'clock. Basically, positioned as shown in the left-hand picture above. If Duna is not in that spot, then it means you're not in the launch window, so timewarp ahead until it is. Once you get the two planets in the correct position, i.e. so it looks like the left-hand picture above, then it's time for you to launch to LKO and set up your ejection burn. Does this make sense? Specifically, does the part up to this point make sense, or should we talk about it some more? if you've got this part down and need advice about the launch-to-orbit-and-set-up-ejection part, let us know? You do sound frustrated, which is totally understandable because this stuff is complicated and we've all felt frustrated with it at some point. You have plenty of company, including Randall Munro. (That particular strip, by the way, was the one that finally convinced me to try playing KSP...) You don't sound even a little bit stupid, because this is literal rocket science and you're just working through the same stuff that we all had to at one point or another. Stay the course, you're doing fine. Yeah, that part is because when you eject from Kerbin, the escape burn is only slightly more than escape velocity. This means that after you do your burn, your path will curve a lot (from Kerbin's gravity) before you leave Kerbin's SOI. You need your ejection from Kerbin to be moving in the "Kerbin prograde" direction (i.e. same direction Kerbin is going) at the point that you leave the SOI. So you need to do your burn while you're still kinda on Kerbin's "backside" to account for that. Basically, "trust the tool"-- try doing it just as the tool shows, and when you set up your ejection burn, then it'll make more visual sense to you.

Does this help? This is not exactly an in-game image... but it's basically the same thing you'd see in-game if you went into map view and adjusted the camera so that it's l ooking down on Kerbin's north pole. This image is taken from my own personal favorite transfer tool, http://ksp.olex.biz. I like it precisely because it's not fancy. It's simple to use and presents these easy-to-understand diagrams as the output. To use it, pick your departure body from a drop-down (Kerbin in this case) pick your destination body from a drop-down (Duna in this case) fill in a little text box to tell it the height of your parking orbit around your departure body (e.g. "100 km" or whatever) It then will tell you three very important things: How the planets should line up when you depart (the left image above) The size of your ejection burn (in text off to the side, not shown above) The direction from which you eject from the origin planet (the right image shown above). So in your case, what you'd do would be to first timewarp until Duna and Kerbin are in the positions shown above. Then get to LKO. Then use the tool to see the size and direction of your burn. You'd plop down a maneuver node at the location designated by "Ship" on the right-hand image above, and give it an amount of burn equal to what the tool tells you. That right there should give you pretty darn close to a Duna encounter. You can then zoom out to the solar system view, and should either have a Duna intercept already, or else some closest-approach markers that are pretty close in the ballpark. At that point you can either do some fine-tuning of the ejection burn to get your intercept before you do the burn, or else you can just go ahead and do the burn and then do some fine tuning later on with a second burn after you've left Kerbin's SOI. The second burn will likely be pretty small.

I do basically this: My surface "base" is basically just a flag that I plant to mark the location of nice high ore concentration. I have an orbit-capable ship that has drills, ISRU, tiny ore tanks, and big fuel tanks. It descends to the surface, lands next to the flag, and mines/refines until it's full of fuel. Then it launches itself back to orbit where it can dock with an orbital fuel depot or whatever. Simple and easy. Another approach that I've occasionally done, where I do have an established surface base, is to use Kerbal Attachment System (KAS). That mod has "connector port" parts that are small and easy to mount radially on pretty much anything. A kerbal on EVA can connect a pipe between any two connector ports, as long as they're within a couple of dozen meters of each other. Go to port 1, click, choose "connect", go to port 2, complete the connection. So when I'm using KAS, I can have an orbital fuel shuttle that flies down to the surface and lands next to my base, then an EVA kerbal hooks up a pipe (very easy to do) and transfers the fuel across, then disconnect the pipe.

No, not in this mod.

Some content has been removed and/or redacted due to people making personal remarks, which is never appropriate (see forum rule 2.2.d). Folks, let's please remember that we're all pals here and that the purpose of the forum is for players to help each other. Which is what's going on in this thread: someone has a gameplay question, and other people who are trying to help are offering suggestions. Whether you find someone else's comments helpful or not, it's never appropriate to get angry to the point of making personal remarks. Keep it civil, please. Thank you for your understanding.

Various content has been redacted, either due to personal/confrontational remarks (forum rule 2.2.d) or to adjust links/quotes to content elsewhere that has been removed. Let's keep things friendly and respectful, please. Thank you for your understanding.

A lot of content has been removed, due to off-topic comments completely derailing the thread (forum rule 2.2.o) to pester a mod author about how they write the mod (rule 2.2.p). Folks, please remember that mod authors do not owe you anything. These are people who put in lots of hard work to give you shiny toys, for free, asking nothing in return. You owe them a debt of gratitude, if you choose to use the toys they give you; but they don't owe you anything. At all. Even one tiny little bit. Therefore, if for some reason you think that the shiny free toys they're giving you aren't shiny enough for your tastes... well, that's your problem, not theirs. If you don't like it, don't use it. It is highly inappropriate to complain that they're doing it wrong, or to argue about your personal philosophy of modding. It's not your mod, so it's not your place to criticize. It's also off-topic: the many users of this mod come to this thread because they're interested in this mod, not because they want to wade through pages of ranting about how you think modders should conduct themselves. That doesn't mean you can't make friendly suggestions-- lots of mod authors love to hear from their users, and feedback can be very valuable. But please, be polite about it. Suggestions are okay, demands are not. And the mod author is, of course, completely free to say "no"-- with or without giving a reason-- and if they do, then it's inappropriate to argue with them. You politely suggested, they politely declined, done. As a final note: If you see someone whom you believe is behaving inappropriately, then by all means, please file a report (with an explanatory note) and the moderator team will have a look at it. Please, however, do not make a public post requesting the moderators take some sort of action. This is called "backseat moderating" and is against the rules (specifically, rule 3.2). Thank you for your understanding.

Thank you, the pics are really helpful! So, verbose thoughts below, but they boil down to: I think your TWR in the early part of the ascent is way too high You may want to look at the aerodynamics of those clipped engines at the bottom of the radial boosters What does your ascent profile look like? First... does this craft really have a TWR of 2.47 while sitting on the launchpad? That strikes me as being way too high. Having a TWR higher than 2 likely means that you're wasting too much of your dV fighting aerodynamic drag. It also means you're lugging a huge amount of dead weight with all the engines you need to give you that high value. Typical launchpad TWR for most players tend to range from around 1.3 up to 2.0 depending on one's design preferences. Not only do you launch off the pad with that sky-high TWR, but it looks as though your first several stages also have extremely high TWR values. Same concerns with aerodynamic drag and wasting dV on engine dead weight. So, my first suggestion would be to get rid of a bunch of engines and lower your TWR values. How low you go is up to you, but I'd strongly suggest that: your TWR on the launchpad should be no higher than 2.0 each successive stage should have a lower TWR than the one preceding To take my own play style as an example: my typical rockets (both large and small) are usually about 3 stages to orbit. The first stage is always exactly TWR 2.0 (I like to keep it consistent to make it easy to nail the gravity curve accurately). Second stage is usually around TWR 1.0 or slightly above when it kicks in (by which time the rocket is already at a 45 degree angle), and third stage is generally fairly low, like TWR 0.5. That's just me, of course-- nothing says you need to follow a similar approach, yourself. It's worth noting, though, that my approach is on the high side of what most people go for, in terms of TWR. Also... it was hard for me to tell exactly what you've got going on with those engines on the radial boosters. Are those... multiple engines all clipped together with a thrust plate? What kind of engines are those? Not totally sure how much I'd trust the aerodynamics on those-- the game can be odd when clipping things like that. Maybe it's okay, but it may be possible that they're generating a lot more drag than you think. Have you looked at the aerodynamic overlay (F12) to see how they're doing during the draggy part of ascent? Finally, could you describe your ascent profile? For example: When you reach 10 km altitude, how fast are you going and what angle from the vertical are you? When you hit a 45 degree angle from vertical, how fast are you going and what altitude are you?

Moving to Gameplay Questions. As others have mentioned, every antenna has a rating. The ratings are in meters, but they usually leave the "m" off. So, a 100G antenna is rated for 100Gm range when talking to an antenna of the same power as itself. The stock antennas' powers are listed here: https://wiki.kerbalspaceprogram.com/wiki/CommNet The most powerful stock antennas in the game are the Communotron 88-88 (direct) and RA-100 (relay). Each of those antennas is 100G. However, it's important to understand that most antennas do not stack linearly. If you need a combined rating of 900G, then using nine 100G antennas would not be enough. You'd need 19 of the 100G antennas on the craft. (There are mods that have more powerful antennas, but 100G is as high as the stock antennas go.)

Moving to Fan Works.

Well, "collect all" is already handled by the optional config file Collect_Science_in_Custom08.cfg, so you can copy that into your install for that-- this works for the science box and the upper-tier probe cores. As for collecting/discarding... I'm disinclined to add it to the mod, since I myself don't want that on my ships. (For example, if I did that, then hitting the associated action key would cause every science instrument on the ship to take a reading, even if it doesn't actually have anything to collect. For me, that would be an incredible hassle and annoyance.) However, if you want to create your own config file to do that, it shouldn't be hard. Copy the sample config file I linked above Replace "ModuleScienceContainer" with "ModuleScienceExperiment" Update the description appropriately Change moduleSource from ModuleScienceContainer to ModuleScienceExperiment Change actionGuiName to the GUI name of the action you want to be triggered (whatever it is for the experiment) Set defaultActionGroup to whichever one you want I note that not every science experiment has the same GUI name for its action, though, so you might want to have separate PART declarations for the different experiments, rather than a single wildcard to catch them all. (Hmmm. That actually raises an interesting point. Would be a nice feature addition to the mod to allow specifying the "invariant name" of the action rather than the GUI name. With such a feature, you could have a wildcard that would match all science experiments... and it would also make the mod more robust at dealing with different localized versions. The only reason it's not like that already is that this is a mod I wrote quite some time ago, before KSP had localized versions. I shall have to think on this.)

I've been looking at this: https://kopernicus.github.io/wiki/main/Atmosphere.html https://kopernicus.github.io/wiki/main/Atmosphere/AtmosphereFromGround.html ...which says a bunch of stuff, but none of the things it says seem to help me make anything happen. The descriptions are cryptic enough that all I can do is trial-and-error tinkering, none of which seems to accomplish anything. All of the examples I've tried seem to do nothing. For example, I have a vague memory of Tekto from OPM having an interesting-colored sky... but when I copy the lightColor from there into my planet, then nothing happens. Would really help to have a working example to go from. Nothing I've done seems to affect the sky color at all.

Apologies if I'm missing something obvious, but I'm having a dickens of a time trying to figure out how to set up what the sky looks like on a world with an atmosphere. i.e. what color is the sky, etc. I've found various cryptic references to a "lightColor" field and an "AtmosphereFromGround" subnode of Atmosphere, but I've tried tinkering with those and can't tell that either one of them does anything. For example, if I want a world to have a blue sky like Kerbin's, say... how would I do that? Everything I do, my sky tends to be flat black and I haven't been able to find any way around that. None of the documentation or tutorials I've found seem to address that. Does anyone have any suggestions?

Moving to Gameplay Questions.

Well, I'm slightly fuzzy on the exact technical details, since I've never been a ReStock user myself, and this patch was kindly supplied (and updated) by others. But my understanding is basically this: ReStock is supplying new models for a huge swath of the existing stock parts. That's a pretty big memory load, and the default way that would work with most KSP mods is that the original models would also get loaded by the game, even if they're not being used. So, apparently, to conserve memory, ReStock does a thing where it has special code to prevent the game from loading models other than its own. Which can cause problems for 3rd party mods (such as MissingHistory) that rely on those stock models. The ReStock people have provided a mechanism to deal with that-- a "whitelist" file that, if present, basically tells ReStock "hey, please don't prevent this part's stock model from getting loaded". So that's basically all it is, as far as I know. Nope. MissingHistory doesn't remove anything.

I assume so, yes. It was an issue with the shaders on the part, which are now fixed. There's nothing about the Stowaway model that's particularly tied to a KSP version, so if you're running an older version of KSP and want the Stowaway in it, I expect you ought to be able to just copy the model & config from the latest MissingHistory build and it should "just work"-- it ought to be backwards compatible. I say "ought to" because I haven't actually tested that myself. But I'd be astonished if it didn't work.

Moving to Gameplay Questions.

It's totally doable in orbit, and in fact has a different animation than on the surface. But you can't be hanging onto a ladder while doing it. You have to let go of the ship.

@The Blazer Another option to consider, if you happen to have Breaking Ground, would be to use a rotorcraft. Electric-powered propeller aircraft are doable on Duna. Just, make sure you have a lot of wing.

Thanks, those are helpful shots! Yeah, the biggest problem is that your CoM is near the rear. That enormous, lightweight fuselage poking out in front of the CoM is your problem-- it's gonna be very hard to keep that pointing forward. Anything you can do to put something heavy farther forward, to move the CoM nearer the front, would help. The real problem, I expect, is the engine. You've got a big heavy engine in the rear-- and if the rest of the plane is basically a bunch of empty fuel tanks and empty cargo bays, then there's just not much that has significant weight to it. One design strategy that some folks use to combat the "heavy engine in the rear" problem is to build a more Skylon-like design. Instead of having a big heavy engine on the rear of the fuselage, have a pair of engines mounted amidships, on the left and right sides of the fuselage. Since this brings the heavy engine mass forwards, it really shifts the CoM and can help with aerodynamic stability. Yes, it can be awkward to design around depending on how the rest of the craft is built-- not saying you have to do that, just mentioning that it's one technique that works well for a lot of folks. Some other suggestions/observations: Canards. You may wish to consider a pair of canards, mounted way up at the front of the ship, as an assist for maintaining pitch. The effectiveness of a control surface depends on its lever arm, and with your CoM way in the back of the craft, it means that any control surfaces back there are fairly close to the CoM and therefore can't exert much control authority. Some little canards way up at the front, on the other hand, are really far from the CoM and therefore have a lot of leverage to work with. So they may come in handy. If you add them, I'd suggest adjusting their actuators so that they're pitch-only and won't attempt to help you with roll or yaw. Vertical stabilizer. As far as I can tell, you don't really have any vertical stabilizer at all-- meaning you don't have any control surfaces to provide yaw stability. It's therefore not surprising that you're encountering a flat spin. I'd strongly suggest adding a vertical stabilizer. Make it as far back as possible, and also try not to stick up above the central axis of the ship too much. When you add it, make sure to adjust the actuators so that it assists with yaw only. In particular, make sure that it has roll authority turned off (it's on by default, so you need to manually disable that in the editor). Reason: if you leave roll turned on, it'll try to activate for roll assistance and will end up fighting your ailerons for control and make the craft less stable.