Zhetaan

On a related-but-unnecessary note, I can add a little bit to @Crown's post and explain why most logarithms are to the base 10, otherwise called common logs. Before scientific calculators, there were two common ways to calculate logs: you could use a slide rule, or you could use the log tables (pages of pre-calculated logs that you would use as a sort of directory to look up the one you wanted). The problem with either of these is that they are physical objects that take up space. Adding more capability makes them take up more space, and since numbers go to infinity, it's not a solvable problem. Or is it? Mathematical trickery comes to the rescue! The thing about common logs is that because they are taken to the base ten, and because our numbering system is also base ten, there are some helpful patterns that appear. For example: log10 5.501 = 0.7404 (approximately, as all of these will be). log10 55.01 = 1.7404 log10 550.1 = 2.7404 log10 5501 = 3.7404 Common logs make calculation easier because they are a special case: for larger numbers, move the decimal place to just after the first digit, and take the log of that number. Then count up how many places you moved the decimal, and put that answer in front of the log. This means that, so long as you can shift decimal points around, you can get logs of any number. If you're using a slide rule, you can usually get three-place accuracy. If you're using tables, you can get four-place accuracy (good enough for almost anything) if you pre-calculate the first ten thousand logs. It doesn't take up much space (and you can make copies for everyone, so they only have to be calculated once). You can take care of the rest on your own easily.

Not if you're landed. Night lasts quite a long time on a Moho base. On the other hand, Ore + Fuel Cells + ISRU converters would take care of that. On the gripping hand, with the amount of heat generated, the ISRU option might even be harder on Moho during the day, thus requiring solar panels and operator attention to cycle everything, not to mention the truly hellacious amount of fuel needed to move that much heavy hardware to Moho in the first place. So, provided that you're landing a base, RTGs may easily make the most sense in terms of total power efficiency with respect to weight hauled, time management, and thermal considerations. To attempt to answer the question, I have never needed additional cooling for RTGs. If I correctly recall it, I think the fact that RTGs have built-in radiator fins was at least partially accounted for when assigning heat values; whatever the case, RTGs don't transfer their core heat directly to active radiators in the same way that, for example, ISRU converters or drills do. The ideal core temperature is 350 K and the shutdown temperature is 10000 K, but if the part or the outside environment is hotter than the core, heat won't transfer into it, so that 10000 K may as well be infinity. The core-to-part heat transfer rate (the heat that can leak into the rest of the vessel) is .01 % (one tenth that of ISRU--which also runs a lot hotter than RTGs do), so I'm going to call it and say that you don't need radiators except insofar as you need radiators for the other passive parts on the craft. The RTG case is relatively light at only 1200 K maximum temperature, so if you are taking a lot of them somewhere hot, you may wish to provide a radiator or two to keep them from blowing up due to imposed heat from other sources. I will warn you, however, that the configuration values for RTGs are commented using old references, so it is possible that these numbers will get a balance pass with the next version. Be on your guard.

In keeping with the militaristic theme, wouldn't the Red Ones be sappers? --Oh, and first time caller, long time reader, &c. I've been following this since page one of Duna, Ore Bust! Absolutely fabulous work, @Kuzzter. I've had almost as much fun watching you play KSP as I've had playing it myself.

Yes, they changed the buoyancy calculations; submersibles are a thing now, too. Of note is that ore sinks; using different tank sizes in combination allows for a crude but effective stock ballast control.

Make sure the vessel with the tourist (or whatever you're using, if it's a vessel flyby contract) is the active one and in focus when you cross the SOI boundary. As I recall, KSP only checks the flyby condition when you cross that boundary; if you switch away from the vessel for the crossing, then it never does the check and you never complete the contract. Yes, this means you can orbit a body without first doing a flyby--at least, as far as KSP is concerned. I do not believe it counts to put yourself in orbit, burn to escape, and get flyby credit that way; if you're already in the SOI and leaving, that should count as 'escaping', which is different from a flyby.

Iron filings and LOx (hybrid rockets!). Sawdust. Flour. Shredded old tyres (for long burn times!). For monopropellant, steam. Larry Niven and co. used steam attitude thrusters on the Michael in Footfall. Coal or wood (and water for the boiler that's making steam).

The only other thing I can think of is that you somehow accidentally put the navigation into target mode, and MechJeb is trying to thrust according to your velocity relative to your tanker. If that isn't it, then I'd have to call it a Kraken attack; MechJeb shouldn't be doing this on its own. After all, the whole point of using an autopilot is that it knows which way is up as well or better than you do.

Did you, perhaps, set your MechJeb module to 'Control from Here'? Did you dock with your fueler using a radial port and set it to 'Control from Here' for docking? Is your Kerbal in a non-command pod, or is your command pod in a weird orientation? If your point of control is in a weird orientation (which can happen if you forget to transfer control away from a radial docking port, for example), and MechJeb doesn't know the difference, it may be trying to orient the ship according to that control point. In the case of a radially attached port or the MechJeb pod itself, it means that the rocket tries to orient sideways. The engine's thrust is perpendicular to that, and the end result is a cartwheel. It's worse if your point of control is on the bottom and MechJeb thinks you're upside down.

Tourists cannot even leave the vessel. You can take them down with you, land with them, and have them pose for pictures by the window, but they can't get out of the ship. You can, however, split the mission into parts: I often take a few tourism contracts at once and split the groups into those wishing to go to specific destinations. If you have someone who only wants to go into Kerbin orbit, then you can take that one on a separate mission and make another seat available on your Mun/Minmus trip.

It's floating-point inaccuracy, and also I recall that KSP calculates off-rails apses based on the root part, rather than the centre of mass. Since it's rare for the root part to be at the centre of mass, rotation (which is based on the centre of mass) changes the root part's position with respect to the orbit, thereby changing the calculated orbit. It would be difficult to test whether they've addressed that because using a single command pod, for example, wouldn't eliminate the floating-point problem. Maybe a command pod on one end of a long rotating boom with a couple of full Kerbodyne tanks at the other would do the trick?

There's no way in stock; you have to use mods to get around the automatic thrust-to-zero of on-rails timewarp. This is a consequence of how KSP handles the physics of timewarp--to get different kinds of timewarp, you need different ways to handle the physics, and that mandates the use of mods. @NanoExplorer released an ion warp mod called, naturally enough, IonWarp, about eight months ago, but it's an alpha and hasn't been updated since the first release. I'd post a link to the GitHub repository, but as I am unsure of the license and so forth, I don't want to inadvertently violate any of the community rules by linking to a mod without one. I'm sure you can find it easily, get the requisite permission, assume the risk, &c. @HoneyFox made something called Orbit Manipulator that was once recommended for Realism Overhaul, but it's listed as last being compatible with KSP version 0.25. I have no idea of what, if anything, Realism Overhaul users are using right now for realistic ion engines; I mention this mod anyway because they're the group most likely both to have this same issue and to do something about it. Check the Realism Overhaul thread for more information. @mrsolarsail has two works-in-progress called SolarSailNavigator, and PersistentThrust. They run in KSP version 1.0.5, but they are in-development alphas. I can't comment on how well these work right now, but they seem to be your best bet.

Yes and no. @Geschosskopf would likely have better information on this--he rather wrote the book on prospecting--but the idea is that there are layers of control available for resources. For example, resources can be made available only on specific planets, or even only specific biomes of a planet. Alternately, one can exclude a resource from certain biomes (or certain planets, or certain situations). One may also set limits upon how often a resource appears, what the minimum and maximum concentrations are, and how varied the distribution of the resource is within the biome. It is possible, for example, to limit a resource so that it is only present in a single, uniform concentration, or to do the opposite and let the random number generator have essentially unlimited influence. This is meant as a tool for modders adding custom resources; if you're playing stock then it is of no consequence to you. Ore, particularly, is never available in oceans, but it is generally guaranteed to be present everywhere else. The concentration varies; how much is available, and where the high and low concentrations are, in a given biome are procedurally generated, but the procedure itself follows enough of a pattern that you can guess to the biome where you're most likely to find high or low concentrations. Finding specific 'hot spots' of high concentrations within a biome requires more advanced scanning and observation.

Yes, you can. Check the wiki again; are you certain the N/A isn't for Kerbol, instead? It is not always clear, but Kerbol is the unofficial fan name for what the game calls The Sun. Kerbin is the green-and-blue ball that orbits Kerbol. Anyway, you can scan Kerbin and drill for Ore there--except in the oceans: all oceans (Kerbin, Laythe, and Eve) and oceanic biomes are hard-coded not to have Ore. For reasons I hope are obvious, you can't drill on the Sun. (Maybe it isn't obvious: it takes too much delta-v to get to the surface of the sun.)

I noticed that on your edited version, you attached the solar panels to a group of what appear to be structural fuselages attached to the larger station by quad-couplers on the top and bottom. Unless the issue has been fixed, that will make a craft less stable because KSP doesn't support multiple connections except for struts (and fuel lines, which are strut-like). Only one of those fuselage stacks joins the top of the station to the bottom; the others just sort of jut into space without connecting. This is more of a problem because trying to launch the station strains the joint asymmetrically; with all respect to @HebaruSan's skillful piloting, it's still easier to pull it apart than to get it in the sky. There is a workaround, however: if you just have to have multinode connections, you can put docking ports on one of the quads and the four fuselages. When the craft loads, three of the joints will start free, but they will immediately dock and then you'll have your quad-connection. Keep that in mind if you ever want a ring station, too; otherwise, the only way to bypass KSP's connection rules is with a mod that lets you add struts in flight.

My gut reaction is to say that the volcanoes of the inner moon will be more spectacular than the eclipse. You're looking at a lot of tidal action here. My less-gut reaction is to offer you a link to a similar topic on another forum here. (I'm fairly sure that's not against any rules.) The discussion is from 2008, but that just goes to show you that this is something that has intrigued people before. The point made there about retrograde orbits is an interesting one; it complicates the question of formation, but appearances suggest that your system is possible.

@ineon is correct: When in orbit, 'down' (meaning 'down' from the camera's perspective) is parallel to the south-pointing axis. When suborbital, flying, or landed, 'down' is towards the centre of the planet. There is always a shift from one to the other when you make orbit or deorbit; pay close attention to your next launch and you'll see it happen when your periapsis climbs off the surface of the planet. Because Minmus has such low gravity, it takes very little to push yourself from orbital to suborbital and back again. Add an overpowered jetpack and you'll find that the 'boundary' you described is quite large. To keep it from happening again when you next go on EVA, try pressing 'V' to force the camera to go from automatic to a specific mode. That should keep it from switching on you. As to the navball changing, keep in mind that the EVA navball follows the camera rather than the Kerbal: change the camera and you change the navball, too.

When you absolutely cannot have drift, don't forget that you can land your relays: until they simulate continental drift on Kerbin, a landed sat is a fixed installation. When you absolutely need Kerbin coverage, you can also land a relay on the near side of the Mun. I like to put a sat with a KR-7 (the 25-degree antenna) on the near face of the Mun for this purpose. For Kerbin system coverage, I also like to stack a few dishes to different destinations on a big truss satellite that I put into an extremely eccentric polar orbit. The periapsis is about 75 km and the apoapsis is somewhere around 70 Mm--I forget the exact figure, but the idea was that the apoapsis would cover Minmus with a KR-7 at maximum possible separation, taking into account Minmus's inclination and orbital distance. This orbit has a period of something like 35 days, many of which are spent up near the apoapsis. I lose coverage when the sat is behind Kerbin at periapsis, but the eccentricity means that the satellite screams through that part of the orbit quickly. For losing coverage for about ten minutes per month, I'm not too upset with this arrangement. I don't have to worry about needing a lot of battery, either. The only real trick to this setup is that being in a polar orbit means that KSC doesn't easily connect to it; the solution is either to put another relay in keostationary orbit over KSC or else add some capability to your comsat constellation.

Nice network; I see you worked out the kinks. In the interest of thoroughness, I noticed on your screenshot that it appeared both of your dishes on the keostationary sat were pointed at Mission Control. In that case, they never were going to connect to what you had on the pad, no matter how you set it up. If the keostationary orbit is stable, then setting a dish to look at Kerbin would pick up everything on that side of the planet, including Mission Control, rovers, planes, and rockets--provided they have active antennae with enough range, of course. In a pinch, set one dish to Kerbin or Mission Control and the other to 'Active Vessel' and you won't have to worry about connecting. I try to be sure to keep a couple of 'Active Vessel' dishes in the Kerbin system just in case I whoops on an Omni's range or something similar. I use dishes if I don't have the DP-10 yet because they don't get ripped off in atmo, but there's a trick to them: even if you right-click them and select 'Start Deployed' in the VAB, that doesn't give them a target. Use launch clamps if you have them, or else start with a deployed Omni (just remember to retract it once you connect the dish to something!). I prefer to set up a relay with three satellites instead of four, mainly because I also prefer to do individual launches and it's a lot cheaper to do fewer of them (by almost 25%, in fact ). I set up my network with Communotron-16s at 777 km because it's not anywhere near any of my usual parking orbits; you can go anywhere from 600 - 850 km with that setup. Below 600 km, Kerbin blocks line-of-sight, and above 850, the satellites are out of range of one another. Going closer than maximum range, as I do, also gives good polar coverage--remember that space is three-dimensional, and that there's a well of dead zone over each pole in an equatorial relay setup. With the right relay altitude, your polar sats won't lose their downlinks if they are sufficiently high up, though you never will get good ground coverage.

I assume you're operating in space, where TWR and aerodynamic concerns don't factor so much. From looking at the rocket equation, it's clear that Isp is a dominant factor, but the mass ratio can overcome it in extreme cases. In the event of an extremely high engine mass or an extremely low fuel mass, the mass ratio (all other aspects of the payload being the same) negates the advantage of higher Isp. EDIT: Ninja'd!

Whoops, my mistake. I blame too much Christmas cheer. Actually, I was reading above about re-locking the steering and somehow turned that into locking the altitude. Derpaderpaderp.

It should be -, not +. The idea is that as the altitude keeps increasing, alt remains as last set, so the difference between them will only vary from 0 to 1000. Once it hits 1000, alt is increased another tick (setting the difference to 0 again), and the cycle repeats. If you make it +, then it responds to the sum, not the difference, which only increases. With alt set to 900, that sum would pass 1000 when the ship hit one hundred meters (100 + 900 = 1000), never reset, and then the pitchover code would run continuously, which is apparently what you observed. I think this line might be a problem: set alt to ship:altitude. This just makes alt equal to the ship's altitude. The difference is always zero, so it never runs the pitchover loop again, and you go straight up into space. Try this instead: set alt to alt + 1000. And see whether that helps.

Take a thermometer and you will see that Laythe's oceans tend to go down to 250 K at the poles, averaging at about 270 K across the planet--it's too cold for freshwater, and there should be icebergs and polar caps in such a situation anyway. High amounts of salt would prevent freezing, and some of the science information indicates there there is a lot of salt present, but it would increase the density of the oceans, causing your craft to float higher, not lower. Also, even salt may not be able to depress the freezing point enough in the polar regions to prevent the formation of ice caps. I cannot discount the presence of salt, but there is clearly something else going on. One possibility that would both prevent freezing and lower the oceanic density is alcohol. Clouds of alcohol have been found in space, but they are generally very large and associated with stellar formation. I do not know what process would cause Laythe to accumulate so much of it, but then again, it is also unknown what would cause Laythe to accumulate an oxygen atmosphere in the absence of life. When one considers that lethe is Greek for oblivion and forgetfulness and refers also to an underworld river that causes the same in those who drink of it, there's something rather poetic in the idea that a similar name could be used for a moon literally covered in booze. Maybe Laythe's atmosphere is actually perfectly safe to breathe, and any statements to the contrary are propaganda pieces from Kerbin's teetotalers and Anti-Saloon League.