Zhetaan

@FloppyRocket: I'll try to elaborate on some of the things that @5thHorseman didn't have much to tell you: Both. The arrows are correct in that they correctly show that once the aux tank is empty, the engine attached to it will continue to draw fuel from the main tank. However, it does not correctly show that the main engine will also draw from the aux tank. Part of the problem is that the fuel flow has to reconcile multiple tanks with multiple consumers, and there is no straightforward way to show that with one directional arrow. I do not know whether that could be fixed if you placed your main engine the same distance from the root part in terms of the tree structure of the vessel (meaning add a second main fuel tank separated from the first by a crossfeed-enabled decoupler, and put the engine on that), but either way, I find that flow arrows that are inaccurate some of the time are untrustworthy all of the time. The (0) value is the deviation from the game's guessed priority, as @5thHorseman said. The '0' button resets the fuel priority to that guessed value, not zero. In other words, it resets the deviation from the game's guess; it does not set the priority to zero. That's a very good question. I'll ping @bewing; if he doesn't know the answer himself, he probably knows who does. You do not have to have unique priority values. However, all tanks of the same priority will drain evenly, which you may not want. Fuel ducts can override this behaviour. Generally, all tanks in a given contiguous stack (meaning tanks node-attached to other tanks) will have the same priority. Priority changes occur when you insert a decoupler. There are reasons for manually changing the priority of stacked tanks; for example, I frequently set the upper tank to a lower p# value so my stack drains from the bottom up for better handling and mass control. But there's no requirement to do so. I use fuel ducts for asparagus staging because fuel ducts are absolutely one-way; when the aux tanks empty, the aux engines shut down. However, I also use fuel priority without ducts for preferential draining of drop tanks. For example, my early Minmus landers often have radial fuel tanks with landing legs attached, but there's also a central tank with a Spark attached to it. When I run out of fuel in the radial tanks, I stage them away and use what's left to return to Kerbin. Priority settings save parts in this, but the launchers that send those landers to Minmus use ducts. I also use priority without ducts for aeroplanes; one of the main reasons for introducing this drain-evenly fuel system was that it kept people from needing cobwebs of draggy fuel ducts to keep their planes balanced in flight. However, note that they didn't remove ducts from the game when they introduced flow priority. There is still plenty of room for them; use what is most comfortable for you.

That's a valid approach, though personally, I use the number pad for wheel control for rovers. This allows me to leave reaction wheels on for purposes of righting flips and tips, but it also allows me to drive the rover without trying to make it flip, as would happen if I used WASD. That is also a valid approach, but in my experience it causes more trouble than it corrects. For example, a station powered by solar panels is going to have a preferred orientation. Large stations may not be able to turn well, or would tear themselves apart if they tried. If you are docking with something unpowered (such as that solar station that you forgot to return to the correct orientation, or to which you are delivering a battery pack because the demand was greater than the power supply), then it isn't even an option.

Yes. It says in very greyed text in the upper left (directly under the word Kerbal) that it is accurate to KSP version 1.2.1. However, PC has seen no changes in either gravity or aerodynamics since then; the map is still accurate for both PC and console.

That tutorial is ancient. If you'll have a look at the picture of the example rocket, do you see that the parts look odd? That's what KSP looked like at about version 0.15. It's from at least version 0.15 because I can see the Runway in the background. The delta-V map is much changed since then: for example, there are other planets now. Enjoy your glimpse of history, but don't rely on the numbers. I note that the most recent edit is January 2018, but I don't know why that edit (or any other) didn't update the delta-V values. In current KSP, you can achieve orbit typically with 3,500 m/s of delta-V, assuming decent rocket design and piloting. It is going towards space, isn't it? Seriously, you're not going to hit terminal velocity unless you have insane thrusts. If you had a heating problem causing your rocket to do its best impression of a fireball, then I would say that you have issues with the design that arbitrarily increase drag, or else you're doing something to keep your rocket in the lower atmosphere for too long. However, you are getting to orbit with a lot of fuel to spare, and those other issues would stop you from doing that unless you had a seriously over-engineered rocket. Fire is not, itself, a problem: rockets are made of fire. If you perform your post-launch pitch manoeuvre (this is what begins the gravity turn) correctly, then there is no reason not to fly at full throttle. If you design the rocket particularly well, then you can leave your hands off the controls after the pitch and it'll fly itself to near-circular orbit with no further input from you.

@OhioBob is one of our resident maths wizards; there's not much for me to add here, except to say that it absolutely would have such a large impact on your delta-V. Add to that that you get out of the thickest part of the atmosphere so quickly that even the Terrier, which has a sea-level Isp of 85 seconds, is up to 99% of its vacuum thrust at a little over 10 km altitude, and you're underestimating your calculations severely all throughout. Overspeed is an issue in extremely thick atmospheres. That applies to lower Eve, lower Jool, and pre-v1.0 Kerbin. Post-v1.0 (and you are v1.2), the aerodynamics are somewhat better, and the gravity losses are the most important losses to attend. That means that most likely, throttling down has cost you delta-V because you are allowing gravity (and its constant acceleration) to work on your vessel for a longer period of time. It can be done, but you're likely better off estimating based on observed figures at various altitudes. Not the way you're calculating it. The Swivel has ten seconds more vacuum Isp than the Reliant, but its sea-level Isp is fifteen seconds lower. You gain a tiny amount of efficiency that way from using just the Reliants. Also, since the Swivel is not taking fuel from the radial tanks if it isn't burning, your Reliants get more burn time at that higher efficiency. If you're calculating with only the sea-level Isp, then all of those little bits of savings add to quite a lot. Of course, the Reliants alone won't muster the same thrust as the Reliants plus Swivel, so you'll spend more time in the lower atmosphere combating drag and need a longer run up to orbital speeds, which also increases gravity losses. Take the fact that you're questioning your results in this case as evidence that you need better assumptions: to wit, sea-level Isp is really only valid at sea level. I will add that there are times when choosing not to fire some engines makes sense. For an obvious example, imagine that your rocket uses strap-on Reliant boosters to get a central Terrier-driven core to orbit. Running the Terrier along with the Reliants at launch in an asparagus-style staging sequence is just a waste of fuel that the Reliants, despite their vacuum inefficiency, can put to better use. On the other hand, imagine that you make orbit with a significant amount of fuel left in the boosters. It makes sense in that case to deactivate the Reliants and use the boosters as heavier-than-normal fuel tanks because the Terrier is so much better in Vacuum than the Reliant. Yes, the dead engines are parasitic mass, but the fuel is free: when you decouple the empty boosters, you still have a fully-fuelled rocket. In truth, you ought to have reduced the fuel load and added more payload, but if you're already in orbit with no reverts, you may as well use what you have. But that's mainly a problem when you're using engines with radically different performance values in the ambient environment. Swivels are essentially Reliants with gimbals; you should nearly always get better numbers when you use them together.

I don't know which delta-V map you're using, but 8,000 m/s is the correct figure. It's possible that you're getting 6,000 from a map that assumes you're taking off from a mountain. SRBs are not a good choice. The Thumper and the Kickback will both light at Eve sea level but they won't produce very much useful thrust. Parachutes work exceptionally well on Eve; you actually don't need very many compared to what you would want on Kerbin. However, keeping the rocket upright is more a function of two things: the arrangement of the parachutes with respect to your centre of mass and the landing zone. The first is not an issue if you build symmetrically, and the second is not an issue if you land somewhere flat and with negligible horizontal velocity. Assuming you can either control your descent speed or shield well, there are other tricks, too. For example, you can have splayed landing 'legs' made of I-beams with landing gear on the ends that will give you a very broad base. Mount the legs on decouplers and you don't have to take them back up. Think of them as a not-so-big, not-so-fancy rocket holder and you'll be in good stead. Or you could try the more traditional approach of having your landing gear on out-rider fuel tanks. You can use girder segments turned horizontally to make impromptu landing skids. Of course, for any of these, you'll need to be careful that your rocket doesn't flip on descent, but in fairness, that's an issue at any time that you make a landing on an atmospheric body with more than a pod.

@Buck Gordon: If it's a pilot error, that's okay: that's the easiest thing to fix. First, stay away from docking mode. It's honestly not necessary and it confuses the controls. Second, turn on fine controls; you can do this with the caps-lock key. You'll know you're in fine-control mode when the pitch, yaw, and roll indicators turn turquoise instead of orange. Fine-control mode limits the thrust from RCS and the rotation authority from reaction wheels so that you get about ten percent of full power. More importantly, it also activates a fractional control to balance the torque of the vessel. This means that if you try to translate in one direction but have an unbalanced craft, the RCS thrusters will thrust to try to keep it pointed correctly. If you're using a tug, then you need this. Third, learn the translational controls. Rotational controls, WASDQE, you already know--or else you wouldn't have gotten this far. The translational controls are IJKLHN, where I and K move you up and down, J and L move you left and right, and H and N move you forwards and backwards, all without rotation, which is what you need to get alignment. Imagine carrying a full coffee cup from place to place; you don't want to turn it over and spill coffee, so you keep it upright while you move it from side to side or up and down. That's translational control. Fourth, don't forget SAS. There are times to use it and times that it gets in the way, but either way, don't ignore it. Fifth, be certain that you set the desired docking port as the target (you can do this by right-clicking on it and selecting Set as Target) and that you also set the port on your vessel (the port doing the docking) as the control point (you can do this by right-clicking on it and selecting Control from Here). Failure to do this will cause everything to be misaligned. Docking Port Alignment Indicator essentially tells you three useful things in its UI. First, it tells you your orientation (that's the orange marker) relative to the docking plane. The important thing here is that the docking plane is not the same as the direction of the other docking port. Instead, if you imagine the docking port's face as defining a plane, then this marker is telling you whether your port's plane and the target port's plane are parallel. Put another way, say that you face the sun and I face away from it. We may not be facing one another or even near one another, but we have parallel 'docking planes' in this respect. This is important because once you line up the orange marker to the cross-hairs (these are the white lines in the indicator, not the green lines), then you are rotated correctly and should only need to use the translational controls (in fine control mode) to align your ports. This may require dodging the station, so I recommend that you at least get to the correct side before aligning for docking. Also, don't forget the rotational indicator at the top, if you need it. Second, it tells you the location of the target port. That's what the green lines represent. If you are aligned to the docking plane and moving to align with the target port, then the lines will move. Getting them aligned with the cross-hairs (and the orange marker) means getting the two ports to face one another. Third, it tells you the direction your vessel is moving relative to the target. This is the yellow marker. Once you rotate to align the orange marker with the cross-hairs, you want to give enough forward thrust (using the H key, not the throttle) to make the yellow marker look like a prograde marker (, but yellow). However, you don't want a lot of forward thrust: you need to move your vessel so that the two ports not only face in the correct direction, but also face one another, and if you're closing too quickly, you won't have time to do that. Give it, at most, a tenth of a metre per second until you accustom yourself to it. To accomplish the alignment, consider where the green lines cross in terms of quadrants on the display. Then move the yellow marker (with the translational controls) into that quadrant. What that means is that if, for example, the orange marker is on the cross-hairs but the green lines cross in the upper right, then you want the yellow marker also to be in the upper right. Use IJKL as necessary to put it there. What this accomplishes is to send your vessel moving in the direction of the target port. I prefer to put the yellow marker about halfway to the green lines, and as the green lines move closer to the centre, I move the yellow marker to keep it at the halfway point until everything converges at the cross-hairs. Once everything is aligned, I use H (and if necessary, N) to close and dock. Good luck!

Oh, Jim, Jim, Jim ... *tsk, tsk* My friend, you simply had to know what you were asking for when you said that .... Anyway, I don't have anything to say as a positive that hasn't been said already, except to add that it is very nice to see a completed story, given how unfortunately rare that is here. However, I do have to offer a bit of criticism: Where's the question mark? How can you have an homage to 1950's and 1960's campy sci-fi serials if The End doesn't come with an ellipsis and a question mark?!

Actually, no. You can EVA and take the data from the instrument. The data can be stored on a Kerbal, in any crewable pod, or in a special science box (it shows up under the Science tab in the editor). I once tried a trick where I sent a probe with a full science suite to--I don't remember where, but the probe landed, took a lot of experimental data, and then had the science box plus necessary hardware only return to Kerbin as a sort of rocket courier for a fraction of the mass and cost. It also left the experiments in the biome so that when I did eventually send a crewed mission, I could reset and reuse the same parts; I just loaded the probe onto a rover and had a fine time. Of course, if you do jettison the thermometer, then you won't be able to get the temperature data from any new Kerbin biomes when you return. I generally prefer to keep the small experiments; they're very expensive but also very light, so I try to recoup the cost when I can. Consider mounting it on the pod next to the hatch (don't obstruct the hatch!); it can't cause drag if it's in a fairing on the way up, and it won't harm anything on the way down. If you could land on Minmus and return with 1,000 m/s to spare, then you are close, but should probably add another fuel tank for a Mun landing. The difference in required delta-V is about 400 - 500 m/s one way, so that rocket doesn't have much safety margin.

Right-click on the part (or if you're on a console, use whatever button opens the context menu) and you should see the autostrut options on the menu that opens. Click the blue button next to anything that says 'Autostrut: Root' until it says 'Off' (or 'Grandparent' as @Dafni says). You may have to do this for every part, though you can usually get a hint of which part is the problem if you watch to see which parts wobble the most or get destroyed first. Pick those and nearby parts and you'll likely find the one with the autostrut problem right away.

You should see the target orbit. If you don't, then you ought to check to see whether you still have the contract (or, indeed, ever took the contract in the first place). Edit: Well, that answers that. Longitude of the Ascending Node (LAN) refers to celestial longitude. In earthly terms, the celestial directions are fixed in space with certain reference stars or other markers to point the way. For example, longitude for Earth is measured from the vernal equinox. This reference point exists completely independently from Earth's rotation--which ought to make sense; the 'landmark', as it were, shouldn't move while you're trying to measure from it. In KSP, there is a celestial longitude as well, but there is no way to see it as a particular star or other object in Kerbin's sky. The problem is that KSP's skybox is essentially painted on the interface at infinity, but that direction is measured relative to the vessel, not the sun or anything else. The only way to know your LAN in KSP is by use of a mod.

@Elroy Jetson: One potential use case is a depot as a temporary fuel dump while you're in a planetary neighbourhood. For example, if you want to get many biomes' worth of science from Minmus, rather than use a biome hopper and end up carrying fuel down and partway back several times, you can send a fuel tank that you leave in orbit and get something that functions halfway between a craft with a large fuel tank and a depot. Of course, you get much better fuel efficiency from a rover. I can see a depot working reasonably well as a port of call for a multiple-use rocket, such as a twenty-seat passenger liner for Jool tourism that only needs to go there and come back (as opposed to Jool-V motherships and science missions and all that). Once you have a rocket that can do the job, you can save some money by using it to do that job several times. Of course, that's the same concept behind SSTOs, just writ large, so savings is generally dependent on your ability to sacrifice raw lifting capacity for lifting efficiency. Reusability goes a long way for that. For other financial advice, 500 kiloFunds is a good place to be for where you are in the game. Don't build any 450 kiloFunds mega-rockets that will wipe out your savings if you crash them, and don't upgrade facilities more than you need to accomplish your immediate needs. This means that you will likely want to get Mission Control to level three first so you can pick and choose from more contract offers, but you can do a lot with the twelve kerbals you get from the level two Astronaut Complex unless you're also staffing bases or completing a lot of long interplanetary missions. You're probably not in a position to trade much of one currency for another, so you might not upgrade the Administration Building to even level two before you've upgraded everything else. You should definitely upgrade the Tracking Station to level two as soon as you can afford it, but you don't need level three until you're either asteroid hunting or looking at a mission to Jool. R&D is one of the last things you'll upgrade (mainly due to cost) but you need it at level two to have access to certain science experiments. However, you can build a lot of useful rockets with the parts from a level two R&D before you feel a pressing need to go on to level three.

Certainly. In fact, with three engines, assuming that they're in a triangular configuration instead of a linear one, there is a solution which will perfectly balance the axis of thrust with the centre of mass (within reason; the centre of mass still has to be between the three engines). Of course, KSP doesn't tell you the information you need to accomplish that balancing once you're in flight, but it is possible. You may consider duplicating the vessel in the VAB and adjusting the engine thrust while you have the centre of mass and centre of thrust indicators activated. When you get slider values that point the thrust vector through the centre of mass, simply use those values for the engines of the vessel in flight.

As these and others said, your problem is off-centre thrust. When you get down to 50 m/s relative, the imbalance is a much larger fraction of the total thrust. I can think of two ways to fix this: Balance the rocket. Wheels and RCS aren't good enough for this, because while they will orient your rocket to the correct direction, your main engines will still thrust through something other than your centre of mass. RCS won't cancel horizontal velocity unless you use translational controls (and won't do it automatically in any case), and reaction wheels can't cancel horizontal velocity. Therefore, you need either to move the centre of mass to the axis of thrust (by adding massive parts as counterweights as @Aegolius13 said) or move the axis of thrust to the centre of mass (by adjusting the thrust limiters on the engines as @Kryxal said). One results in fuel waste because of the extra mass and the other results in tricky landings because your rocket, though balanced, will not be level. Also, unless you're using radial engines or another solution that draws fuel from a central tank, the imbalance will reappear because uneven thrust means uneven fuel use. Learn to fly by hand. And that's really what you have to do. Knowing that is not the same as knowing how, but it can be done. Alternatively, you can always build a little excess horizontal velocity into your approach vector and orient your rocket so that the imbalance kills that velocity rather than adds to it, but you will still need to do that by hand. Don't expect accuracy, and hopefully you have a way to move the module on the ground if it needs to attach to anything already there. I don't think that the problem is that you're rising again, as @HvP suggests, because if that's happening when your surface velocity is 50 m/s, then it means that you have 50 m/s of horizontal velocity--which means that the problem is still horizontal velocity. I do agree that engine gimbal is probably helping you until you get to low velocity, but that's because gimbal is a way of moving the axis of thrust. It's usually better to deal with the problem at the source (by realigning the thrust axis to the centre of mass) than to rely on gimbal or RCS or what-have-you to compensate. Otherwise, good luck, welcome to the forum, and do please give us an update on how things work out!

Not a chance. The issue is pressure, and the Nerv hits zero thrust at two atmospheres, which is less pressure than at any point on Eve's surface. Actually, it's zero Isp, but you're still not going to space today. There may be mods that offer nuclear thermal jets which will get you to orbit (or at least high enough that the Nervs work), but there is no stock nuclear solution. It is possible to use a Mammoth (and by extension, Vectors) on a flying fuel tank to get from surface to orbit with one stage, but even that has minimum altitude that's a few kilometres above sea level. I don't know whether it's been tested, but it might be possible to do it with a Mastodon from Making History, as well. Either way, you need a lot of punch and either a lot of surface efficiency or else a lot of stages. On the other hand, if you are only interested in flying at Eve, not actually landing there, then it could possibly be made to work. Of course, that negates the advantage of the thick atmosphere, so you're better off keeping the wings you have or otherwise configuring for high-altitude flight. 'Flying Low' begins at 22 kilometres, so you need to get that low for the science, but the pressure there is somewhere between one-quarter and one-third of an atmosphere. I don't know whether you can come back up from that on nuclear power alone.

You can do that. I doubt you need that much thrust, though. Consider adding a fuel tank to the core stack before you add more engines. A general rule is to have enough fuel in your stages that they burn for about two minutes each, though that rule has to be relaxed a bit for asparagus staging, which brings me to the next point. Here's a free sketch of what asparagus staging looks like, from the bottom of the rocket: Fuel lines (flow direction shown with arrows): B2 <---- B3 / / B1 ---> C <--- B1 / / B3 ----> B2 Usually, all of the stacks are attached to the core with decouplers, but the fuel lines run in the order shown from the first boosters to be staged (in this rocket, the B3 boosters) to the next boosters (B2) to the next boosters (B1) to the core stack (C). You're running a rocket that only has two sets of outer boosters, but the principle is the same. What makes asparagus staging attractive (and what gives it improved delta-V) is that it sets up the fuel flow so that all of the engines (in the example, all seven; in your rocket, all five) use the fuel from the outermost boosters first. This means that those boosters drain at lightning speed, but once they are empty and staged away, you're left with a fully-fuelled rocket. Now the remaining engines drain the next set of outermost boosters, but since there are fewer engines, it takes longer, and when those boosters are empty, they are staged away, leaving a fully-fuelled rocket ... and so on. In the end, when you get down to the core stack, it's full of fuel, has an appreciable downrange velocity, and is likely fairly high in the atmosphere. To make it, you have to attach the boosters in pairs, for balance. In theory, you could attach quads and have a valid asparagus arrangement that way, but that gets a bit crowded and it's too much for rockets that have only as many as six boosters. Personally, I simply make a booster, attach it with 2x symmetry, and then copy it. I only add the fuel lines after I've fixed the staging (you have to be very careful to get the staging correct, or else you'll stage away half of your fuel). Also remember to put all of the engines in the bottom stage: they need to ignite all at once. You can always add a reaction wheel, but I think your problem can be solved with a different approach to control authority. Others have said to switch your fins--and that is good advice; the Delta-Deluxe fins you're using now only have 20% control surface--so pick something such as the AV-R8 Winglets, which are 95%, or the suggested Elevon 1, which is 100% and cheaper than either the AV-R8 or the Delta-Deluxe. Others have also said to change your central Swivel engine for a Reliant, and that is possibly good advice, but not necessarily. If you stage away your core stack and make orbit on your upper stage, then yes, do that, because you will only need the extra rotational control when you are in the atmosphere and the fins are working for you. If you use the core stack to make orbit and possibly also as a transfer stage to get to the Mun, then keep the Swivel because in space, fins are decoration. Also, the Swivel is slightly more efficient in space than the Reliant (only ten seconds, but why not?). Using SRBs instead of liquid boosters is a valid approach but you can't get asparagus efficiency out of boosters that can't share fuel. On the other hand, SRBs provide cheap thrust for what they cost. It's worth exploring. There's also nothing stopping you from using strap-on boosters with enough kick to get your rocket in the air with the main engines off, and relying only on fins for attitude control until you drop the spent boosters and ignite the main engines--this gives you a sort of 'poor man's asparagus', so feel free to try it. The booster-with-an-LFO-tank-on-top idea is a good one, as well. Another trick to use is to set the fuel flow priority on your stacks so that the fuel drains from the bottom up, rather than the top down. This has the benefit of pushing the centre of mass forward as the tanks drain, which gives your fins (and Swivel if you keep it) more lever arm, which gives more control. To do it, set the fuel flow priority (I believe you need Advanced Tweakables, which is in the difficulty settings, turned on for this) on the lower tanks to a higher number than the upper tanks. Fuel drains from higher priority numbers first, so you want the numbers to increase as you go farther out from the core stack. When you set the staging, the game usually advances the fuel flow priority by ten for each stage (to give you some room to tweak), but sometimes it gets confused with asparagus staging, so be certain to check. In my example above, the core would start at priority ten (the upper stage is normally priority zero), and the boosters would be twenty, thirty, and forty, respectively. Leave the upper tanks as they come but set the bottom fuel tank in each stack to priority eleven, twenty-one, thirty-one, and so forth. If you have three tanks in a booster, then the middle tank is twenty-one and the bottom is twenty-two, and so on. That being said, I prefer to have a reaction wheel anyway, because I like what I will call a 'snappy' rocket. You should have plenty of wheel, though, if you're using lander cans. Be certain that you remove the monopropellant from the pods if you don't intend to use it. It's not a lot of mass but it is unnecessary. Also, as @Aegolius13 said, lander cans are not really meant for atmospheric use and are very draggy. Drag at the nose of the rocket causes control problems, too. Consider a fairing or the Crew Capsule, as others have suggested. Struts are also draggy, and as @Plusck said, you don't need two per booster. The fuel line doubles as a strut (I doubt it's got the same strength, but it still does something) and to be honest, the only thing you need to do for this design is keep the boosters from shaking too much. One strut is perfectly sufficient for that. Good luck!

Are you using Nertea's stuff? There's a plant growth experiment on the greenhouse of the Station Parts Expansion. The Triple-Z Radio Telescope has a radio astronomy experiment that's actually called 'Radio Astronomy'. My only other guess on the source is that there may be something in DMagic's Orbital Science, but I'm not familiar enough with it to commit. Also, depending on how you arrange your install, it's possible that the experiment exists but the parts to perform it do not: science experiments, their applicable situations, and other bits are stored in a science definitions file that is separate from the part configuration file which tells a science part which experiments to perform. [x]Science! looks at both, so if you have a vestigial science definitions file somewhere, then it will see that the experiment is possible but will never see the means to perform it on the vessel.

It shows the average of a series of optimum Hohmann transfers. That means that the numbers will tend to be low. There are more efficient trajectories, but most of these are not direct transfers; they require increased flight time, gravity assists, or both. There are infinitely many less efficient trajectories. As @bewing said, you can be 100% inefficient.

But there is also a minimum Reputation requirement to activate that strategy, so for practical purposes, yes, you can, in the sense that you can have a public image that is so bad that you cannot sell that image for money--the extraordinary need of which, as I understand it, is why you would want to sell that Reputation in the first place. The only thing to do then is hope that you get a contract to test something on the Launch Pad.

Strategies, explained: The Finances, Science, and Public Relations Departments are interested in Funds, Science, and Reputation, respectively. They each have two long-term strategies that turn the other two currencies into the one that they're interested in. There is a required minimum Reputation and a set-up cost, so you have to have some of what you're converting to begin, and the conversion amount varies depending on how much you choose to commit (which is also limited by how much you've upgraded the Administration Building), but it can go as high as 100%, meaning that you can conceivably trade all of your gains in one thing for another. This makes sense in the late game when you've researched the entire tech tree and no longer have a use for all of those Science points you keep collecting, for example, but you may want to have a few million Funds to pay for your new mega-rocket that uses all of those new parts that you just finished unlocking. It's also useful if you keep killing your Kerbals and want a balm for the strikes against your Reputation, though I've found that bad Reputation is actually the easiest obstacle to overcome. Finances: Fundraising Campaign: Trades Reputation for Funds Patents Licensing: Trades Science for Funds Science: Unpaid Research Program: Trades Reputation for Science Outsourced R&D: Trades Funds for Science Public Relations: Appreciation Campaign: Trades Funds for Reputation Open-Source Research Program: Trades Science for Reputation There are two more long-term strategies (both from the Operations Department) that change the balance of launching and recovery: Aggressive Negotiations: Trades some Reputation for lower costs on launches, building repairs and upgrades, and unlocking technologies in the R&D building (not the nodes which require Science, but the individual parts which require Funds). This is applied for each discount, meaning that there's a Reputation cost for every new launch, every new technology you research, and so on. On the other hand, the discount is a percentage of the Funds cost (up to thirty (Wow!) percent for launches) and the Reputation cost is limited to six (that's six Reputation Points, not six percent), so if you're in the habit of buying expensive rockets or you want to unlock the expensive third-tier upgrades (or you need to fix the third-tier VAB since you just crashed the expensive rocket into it), this is potentially a lot of money saved for a comparatively minor strike on Reputation. Recovery Transponder Fitting: Trades the maximum recovery value for a higher minimum. This is the only Funds-for-Funds strategy; it mainly is useful if you tend to drop your rockets on the other side of Kerbin. If you land near KSC, use a lot of disposable probes, or like to keep your vessels in the sky for many multiple missions, then this strategy is silly. If you want to land on the other side of the planet and get 25% recovery at the risk of only getting 88% when you're next to KSC, or if you just have too much money and need to invent nonsensical ways to spend it, then this strategy is for you. It may have a use in the early game when you may not be able to land planes in one piece or you don't have good landing control, but as soon as the value of the rocket begins to make this worthwhile, you've got both the skill and the technology to do better on your own. Besides, if you want nonsensical ways to spend money, why not do something spectacular, such as launching a rocket full of Xenon tanks into the sun? Lastly, there are two immediate-return strategies, one in the Science Department and one in the Public Relations Department, that respectively trade some amount of your Science and your Reputation for Funds right away: Research Rights Sell-Out: Sells Science (up to 100% of it) for Funds Bail-Out Grant: Sells Reputation (again, up to 100% of it) for Funds These strategies appear to be intended for those who manage, either through bad luck or bad management, to bankrupt their space program and have no other way to make money (because, for example, they don't have enough to pay for the rocket that can complete the contract to get more money--Rockomax does not, apparently, accept credit). Granted that people in this situation must also have managed to do a few experiments or else remain in the public's good graces, so if you're completely out of Reputation, Science, and Funds, you're also out of luck. The other use of these that I can think of is that, for example, let's say that you've completed the tech tree and set up Patents Licensing for 100%. There's a Science set-up cost, but after that, there is still a lot of Science left over; Patents Licensing only works on new incoming Science, not what you already have. The Sell-Out in this case gives you useful money from the Science you still have left over. Long-term, the strategies you've activated will both lower your reputation, so it will be more important for you not to fail contracts or to kill Kerbals. One will help your Funds by giving you cheaper launches and facility upgrades, and the other will give you Science for everything you do well (new World's Firsts and completing contracts mostly). However, the amount of Reputation loss is balanced by a few things. One of these is that Reputation is actually fairly easy to get, provided you have the standard difficulty settings for your game. Another is that Reputation, unlike Science or Funds, is not strictly additive. By that I mean to say that when a contract promises a certain amount of Science or Funds, it pays that amount and your totals increase. Reputation, on the other hand, is limited to 1000, so as you get closer to that value, contracts pay out less of it. Lowering your Reputation with strategies, oddly enough, actually opens the way for you to get more of it from each contract.

Firstly, welcome to the forum; you've definitely come to the right place. That depends on the experiment. Here's the essential idea of how science works: First, experiments work in specific 'situations'. There are a number of these: landed, splashed, flying low, flying high, space low, and space high. Some experiments work in all of these situations, but some experiments only work in a few situations. On top of that, any, all, or none of these can be biome-specific, meaning that instead of a global result for the whole planet, you can get specific results for each biome. For example, the seismic accelerometer only works when 'landed'--it won't let you take a report otherwise--but it gives different reports for every biome. The infrared telescope only works when in space high, and it's global, so it only takes one result total for each planet. You can take EVA reports for each biome in space low but only one for all of Kerbin in space high. Also, it's not necessary to enter orbit: so long as the situation is correct, you can get the results, even on a suborbital hop where you clear the atmosphere for only ten seconds, or a hyperbolic flyby where you dip low enough to get the low space science and then then head back to Kerbin. Second, not every world has all of these situations. 'Flying' requires an atmosphere; 'splashed' requires an ocean (that may or may not have water in it; it just needs to be liquid), and so forth. Third, the altitude transitions for these situations vary with the location. For Kerbin, 'flying low' changes to 'flying high' at 18,000 metres; 'flying high' changes to 'space low' at the edge of the atmosphere (70,000 metres), and 'space low' changes to 'space high' at 250,000 metres. You can't get flying science when you're in space, for example, so that's a limit, but all that means is that there's a different range of experiments to do. Eventually, you leave Kerbin's sphere of influence, so I suppose that's the absolute maximum. There's no preferred order of experiments; the only thing to be really concerned about is that when you take crew reports, you have to gather the data from the pod, as well. I'm probably telling you something you already know, but the steps are: get out of the capsule, right-click on it (or the experiment), select 'Take Data', right-click on the capsule and select 'Store Data', and then get back in for the next report. You may also choose to just board the capsule after taking the data, which will also store the data in the correct place. Otherwise, the most recent report is stored in the--we'll call it the active data slot--and keeps a new one from being added without overwriting the active one. You have to pull the data from the active slot and put it into inactive storage in order to make room for a new report. As to why you have to get out of the capsule to do this, I have no idea. If you continue to get errors such as duplicate report errors, that only means that you've already visited that biome. Alternatively, it means that you've got a global experiment and can only take one for that situation, which is the same problem but with fewer total reports. Temperature, for example, is global unless you're landed, splashed, or flying low (two of these are not an issue at the Mun--I'll let you guess which ones). The same is true of crew reports. Pressure is global except on the surface--it doesn't do biome-specific science even flying low. In fact, the only experiments that are biome-specific in space low are EVA reports and gravity scans. You can tell whether an experiment is biome-specific in any situation by looking at the experiment result. If it says, for example, 'Temperature while Landed at Mun's Poles', then the biome name (Poles) tells you that it gets results by the biome. Obviously, 'landed' tells you the situation. If it says, instead, 'Temperature while In Space Near the Mun', then that's a global experiment ('space near' is the same as 'space low'). Anyway, to properly answer your question, preparing your orbiter is a matter of putting the experiments you want on it. I'd recommend using a service bay to keep them out of the wind on the way up, but that doesn't help you get science except indirectly. However, assuming that you've already gotten Kerbin's low and high space temperature and pressure results, then on the way down to the Mun with a thermometer and barometer, you'll get four experiments in high space: temperature, pressure, EVA report, and crew report. All of those experiments are global in high space. The change from high to low occurs at 60 km at the Mun, so 15 km is definitely close enough. There, temperature, pressure, and crew reports are all global, so you'll only get one each, which means that in all honesty, getting the most science entails hanging off the ladder and taking EVA reports in each new biome (and remembering to put the reports away to make room for new ones). In general, preparing your vessel is a matter of knowing what you intend to do with it. Don't put a telescope on your lander; it only works in orbit. Don't put seismometers on your orbiter; they only work when landed. Take a barometer (surprise!) but not an atmospheric analysis unit, unless you're both visiting a world with an atmosphere and intent on flying there (Jool and Eve can be tricky). I'd recommend a polar orbit in order to get all possible biomes, but if you want any more science, then you'll need to land (or take different experiments). As I said above, use a polar orbit. When you launch and turn east, you end up in what's called an equatorial orbit (so named because it's above the equator). If you were to turn north instead, you'd end up in a polar orbit, so named because it goes over the poles. The ISS is an intermediate case; but the general term for all orbits that are not equatorial is inclined orbit. Much like a ramp has a tilted surface that is called an incline, an inclined orbit is tilted with respect to the equatorial plane. Something of which to be cautious is that the Mun, being tidally locked to Kerbin, has an extremely slow rotation period of nearly six and one-half days, so it will take a while for the Mun to rotate under your vessel. Forty-five degrees of inclination will give access to most biomes in less time. To set up a polar orbit, the most straightforward way is to burn to transfer to the Mun as usual, but as soon as you cross into the Mun's sphere of influence, set up a node for an immediate normal burn ( on the navball). The time isn't too critical but you'll want to burn as soon as possible after entering the sphere. However, you won't get the most up-to-date orbit information until after you enter the Mun's sphere of influence, so don't set up the burn until after you've crossed over, either. Add enough normal burn to tilt the orbit as much as you like (or put it over the pole if you want to try for a polar orbit), add enough prograde or retrograde so that your periapsis is out of the ground and at the altitude you want (15 km), and then burn to capture when you get there as usual. The comm system is useful for other purposes, but for science it's really only good for transmitting science results back to Kerbin. If you intend to bring Jeb back, you don't need it because you can recover the experiments along with the pilot. Also, transmitted results tend to be worth less and there's a limit to how much can be transmitted, anyway (whether or not that makes sense: temperature and pressure are capped at 50%, which is weird, because those are just numbers). Eventually, you have to bring the science back. The Science Jr. is a nice experiment and gives a lot of science, but it's heavy and single-use. It can be restored by a scientist if you have one along, but not by a pilot. It's worth taking one or two to get the space high and low science, but unless you really need the science to unlock something, you may want to wait for a dedicated landing mission with a scientist in a two-seat vessel, in which case you can grab the space science on the way there.

As I understand these sorts of missions, the mission is accomplished when a vessel with the correct specifications enters the correct orbit and stays there for ten seconds. As such, I don't think there is any specific prohibition against taking it on the nose of a manned rocket. Don't forget any antenna or other accoutrements that the mission might require--some of them are terribly specific. There should be a target orbit in the map view; the correct longitude of ascending node is wherever the ascending node is on that target. KSP doesn't provide a good way to know that orbital parameter. Zero longitude is a specific direction in the game, but since the skybox is essentially wallpaper painted on the face of infinity, it doesn't correspond to any actual celestial object. You'll either need to use a mod that gives you the information or else get comfortable with flying from map view. Your design approach is still correct; it's just that you need to add up a bit more delta-V at the top end, which of course will have exponential increases down the rocket in terms of necessary fuel. But delta-V adds: if you need, for example, one hundred for the probe release and five hundred for the rescue, then take six hundred for that part of the mission. The Mun transfer is going to cost the same no matter what you take; you'll just need to account for the extra mass. Of course, you'll need to take care because of drag for the launch from Kerbin, but I assume you know how to handle that. The trick for these sorts of missions is knowing which parts can be combined with other parts and which are best done independently; anything combined saves fuel. For example, it may pay off the most to capture with a perispsis close to the Mun and an apoapsis at the probe orbit; you simply leave the probe with enough fuel of its own to fix its orbit. Then you can continue to burn down for the rescue (assuming the rescue is closer to the Mun than the probe orbit) at the next periapsis and you won't need to carry any extra fuel beyond what you need to loft the probe to that point in the first place. This works because it's trivially easy to give a probe the hundred (or whatever) metres per second it will need to do its mission, as opposed to changing orbits with a more massive rocket up high where you don't get any free efficiency. But the best part is that so long as you burn at the near-Mun periapsis, it doesn't cost you extra fuel to drop off the probe; the only expense is time. As far as knowing what the delta-V costs will be if you've never been in the neighbourhood, you'll need either a map or a good calculator. But I got the impression that you can plan for a single mission just fine; it's the two-for-one that you've not yet done. There's no reason not to do so, especially if you can cut the probe mass to near-trivial levels. I caution you to remember the extra required delta-V for the return and the higher speed of moon return re-entry. Also double-check your extra seat; nothing inspires imaginative cursing like taking a rescue ship that has no room, but without your knowledge until you get there. Probe design is fairly straightforward: you need the core, a battery, antenna, and solar panel or four, plus fuel and an ant engine if you want them (hint: yes you do), and whatever else the mission specifies. Sometimes the mission asks for certain science experiments. Sometimes, it wants a docking port. Sometimes, it asks you to take certain other parts (like landing gear, for some reason I don't ken), so be sure that you add them. Then add a separator (not a decoupler), a fairing, and stick it on top of your rocket's nose. For these kinds of probes, you should keep the size down to .625-metre parts. Don't forget that a probe on your nose means that a parachute won't be. Take radials. Good luck!

You have my apologies; I oversimplified. You're correct in that the period of the orbit cares not a whit about the location of the nodes--though the comparison between two scaled orbits does care about the location of periapsis insofar as that defines zero true anomaly. My intent in saying that was only to recall that for this specific problem, there is a special reason why the ascending node must occur at ±90° true anomaly: the Draim constellation constrains not only the inclination and eccentricity, but the argument of periapsis as well. This is the angle between the ascending node and the periapsis as measured on the orbital plane (as opposed to the longitude of ascending node and longitude of periapsis, which are measured on the equatorial reference plane). Specifically, all of the orbits in the tetrahedron have an argument of periapsis of either 90° or 270°, which puts the periapsis at right angles to the line of nodes with respect to the primary as the vertex. This is why, in this case, the line of nodes coincides with the latus rectum of the ellipse, but for any other argument of periapsis, this would not be so. Since your original question was not how to find the latus rectum, but how to find the correct point at which to change inclination, I was pointing out that although you have a general solution to scale orbits of constant eccentricity by their orbital period regardless of their orientation and can also find the latus rectum of any orbit with relative ease, the equation will only find the correct burn point if you begin with the correct argument of periapsis: 90°, 270°, or undefined (which means starting from equatorial orbit). Granted, I'm also aware that your entire purpose was to simulate the Draim constellation, so alternative arguments of periapsis were never in your plans. Perhaps I was being over-thorough ... you may have noticed that I have that habit.

I did swap them; that was my error. The apoapsis sight angle will always be smaller because it is farther away. I fixed it, in any case. That will work well enough for most situations. It will give issues when you need to deal with either massive bodies orbiting your targets closely (because their sphere of influence will interfere with your desired orbit) or targets with low mass orbiting closely to their primaries (because the target's sphere of influence is too small to give you the correct orbit within the constraints). I know that there is no solution for Laythe that fits the parameters (Laythe is fairly large for a moon but not compared to Jool at that orbital distance), but Duna should be possible provided that you orbit outside of Ike's influence. The target value from the other thread is a semi-major axis of at least 7.25 times the planetary radius, (which is the value of 1 / tan 7.853°) so that's yet another verification method. I saw nothing constraining the maximum value of the semi-major axis except insofar as the constellation needs to remain in orbit. Oh, I don't doubt that one launch would work better for anything interplanetary, at least in transfer costs. That being said, you may still want to consider the flotilla alternative, or possibly a hybrid where you have one carrier to take the satellites into interplanetary space but then separate the satellites and set them to their own intercepts before the target encounter. That may not be necessary but it's probably worth investigating; thirty-three degrees inclination is expensive no matter how you look at it. As I mentioned above, Laythe's sphere of influence is too small and Laythe itself too large for the tetrahedron to work with 33° inclination and .28 eccentricity. Its sphere of influence is 7.45 times its radius, which fits one parameter, but that requires orbits to have eccentricity of no more than .027, which is too circular to be of help (the minimum for a Draim tetrahedron appears to be more than .1). I have seen references to some other solutions that work with five satellites, but I am not familiar enough with the details to tell you whether they would work in Laythe's sphere. Duna has a radius of 320,000 metres, so that would require a constellation semi-major axis of 2,320,093.7 metres. Eccentricity of .28 gives an apoapsis for that orbit of 2,969,719.9 metres. Ike's periapsis is 3,104,000 metres, and with its sphere of influence of 1,049,599 metres, that gives a potential closest approach of Ike's influence at 2,054,041 metres. More likely, that conflict would occur farther out (33° inclination gives a lot of extra room in 3-space), but it would still occur. You're right about the coverage gaps: the table-given SMA of 2,080,000 metres reflects the three-dimensional geometry (it's too large for anything coplanar), but even so, 2,080,000 / 320,000 = 6.5, or alternatively a sight angle of 8.746°, which is too close to Duna. On the other hand, if you go higher, then Ike's apoapsis is 3,296,000 metres, so it gives a maximal influence conflict at 4,345,599 metres. Let that be the periapsis and that gives the satellites a semi-major axis of 6,035,554.2 metres. You can get closer (again because of three dimensions) but that value guarantees no conflicts with Ike. It's nearly nineteen times the ratio of the radius to the SMA, or a sight angle of only 3.035°, but I see no reason why that wouldn't work. Satellites on that orbit would have an apoapsis of 7,725,509.4 metres, which is well within Duna's sphere of influence (nearly 48 million metres). But there are still coverage gaps: Ike gets in the way. That's probably why the author chose the lower orbit. On the gripping hand, the solution to that is simple: put a constellation around Ike. By definition, a body with one hundred percent coverage is transparent to the network--meaning that if you can see every point on a planet, then there's no reason why you can't see through to what's beyond that planet; it's only a question of whether you're looking. So long as your Ike satellites have transmitters that can see Duna, then you'll get full coverage without needing to send anything extra beyond the more powerful antennas--which you need to send anyway if you want that constellation to talk to Kerbin. If you put your Kerbin-capable relays around Duna and have Ike talk to them, then you still get full coverage without needing to do anything extra; the required minimum transmission distance to the relays is greater than the distance to Duna's surface. Yes; assuming that you hold eccentricity constant and travel from a specific true anomaly θa to a specific true anomaly θb on both orbits, the change in mean anomaly will be the same and the travel time will scale linearly with the period: t = MT / 2π. It's not enough that the craft travel through the same angle; the caveat is that the trip must begin and end at the same true anomaly on both orbits. Since you're going from 0° to 90° each time, it works. However, understand that this is a special case since both endpoints are identifiable as other orbital parameters (Pe and AN/DN).

Without access to that particular paper, I am limited in what I can figure out. The radius and the gravity tend to increase and decrease together, but there is no requirement that they do so--planetary density can vary quite a lot. Saturn, for example, is less dense than water, because its volume belies the fact that there simply isn't that much mass to it. In other words, Saturn is our fluffiest planet. However, satellite coverage has more to do with the visible surface, which is of course related to radius, but it appears that the parameters for this tetrahedron are very flexible. Nevertheless, I note that the table of parameters in the original challenge post seems to preserve the angular relationship from Draim's work, which is why the satellites in KSP have the semi-major axis that they do. For a satellite orbiting Kerbin with a semi-major axis of 4,350,000 metres and an eccentricity of .28, the (true) apoapsis and periapsis are as follows: Ap = 5,568,000 metres Pe = 3,132,000 metres These were derived from the relation Ap = (1 + ε) * SMA and Pe = (1 - ε) * SMA. With the planetary radius of 600,000 metres, the angle between the satellite and a point on the circumference of the greatest-size cross section that faces the satellite (in other words, the farthest possible visible point) is given by: Sight angle Ap: arctan 600,000 / 5,568,000 = 6.15° Sight angle Pe: arctan 600,000 / 3,132,000 = 10.84° Using a similar derivation for satellites orbiting Earth: Earth's standard gravitational parameter is about 3.986004419×1014 m3/s2. Earth's average planetary radius is 6,371,000 metres. The required minimum orbital period for Earth of 27 hours is equal to 97,200 seconds. A 27-hour period gives a semi-major axis of = 45,691,651.57 metres, so: Ap = 58,485,314.01 metres Pe = 32,897,989.13 metres Sight angle Ap: arctan 6,371,000 / 58,485,314.01 = 6.22° Sight angle Pe: arctan 6,371,000 / 32,897,989.13 = 10.96° I think we have our relationship. So long as your sight angle is less than 6.22 degrees at apoapsis and 10.96 degrees at periapsis (smaller angles mean greater distance, which means better coverage), it can work. Since we're using the same eccentricity for everything, we can also find the semi-major axis directly: Hypothetical sight angle: arctan 6,371,000 / 45,691,651.57 = 7.938° To figure the minimum semi-major axis for a given body of known radius: SMA = rbody / tan 7.938° To check for Kerbin: 600,000 / tan 7.938° = 600,000 / .1394375 = 4,303,002 metres. This is lower than the given value for Kerbin because, I think, the original poster decided to be safe, but again, without having access to the paper, it is possible that there is a practical reason for the given figure. If you prefer to have that margin, then the hypothetical angle to use is actually 7.853°. This is in line with your supposition that you can scale the semi-major axis by the radius times a constant; I simply took it a step farther to determine both that 1 / tan 7.853° is the value of that constant, and why it appears. To check these figures, we can use the Mun (radius = 200,000 metres): 200,000 / tan 7.938° = 1,434,334.13 metres Alternatively, with the safer angle: 200,000 / tan 7.853° = 1,450,058.58 metres See whether you can get a good network there using that parameter, and if so, you'll have your solution. Edit: Alternatively, you can use this set of precalculated figures that I just found, of course, only after doing all of that: https://forum.kerbalspaceprogram.com/index.php?/topic/155188-orbital-parameters-for-a-tetrahedral-satellite-constellation/ Edit edit: Draim's original paper is behind a paywall, but he also got a patent for it, and because of the wonderful scope of U.S. patent law, the patent itself is available: Tetrahedral Multi-Satellite Continuous-Coverage Constellation Edit edit edit: And here's an interesting animation of satellite coverage using this model: