Zhetaan

For my part, I'm interested in the fact that after all this time since Chapter One of Duna, Ore Bust!, we're finally getting close to the point where Starhawk's customary farewell runs to a second line. Come on, @Kuzzter! Pour on the suspense!

It's in the opening post immediately below the video. Or you can click on this.

@TheKurgan: Variance adds noise to the resource distribution. It makes the concentration more 'spiky' on the map; that is to say, it introduces a pseudorandom element that causes the concentration of a resource to vary around the mean abundance value. This element allows the concentration at a specific point to 'swing' between extreme values, and the variance adjusts how far apart those extremes are. The idea comes from statistics; for example, a set of concentrations {5, 5, 5, 5, 5, 5} has a mean of 5 but zero variance. A set {0, 0, 0, 0, 5, 25} also has a mean of 5, but with one hundred variance. I do not know whether variance in resources is the same as variance in statistics. Dispersal, if I recall correctly, was added after Regolith was added to the stock code, so there's no source to consult. Of course, this also means that what I just said about Variance could well be out of date. However, I believe it further modifies the variance. @DMagic said once in the SCANSat thread that he thought Dispersal affected resource concentrations within a biome and Variance affected concentrations across biomes (meaning that Variance randomised the average concentrations of global and planetary resources, and Dispersal randomised the point-specific concentrations within biomes. He also said that there was an old bug in the Karbonite resource config that the Dispersal was set to zero and that this caused there to be no variance within each biome (in other words, the biome's average concentration was the only concentration anywhere). This lends a lot of weight to the idea, but lacking either actual code to consult or word from The Man Himself, the best way to find out what it does is to try modifying the config between extreme values to see what happens.

@NoobTool: This is a wild guess, but if flipping the pylon around didn't fix the issue, then it may be that the pylon is coded to remain on the daughter part regardless of the orientation. Try setting your small plane's cockpit as the root part and see whether that helps. You may need to play with it a little to get the launch orientation right.

True, but the story was about a rescue mission to a research station on Pluto that had to get there in something like a week. The plot always needs high gees. The central drama of the story was about whether the pilot had the courage necessary to essentially sacrifice himself for that mission while also possessing the fortitude to survive long enough to complete it. The sacrifice-for-the-common-good is a common idea: it had been done earlier, and possibly better, in 'The Cold Equations', and is seen in sci-fi and action movies all the way up in popularity to Star Trek II, where Spock had to fix the warp drive before either the ship was destroyed or the radiation killed him. The difference in 'Sky Lift' was that the pilot had to continually make the decision to ruin his body over the course of days; most examples of this device are more swift in their mercilessness. That being said, the addition of G-tolerances in KSP makes these kinds of considerations possible. A little bit of coding (such as with Kerbal Launch Failure, Dang It!, Entropy, and others) can make them dramatic. Imagine running a life-support mod and a tank of supplies at a colony somewhere ruptures. The only ship that can get there in time to bring relief is also going to kill four crew with G-forces to do it--and that's assuming it doesn't rupture itself in the attempt. The ship can make it--it has a probe core--but the crew cannot, and if something goes wrong after the crew is unconscious or gone, then everybody dies. Do you go?

Super fast interplanetary travel: You're describing torchships, to borrow Heinlein's word for them in Farmer in the Sky. Clarke and Niven also wrote about constant-acceleration drives; Clarke specifically in 2061: Odyssey Three and Niven in nearly every Belter and ramscoop story. Heinlein's 'Sky Lift' features torchships specifically, and pays quite a bit of attention to the health problems involved with flying at extremely high gee for weeks on end. If you use a combination of Freight Transport Technologies and Karbonite Plus (both USI, both with dependencies), you get torch drives in KSP. The solar sails mod that @Streetwind mentioned was really made for long-term, low-thrust drives, but unless there's a thrust limit, I don't see why it wouldn't work for torches. Getting it to work in the background would be trickier, though. Automated space exploration and construction: I'm honestly not sure that there's a market for this in KSP. Automate space travel and construction, and you turn KSP into an idle game. I think that the closest you get to scheduling, off-world construction, and automated flight would be a weird admixture of Kerbal Construction Time, Extraplanetary Launchpads, and Routine Mission Manager. The problem is that Routine Mission Manager only works for launches from KSC to Kerbin orbit. Politics and conflict: You get the rudiments of politics in State Funding, and while there are plenty of weapons mods, there's no AI for any of them. Maybe with multiplayer, you could do this (you'd need an alternate space centre for the enemy, though), but there's no single-player alternative for what you're asking here. I don't doubt that it could be fun, but then again, that sounds more like Space Engineers than KSP. Surface and space events: Nertea's Radioactivity gives you deadly radiation belts. As far as cool-looking environments, be patient and you'll get it. As far as those environments being hazardous, I'm on board with you there; I like the idea that landing on Duna during a sandstorm could cause my solar panels to fail, or that winds on Eve could throw my rocket into a corrosive pool. I have no idea how many mountains of code it would take to make that happen, though.

Indeed; that stain is the *splorch* to which I refer. I'm also referring to the scene after that (though the mug is much brighter) and the one two scenes later, where the Koffee mug, in all its pristine glory, sits on the map of the world. I assume that the dear departed Supreme Leader surely must have had a delayed *poof*. Now that I think about it, that may explain some of the allure of violent murder among the Kerbulans: there's no body to hide.

Does that include being bludgeoned to a paste with a Koffee mug? I wondered how that mug got so clean so quickly, given the big *splorch* of blood on it.

To flesh out that history a bit, before Regolith, Karbonite originally used ORS (and then RoverDude's fork, ORSX), which was the KSP-Interstellar resource system. ORS had the advantage of being concentration-based, meaning that if you found a good deposit, it would never run out, but the disadvantage of being totally nonrandom. In other words, once you knew where the goods were, every game had you going to the same spot, which rendered the exploration side of it irrelevant after you played through it once. The great advantage of Regolith was arguably not the biome-based resources so much as the fact that each game had a different, random resource distribution among those biomes, which increased the replayability by leaps and bounds. A moon of Jool, for example, might be totally lacking in a resource, thus forcing you to create a freight infrastructure, where your next game wouldn't require that--or would require something different. Regolith also lets you define resources absolutely, so ore will never be found in the ocean, and water will always be found at the ice caps, for example. Granted, that's more relevant to MKS, not Karbonite, but Regolith was built for both. The big difference between Karbonite (the resource, not the mod) and stock ore is that Karbonite can be used directly as a fuel, no ISRU converter required (correct engines and tankage, however, are required). Ore, on the other hand, is used only to either make LFO+Mono or to provide ballast for stock submarines (also for those 'Bring X Amount of Ore to Planet Y' contracts, but the ore isn't really doing anything in that case). Karbonite can be found in atmospheres and oceans, but ore cannot (the oceans are especially nice, and a big selling point if you're only looking for an alternative to stock ISRU mechanics for Eve and Laythe) (On the other hand, it's easy enough to mod ore so it's found in the oceans, too). The Karbonite-burning engines all tend to be very-low-efficiency-but-ungodly-high-power parts. The description of one Karbonite engine says using it is like 'riding a crazed robot made of explosions'. It's not wrong: you can rip rockets apart with Karbonite engines if you're not careful. There are a couple of other little extras in Karbonite (the mod) that do things like-but-not-quite-stock in there, too: there are Karbonite fuel cells, Karbonite engines that produce monopropellant as a side product instead of EC, refillable Karbonite SRBs, and so on, so I would hesitate to say that it doesn't do much different from stock, but I would agree that stock does blunt it a bit: a lot of what it does that is different was crowded into more of a niche role by the stock mechanics. Then again, it could be said that all mods serve a niche role, so that's not really a problem.

Also, there are zepto- or 10-21 and yocto- or 10-24. And you're right: there are no official names after that. A zettametre describes distances between galaxies; a yottametre describes the sizes of superclusters. At these scales, megaparsecs make more sense--assuming, of course, that any measure of such distances truly makes sense. On the small side, a zeptometre is ten thousand times smaller than a proton--again, assuming that 'distance' at such scales makes any sense. It and the yoctometre sit uncomfortably between the range where ångströms are useful and where you really should just be using multiples of the Planck length.

Correct. The effect results from the properties of the fuel, not the engine, and thus would be the same for every engine you altered in this way. Delta-v derives from three things only: the exhaust velocity of the engine--unchanged if you didn't touch the Isp, the dry mass--also unchanged, and the wet mass, which, assuming you did not change the number of units in the fuel load, must mean the fuels have differing intrinsic properties. SolidFuel has a density of .0075, whereas LF and Ox each have a density of .005. This alters the mass ratio and is the source of your extra delta-v. Edited to add: Actually, there's more going on, given the bipropellant versus monopropellant nature of the fuels, but it's always more complicated than it says on the package. The good thing of it is that LF and O are given the same density (totally unlike real life), so you can simply treat them as one resource and add them together. Given that you are seeing a delta-v increase, I assume that you are adding the previous LF and O values together and giving the engine the same number of units of SolidFuel as that sum. Reduce that SolidFuel load by one third and you should see the correct performance.

@Gamel0rd1: If I recall correctly (my numbers are approximations; I don't have my calculations handy--and I'm sure that there are others who will be all too willing to correct my misinformation), SSTO ascent from Eve is only possible from altitudes over 6,000 m and even then only with an atmospheric (Kerbin rating, not Eve) ISP at or above 290. Only three engines can do that, even in theory: the Aerospike, the Vector, and the Mammoth, and the Aerospike cannot SSTO from Eve because it lacks the needed thrust. On the other hand, it can be done: it has been done. What I do not know is whether such a craft can reach and return from all other bodies of the system in addition to Eve. You would have to design your craft as an Eve SSTO first and then work from there, always building and designing within the limits of an Eve SSTO. Unfortunately, those limits are beyond insane, as has been pointed out ... but still, it has been done, so maybe there is more to do. Regardless, if you want to try this, you really ought to start with the Eve craft and go from there. I'd suggest looking at the Eve SSTO Limbo Challenge for ideas on craft, and also to gain a better understanding of how to work this sort of a mission.

1. The trick to getting the spacing correct is resonance. If you want to start at 80 km, go ahead, but it's not going to help you space the satellites correctly. There are a few ways to do it; with four satellites, the various ways distil to two general methods: First, you can set an orbit with apoapsis at the stationary orbit, but when you're there, adjust the periapsis so your orbital period is one quarter (quarter because you have four sats) the orbital period. A stationary orbit is six hours, so one quarter amounts to an orbital period of 1.5 hours. This may not be possible on Kerbin: the periapsis for this orbit may be in the atmosphere or under the surface--you can tell that I don't use this one much. Second, you can go to the stationary orbit and instead opt for an orbital period that is either three quarters or five quarters. This orbit is much more like your final orbit, so it takes less fuel to circularise everything, and more importantly, it is far less likely to graze the atmosphere or otherwise run into issues. 2. I'm not certain I understand the query here. If it's a single-launch, multiple-payload mission, I prefer to decouple via right-click on the decoupler or separator rather than bother with complicated staging. Make certain that any antennae you need are deployed so you don't lose control of anything. To switch from one craft to the next, press the square bracket ([ or ]). If you're putting engines on the satellite and want to use it to circularise, then make certain you decouple before you reach the manoeuvre node. If you're using a transfer stage to do the orbital placement, then make certain your separators have their decoupling force tweaked to zero. 3. Geostationary delta-vee is theoretically 4,515 m/s. From an 80 km orbit, it is theoretically 1,115 m/s. This is from the delta-v map on the wiki. If you're launching one lifter to orbit and then using the sats to circularise, then each sat needs at least 1,115 m/s. Some amount of fuel on the sats is usually a good idea, if only for the fact that you probably won't get the placement exactly perfect and will need to adjust the satellites to compensate for orbital drift in ten years or so.

You may have accidentally set trim and need to clear it by pressing Alt-X. Do you have reaction wheels, or are you primarily relying on RCS jets?

@Victor3: Try the forum search tool, instead: Precise Node Precise Maneuver There are quite a few mods that are not posted to Curseforge; many post to SpaceDock or Github exclusively. The forum is your best place to look for a mod, either because it's here or because someone who uses it is here. Also, and this is even later to the party, but your son is right: calculators and planners are great, but at the end of the day, you're the one who has to fly the ship.

There's a GitHub issue that's been up for a while, but as was mentioned earlier, development has been slow. The code doesn't really tell much except that the weird toggle behaviour is part of the UI, which was added rather recently compared to the rest of the mod. It clamps slider values at or under .49 to zero and values over .49 to one--and since the slider is polled for a multiplier value after the .cfg, changing the setting in the .cfg won't help. I believe the current thought is that it was either some test code or a copy-paste error, because it certainly makes no sense as it is right now.

So long as RO exists, there will be interest in RemoteTech, and I strenuously doubt (no, really, I'm hurting myself by doubting so hard) that RO will go away any time soon. Additionally, from what I'm seeing, the stock antennas don't even reliably reach Eeloo all of the time, which means anyone using RSS, OPM, or any of the scale refactor mods will need to modify the stock system anyway. What better way to do that than to use a ready-built antenna system that's made for this kind of thing? What I am more curious to know is how difficult it will be to make the 'ready-built' part of that statement true. Does 1.2 so thoroughly break RT that a total rewrite is needed, or can we get back to familiar behaviour with relatively minor modifications?

*Faceplam* Oh, criminy ....

@aluc24: Or if, after I've espoused my whole 'life is a journey, so enjoy the trip' philosophy, you've decided that I'm full of kowmulch, you can use this feature, which I only now learned existed: Respects to @LN400 and @Diche Bach for pointing it out. Just from looking at the buttons and what I can make out of the code, the way this works is that the mode shown lets you specify waypoints by latitude and longitude, select a speed, and set up your trip a waypoint at a time as you would with a GPS. As a mostly blind guess, the Hdt. mode may let you do the same thing, but by picking a direction and a distance rather than a target coordinate, so it's more like a dead reckoning tracker--but I do not know yet because I am not at my KSP computer right now. I'll get back to you on that. Edit: 'Hdt.' is indeed a DR tracker, or acts along those lines. You tell the rover to go a certain distance along a certain heading from its current position, and it will go there. My test rover was just a RoveMax with a 1k battery, solar panel, DP-10, and four ruggedized wheels (two with motors off and two with steering off), so it may have been too torqued, but from that testing, it did seem that the steering PID needed a bit of tuning. It tended to overcorrect. 'Fine' appears to tell the rover to go a certain distance while steering at a certain angle, though I admit that I did not play with it much. Also bear in mind that unlike the 'BURN' and 'EXEC' buttons on the first page of flight computer controls, the rover 'DRIVE' command is to press enter in one of the input boxes (hint to the devs--a 'DRIVE' button would be less ambiguous).

@aluc24: It takes a bit of planning, just as a real-life mission. Avoid awful terrain, zoom out a little so you can see what's coming, and feel free to turn down the drive motors (it's a tweakable that you find by overriding traction control) to give yourself a bit of cushion until you can get used to the delay. When I send rovers to Duna, for example, I tend to do it Pathfinder-style and send a base with the heavy, non-repeatable science modules (Goo and Jr.), the big antenna, and the power structure to run it, and a micro-rover in a service bay that I decouple and can run around with. The rover has all of the repeatable science (barometer, thermometer, &c.). I tend to land near the borders of biomes so I can rove around, pick up the repeatable bits of science, and transmit them back. The key is to set the motor controls so that pressing W doesn't cause the thing to jump and to set the camera so that you can see what's a minute ahead of you, because if you see a bad thing coming sooner than that, it's too late to stop it. I admit that this play style isn't for everybody, but I enjoy the almost otherworldly disconnection from the spacecraft and the need to know what I plan to do a minute before I see it happen. Once I got used to it, I found that knowing in advance what I'm going to do frees me up to enjoy the experience of going around with a small probe to see what there is to see on Duna--I rather take a cue from @Overland on that one. He likes rovers so much that he chains them together to make trains and runs all over Kerbin with them. I don't know whether he's even been off-planet in the past year; there's a lot to see on the planets in KSP, and if you're going to get into a rover to take a look, you may as well take the time to enjoy the view. So yes, it's slow, but it can be rewarding in its own way. It's only frustrating if you want to get to Point B right away--in which case, I agree that signal delay is not for you. There certainly is no shame in that--the option to turn it off exists because there are people who find that fits their play style better. So long as you're having fun, you're winning the game here.

Not impossible; just slow. They do this with Opportunity and Curiosity every day--or every sol, I should say. I'll say it took some getting used to, but it works for me. In fairness, though, I don't use probe rovers further away than Duna and Eve.

All right, the on-board oxyhydrogen generator is a scam, the first and second laws of thermodynamics still apply, and that's all well and good. I'm curious to know whether there could be any benefit to off-loading the production of the gas to a stationary unit. That is to say, if you happen to have a solar system or wind turbine and can get the electricity essentially for free, is it possible to store the gas and use it as a supplemental fuel source? Obvious concerns that I can come up with are: 1) that the gas could wreck the engine or otherwise cause damage to internal components, thus reducing the life of the vehicle and costing more than is saved in fuel, 2) that the gas cannot be stored at high pressure lest it explode, thus making it impossible to use except in the aforementioned scammy on-board generators, and 3) that the gas, even if it is relatively safe both to use in the engine and to compress for storage, simply does not burn well enough or efficiently enough to recover even the limited expense of generating it--essentially, unless one had an industrial complex making the stuff, the vehicle would burn through the supply faster than it could be generated, even at 100% production. In other words, is the oxyhydrogen gas quintessentially uneconomical, or is it only the on-board generation units that are the scam?

In standard RemoteTech, you need a command station so you can reduce the signal delay to something that doesn't ruin your reaction time. It is certainly possible to program a landing with the flight computer, but it is tedious and depends on several factors, specifically knowing exactly where you will land, exactly what your flight characteristics are, and whether there are any funny terrain obstacles in the way that will ruin the landing. If you make a mistake in any of the calculations for one of your burns, then it will carry down to the others and there won't be anything you can do about it. Doom and gloom aside, it is possible. I don't bother with it, myself--I use kOS--but if you're willing to put up with the fuel requirements needed for a really inefficient landing, you could always try a series of burn 'steps' to bring your lander down with enough control to survive most miscalculations.

In fairness, people aren't putting RTGs on launch clamps per se; it's just that ModuleResourceGenerator works as an infinite power source simply by failing to specify an input. Doing this to the launch clamp makes a good simulation of the electrical umbilical that real launch towers have (after all, pad power may as well be infinite). Of course, using the same configuration for RTGs (unfortunately and in fairness to you, the lack of input is the only thing that distinguishes RTGs from any other electrical generator) merely serves to further highlight this mod's usefulness to my mind. KSP has functions for exponential decay: you see it in the research rate of the mobile processing lab, and possibly in a very approximate form in the diminishing science return of repeated science experiments. Why Squad chose not to implement this code for RTGs, even with cartoonishly long half-lives, escapes me. Cool! *Looks back at the research now rendered obsolete* Still cool! I'm looking forward to see what you do with it. The reason I like this mod so much, and the thing it offers that no other mod offers, is its uniquely final time limit on missions. There are plenty of nuclear power and life support mods out there, but for all of them, the challenge is one of bringing enough supplies: in the end, it's about launching larger rockets, and once it's in orbit, it's halfway to anywhere. Take ISRU and it's halfway to everywhere. This mod, on the other hand, brings about an entirely different logistical challenge. With only x days to complete the mission, including travel time, and no replacement fuel units, no rare finds of funny mineral deposits, no anything other than the RTG and the fuel load it got at the factory, it becomes more attractive to look for alternative flight plans and mission profiles. It puts pressure on you to pack the most mission into the shortest time possible, and I've had some amazing ones (to me, at least). Everything is a trade-off in a way that neither 'moar boostrz' nor time warp can fix, and that has a lot of appeal to me. So thank you very much.

This is by far the most coherent explanation, both in-universe and out, for all of Kerbin's crazy density shenanigans. I love it. There is one thing I'm curious to know. Perhaps it is picking too many nits, in which case I will remove the comment, but I figure there's no harm in asking: