Snark

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.

Moving to Breaking Ground Support. I suspect it's the former, need more info to be sure. Here's the deal: So... if I'm reading this correctly, you have: a central control station (requires 1 power unit) a goo experiment (requires 1 power unit) a solar panel (produces only 1 power unit, if deployed by a non-engineer) So, if you have a non-engineer deploying the solar panel, that means this setup would require 2 power units but produce only 1, and therefore be non-functional. The solution would be to either deploy two solar panels, or else use an engineer to deploy one panel. (Did you in fact deploy the solar panel with a non-engineer? If that's the case, I suspect this is what's going on. If you did deploy it with an engineer, then perhaps something else may be going on, in which case it would be useful to see what the status displays say for the other components besides just the goo shown in the screenshot.)

Wish... granted! You're too late. Because it already has. In the best possible way-- meaning that @UnanimousCoward has already been and gone and done it. I haven't had a chance to integrate it into a new IndicatorLights Community Extensions release, due to IRL issues that will occupy me for another couple of weeks. But at the earliest possible opportunity I will do so. (And if anyone is impatient enough that they just can't wait, I believe he's submitted a pull request on github so you could pull it down and try it yourself. Or you could just wait a couple of weeks until I have a chance to fully integrate it in a new ILCE release.)

Yup. Actually, it's even better than that: you can use this little trick to plan an intercept multiple orbits into the future. (Pretty similar to what @Geschosskopf describes above, except that you can plan the encounter from the get-go without having to actually time-warp through multiple orbits to see where you're going.) Let's say I want to go to Moho, and I want to simplify the problem caused by the fact that its orbit has a fair bit of inclination to it. The easiest way to do that is to launch from Kerbin when I'm at its AN / DN relative to Moho's orbit. But of course that won't be the "correct" launch window to Moho. So here's what I can do: Wait until Kerbin is at the AN / DN relative to Moho's orbit, and launch solar with enough dV that my Pe precisely kisses (i.e. is tangent to) Moho's orbit at the opposite node. Place a node right at solar Pe (i.e. at the place where my orbit touches Moho's) but don't give it any dV yet. The "closest approach" marker now shows where Moho will be after that. I could do one big huge burn to lower my Ap until I get a Moho encounter at my second Pe... but suppose I don't want to do that (for example, it gives up a lot of Oberth benefit due to not doing my braking burn low over Moho). So I then place a "dummy" node out at Ap (after my first Pe, where I dropped the first node in step 2 above). Now I click the + button on the dummy node. Note that the "closest approach" marker for Moho jumps to a new location. That's because it's now showing the closest approach an extra orbit into the future. Is this new approach pretty close? Yes? Then great. No? Okay, click + again to jump ahead another orbit into the future. When I'm reasonably satisfied with the approach... go back to my initial node at Pe (the one I created at step 2) and start giving it some dV in the solar direction. Note how quickly the closest approach marker moves, with just a little bit of dV! That's because it's "amplified" N times, where N is the number of orbits ahead I've gone. This allows getting an encounter with the target with a smaller burn, as long as one is willing to wait more orbits for the encounter to happen. I've also used this technique to good effect for rescuing kerbals in LKO when I want to use one mission to rescue multiple kerbals. Using the multi-orbit rendezvous lets me sweep up extra kerbals with very tiny amounts of dV expenditure.