Zhetaan

@abickocz: There are a lot of suggestions about fixing the drag issues on your rocket, and you should consider that advice, but your problem is not really a draggy rocket; you don't have enough fuel for the mission and no amount of aerodynamic redesign can fix that. Your atmospheric delta-V for the entire rocket is only about 4300 m/s. If we assume you're using the Terrier (stage 2) exclusively in space, then you have roughly 3800 m/s (atmospheric) to use to get to orbit. You need about 3500 m/s to get to orbit, so that should happen fairly reliably, except that this is where all the extra drag becomes a problem. It's probably costing you more to make orbit and it definitely is not stable, but you are getting there, so let's keep looking for other problems. Let's assume that you have only the 2222 m/s (vacuum delta-V now) in the Terrier for your Mun mission: You need 1200 to get from low Kerbin orbit to low Mun orbit. Add the 600 or so that you need to land, 600 more to take off, and 300 or so to return from Mun orbit to Kerbin atmosphere, and that requires 2700 m/s; you simply do not have enough rocket to finish the mission with your current design. Specifically, you have enough to land on the Mun but not take off again, which is exactly your problem. Therefore, you need to either: Add more fuel and engine to your rocket. Remove payload. I'd consider switching the drop tanks from FL-T200 to FL-T400 tanks (you have enough thrust-to-weight to do this without too much trouble), but you're probably best off by adding a dedicated transfer stage in between the orbital launcher and the lander. If you can get the lander to Mun orbit fully fuelled, then it can both land and get back to Kerbin. But you have to deliver it to the Mun with full tanks.

Event Horizon, but in fairness, I didn't like it very much. I've seen plenty of 'some things were not meant to be known' stories but wasn't really enthused about a picture that took that to the campy extreme of a literal 'have spaceship, go to hell' theme. I get that that was part of the point (made painfully obvious by the picture's use of the 'saying it in Latin makes it scary' trope), but it's really not my cup of tea. I prefer flinging space rocks in KSP. Anyway, I'd suggest being very careful about your tug's engine placement. Tugs are far and away better than pushers but they have a weakness: if your engine exhaust impinges on the asteroid, you get zero thrust. For a regular vessel, that just explodes the impinged part, but asteroids have an extremely high thermal capacity. Most tugs I've seen either took the cosine losses and angled the engines or else built the Klaw onto the end of a long boom.

My probe to Duna was called Trail Locator and its little rover was called Honest Wanderer. That kind of tongue-in-very-cheeky allusion follows most of my conventions; when I found out that tourists could not leave the ship, that spawned a whole line of craft named some version of Tourist Trap. My asteroid mining vessels are all called something along the lines of Rocket with Real Rocks in It--especially after I got Asteroid Recycling Technologies, which has a 'Mass Driver' engine that uses a 'Rock' resource. If I send a crew out on a training mission to get up to three stars before I ship them all out to points unknown, then that's called Magic School Bus because why the heck not? If I could get a Frizzle Kerman to be the pilot, then that's the only thing I'd have her do. When my wife sent up a fuel tanker in her game and called it Thomas, I made a station tug and called it Theodore because I was not about to be outdone by a children's television programme. My first mission to Moho was called Hermetic (for Hermes, the Greek version of Mercury, the real version of Moho) and the flag for it featured a seal in a space suit. My first 'escape the sun' craft looked like a big noodle (and moved like one, too--this was version 1.0), so I called it Ramen as a double allusion to both the noodle and the Clarke story about an interstellar visitor.

This video is old enough to be an archaeological study, but it is still the best docking tutorial out there. That's because when this was made, there simply weren't any good docking aids in KSP yet (not only was there no prograde/retrograde hold, there weren't any normal/antinormal navball markers, either), so if you wanted to dock, you had to do it with a minimum of help. What this means for the current player is that if you can learn to dock this way, then it will never trouble you again.

That is no longer entirely true. Originally, the lab would convert the experiment into data but would return the experiment; you could grab a surface sample from somewhere, convert it into data, and the lab would both process data for additional science and give your sample back. Now, converting an experiment into data in the lab consumes the experiment; if you want to run an experiment in multiple labs, you need multiple copies of the experiment, plus an extra if you want to return or transmit one of them to Kerbin.

I know two relatively easy ways around this that do not require a mission restart. I'm going to assume that your lander doesn't have a correctly-oriented control point (the solution to that is simply to select it as the control point, as @Cpt Kerbalkrunch said) and that you are stuck with your engine orientation. First, you would need to remember the position of your manoeuvre marker on the navball and figure out the position that is the exact opposite of that; this isn't so difficult if you orient yourself to the marker and then use yaw to spin about exactly 180 degrees (you have a heading readout on the navball, so getting that exact isn't too difficult). By changing only yaw, you don't need to correct your pitch or roll. Second, instead of trying to find or make an anti-manoeuvre node, you can just plan an anti-manoeuvre. What I mean by this is to take your planned burn (this would work best with uncomplicated purely-prograde or purely-retrograde burns) and note the required delta-V (this is the number above and to the right of the navball when you set up a burn), then cancel that burn and set up one that is the opposite of that but for the same amount of delta-V. For example, let's say you want to break Minmus orbit and return to Kerbin. That would usually be a prograde burn from Minmus for some mid-100's value of dV--let's say you set up the burn and it costs exactly 200 dV to get a good Kerbin return. Now grab the retrograde handle and pull it back until the dV readout goes to zero and builds up again to 200 dV. Set the autopilot to node hold and execute your burn. You may need to switch from node hold to stability assist before the burn; I do not know whether such a node is stable. The plan in map view will look as though you plan to drop straight into Minmus and the required dV for the burn will climb to 400 (the correct cut-off will always be double the needed dV), but since your engines are facing the wrong way, you actually break orbit for that good Kerbin return. I'll grant you that neither of these help very much with a landing; for that, you're either going to need to try again or else see whether you can fly-by-luck. Some can--I remember a YouTube video of a Tylo lander that sputtered out of fuel at about ten metres above the surface completely by accident. Minmus is a lot easier because the weak gravity gives you time to arrest your fall, flip your lander, and contact the ground gently enough that you don't break anything important. But you'll need to do some fairly fancy piloting to pull it off.

It reads as though you have a few problems with your rovers. First, don't set your navigation to target. The autopilot assumes that you're in space and have three dimensions of rotation; it doesn't know that you can't travel through the centre of Minmus to get to a destination on the other side. Second, the navball is going to assume the same orientation as the current control point: this means that if you, for example, have a command pod sitting upright on the ground, then the navball will be oriented so that up is also forwards. This is fine for flying but does not work for overland travel; you'll need either to use creative rover design or else to place a small docking port or some such on the front of the rover so that you can right-click it and select the option 'Control from here', which will reorient the navball so that your heading is forwards. On rockets, you want the navball when you first begin to have only blue visible; on rovers, you want the navball always to have blue on top and brown on the bottom (that's the function of those colours; they serve as an artificial horizon). Third and last, you should be certain to deactivate reaction wheels in your rover or else to bind separate rover wheel controls from the attitude controls; the default has W serve as forwards but it also tries to pitch your rover over its nose. D by the same effect is both 'turn right' for the rover wheels and 'roll right' for the reaction wheels. I prefer to bind my keypad for rover wheels; 8-4-6-2 serve the same purpose as W-A-S-D but without involving reaction wheels at all; I also use 5 as an alternate brake key. As far as rover design, the main reason to add more wheels is to reduce the load on them; in some cases, more wheels add to the trouble without adding much benefit. It depends on your design. Honestly, if you have enough stuff on your rover that it breaks wheels, you're more likely overloading the design than anything else. Navigation ought not to be so difficult; set your destination as the target and it should give you a marker--especially if you're only 5 km away. I suspect that the reason you had so much trouble getting there was because of other issues I pointed out above, such as the reaction-wheel/rover-wheel dual binding.

@ezequielandrush: It may be possible to queue a science transmission with a delay. If I recall it correctly, you have to right-click on the antenna that will transmit and tell it to send the data rather than work through the usual science dialogue box. If you add a delay through the flight computer so that the transmission begins at the best time (which I assume is probe loss-of-signal minus however long it takes to transmit minus some safety margin), then sending the transmit command in advance puts the instruction in the computer on a timer. There's no additional delay once the timer runs out. However, I must admit that I am unsure of that one because I have never used it; my probes have always either included a science return capsule or were otherwise less than totally suicidal, so there was no urgency behind the transmission and I therefore always used the science dialogue. I have one other idea that uses only the RemoteTech architecture: make a craft with a 2.5m probe core and six kerbals, and send it to the same planet. If it is in orbit and connected to the probe, then the signal delay will be reduced to that of the link between the remote command vessel and the probe. Be mindful of the link back to Kerbin, though; the command vessel can reduce signal delay but it cannot store science for relay to Kerbin.

Without seeing the burn itself, I'll say that you most likely burned at the wrong time, so part of your prograde with respect to the Mun became radial-out with respect to Kerbin. It's not a major problem; you have enough delta-V to correct easily your periapsis. The conventional wisdom that tells you to use equatorial orbits for Mun landings and such exists because it simplifies returns: if you're in an equatorial Mun orbit, then burning prograde at the 'right time' ends up moving you retrograde with respect to Kerbin, and so you can return with only one burn. When you are in an inclined orbit, the situation gets trickier, because the 'right time' doesn't occur every orbit of your spacecraft, but rather occurs only twice per Mun orbit of Kerbin at the points where your axis of ascending/descending nodes lines up with the Mun's prograde/retrograde. If you can't wait for that, then you can burn to zero inclination and then leave at your pleasure, but it costs fuel. On the other hand, if you're only slightly inclined, then you can burn for return as you would from an equatorial orbit without caring for the misalignment, but your slight misalignment will add up to a slight deviation from retrograde when you enter Kerbin's sphere of influence.

@KSK, thanks for the idea. And remember, kids: Before they send us To a grave, Evil Kerbs use Kerba Shave.

Occam's razor says that the simplest explanation is probably the best (though it does not point out that by that logic, Occam's razor is probably a razor used by someone named Occam), and combined with Chekov's gun, it says that Val or Dilsby have an honourable duel up one of their sleeves. As for how to get out of that, I am waiting with bated breath. Maybe razor can beat gun in a duel?

I usually go for an equatorial (and equilateral) triangle of satellites set at 777 km altitude, but that's because I use RemoteTech and that altitude gives separation at a good middle of the range for two satellites using Communotron-16s. I don't bother with a set that gives polar coverage because a) I'm not that OCD of a completionist, and b) I also use SCANSat and that guarantees at least three polar-orbiting, relay-capable satellites anyway. If I have a probe that needs to do something over the north pole and there's no coverage, then by the next orbit, there will be. If I go high enough, I get coverage anyway because there's an altitude above which the equatorial satellites are visible from the poles. I don't know what the range limits are for CommNet in stock KSP, so you'll have to figure it out. Remember that for a constellation, there is both a maximum limit set by the antenna range (the sats in the constellation need to be able to talk to one another) and there is a minimum limit set by the planet (three sats at 70 km will not be able to see one another; the planet is in the way). You may wish to avail yourself of the Visual RemoteTech Planner to find the best altitudes (it lets you add custom antenna configurations), but if you want to do it the long way: Remember, that is all preliminary and meant to get the right altitude at which to place your constellation. Once you have that altitude, it is actually sufficient to get only approximately close--the trick to orbital synchronicity is not orbital altitude, but orbital period. So long as the orbital periods are identical, the satellites won't drift. The problem is that KSP uses floating-point maths, and that leads it to make rounding errors that build up over time to alter the orbital period and thus the spacing. My solution is to get the satellites to agree on an orbital period, hopefully within a tenth of a second (this requires Kerbal Engineer Redux or equivalent, thrust limiters, and tiny engines), switch views to something else, set the correct values in the persistence, and then never focus on the satellites again so as to keep them on-rails and immune to orbital recalculation. However, for an evenly-spaced constellation, you'll need to do a couple of additional things: You've picked a good test of both piloting and navigational skill, but make no mistake: KSP has some very specific limitations to what it can do because of the nature of the simulation and the amount of computing power it has available. The best overall solution is to get your constellation in the sky so you don't have to worry about controlling probes, and once you have a constellation that will stay reasonably functional for a year or so, simply make certain that you put a relay on everything else that you put in the sky. Eventually, you'll have enough of them that it won't matter what the spacing is.

It is true for some stock bodies and not others. The Minmus flats biomes are all the lowest point of Minmus's surface and all set at datum. The Mun's lowest point is about 250 m below datum. Moho's lowest point is--or was at one point--30 m above datum, and I don't know why. I do know that all stock bodies with oceans have the datum set to the ocean surface, and the ocean is present everywhere that the terrain dips below datum, but that only accounts for three bodies.

@DrPastah: No, there's no preference for which side of the link gets the stronger dish: the range in root mode depends only on the antenna combination, not the order. However, the solution is easy: add stronger dishes at Kerbin. You won't even need to re-do your current satellite constellation: just have one new satellite in a large-radius polar orbit (this reduces the chance of occultation) that has a dish powerful enough for Duna and enough antennas to connect to your existing constellation. As to the reason why you cannot connect, the range is not the average or arithmetic mean of the component antennas' ranges; it's the geometric mean. The formula for it is √(r1r2), where the r values are the antenna ranges involved. 90 Mm x 90 Gm gives 8.1 x 1018, and the square root of that is 2.846 Gm. There is also something called a clamping value, which says that an antenna is limited to a hard increase of 100x its base range for omnis and 1000x its base range for dishes, but we're not running up against that. The idea there is that it keeps you from using a DP-10 to communicate from Eeloo just by linking it to a stupidly-overpowered dish at Kerbin. This also means that you will never be able to connect a KR-7 (which, if I have it right, is what you're using at Kerbin) to anything more than 90 Gm away, because 90 Gm is 1000x the KR-7's range. When linked to a sufficiently-powerful dish, they can reach Duna, but the dish you chose to use at Duna is not powerful enough. You'd need something rated to 4.5 Tm or better to connect when Duna is 20 Gm away. The issue is essentially that while Duna has powerful dishes orbiting it, the ones at Kerbin are so weak that they can't transmit a usable signal with enough strength for the Duna dishes to sort from the background noise. In reality, more powerful antennas are perfectly capable of picking out the signal from weaker antennas. For example, sensitive antenna technology is what allows us to continue communicating with the Voyager probes (at least, I'm fairly sure that no one's upgraded Voyagers' radios), but the simplified model used in RemoteTech does not allow for that because it doesn't simulate noise at all. They're working on it for RemoteTech 2.0, but there's nothing like a release date on that yet.

@OhioBob is one of our resident experts on this one (just look at his signature), so treasure that link. You want the vis-viva equation, which is as follows: v2 = μ ( (2/r) - (1/a) ) where: v = orbital velocity μ = the standard gravitational parameter of the primary (that's the mass times the universal gravitational constant, which for Kerbin is 3.5315984×1012 m3/s2) r = the distance between the orbiting object and the primary's centre of mass (in KSP, current altitude plus primary radius, whick for Kerbin is 600 km) a = the semimajor axis of the orbit (in KSP, this is equal to the periapsis plus the apoapsis plus the planetary diameter (for Kerbin, 1200 km) all divided by 2) If you want a circular orbit, then the orbital radius is both r and a, so the equation becomes v2 = μ / r Inclination doesn't matter; the equation relates the gravity and any lateral velocity (I would say horizontal velocity, but the value of horizontal keeps changing when you're in orbit) independently from a 3-d reference frame, which means that the solution can be fully represented in 2-dimensional space. In real life, inclination can matter quite a lot because planets don't distribute the mass evenly and that causes perturbations (see Molniya orbits for an explanation and solution to part of that problem). Keep in mind that the orbital velocity at a given altitude for a circular orbit is going to be different from the orbital velocity for an elliptical or hyperbolic orbit; while the altitude of the craft at that point is the same, the orbital energy is different, and that is reflected in the interplay between potential and kinetic energy that occurs as the object moves between apoapsis and periapsis. Specifying that the velocity is for a circular orbit at that altitude makes computation easier but it doesn't really help when you want to know about the elliptical and hyperbolic orbits that get you there in the first place.

I found two Dres-Jool transfers, but they're terrible; they require 5.5 km/s of dV, take about ten years to complete, and require flyby altitudes of three and four metres in order to get enough of an assist to make it happen. It's possible that better ones exist, but I don't see the point in looking; the problem is that Dres is, as others have said, too small. If Dres only has a few m/s to give to you, then you have to arrive at Dres with the rest, but when you add the timing and conjunction to the problem, the end result is that you spend years on an orbit that reaches out to almost Jool while waiting for an absolutely perfect encounter with Dres. Contrariwise, if you start at Dres, there are a couple of good assists via Jool that get you home. Somewhere in this forum is a post from a person who ended up at Dres with a fuel miscalculation; while the Rocket couldn't get to Kerbin, it could get to Jool, and that was enough. Jool gravity and Kerbin atmosphere took care of the rest.

Three days is an insanely fast transfer. I'm a little curious to know how you're getting such a trajectory if you're burning only 930 m/s in low Kerbin orbit; such a burn should keep you within Kerbin's sphere of influence, if only just. Since it does not, there is something else at work, even if it is only that you are burning far more than 930 m/s without realising it. When you set the node for the Minmus transfer burn, do you do so using only the green prograde/retrograde adjustments, or do you use the magenta normal/antinormal toggles to change your inclination in the same burn? If so, then that could explain why your capture burn is an extra 400 m/s--it can take about that much to change inclination in low Kerbin orbit. You are far better off correcting your inclination in a separate burn, either in low Kerbin orbit or as a mid-course burn where it isn't quite so expensive. Better yet, you can try launching directly into an inclined orbit, but you have to do it at the right time of day.

Ha! I did. I have to say that the coincidence is almost too good to pass up, but pass it up I will.

Yes, well, given that we have a nuclear reactor on board, I would rather not see this end the same way as On the Beach. There is still time, brother.

@Booots is right. You'll find it in GameData/Dangit/Textures as appBtn.png. I can't tell you what the multiplier does; I'll have to go digging for that.

@Fergrim: I'm inclined to go with @Spricigo's answer here. You mentioned that this is at 2.5x scale, so any issues with line-of-sight at ground level would be exacerbated. It's also possible that you didn't scale the ground station location correctly and it is now technically below ground level, which could put it out of sight of everything. Change the ground station height in RemoteTech's default settings file and see whether that helps. I believe the default for a 1x scaled Kerbin is 75, so try 187.5 (or 200 if that doesn't work) and let us know whether that fixes the problem. If that doesn't work, then try rescaling Kerbin back to 1x to see whether it really is a scaling issue. Then try turning off the connection requirement (also in the settings), and if that doesn't work, then try reinstalling the mod. @James Kerman: Only certain types of antenna can 'point', as you put it, but the funny thing about RemoteTech is that if you need to point to Mission Control and are not already pointed to Mission Control, then there is no option to reset the antenna because there's no connection to send the command. Unlike stock, loss of signal means total loss of real-time control (you can pre-program commands using the simple flight computer, but that's it with default settings). However, the dipole antenna (both of them, actually) start out activated, so that cannot be the issue. I don't know whether the challenge appeals to you, but since you haven't used RemoteTech yet, I do encourage you to try it out.

It depends on the choice of Ap, but my back-of-the envelope calculation (ignore Kerbin escape and the initial Oberth effect; just assume you're starting in space at Kerbin's altitude over the sun) gives about 6260 m/s for a Hohmann transfer and about 4310 m/s for a bielliptic for this mission. The bielliptic is split between an initial burn of about 3090 m/s and a second burn of about 1220 m/s. Of course, these numbers are off by a lot because of my initial assumptions, but the relationship between the Hohmann and bielliptic transfers should be apparent.

That's called a bielliptic transfer. When the higher orbit's SMA is greater than ... eleven times, I think ... that of the lower orbit, the bielliptic transfer is cheaper in delta-V than the Hohmann. It requires three burns instead of two for the full transfer (or two instead of one for this sort of fly-by) but the relatively high cost of the initial burn to reach the high Ap is negated by the much cheaper cost to lower the Pe once there. Given that Kerbin orbits at over thirteen Gm and the target Pe was half of a Gm, bielliptic was the way to go--the only real drawbacks to it are that has a minimum limit of effect and that it takes even more time than the Hohmann. @Bill2462: Nice mission! What did you use for a core on the return probe? I take it that you clipped it into the adapter?

When you find yourself putting Kerbals beneath Mk. I Illuminators for dialogue and introducing Jeb's fifth long-lost twin, then you'll know it's gone too tacky and that it's time to wrap up the story. Otherwise, run it until the bolts fall out.

And that's why I use Gyrojets for all of my space-borne boarding actions, even though it's cheating. In other news, welcome back, Kuzzter--now there's something else to be thankful for.