Snark

If there's something about cool little known KSP things, and if it mentions waypoints, then it's probably just talking about the KerbNet thing mentioned above.

Well, yes. Other than that, I mean.

That's basically it, for the stock game. Pretty sure there are mods to give a different experience, maybe something closer to what you want. But I've never used any myself and don't know what the names may be. Perhaps you could ask over in Add-on Discussions?

Not that I know of. If you set a node before undocking, one of the resulting ships will keep it after undocking, but I don't know of any way to pick which one in the stock game. When it comes up in my own gameplay, I just make it a point to undock before trying to set any nodes.

Moving to Add-on Discussions. (Though it's worth noting that if you have a question about a particular mod, the best place to ask is usually in the mod's release thread, since that's where the author and expert users generally hang out.)

Hello, and welcome to the forums! Moving to Add-on Discussions, hopefully you'll get some answers. Though it's worth noting that if you're having issues with a particular mod, the best place to ask is usually in the mod's own release thread, since that's where the expert users (and author!) generally hang out.

Moving to Add-on Discussions.

This. It's Scatterer. I get it myself from time to time, seemingly at random, usually just when I'm launching from the vehicle editor. Have never bothered to count statistics, but I'd guess I get it about 1 launch in maybe 20 or so. Whenever I launch to the pad and happen to get this, I just hit the "revert to launch" button and it goes away. If you're getting it at some other time, I'd suggest doing a quicksave/quickload to twy making it go away, or perhaps go back to the tracking station and then back to the ship again. Hopefully this will get you pointed in the right direction-- would suggest directing further inquiries to the Scatterer thread. (Moving thread to Technical Support.)

What's the exact text of the contract?

I've found that the issue with Gilly isn't much to do with level ground. If you're bouncing on a slope, you'll bounce where it's level, too. A couple of things: Make sure that the "solid" part of the drills (i.e. the part with a collider, that doesn't include the telescoping portion) doesn't touch the ground when you swing the drills down to deploy them-- i.e. make sure that your drills are mounted high enough on your lander. The drills "jiggle" while running, and if the uppermost short "sleeve" touches the ground, it'll keep jouncing you. As long as that part doesn't touch the ground, then the drills will impart no motion to you and you're fine. Make sure that your landing legs are tuned appropriately. YMMV, but in my experience, the "auto" setting for spring / damper isn't super great and tends to result in oscillations. Try cranking the spring setting fairly low, and the damper significantly higher than the spring.

Some content has been removed and/or redacted due to personal remarks. Let's remember that we're all friends here, and avoid personal criticism. Thank you for your understanding.

Sure, if the physics engine they're using supported that, which it doesn't. Thus the problem.

Or indeed a buoyant balloon, which would work great in certain atmospheres, has the advantage of making local gravity strength irrelevant, and may or may not achieve your purpose, depending on what the mission is.

It's easily observable. Don't take my word for it, set it up yourself. There are plenty of ways you can set up a reaction wheel at the end of a loose-jointed contraption and it's easily visible that it's the reaction wheel itself that's twisting around. For example, build a mobile with various reaction wheels dangling on "ropes" of floppy joints, and only the one that's turned on will flop around when you give it control input. Not really a problem-- the laws of physics are the same in both cases. Yes, it does exactly the same thing in orbit, as one would expect. And if you make it easier to observe by slowing it waaaaay down (e.g. by reducing the control authority on the wheel to 1%) and change its mode to "Pilot Only" and play with the pitch/yaw controls a bit, it's very visibly obvious that it's just the wheel itself that has any torque on it. Yup, that's not gonna work, because the input to reaction wheels is global (whether from SAS or from player input); it's just their torque output that's applied at the part itself. So that test's not doable in KSP. However, you can build strings of floppy hinges to make flexible "ropes", which makes it pretty easy to see where the torque is. My example is just a very simple one-- there are more complex constructions you can build that make it even more obvious. (Example: Have your probe core rigidly mounted to launch clamps, a fair distance above the launchpad. Have a loose/floppy string of hinges hanging down, with a reaction wheel on the end. Play around with the pitch/yaw controls while SAS is off. It becomes very obvious that it's just the reaction wheel that's torquing itself around. You can have multiple reaction wheels dangling like Christmas ornaments from multiple ropes, and try turning them off and on, and only the ones that are turned on will be affected.)

I believe that this is not the case. Reaction wheel torque is absolutely applied at the reaction wheel itself, now, which is easily demonstrated by inserting a free-floating hinge in between the control point and the reaction torque: ...That's completely hands-off the controls, there. It's just SAS that's doing that. The hinges are set to unmotorized, no damping (i.e. freely flopping), limits of motion set to plus-minus 15 degrees from center. All I did was launch to the pad and set SAS to hold . It freaks out because it's trying to hold the probe core perfectly upright, when it's mounted on a floppy stalk at the opposite end from the reaction wheel. So what you see above is basically the floppy-station problem, exaggerated and in miniature. It's because KSP's SAS is implemented in a fairly straightforward, simple way that essentially assumes a rigid system. When you have a floppy system, especially one where the source of torque is physically separated from the control point (and therefore there's a delay between applying torque and seeing a result)... this is what you get. The cause-effect delay causes PID tuning problems. Speaking as a KSP modder with a fair amount of familiarity with the game's internals (at least the ones accessible to modders, which is a lot), I'm pretty sure it's worked this way (i.e. "torque is applied at the part with the reaction wheels", not at CoM) since forever-- or at least since well before 1.3.

As folks have said: totally depends on the situation, and what you're trying to do. You need to be more specific. What kind of atmosphere? What gaseous mix? What temperature and pressure? What sort of vehicle do you have in mind-- an airplane, a rover? How fast do you want it to go? How long does it need to be able to operate? etc. etc. Electricity's a great option for many applications, not least of which is that in many circumstances you can make it without needing to expend consumables (e.g. solar panels, RTGs). But whether or not solar panels or RTG are viable for a given application depends on circumstances. Solar only works if you're close enough to the sun to generate the power levels that you need, works only in the daytime, depends on the orientation of the panels relative to the sun, and is vulnerable to clouds / dust / dirt / etc. RTGs run for years and years, but they're heavy relative to the amount of power they generate-- great for rovers, probably not so great for airplanes. Piston engines are heat engines, so their maximum possible efficiency is limited by Carnot's theorem, which is determined by the temperature of the combustion chamber relative to the environment. So how efficient that's going to be depends a lot on what you're burning and what environment you're in. Note that one thing that both fuel cells and internal-combustion engines have going for them, on Earth, is that they get their oxidizer for free from the ambient air, meaning that they only need to carry the fuel. In certain atmospheres, you could turn that on its head: instead of storing only fuel and getting oxidizer from the air, you store only oxidizer and get fuel from the air. For example, if you're on Titan, the atmosphere is over 5% methane. So, in principle, you could have a vehicle that simply stores oxygen (or some other oxidizer) as its "fuel", and then uses atmospheric methane to react with. Whether that's at all useful relative to an RTG or something is another matter, but it's an interesting idea to think about.

Moving to Add-on Discussions. Planet packs that I have used and enjoyed: Outer Planets (a.k.a. OPM): Adds a bunch of new planets to the outer fringes of the solar system, leaving the stock system untouched (other than moving Eeloo to becoming a moon of one of the new planets. Beautifully done in a stockalike art style that meshes well with the stock system. New Horizons: Completely rearranges the solar system. All the stock bodies are still there, but rearranged (e.g. Kerbin becomes a moon of a gas giant), and lots of new planets/moons with some interesting gameplay properties. Galileo's Planet Pack: Completely replaces all stock bodies and has some interesting designs. Snarkiverse: This is my own. Pretty minimalist-- doesn't actually add any new bodies to the system at all, but rearranges them to add new gameplay challenges. Since it adds no new artwork, it has minimal memory footprint and may be useful if you're playing on a lower-end system. (Compatible with OPM and Kerbol Origins, if you're also running those.) JNSQ: Still under development, but playable (it's what I'm trying out on my current KSP career). From the same folks who brought you Galileo's Planet Pack. Keeps all the stock bodies, but scales them up 2.7x and replaces their artwork completely, and sizes / distances are adjusted, and adds new planets/moons as well. It's also worth giving a shout-out to Alien Space Programs, which isn't really a "planet pack" per se (it doesn't add any new planets or move anything around), but it does switch the home planet (i.e. KSC) to be something other than Kerbin, with a variety of options to choose from. So, for example, you can play with Duna or Laythe or other places as the home world, which gives KSP quite a different feel, particularly in career mode.

With rare exceptions, gravity assists are only going to save you a pretty small amount of dV, not thousands of m/s. The extra hassle of trying to set them up will likely far exceed the extra hassle of putting an extra 100 m/s of dV into your rocket in the first place. Do you really want to spend an extra hour fiddling around trying to set up a Mun slingshot so that you can save 100 m/s of dV? Not to mention the fact that they're tricky enough to set up that there's a good chance you'll need to do a correction burn afterwards to adjust your aim, and the correction burn could easily end up being bigger than the "savings" in the first place. The one place in the solar system that I've found that provides both a dV savings big enough to be worthwhile (i.e. several hundred meters per second) and pretty easy to set up, is using a reverse gravity assist at Tylo or Laythe in order to capture to Jool. Other than that... seriously, it's just not worth the bother. It's a lot of extra hassle for very little benefit. Which is fine if you like the hassle (i.e. you're doing it for the challenge) ... but otherwise not something that's worth it. Note that I'm speaking of the stock solar system. Modded solar systems may provide other opportunities.

Some content has been removed and/or redacted due to personal remarks. Let's remember to be considerate to each other, please. In particular, this means don't make personal comments about fellow forum members. It's fine to be constructive, it's not okay to engage in name-calling or finger-pointing. Also, please remember that if you're not a moderator, it's not your place to tell anyone what to do or what not to do. That never ends well, and basically accomplishes nothing but starting flame wars in which everyone loses. If you see someone behaving in a way that you believe is so egregious that it's actually violating forum rules, then by all means report the post so the moderator team can have a look. But if it's not violating rules... then it's not your place to criticize. Thank you for your understanding.

Nope, that's pretty much it. Of course, you can leverage your knowledge. Unlike me, you know what all the mods you've installed actually do-- at the very least, I expect you'll have somewhat of a clue which of them may be tinkering with resources in stock fuel tanks. So that may help you narrow it down more quickly. If you're a dab hand with scripting tools like perl or whatever, you could always grep your GameData tree for MM-enabled .cfg files that contain the string "RESOURCE", or something like that, I suppose, which might help give some idea. But yeah, short of something clever, Ye Olde Binary Search process-of-elimination is basically it.

Thanks, but your full mod list isn't actually helpful to me, since of course I haven't the faintest clue what most of your mods do, technically, because I didn't write them and don't use them myself. That gigantic list does make it overwhelmingly likely, though, that it is indeed a mod interaction with something in there. So, what you need to do is to establish which mod you've installed is incompatible with SimpleFuelSwitch. Once you've done that, then it'll be clearer what a solution might be. Let us know what you find out!

Glad to hear you sorted out your problem! For anyone else who may be reading this thread and wondering the answer to Space Nerd's question above: yes, Laythe can definitely do that. Laythe reverse assists can also be very helpful, just like Tylo's. The instructions for a Laythe assist are pretty much the same as for Tylo, as described above. I've never tried to quantify exactly how much dV one can squeeze out each one, but it's "hundreds of m/s" in both cases, and both of them are good enough to capture to Jool from an interplanetary trajectory. The main difference is that Laythe has an atmosphere, which means that aerobraking's another potential tool on the table, depending on ship design-- which obviously isn't a thing on vacuum-clad Tylo. Which one's "better", in general, depends on circumstances and intended mission profile. Laythe has aerobraking, which is great if you're equipped to take advantage of it. But Tylo has a higher orbit and is easier at capturing to a less-eccentric Jool orbit, which can save you some dV if your destination is one of the upper Jool moons.

Are you doing it for the challenge (i.e. precisely because they're hard)? Or are you trying to use them to make life easier, i.e. "Oh, I'll use a gravity assist to save myself some dV so that building my rocket will be easier!" If it's the former, then great-- nothing wrong with that, a big part of KSP is all about finding interesting challenges for yourself. If it's the latter... honestly, I gotta say that in most cases, my experience has been that they're far more trouble than they're worth. It's pretty straightforward to build a ship in KSP to get anywhere you need to go without needing a gravity assist... and gravity assists are hard. They're difficult and finicky to set up, they're really hard to make accurate enough to get what you want, and in most cases they honestly don't give you all that much advantage (i.e. the dV savings is minimal). In other words: lots of time and effort for minimal benefit. The one place I've found where they make sense to me (i.e. provide a large benefit for minimal effort)-- in the stock solar system, anyway-- is using Tylo or Laythe to do a reverse gravity assist for capturing to Jool. Done right, this can save several hundred m/s of dV, and they're pretty straightforward to set up. Detailed instructions for setting up a Tylo reverse assist here:

Well, yes and no. Yes, in the sense that those are indeed errors relating to the config files from this mod. No, in the sense that SimpleFuelSwitch works just fine for most folks, so it's just broken for you-- which means there's something about your local installation that's giving SimpleFuelSwitch a tummy-ache. My guess would be that it's some mod interaction, but that's just a guess. In any case there's not much I can do about it from this end, since it works just fine for me and there's no way for anyone other than you to know what's going on with your local install. First off the bat: what version of ModuleManager are you running? (I suspect you're fine, here, just a sanity check to make sure you're not running some old version.) Assuming that your MM is up to date (version 4.0.2, which is what's installed with SFS), then I'd guess it's some interaction with some other mod on your system that tinkers with fuel tanks in some way. What other mods are you running that touch fuel tanks?

Hello, and welcome to the forums! Moving to Kerbal Network, since it's about purchasing the game rather than the gameplay itself. That will entirely depend on where you bought it from. Where did you buy it?