Snark

Moving to Add-on Discussions, since this is a question about a mod rather than the stock game. 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 thread in the Add-on Releases subforum. That's because that's where the mod's most experienced users (and the author!) tend to hang out, so it's the best audience for finding you the answers you need. Good luck!

As @bewing correctly points out above, the Communotrons won't help you at all for your relay power, since they're direct antennas. All that matters is the actual relay antennas. RA-100, like most antennas, doesn't stack linearly. It's an exponential fall-off. The actual antenna power is: take the number of antennas, raise that to the 0.75 power, and multiply that by the power of one antenna. You have 9 of them, so 9 ^ 0,75 = ~5.2. Therefore, as bewing points out, At its outermost orbit, Plock is beyond that (689G), so this comsat won't reach that far as a relay. The issue that you're running into is that the stock antennas were designed to work with the stock solar system. If you're working with solar systems that are much bigger than the stock one, this has the potential to cause problems. There are various ways to deal with this. One way is to use some combination of multiple-hop relays with spamming lots of RA-100. Another way is to use a mod. If you're open to the idea of using mods, here's a mod with a giant 1000G antenna, specifically designed for playing in larger-scale modded solar systems. It includes a compatibility patch for Outer Planets:

Moving to Gameplay Questions.

Well, at least at a very rough level, just look where the camera is pointing (i.e. at the middle of the screen). Unless you manually set the camera to focus on sometihng else, by default the game always points the camera at the CoM of the current vessel. So you can just look at the center of your screen and that's it. (It's easier to see where the spot is if you rotate the camera back and forth a bit-- the CoM is the part in the middle that doesn't move when you rotate the camera, because it's at the center of rotation.) Dunno if that's good enough for your purposes, but it can give you at least a rough idea.

For making extremely fine-grained adjustments to orbital period, of course it's good to have the thrust as tiny as possible. However, you can also reduce your effective thrust by a factor of 10 or more just by pointing your ship in the correct direction. The idea is to leverage cosine losses, same as you've done with your angled-mount RCS thrusters here. But instead of angling the thrusters on the ship, you simply angle the whole ship. Longer explanation is below, but the TL;DR is, don't point your ship or . Instead, point it just barely on the or side of (or one of the other three cardinal directions). This will give you a massive cosine loss that allows making very fine-grained adjustments to your orbital period. Lengthy explanation in spoiler. I use this method all the time, and it works great. I don't use KER myself, but I do use BetterBurnTime, which provides a feature that shows (to the millisecond) how far off your orbital time is from another target's. My comsats usually have some little engine on them like a Terrier or Spark. I just reduce the thrust limiter down to the lowest it'll go above zero (0.5%, IIRC), then use this cosine method I describe here. Works like a charm, and I can pretty easily adjust the orbital period to within 1 millisecond.

Yep, that's your problem right there. It's really far back. Unless you can figure out some way to move it forward, you're gonna have some problems. You could scootch that LV-N forward a bit and clip about 2/3 of its length inside that fuel tank... that would help with the CoM, but not sure if you're okay with the aesthetics. Probably the easiest way to move CoM forward would be to take those two "outriggers" (the ones with the aerospikes on them) and slide them way forwards, so that the aerospikes are closer to the middle of the plane rather than the rear. Another problem you have is that you have very little control authority. With the CoM so far in the back, those ailerons on the trailing edge of the wing have very little lever arm to work with, since they're not very far behind the CoM. So you need to figure out some way to get pitch authority from control surfaces that are not close to the CoM. One thing you could do would be to add some canards to the front of the plane, as far forwards as you can. AV-R8 winglets work well for this. Set them to reduced range of movement, and I'd advise giving them pitch authority only. Since the CoM is far to the rear of the plane, that means that canards up front will have a really big lever arm to work with and ought to help with stability quite a bit, as long as you don't let your AoA get too large. Have you made sure that your vertical stabilizer has roll authority disabled? (It's on by default-- you have to manually turn it off.)

Moving to Technical Support.

Just a little reminder, folks, that this question was asked three months ago. So additional discussion is all well and good, but it's likely that the OP has gotten things sorted out by now. Ions are gonna have trouble out at Jool and beyond; there's just so little sunlight available. If you're going out to Duna or beyond, yeah, you're gonna need to spam a lot of panels. Where ions really shine is for missions to the inner solar system, especially Moho. The sunlight's so bright down there that you don't need many panels; plus, Moho missions need tons of dV, and that's precisely what ions are good for.

So, this plane, then? It looks to me like the CoM is probably too far to the back of the plane. Could you post a SPH screenshot that has the CoM display turned on? (yellow-and-black checkered sphere). (Especially with all the changes you mention, since that could have a major effect on the plane's stability depending on what you've got where.) I have some suggestions if my hunch is correct, but I don't want to make assumptions without actually getting an accurate picture of the CoM placement. Also... is there any chance the plane may be bending? You've got a long narrow plane with only 1.25m stack and a whole bunch of stacked parts, meaning a lot of part joints-- that's the sort of scenario that can easily lead to bending under stress. If the part of the plane in front of the CoM with the front wings is bending, that could cause bad instability at speed. Are you using anything to stiffen the plane, such as autostrutting the engine and rear wings to the cockpit?

Longer explanation below, but the excutive summary is: CoM should be towards the front of the plane Pitch and yaw controls (e.g. on the aircraft tail) should be as far behind the CoM as possible Vertical stabilizer on the tail shouldn't stick up high above the fuselage, and should have roll authority disabled Show us a screenshot and we may be able to offer advice Okay, now for the wordy part: The common reason for an unstable plane (especially on the pitch axis) is that your center of mass is behind the center of dynamic pressure. What I mean by that: Imagine you have a badminton birdie. If you throw it with the heavy weighted end in front, then it's stable and will fly through the air in that orientation just fine. But if you try to throw it with the feathered end in front... it just aint' gonna happen. It'll flip around; the weighted end wants to be in front. It does that because, the CoM wants to be in front, and the draggy part wants to be in back. So for example, if you have a plane with a big lightweight fuselage sticking way out in front, but a lot of heavy engines at the back of the plane, you end up with a CoM that's pretty far to the rear, meaning the plane kinda wants to fly backwards. You can make up for that a little bit with control surfaces... but not only is that a bit dicey, but also the effectiveness of a control surfacve depends on its lever arm, measured to the CoM. If the control surface is too close to the CoM, it has very little control authority on the plane. For example, if you build a craft whose CoM is way towards the back of the plane... then that means that any pitch controls on the aircraft tail ("elevators") are pretty close to the CoM and won't actually do much for you, meaning they can't help stabilize the plane's pitch well. Also: If you have a vertical stabilizer on the tail to control yaw... you should make it as vertically close to the center axis of the plane as possible (i.e. not sticking way up high above the plane). And be sure to disable roll authority on it (i.e. it should be set to address only yaw, not roll). I could explain in detail why this is, but it would be a longer explanation and I'll save it unless you're interested. Yep. It really depends a lot on how the plane is arranged-- where's the CoM, where are the wings, where are the control surfaces. If you could post a screenshot of a plane that's having difficulty, then we could critique it for you ("oh, see, there's your problem right there-- you need to move this thing over there," that sort of thing). Ideally, a shot of it in the SPH with the CoM display turned on would be best.

Sorry... but this is not the case. RCS does not follow the crossfeed rules. See this excellent explanation by swjr-swis, above:

Moving to Kerbal Network, since this isn't really about KSP per se.

Hi folks, Let's take it down a notch, please. We appreciate that people feel passionately about this game, and that's great. We also appreciate that opinions differ. However, tempers appear to be flaring to the point that civil discussion is suffering, so please try to rein it in. Of course everyone's entitled to their opinions, and of course we all know this and nobody here would assert something so silly as to claim that their opinion is the only valid one, right? For any topic (this, or others): Some people care passionately about <thing> Other people may diametrically disagree, and be pasionate about that. Still others-- I'd hazard a guess, the large majority-- think it's no big deal and have other priorities. All three groups are perfectly legitimate and "correct", because they're simply stating what they like and consider to be important. Let's please try to keep sight of that, and not let it build to acrimony, shall we? So, to be clear: You're entitled to your opinion. Nobody else is in any position to tell you that your opinion is wrong. Other people are entitled to theirs. You're not in a position to tell anyone else that their their opinion is wrong. Nobody is obliged to care about anyone else's particular opinion. The fact that you're passionate about your opinion doesn't make it outweigh others'. So, when discussing opinions, let's please try to stick to the form "I like/dislike <thing> because <reasons>", or "My view is different from yours because <my priorities>", and not go down the path of "Your viewpoint is wrong and doesn't matter because mine is the only valid one." Please remember that what really matters is that we're all friends here and that our discussions stay civil-- because that's the only way we can really have discussions, which after all is what the forum is made of. Leaving the thread locked for a little while to allow tempers to cool off. Thank you for your understanding. [EDIT] Okay, opening the thread back up. Please play nice, folks, okay? Thanks.

Some content has been removed. Folks, please remember that decompiling KSP is not allowed due to legal issues: Thank you for your understanding.

Still having a bit of trouble following exactly what you've done in which order, but basically the diagnostic sequence goes like this: Getting an error upon loading a save that you manually edited? If so, assume that it's your edit that's causing the problem. Revert to a clean copy of the save that you didn't edit. If you get the error even when it's a "clean" save that you haven't edited, continue below. Getting an error when you're running any mods? If so, assume that it's likely the source of the error. Try running without the mod and see if you can still reproduce the problem. If it reproduces only when you're running the mod... then that's likely the culprit. Go ask your question in the release thread for that mod. If it reproduces even when you're not running any mods... then continue below. If you're getting the error on a clean, pure stock game-- where you're using a clean save you've never edited, and no mods are running-- then you have a legitimate tech-support issue and this tech support sub-forum is the right place to be asking. Which of the above cases are you running into? More to the point: Have you, or have you not, gotten this error when you're running completely unmodded on a clean save that you haven't edited?

If you've been manually editing save files, then almost certainly what's happened is that you horked something and corrupted the save. With a corrupted save file, all bets are off what the program will do. That's not a bug; it isn't the program's fault that broken input causes it to break, any more than it would be your car's fault for having mechanical problems if you put apple juice into the gas tank. It's not designed for that. If you revert to a "clean" version of your save from before you edited it, does that resolve the problem?

It can be hard to know what a mod does or doesn't touch, if you're the author. For example, I would not be at all surprised if a visual mod affects the camera in some way at the code level, even if it's not obvious to the player. Since this is affecting you, but appears not to be affecting all the players in stock games, there's a reasonable chance that some mod might be causing your problem. So, that would be the first thing you'd need to diagnose, before anyone could help you. Is it a mod causing this, and if so, which one? Have you tried running a stock game without the mods and see if you can still reproduce the problem? If you can't (i.e. if it only happens with your mods installed), then the next thing you'd need to do is to narrow it down to which one might be the problem.

Moving to Fan Works.

Lots of content removed, from people who should know better, due to violating various forum rules, specifically: rule 2.2.d: making gratuitous personal remarks (e.g. addressing the poster, rather than the post) rule 2.2.n: deliberate trolling in an effort to put down people rule 2.2.o: going off-topic (to argue about arguing, rather than discussing the thread topic) rule 3.2: blatant "backseat moderating" -- folks, you're not moderators, don't try to act like one. If you see something you think is wrong, just report the post and let the moderators deal with it None of those things are okay, ever. As you all know (right?), since you agreed to the rules when you created your account. And most of you have been around here for a long time and know that this is a friendly place where uncivil behavior is never called for. But it's especially egregious in this case because this very point was raised by the moderator team, ahead of time. From the very start of the thread: From the start of discussion after the thread was split: In short: You were all asked nicely to please keep it civil and polite and not resort to personal attacks, and to stroll on by if you can't do that. (Which shouldn't even be necessary advice, as the reason so many folks like to hang out here is because it's a nice, civil place.) Most of you follow those rules pretty well, the vast majority of the time, so it's pretty disappointing to see this happen. What's especially sad is that, mixed in with the vitriol and mud-slinging, there was actually some thoughtful, constructive advice tossed in as well-- which unfortunately had to get removed along with the sludge, since it was quoting & directly responding to it and there was no way to keep it in without keeping in the stuff that had to go. Which means some kind, well-meaning KSP forum user just wasted a bunch of his time trying to help people... which makes me sad. Moral of the story: This is a place where people are reasonable and civil, and it will remain that way. When people don't follow that, everyone loses. The thread has been temporarily locked while cleanup is underway. Please stay tuned. Thank you for your understanding.

Moving to Gameplay Questions, since this is a question about "how do I...?" and not a tutorial that explains how to play the game to other people. Well, the shortest (but unhelpful) answer is "with an engine, same as you'd land any other rocket". I realize that's totally unhelpful, but... it would help to have a better understanding of the problem space, i.e. exactly what trouble you're having? For example, is your situation "I've landed regular ships on the Mun with no problem, but not sure how to do a rover"? A few thoughts, which may or may not be helpful depending on exactly what problem you're trying to solve: There's nothing special about rovers. They're like any other craft in KSP; they just happen to have some wheels on them. There are a few different ways to solve some of the problems they present. One thing about them is, they tend to have really horrendous aerodynamics. Streamlined, they ain't. So part of the problem some people have is, "how do I launch this thing." A common solution is to put them at the top of the rocket as payload, and encase them in a fairing. This makes it easy to launch. Then just do your whole flight and landing, all with the rover coupled on top. After you land your craft, decouple the rover and you're all set. Some people have designed craft that hold a (small) rover inside a large service bay, designed such that when the craft lands, the service bay is on the bottom of the rocket, either resting on the ground or just above it. Then they open the service bay doors and drive the rover out. My own personal favorite thing to do is to just give the rover engine a small fuel tank and a rocket so that it can land itself. For example, if I've built a small rover whose main axis is 0.625m in diameter-- typically with a HECS probe core and Octagonal Struts making up most of the body-- then I'll just stick an Oscar tank or two with a Spark engine on the back end. That's plenty of dV to descend from orbit and land itself, tail-first, like any rocket. Then it just flops down onto its wheels and drives away. Not sure if that answers your question, but does this help?

I think what was meant was, "could you post the screenshots here in this forum thread, please"

As @HebaruSan said, it would be helpful to see a screenshot of what you're talking about. However, I'll hazard a guess as to what you're referring to: In recent versions, KSP has a dV display (little numbers in blue) that shows how many m/s you'll get out of various stages. It can be super handy, but it's important to understand how it works, because there's some subtlety there. In particular, there can be a substantial difference between the vacuum and atmospheric Isp of engines, which has a major effect on dV calculations. How the game handles that is different between the VAB versus in flight. In the VAB, those numbers will assume Kerbin sea-level pressure by default. This is good for calculating the dV of your first booster stage off the pad... but if you have an upper stage with a vacuum engine that has very low atmospheric Isp, the number displayed will vastly underestimate how much dV that stage will give you, because it's not smart enough to realize that you plan to use it when you're in vacuum. You can control this behavior. One of the option buttons (in gray, at lower right) in the VAB allows you to control what pressure the dV calculations should assume. You can, for example, tell it to assume a vacuum... which will give you accurate dV numbers for your orbital stages, but now it's too optimistic about the dV for your launch-from-the-pad booster. Or, for example, if you're designing a crewed Eve lander, you could tell it to assume Eve sea level pressure. The important thing is that you can only pick one pressure for it to assume. If you have a rocket that will be operating in different pressure domains over its path (such as a rocket that goes to orbit from Kerbin's surface), then it's impossible to get numbers that are simultaneously accurate for all stages, because there's no way for you to tell the UI "assume this pressure for stage 1, assume that pressure for stage 2", etc. Basically you just have to try flipping it back and forth to display reasonably accurate numbers for the different stages. That's in the VAB. In flight, it's a bit different (simpler, actually). There's no option for choosing what pressure to assume. Instead, it bases all its calculations, for all stages, on the current pressure at the rocket's current location. Thus, if you have an orbital rocket sitting on the launch pad, and it has a vacuum engine (like a Terrier) on an upper stage... well, it will show very inaccurately low numbers for the Terrier stage's dV as it sits on the pad, because it'll be using current atmospheric pressure for the calculations. But then, after you launch: if you watch the number as your rocket climbs, it will show that stage's dV getting bigger and bigger (because the pressure is dropping as the rocket gains altitude). By the time you're out of the atmosphere (or nearly so) and actually are ready to activate the Terrier, the number will be showing the correct (vacuum) dV, because that's what the current pressure is. Does this help?

Moving to Gameplay Questions.

Moving to Gameplay Questions.

Moving to Gameplay Questions.