Snark

Sorry, I have no idea what you're talking about?

You'll note that @sal_vager's profile says "Moderator Emeritus"-- the only person on the forum in that category. Sal's special. He was a mentor and friend to us during his time here. For those of us who've been fortunate enough to know him personally, he's the guy who showed us what it means to be a moderator here. The special title is our small way of honoring him.

A couple of years (and a couple of thousand posts), in my case. Because they're friends, and in some cases their absence might not necessarily be permanent and they may drift back. Bear in mind that we're just volunteers, we don't get paid for this, and we have to deal with day jobs, family matters, school, etc. like anyone else. Sometimes folks don't have time for the forums for a while. Not sure what you mean-- @HarvesteR left Squad quite some time ago, and his profile is currently listed simply as "Members", same as most users.

How are they useless? The lateral thrusters are the most important for docking, and are pretty much all you need. If you need to thrust , just put a brief blip on the main engine. It's true that this would lack thrust, but that's not really needed-- if you're docking, you want to go towards the target, anyway. In any case, its usually a moot point for me anyway. If I'm docking something with a Mk1-3 pod on it, most often it's something that's fairly long and skinny. In which case my usual distribution of RCS thrusters is "ring around the front, ring around the back." So the thrusters on the Mk1-3 do just fine for the fore-end thrusters. Just put a ring of four of the four-way RCS thrusters on the aft end of the craft, and it's all set, with full maneuverability. In short: I find them highly useful. You can always upvote it, though. Helps them to know how many people are affected. Though from reading the bug report, it sounds as though they've already picked it up and are actively investigating, so yay!

Oh, goodness no-- girders are astoundingly hideously draggy, that'll make it fly like a brick. Here's a design type I like to use for scenarios like that: Those side stacks are attached to the center using Small Hardpoint, which is very light and quite aerodynamic. (There's also "Structural Pylon", which gets quite a bit more separation and is also very aerodynamic, but those are pretty heavy so I tend not to use them as much.) Again, virtually tip-proof. As shown, that has nearly 2 km/s of dV in a vacuum. Quite aerodynamic. Depending on the design of what goes beneath, the side stacks can be made aerodynamic for launch by putting upside-down nosecones on decouplers under the engines (to be discarded as soon as it's out of atmosphere), or you could put booster stacks under them. Highly tweakable design concept depending on needs. Got a contract that wants more kerbals in the base? Make the side stacks have a much shorter fuel tank, like the 0.5t one, and put Mk1 crew cabins under them. Need more dV? The left and right sides are available-- you can attach drop tanks there. A pair of FL-T800s (with nosecones on top and bottom) will give you 8 more tons of fuel, and still reasonably aerodynamic. Since the center of the stack has no engine, you can attach a 2.5m droptank below the central stack (say, 8 ton or 16 ton), with the decoupler having its crossfeed enabled so that the engines can pull from it. Of course, you can't land with the droptank below there, but it's a great way to add dV in order to, for example, eject from LKO, without having to lug around extra engines for the purpose. Note that autostruts can't cross an unlocked hinge. Breaking Ground robotic landing legs can work, and can work just fine without KJR. But you need a bit of design attention to them. After extending the robotic hinges, you then need to lock all their joints. That will allow the autostruts on the landing legs to lock on to the center body of the ship, and it'll be plenty stiff enough.

Well, it depends on the design. It's possible to build a fairly squat / stable lander whose aerodynamics during launch isn't too bad. Here's an example of a Mun lander that's typical of the type I like to use: The Baguette fuel tanks are great. You can attach them to pretty much anything, and they're reasonably aerodynamic on ascent. And by attaching the landing gear to them rather than to the central stack, that really widens the lander's "stance" and makes it quite stable. And I can adjust the vertical positioning so that the Baguettes are really low down-- they're nearly touching the ground as the lander sits on its landing legs. I've set the fuel draining priorities so that the lander drains from the top down (the opposite of what one usually does, since we're going for bottom-heavy). The Baguettes, right down at ground level, are the last to empty. So they really lower the CoM. This lander can rest on a slope of nearly 45 degrees without tipping over. It's fairly aerodynamic, and it sits comfortably atop a 1.25m stack. Here's another variant of the same basic idea-- this two-kerbal lander is also quite aerodynamic, virtually tip-proof, and sits nicely on a 1.875m stack.

Moving to Gameplay Questions. Those look like the integrated RCS thrusters that the Mk1-3 command pod has built-in. By any chance did you, 1. leave monopropellant aboard that pod, and 2. accidentally turn on RCS? Weird that the RCS thrusters that are visibly attached to that big fuel tank don't appear to be activating, though. That sounds... buggy. Did you look to see if anything odd was going on with your KSP log file? Also, is this a stock install, or are you playing with mods?

Moving to Suggestions.

A common solution to this problem is to turn it the other way around, and build a lander that's really stable so that it can land on a slope without tipping over. Low CoM, wide / squat build. That way you don't have to care whether the ground is especially flat or not. If you're talking about the Mun, most of its terrain is not all that steep. Crater floors are reasonably level when you get away from the ring wall, as are the lowlands / midlands / highlands in between craters. As long as you don't land on the side of a crater, it's usually not too bad.

Hello @The_Faulty, and welcome to the forums! ...just a reminder that actually sending someone the contents of your GameData folder would not be allowed (at least, not if it includes the Squad or SquadExpansion folders), since KSP's game code and resources are copyrighted. Providing a copy to anyone would be a EULA violation. So please be careful not to do that.

Nope. We're not Squad employees, we're just volunteers who help out with the forum, so we don't have any more visibility into what's going on inside KSP production than you do. We do occasionally get a little bit of advance warning when a major announcement happens in the forums (so we can plan accordingly, make sure that some of us are around when the news breaks, that sort of thing)-- in which case we'll sometimes learn stuff a few hours before you do. But we don't learn any more than you do, generally speaking. Because everyone else was quicker at calling "not it!" (seriously, though, it's what Vanamonde said... and believe me, I'm grateful for that, because it's not a job you take on for the "fun" of it)

I've noticed sometimes that the ability to edit maneuver nodes can get "wedged" if I drop multiple ones for the same craft. It doesn't seem to reproduce consistently, so I don't know what triggers it. (I also don't know if it's still happening in KSP 1.11, I haven't run into it in a while but that doesn't prove anything). When I do get wedged like that, I simply exit the map screen and go back in, and then they're fine and I can edit them as expected. Not sure if this is relevant to your problem or not, just something it might be worth trying.

Thanks for the report! Yes, I've seen that on occasion. AFAICT, it's been an intermittent error that's been around for a long time. I've never been able to get it to reproduce consistently enough to nail down exactly what causes it. I haven't noticed it causing significant problems. If you have a specific, 100% reproducible sequence of actions that could cause that to happen every time, then that would be useful in tracking down what's going on. Otherwise I'll just have to let it lie, pending more data.

The problem is that your CoM is so low that the Rhino can't help much. The control authority of a gimbaling engine is directly proportional to how far behind the CoM it is, so it has a decent lever arm to work with. In your case, the Rhino is so close to the CoM that its gimbaling doesn't help you all that much. Probably nearly irrelevant, especially on a craft that size. The issue is that as a rocket goes faster and faster, the aerodynamic forces get huge during the "max Q" part of ascent-- easily enough to totally swamp the (relatively) tiny torque that reaction wheels can provide. If a craft is aerodynamically unstable, then reaction wheels probably won't help it much. The way to fix it is to make it more aerodynamically stable by moving the CoM forward, and to provide control authority in the form of fins and gimbaled engines that are as far behind the CoM as possible. This is not a bad idea. One question: Did you tinker with the fuel priorities of your tanks so that they drain from the bottom up? I ask because, by default, they'll drain all together in parallel. Whereas if you change it so that the bottom one drains first, then that will help shift the CoM forward more.

Moving to Add-on Discussions.

Your CoM is too far from the front of the ship; it's basically in the rear. And since you're taking off on the SRBs alone, you don't have any significant engine gimbal to give you any active steering. Suggestion: Move the SRBs down. I mean, way down-- mount the radial decouplers as low as you possibly can on the central stack, then mount the SRBs as low as you can on the decouplers. And put stabilizing fins on the bottom of the SRBs. Also: Are those SRBs flexing at all? Are you using autostruts (or regular struts) to stabilize them and hold them rigidly in place?

Moving to Add-on Discussions.

Hi gang, I'm pleased to announce the release of BetterCrewAssignment 1.4.1, with an important bugfix for KSP 1.11 compatibility. Thanks to @PocketBrotector for an excellent bug report with plenty of useful context! (see above posts) This also updates to the latest version of ModuleManager, 4.1.4. Other than that, no new features, just the KSP 1.11 compatibility fix.

Thank you for posting the report! Very well and coherently done, especially the inclusion of the video and the log file. Those are invaluable. So, based on some cursory examination, I think this behavior is at least partly BCA (I've observed somewhat similar behavior myself), but I wouldn't be surprised if other mods are getting farbled as well. In particular, you may want to look at whatever is spamming "[SystemHeat][SystemHeatOverlay]" into the log files in the same areas where BCA is having issues. Here's what I believe is going on: BCA works by trapping "ship changed" events in the editor, such that every time the ship "changes" -- for example, if you've added or removed a part-- then it does various calculations to decide what to do. And also writes stuff to the log. I think KSP 1.11 changed something about the way that the game fires "ship changed" events, such that it fires a lot more of those events than it used to. For example, if you drag a slider up and down in a part's right-click menu, that spams tons of "ship changed" events. Since BCA does fairly heavy-duty processing on every "ship changed" event... the fact that those events are now getting heavily spammed is causing BCA to gum up the works. There's a pretty simple fix that I can do to BCA that should filter out all that event spam. However, any other mod that also triggers on "ship changed" events in the editor, is likely to have similar problems to what BCA is hitting. Thank you for posting your log file-- that's very helpful. Holy mackerel you've got a lot of mods. There's a lot of stuff in that log. One thing I noticed was that in the area where BCA is spamming-- i.e. the place I need to fix-- it looks like some other mod is spamming even more. I see tons of stuff like this: [LOG 23:48:39.699] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.716] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.732] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.749] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.766] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.785] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.802] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.817] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay [LOG 23:48:39.834] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay I don't know anything about whatever is logging all those "SystemHeat" messages... but it's extremely spammy, looks even spammier than BCA. It may be that it's being bitten by the same thing that's biting BCA, perhaps even worse. So, TL;DR: yes, this is a BCA problem, and I already have a fix in hand, I just need the time to release a fix. The fix clears up problems for me just fine-- but I don't have that "SystemHeat" thing going on. But even with that fix, I wouldn't be surprised if you end up still having a problem due to the SystemHeat thing, so you might need to check whether whatever-it-is that's logging that has some sort of KSP 1.11 compatibility fix to deal with the event spam.

Rhymes with Bananamonde. It's not really "for" anything of consequence-- it just gives you a feel for how often fellow community members give "likes" to a particular person. It's a standard part of the forum software, and most forums have some equivalent mechanism.

Care to post a link to the reported issue, for those of us who may be interested to follow along?

Ding ding ding. Your orbital velocity around the Mun is significant. It's over 500 m/s relative to the Mun. That's large, compared to the amount of dV you need to do, so Oberth effect really matters. In other words, Doesn't matter that it's smaller than Kerbin. You get a local Oberth boost due to being close to the Mun. The other thing you have going for you, if you eject from low Mun orbit to go back to Kerbin, is that you're ejecting when your orbital velocity around the Mun is directly opposite the orbital velocity of the Mun around Kerbin. Therefore that gets you much of the way home, so to speak-- your actual orbital velocity around Kerbin at the moment you do your burn is equal to the Mun's orbital velocity around Kerbin, minus your orbital velocity around the Mun.

Desculpe o texto do Google Translate, pois eu não falo português. Não é permitido a ninguém compartilhar seus arquivos de jogos KSP entre si; o EULA não permite isso. No entanto, dependendo de onde você adquiriu o KSP, é provável que haja uma maneira de reparar você mesmo uma instalação danificada. Por exemplo, se você comprou no Steam, você pode apenas escolher a opção "verificar arquivos locais" e ele irá baixar automaticamente uma nova cópia de todos os arquivos que estiverem faltando ou corrompidos.

Depending on the craft, that can work... but not necessarily. For this to solve the problem, it requires two things: The craft can't be too aerodynamically unstable when pointing . For example, an extremely nose-heavy craft is going to be extremely unstable in a tail-first orientation, and when aerodynamic forces get really big, tiny fluctuations (which you get even with SAS) can suddenly blow up and the craft can suddenly flip . The craft's ballistic coefficient can't be too high. Yes, a butt-first orientation is likely draggier than a nose-first orientation... but the real question is not "is it draggier" but rather "is it draggy enough." For a ship that's long, skinny, and dense enough, even entering and holding that attitude might not slow it down enough for drogue chutes to do their work in time. I agree, simple entry is ideal if possible, and personally I design my ships that way the large majority of the time. But occasionally, circumstances are such that I need to design a ship whose reentry vehicle is more of a javelin... and in such cases I find that "use steerable fins to get a nose-up attitude" is more dependable and reliable for me. YMMV, of course, that's just my own experience.

Mainly because KSP is supposed to be at least somewhat realistic, and they are, in fact, basically impossible. Electric engines are, of necessity, extremely low thrust. That's because they get their thrust by using electric power to accelerate the reaction mass, and it takes huge amounts of power to do that. Batteries and solar panels produce teeny, tiny amounts of power compared with what you get from burning rocket fuel. They get very high dV values because they can accelerate their exhaust to extremely high speeds, but they can only do that as a tiny trickle, thus the extraordinarily low thrust. And even to get that level of efficiency, they have to be in a vacuum, or extremely close to it-- so you'll never be able to use them to launch from the surface. Launching from the surface of a high-gravity planet (like Earth, or Kerbin) requires high thrust. If you don't have that, no matter how efficient your engines are, you'll never make it to space. And high-thrust engines require expenditures of very large amounts of energy very rapidly, and the technology to do that in an electric fashion simply doesn't exist.