Snark

Basically no. The freely available versions are listed here: ...but the most recent among them is 0.13.3, which I suspect would fall into your "super old" category.

Moving to Technical Support.

Some content has been removed, due to pressuring a mod maker about updates, which of course we all know better than to do. We know that for a variety of reasons. For example, we know it because when we were young, we were taught basic politeness such as "when someone kindly gives you a free gift, it's really rude to complain or make demands about it." And also we know it because it's specifically forbidden by the forum rules we agreed to when we created our accounts (2.2.p, in particular). And we know it because a moderator told us just a few days ago to knock it off. Since we all know that so well, good thing we're not going to do that anymore, right? Thanks.

Gas itself wouldn't work. It would disperse too quickly to be of any use. This is not unlike an idea I've heard proposed. The suggestion I heard, IIRC, was to use big slabs of aerogel. No idea how practical it would be.

So, as folks have pointed out, the physical orientation of any antenna is completely irrelevant. Yes, they're modeled to look like IRL dish antennas and such, which visibly "point" in some direction, but that's just a cosmetic detail. In gameplay terms, all KSP antennas are completely omnidirectional. All that matters is range (i.e. can the antenna reach far enough) and line of sight (i.e. is something getting in the way of the signal, such as a planet or Kerbin's horizon). Nope. One relay antenna can manage any number of connections. Having multiple antennas *does* boost the antenna power of the vessel (i.e. give it a longer communication range), because they "stack". However, for most antennas it isn't linear-- there's diminishing returns-- so spamming large numbers of them is of limited effectiveness.

Moving to Breaking Ground Discussion.

Moving to Breaking Ground Discussion. No, the robotic parts aren't involved in staging in any way. Though I'm kinda curious what sort of use case you have in mind? i.e. what exactly would you want staging to do to the part, and how would you use the functionality?

Moving to Breaking Ground Discussion.

Moving to Breaking Ground Support. Could you provide a few more details? Specifically, - exactly which components do you have deployed - how many of each - which profession of kerbal deployed them (in particular, for any solar panels, did you use an engineer and, if so, what level)

Hello, and welcome to the forums! Yes. This is happening because you're using an engine that's smaller in diameter than the fuel tank above it. Note that the cylindrical thing around the engine that you're looking at has nothing whatsoever to do with the decoupler. It's not part of the decoupler. It's part of the *engine* and is called a "shroud". And it's the same size as the engine because it's part of the engine. Yes. Use an engine that's the same size as the fuel tank above it. Or, if you have the Making History expansion installed, there's a set of parts called "engine plates" that can allow you to do what you want. Or there are various free mods available that include engine plate parts.

...powered by a battery? ... entire post quoted for truthiness. Very much this.

Given that the OP was asking this question four years ago, I think it's fairly safe to say that they've long since settled on a strategy, and further advice on the point is probably moot. Accordingly, locking the thread to prevent further confusion. If someone wants to discuss Jool-system mining operations, feel free to spin up a new thread.

I'd say it would be extraordinarily unlikely, given the very different platform architectures. Impossible to say without a crystal ball, of course, but personally I'd put this solidly in the "not gonna happen" category.

Well, there's one way to find out! I suspect (but do not actually know) that it would work just fine, as long as the two KAL-1000s aren't trying to run at the same time.

Hello, and welcome to the forums! Moving to Science & Spaceflight.

Moving to Add-on Discussions.

This one seems like a bit of a mixed bag, to me. On the one hand, having this could be useful in certain circumstances. On the other hand... it would be adding yet another button to the giant chaotic teeming horde that is the command pod's PAW. I already get the collywobbles from that PAW-- it has so many buttons in it, and is so chaotically cluttered, that I always have to hunt all over the dang place to find the button I want. Adding yet another button in there would be a UI "tax" I'd have to pay on every single time I pop up a command pod PAW, whereas the payoff would be the ability to use the feature as you describe. For me, the benefit isn't worth the cost, there. I might find myself wishing to use that feature in flight maybe once for every 1000 times I pop up a command pod PAW. And to me, getting to use it that one time is not worth having to slog through the added clutter of the button getting in my face the other 999 times I don't need it. I realize that this is going to be highly player-dependent. Some players would like to use such a feature fairly often, and maybe they don't mind having tons of buttons in the PAW, so to them the benefit outweighs the cost. Other players may be like me-- rarely need such a feature in flight, and really hate clutter, and it's very much not worth the tradeoff. So about the only way I can think of to let everyone win would be to make it something that can be adjusted via config, so that someone who doesn't like the default behavior can use a ModuleManager patch to make it act the other way.

The problem is that the smallest physical screen amount you can move any slider is going to be 1 pixel. It's not physically possible to move a mouse any less than that. So if the number range that the slider covers is bigger than the physical number of pixels that the slider occupies... it's unavoidable that values are going to be skipped. There's just no way for a slider that's, say, 200 pixels wide, to allow using a mouse to adjust to a range of, say, -177 to +177. More numbers than pixels equals heartache. Maybe this could be made "better" by enlarging the UI scale (to provide more pixels and thus a greater range of possible values), but that seems like, 1. a band-aid with limited applicability (no matter how big you make the UI scale, there could be a slider bigger than that sometime), and 2. if you've got the UI scale set where you want it for general playability, it would be kinda irritating to feel forced to enlarge it just for that one thing. Since the pixels place an inherent "granularity limit" on adjusting a thumb on a slider, that means the only way to really solve it would be to provide some non-slider-drag way of adjusting the numbers. A text input box, like @Majorjim! suggests, could do that... though it might be a bit of a UI challenge to squeeze that into the PAW without eating up screen real estate and/or generating clutter. Another idea that occurs to me, which would be less UI-intrusive (but also less flexible than a text entry box) would be to put a little "+" button at one end of the slider, and a little "-" button at the other, so that you can click the buttons to adjust the value up or down by one increment at a time. How big an "increment" is could be a configured property of the slider (e.g. maybe it's 1 unit, maybe it's 0.5 or 0.1, etc.-- something appropriate based on the min/max scale of the range).

Kinda, yeah. It goes like this: Control surfaces can work (and have always worked) in two different ways in the stock game: "normal" and "deployed". In normal mode, they default to 0 degrees deflection, but can pivot up and down (up to plus-or-minus the control authority amount) in response to SAS or player control input. In deployed mode, they default to going right to the control authority amount (or minus that, if the "deploy inverted" is turned on). So if you want them to act like "flaps in steps" (e.g. sorta the way IRL airplane flaps are used), you can do this: Set them to "deployed" Set the control authority to zero (so they're centered while in normal flight) Use this new 1.7.2 ability to bind them (in the editor) to an axis group. Pick whichever one you want. For example, you could use "Translate U/D" (i.e. the I and J keys). Then launch. In flight, you can then use the I and J keys (or whichever ones you bound in step 3) to adjust the angle of the flaps.

Moving to Spacecraft Exchange.

Moving to Breaking Ground Discussion.

Moving to Breaking Ground Discussion. Correct. What you want isn't possible, and your intended design won't work as described. Autostruts, by design, cannot traverse a robotic part unless it is locked. So you'll have to come up with some design that doesn't rely on autostrutting. You could mount another powered servo between engine and wing, to counter-rotate and cancel out the engine's rotation (as @Epicdreamer suggests)... though, given the mechanical stresses on wings from aerodynamic forces, and the large number of joints involved, I rather suspect that your design will end up so floppy as to make flying problematic. Just speaking for myself, I've found that I've had the most success with VTOL designs when I mount the wings rigidly to the fuselage, and do the same with the engines. Here's an example.

Moving to Gameplay Questions, since this is a question about how to play the game rather than instructions about how to play the game.

Hello, and welcome to the forums! Moving to Breaking Ground Support.

Some content has been removed. Folks, just a friendly moderator reminder to, well, stay friendly. Let's keep things polite and civil. Nothing wrong with asking polite questions, but it's not appropriate to get upset or make demands. And also remember that this is the RO authors' thread and that (like any modder's thread) they don't owe anyone anything and are simply posting about their stuff in their own thread. So please remember when posting here (again, like any modder's thread) that essentially you're a guest in someone else's house, and comport yourself accordingly. Thank you for your understanding.