Snark

Well, not necessarily. My own craft does do that, ...but it doesn't actually need to. It can fly just fine on the helicopter blades alone, i.e. flying somewhat nose-down in order to generate forward motion. It's perfectly happy to do that, can do a vertical takeoff and landing, can cruise on the level at around 35-40 m/s on heli blades alone. The forward-thrust props are just for putting on extra speed. When I'm running those, I can get up to around 60-80 m/s horizontal cruise speed, depending on altitude (Duna air pressure is pretty altitude-sensitive).

Wait... does this mean that I'm only going to find Ore in the inner solar system? i.e. it's completely deliberately excluded from the outer solar system? (So far I've only gotten to Mun and Minmus in this career, Duna comes next.) I've got this whole plot line mapped out in my head, involving exploring the outer solar system and mining for resources to fuel that... but I'm only willing to play with stock Ore, and if that plan is doomed from the get-go I need to rethink my career plans. I'd hate to spend dozens of hours setting up an extensive resource-scanning probe program to map out "where's the ore" and then discover there's nothing at all...

Thanks, I'll give that a whirl! Perhaps worth including a "readme" file in the root folder of RationalResources that explains this fact? "Here's what RR does, here's what the implications are for gameplay compared with stock, and here's what you can do to customize". Not sure what this "MonoPropellant A" and "MonoPropellant B" converter is that you're talking about? There's no converter like that on the ISRU-- just LqdAmmonia, Kerolox, Hydrolox, Methalox, CO2 Splitter, and Hydrates Splitter. Unless you're talking about some other part? If so, where's it located? I sure don't see any other resource-converter parts in the "Utility" category, other than the stock big and little Convert-O-Trons. [EDIT] Okay, I just now tried running after creating a "RationalResourcesEasy" folder in GameData... doesn't appear to do anything, I'm still not seeing ISRU acting like it usually does. As far as I can tell, having RationalResourcesEasy present doesn't actually do anything at all, at least not on my installation. I'll just go back to manually deleting the files that tweak the Convert-O-Tron.

Fair 'nuff. Perhaps I should have read the fine print on the label for RR, more. I wasn't looking to change the core dynamics of the game or add complex chemical pathways with umpteen different resources-- I've played with mods like that before (did an MKS career), and though it was impressive and I'm sure lots of people like it, it's really not for me, mainly because it turned KSP into a logistics game and I want it to be a rocket-ship game. (Out of curiosity... how does one make monopropellant, then? "related to hydrazine" doesn't help me in gameplay terms. Is there some other converter part that makes it? Because the Convert-O-Tron can't, and that's the only part in the game that I know of that has any ability to convert one resource to another.) I'd just been assuming that RR was doing things like adjusting what stuff is in which locations so that it's harder to find a good ore patch, that sort of thing-- I could be totally on board with that, because ore that's simply harder to get to provides a challenge (which I like)... but more importantly, the challenge is about building and flying spacecraft, i.e. it's a rocket-building thing, which is why I'm interested in it. If the goal of RR is to make a more complex and interconnected set of many different resource types such that it's not possible to fill a space program's basic needs (LF, O, monoprop) without getting several different types of resources from different places and them minding them through a complex set of reactions... nothing wrong with that, of course. It's just that it wasn't at all what I was expecting, because the blurb about RR in the OP of this thread doesn't say anything at all about that: ^ The above didn't give me a hint that it's totally rejiggering the resource system. Here are the things that it actually says about it, and how I interpreted them: ...makes Ore even more scarce and challenging... "Oh, okay. It means that ore will be harder to find, maybe on fewer bodies or in harder-to-get-to locations." ...purge the random resource configurations... "Ah, I see. 'Random configurations', that's another reference to the distribution of ore. Clearly it's simply about changing ore distribution to something more 'realistic'." ...grant increased compatibility between planet packs and mods that use certain resources, and encourage the use of mods that use advanced resources... "Sure, that makes sense. It's saying that if you're one of those people who likes a fancy resources setup with umpteen different resources and a complex logistics chain, then they've got that aspect of compatibility covered. Good for them. Of course, I'm not one of those people and I'm not running any of those mods that do the umpteen-resources thing, so this won't affect me." Perhaps worth maybe rewording the blurb a bit, just so it's clearer to folks what they're getting? e.g. something that says "RR completely replaces the resources system, and will require mining multiple resources and a custom logistics chain to make needed supplies, rather than just Ore for everything."

Hmmm... I've run into a problem. (I'm guessing it's Rational Resources doing this?) Have my miner / refiner on Minmus, and I just discovered that... stock options are missing. It still has LFO as an option... but there's no option for "just LF" or "just oxidizer", nor is there an option for monopropellant. This is a problem, since I'm relying on this to resupply not only LFO-powered ships, but also LV-N ships running on LF only. Really need the options for liquid fuel and oxidizer independent of each other, plus a monoprop option. (It also adds a whole bunch of other options for things like "liquid ammonia" and so on and so forth, which I have no use for because I'm just playing with stock resource types.) Is it by design that LF, O, and monoprop are no longer there? [EDIT] ...Oh, my bad, apparently it is. Found the relevant configs, just deleted them and the ISRU is back to normal. Kinda curious about the design choice, though-- is it intentional that KSC should be the only place that can supply monopropellant?

Moving to Add-on Releases, since this is a KSP mod and not an external tool/application. @NaK1119, glad to see you're joining the modder community! Please take a moment to review the add-on posting rules, though. You need to do the following things: Add a statement of license to your post above. I see from your SpaceDock page that you've chosen LGPL, so it's sufficient just to add a comment "License: LGPL" to your forum post. Include the full text of your license with your mod. Your downloadable .zip file doesn't currently contain a "LICENSE" file. Please add one, and ensure that it contains the full text of the license (i.e. not just "License: LGPL" but the full text of the LGPL license with all legalese and so forth). Thanks!

I agree... though I can't claim credit for it, much though I'd like to. Saw someone else doing this somewhere, right at at the start of BG (unfortunately, now can't remember who or where), immediately thought "oh, of course", and have built every single coaxial vehicle like this ever since. It works fantastic, no asymmetric forces requiring futzing around, and it's super sturdy/rigid so it doesn't cause vibration / flopping problems. Here's a Duna flyer I built with helicopter blades using the same principle.

Sure, I don't deny that something changed between the updates. But how do we know it's airflow and not something else? I've gone and done an experiment to see if I could spot any airflow interactions between different propellers when one is not attached to the other. Details below, but the executive summary is that I did not see any such interaction. (This is in 1.7.3.) I built this craft in the VAB: Both rotors are mounted directly to the probe core. It looks like the top rotor's attached to the bottom one, but it isn't. I attached them both to the probe core, then used the offset tool to locate the one physically atop the other-- but it's still "attached" to the probe core underneath. In this way, the rotors' rotation is completely independent, both are equally rigid. That way, if there is any phenomenon that involves the two rotors somehow interacting with each other, we can deduce that it comes from airflow (such as has been discussed in this thread) and not something involving rotation physics. I launched it, and here's what I observed as it climbed: All I did was hit Z to max the throttle (which I tied to RPM limit of both rotors), and was otherwise hands-off the keyboard, with no control input, and I deliberately did not engage SAS; it's free to tumble or spin as it likes. Result: It rose straight up. The probe core experienced zero torque and didn't roll in either direction, because the torque from the two motors was perfectly balanced. Aero display shows identical up-arrows for all prop blades. I enabled the aero stats display for the PAW and pitched both sets of blades (via action group button) more steeply, to accelerate to a 130 m/s vertical climb, which is a respectable airflow. Here's what I observed: The top PAW is for one of the top propeller blades, and the bottom PAW is for one of the bottom propeller blades. The craft is rising vertically at 130 m/s in this shot, with both rotors spinning at the max 460 RPM. As you can see, the lift and drag on both sets of props is essentially identical. I note that the lift on one is 3.11 kN and the lift on the other is 3.12... but that's just a 0.3% difference and certainly not some big, major factor that anyone would have to adjust prop pitch or do anything else about. Certainly it was utterly invisible in terms of gameplay; I never would have been able to detect it, if I hadn't carefully been constructing a controlled experiment and peering at the numbers with a magnifying glass. Whatever's causing that difference, it's so tiny as to be utterly negligible in terms of gameplay-- it certainly doesn't describe a situation such as you or the OP have run into. So at this point, you and I are observing very different results in-game. You see a major effect, and I see none whatsoever. And as far as I can tell from your description, the only difference I'm aware of in our construction techniques is that you mount one rotor to the other, whereas I don't. So it seems reasonable to me to suppose that there's no airflow modeling going on (because if there were, I'd observe it too), and that what's actually happening is that it's something about the physics interaction of mutually mounted rotors. Doesn't mean that there couldn't in principle be some other explanation, I suppose, but that's the only one I can think of that fits the available observations.

That's interesting to hear, would love to know more! However... I still find myself strongly doubting that they've modeled anything of the sort. (If I'm wrong, would love to find that out, of course, which is why I'd love to hear more. And I should go do some more experiments of my own.) I base that presumption on what I know of the way KSP models lift and drag (and what it doesn't do), with some idea of what would be likely be involved in an attempt to do so (i.e. my programmer's and physics-major's gut saying "seriously big fat hairy deal"): an unattractive prospect to a software developer, with a very large cost to develop (lots of programmer time, even more tester time, extremely fertile ground for potential bugs) and a very minor benefit (subtle effect that most players won't notice). In my own contra-rotating prop designs, I haven't noticed anything of the sort. They "just work" and I don't see any discernable difference from the fact that one propeller's behind the other. (Some speculation on why you're observing it and I'm not, below. Further testing is indicated, I should go and tinker with this.) Except that I'm pretty sure that KSP doesn't model drag occlusion at all, except for stack-mounted objects that are connected at nodes. It models heat occlusion, but not drag occlusion other than the specific case mentioned above. That's why, for example, airbrakes work even if you hide them behind a heat shield. That's why, if you have a Mk1 reentry capsule with a bottom-mounted heat shield, and it's undergoing a few gees of aerobrake deceleration, and you jettison the heat shield (which then immediately gets pinned against the bottom of the capsule by the wind), you get higher deceleration than when the shield was actually attached to the craft: because now you're getting air resistance from the bottom of the capsule plus the force of the heat shield pinned against it. The shield doesn't occlude the craft from drag. Again, I'd love to hear more, with specific examples-- this hasn't been my own experience (and I should do more testing myself). My own experience has been that no rotor ever affects any other rotor, as long as one's not mounted on the other. I suspect (again, need more info and/or observations to be sure) that what you're observing isn't due to some volumetric airflow modeling, but rather due to the fact that you mounted one rotor on top of another. If you mount one rotating thing on top of another rotating thing, that unavoidably couples their physics together, the way it's implemented. The rotation of one affects the rotation of the other because they're mounted to each other. IRL counter-rotating props don't have to have that limitation. The top one can be mounted to a shaft that passes through the center of the bottom one and doesn't actually couple to it (i.e. the bottom one is on a hollow axle). There's no reason why Squad couldn't have implemented a rotor part like this (i.e. a thing with a rotating armature, that has non-rotating attachment nodes on top and bottom), and indeed I've seen quite a few players ask for this; wouldn't be surprised to see a modder produce one in due course. But since we don't have such a part currently, one has to get creative. You can mount one rotor to another rotor, on top of it, but then it's unavoidably affected by the lower rotor and I suspect there's going to be some tinkering required to compensate for that, not to mention that there may be potential stiffness problems from "one narrow-diameter thing attached on a tiny attach node atop another narrow-diameter thing." The other option is to get creative with part offsets, which is what I do in my own designs. If I want to have two counter-rotating props-- call them A and B, with B above A-- then I don't mount A to the aircraft and then mount B to A. Instead, I mount them both directly to the aircraft, and then use the offset tool to move B so that it is located directly atop A. That way, as far as the game is concerned, in the "tree" model of the vessel, both rotors have the same, non-moving part as their direct parent to which they're rigidly attached. I can then set up the two rotors so that they are perfectly identical in every way (other than being mirror-image reversed), and they work just fine and I don't get any rogue asymmetric torque or other such problem. That said, though, I haven't gone specifically looking to see if I could find any difference anywhere-- I just built my ships assuming that there's no such problem, and they "just worked", so I've been taking that as evidence that no such problem exists. I should go take a closer look.

That looks like you're running some contract-related mod; I don't think that's a stock contract. In which case, you'd need someone familiar with that mod to help you. I'd suggest asking about it in the mod's release thread.

As folks have mentioned, you have to buy Breaking Ground to get these. If you already have Breaking Ground, you'll find the rotors (i.e. the motorized hub) in the robotics category, and the propeller blades under aero surfaces.

Actually, I'm pretty sure it doesn't model that. My guess as to what's going on is that @Mignear has built the plane in some way such that there's something about the rear prop that's different from the front prop. The fix would be to find the difference and address that. In real life, yes. Not in KSP, though. Both props should have exactly the same pitch, assuming that they're otherwise constructed identically. Via the action groups UI in the editor. First you go to the action groups UI, then you click on a prop blade to select it, then you pick one of the axis groups that show up in the left hand column. When you do that, you'll see that the control authority for the prop blade shows up in the right hand column. Click on that to bind the control authority to the axis group you've chosen. Leave the axis group menu, then toggle the prop's deploy status to "on". Now you're all set, and can use that axis group to control your blade pitch in flight.

Well, the reason you're seeing many many labels is that you're zoomed way out so that they're all located within a few pixels of each other, so they all activate when you hover the mouse there. So, one way around that is to zoom in on Kerbin until they're not all bunched together, but rather spread out around the screen. Then you can pin just the label (or labels) that you're interested in, and then zoom back out. As long as you don't mouse over Kerbin itself, only the ones you pinned will stay displayed.

I believe that in fact it doesn't matter, in terms of in-game behavior, i.e. that it will perform identically regardless of which side is up. That's not true in real life, of course, but KSP's aero model is simplistic enough that the distinction is lost. That said, though, in terms of aesthetics, they're modeled asymmetrically to look like real-life propeller blades, so in that sense it does "matter" in terms of looks. So, in answer to your question, the painted side of the propeller (i.e. with the white and gold striping near the top of the blade) "should" be facing towards the incoming airflow, and the thin silver stripe "should" be on the leading edge of the blade.

Moving to Gameplay Questions.

Hello, and welcome to the forums! That's as may be... but the person you're answering wrote that question nearly five years ago, and presumably has long since found an answer and moved on. Any further discussion at this point would be moot. Accordingly, locking the thread to prevent further confusion. If anyone has further questions on this topic, feel free to spin up a new thread. Thanks!

Ah! That appears to have solved the problem. With current RR (0.8.5) as shipping in JNSQ... the bug happens. With the latest release (0.8.6) of RR from its git repo... the bug happens. Just cloning the RR repo itself to get every commit including recent days... bug goes away! So, all cleared up for me, though it required cloning a git repo, which means any user who's not a techie might not know how to do that. Hopefully the next release of JNSQ will have an updated RR in it.

Thanks, that's helpful to know! If possible, I'd like to try playing with RR enabled, simply because I gather that that's playing JNSQ "as the authors intended", i.e. overall game balance of the system with the new bodies and so forth. I trust their design skills, and would like to simply place myself in their hands and experience the solar system as their imagination has constructed. Besides... part of being a player using a mod like this one that's still a WIP is to help flush out any bugs that are there in development, and I suppose I'm probably a more helpful guinea pig if I'm using the full mod.

For those of us who don't necessarily have full context, could you mention briefly what "the" bug in Kopernicus may be, and what gameplay consequences it's causing? Would be helpful. Also... I'm running into a bug, but it's not clear to me where the bug is, was wondering whether anyone else is seeing it. The situation: I've just scanned Mun and Minmus for resources with the orbital scanner. First I did Minmus, then the Mun. I haven't been to any other planets yet. The trigger: It appears to be scanning the Mun for resources that set off the bug. I don't know whether it's because it's the Mun per se, or whether it's because it's the second one I scanned, or what. All I know is that the problem started right after I scanned. The symptom: Any time I try to select the Mun in planetarium view (either in the tracking station or in map view while in flight), it generates a NullReferenceException and the resources-overlay UI is either empty or the button to show it is missing entirely. Workaround: I don't know of any. Saving and re-loading the game doesn't solve the problem, so as far as I can tell, my career save is borked and I have to just avoid the Mun for the rest of this career. Here's the error that's getting logged when the exception happens: [ERR 11:22:44.191] Exception handling event onPlanetariumTargetChange in class KnowledgeBase:System.NullReferenceException: Object reference not set to an instance of an object at ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList () [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target) [0x00000] in <filename unknown>:0 at EventData`1[MapObject].Fire (.MapObject data) [0x00000] in <filename unknown>:0 [EXC 11:22:44.193] NullReferenceException: Object reference not set to an instance of an object ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body) KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList () KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target) KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target) KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target) EventData`1[MapObject].Fire (.MapObject data) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(MapObject) PlanetariumCamera:SetTarget(MapObject) KSP.UI.Screens.SpaceTracking:SetVessel(Vessel, Boolean) KSP.UI.Screens.SpaceTracking:OnSceneLoadRequested(GameScenes) EventData`1:Fire(GameScenes) HighLogic:SetLoadSceneEventsAndFlags(GameScenes, Boolean) HighLogic:LoadScene(GameScenes) KSP.UI.Screens.SpaceTracking:BtnOnClick_LeaveTrackingStation() UnityEngine.EventSystems.EventSystem:Update() I don't know whether this is a problem with, 1. the stock game, or 2. Kopernicus, or 3. JNSQ itself. I'm guessing it's not the stock game, since I've scanned resources in a non-Kopernicus career in KSP 1.7.3 with no problems. However, this is the first Kopernicus-based career I've tried playing since 1.7.1, so I don't know whether this is a Kopernicus thing or a JNSQ thing. The reason it occurs to me to wonder whether JNSQ may be involved is that I gather the mod does something special with resources, so perhaps there's something involved there? Maybe there's some code somewhere that's leaving a list member as null, rather than initializing it to an empty list as consumers expect, or something? Has anyone else run into anything like this? Conversely, has anyone successfully scanned both Minmus and Mun for resources with no problems?

Moving to Gameplay Questions.

Sure, in a hypothetical universe where the laws of physics are different and orbital mechanics don't obey Newton's laws. That does not pertain, however, either in real life or in KSP, so it doesn't strike me as an especially useful generalization to make. In a Newtonian model with 1/R2 gravity, such as KSP.... no, it's not. Because a 180-degree turn around a planetary body happens only when the encounter is at extremely low speeds and therefore very little net benefit. Remember the topic of this thread. It's about getting a Tylo assist. "What's the best way to do that." And trying to get a 180-degree turn out of Tylo is absolutely not a good strategy-- it's a terrible one, it'll give nearly zero benefit. In your initial example-- which you say you misstated, but which is in fact basically the only way to get a 180-degree U-turn around Tylo-- the benefit is under 1 m/s, which doesn't seem to me like helpful advice to be giving someone who's looking to save dV with a gravity assist. No, it's not, quite. It's pretty similar, yes. A gravitational trajectory in this sense does behave like an elastic collision... with one important difference. The angle of deflection of an elastic collision is independent of the speed of the encounter. You can have an elastic collision that causes a deflection from 180 degrees down to approaches-zero degrees. And that full range of results is possible at any speed. Whereas with a gravitational encounter, the angle of deflection is a function of the encounter speed. And there's no way around that. Correct, and KSP does not, either (at least not in any way that affects orbital mechanics). Correct, and KSP does not, either, if a ship's not in an atmosphere. Correct, and that also describes KSP, too. It uses a 2-body model in which the only gravity a spacecraft experiences is that of its primary. So yes. This is the ideal. You haven't given a single factor in your "ideal" situation that doesn't apply to KSP, nor have you shown any reason why KSP doesn't meet that criterion. It matches up pretty well. And where it diverges, it does so because KSP is actually the ideal situation you speak of, and reality isn't. Reality has lots of factors that aren't modeled at all in KSP-- those "non-ideal" factors you've mentioned, plus N-body interactions, plus general relativity that can alter trajectories by measurable amounts (though after quite a few decimal places). KSP has none of that. A KSP ship that's not in atmosphere or using any thrusters moves on a perfect, mathematical-ideal conic-section trajectory. They've correctly modeled that. It'll be either an ellipse, a parabola, or a hyperbola, depending on whether the ship is traveling under, at, or above escape velocity, respectively. The closer you can get to a body, the sharper the turn you can make. So yes, if Tylo were a point source of gravity and not in fact a sphere of radius 600 km, then yes, you could dive to a super-duper-low altitude and make a sharper turn. I have no argument there. But we're not talking about a black hole, or theoretically what you could do with one. We're talking about Tylo. Because, lest we forget, the whole point of this thread is to help someone who's playing KSP and wants to know how to do a gravity assist to accomplish what he wants to do. And Tylo, like all KSP bodies-- and like all real-world bodies that aren't black holes-- has a physical extent that limits the minimum possible radius that an encounter can reach. Exactly. So, when the OP was asking, ...and you said, ...then you were, in fact, giving him incorrect advice, i.e. describing a situation that is physically impossible, and which, if he had attempted to follow it, would have resulted in frustration and confusion. If you had amended your comment to say "Well, if you're planning on visiting a black hole instead of Tylo, here's what you would do", then your advice would have been technically correct, though not applicable to the OP's actual problem. Everything that I (and, as far as I can tell, everyone else in this thread) said up to this point in the thread has been assuming we're talking about a body with an actual surface, i.e. Tylo. Sorry, I assumed that was obvious. You didn't mention until just now that you were talking about theoretical limits of infinitely dense point sources and not Tylo or other planetary body. Sure, but they're completely irrelevant here, of course. Because such solutions assume you can get much closer to the gravity source than a planetary surface permits, which naturally excludes them from consideration here, because we're talking about Tylo and not a black hole. They're laid out fairly nicely here: https://en.wikipedia.org/wiki/Hyperbolic_trajectory#Eccentricity_and_angle_between_approach_and_departure With a bit of algebraic rearranging of the equations on that page, you'll find that the equation for the sharpest possible turn you can make is given by: θ∞ = cos-1[-1 / (1 + μrp / v∞2)] where: μ is Tylo's standard gravitational parameter (2.82528e12 m3/s2) rp is Tylo's radius (6e5 m) v∞ is the hyperbolic excess velocity of your Tylo encounter. Derivation of the above equation in spoiler: So just plug in the velocity, and that'll tell you how sharp a turn you can make in the ideal case where you're scraping your toes on Tylo's surface. You'll find that if you want a very high angle (i.e. close to 180 degrees), you need a very low velocity. (The only way to get a very high angle without a very low velocity, would be to choose a very tiny rp that's actually smaller than the planetary radius. But in that case, of course, lithobraking is involved, which I suspect is not in line with the OP's plans.)

Apologies if this has already been asked before, but... I'm currently in the Minmus Highlands, and came across a BG-style scatter on it (a big, potato-shaped boulder, perhaps 10 meters across, has a collider) that's floating several meters above the surface. I can land on it and stand there, looks kinda neat but I suspect was not intentional. Known issue? (I'm at 4d 43' 50" N, 147d 39' 42" W, if that is helpful or relevant).

Control surfaces have an action called "deploy" that can be toggled on and off (either by a button in their right-click menu, or via action group). When "deploy" is active, the control surface automatically moves to its maximum (positive) deflection possible, instead of being at its default "zeroed" position. The control surface also has an option "Deploy Direction" which can be set to normal (the default) or "inverted", which you toggle on/off via a button in the right-click menu, either in the editor or in flight. When "inverted" is turned on, then activating "deploy" causes it to go to its extreme negative position (i.e. the min instead of the max). So, for example, suppose you've built an airplane, and it has some ailerons on the wings, and you'd like to be able to use those as "flaps". So, here's how you could set that up in the vehicle editor: Open the right-click menu and click "deploy", and see which direction they go. Up, or down? Presumably you want the flaps to go down, if they're on the wings, so they can give extra lift. So, if you try the deploy button and they go down, great. If they go up instead of down, just click the "invert" button to fix that. Now that you've got them correctly configured for inverted-or-not, toggle deployment "off" again so they go back to the neutral position (assuming you want to launch your craft that way). Let's say you want to be able to deploy/undeploy them via action group. Go to the action-group pane, click on the aileron, and choose the "Toggle Deploy" action to assign to whatever action group you like. There, that's it, you're done! When flying, just press the appropriate action-group button to toggle your flaps on and off. That's the simplest, most basic way to set them up. There are some other options if you want to get fancy-- for example, if you want to have a control surface that only functions as flaps (and won't try to adjust pitch/roll/yaw), or if you want to have variable flaps instead of a simple on/off. But that's the gist of it.

Okay, with you so far. No. You do not. Because if you enter Tylo's SoI at 2030.6 m/s Tylo relative, then you do not make a 180 degree turn. You go streaking past Tylo like a bullet, and your path is only bent by a slight angle. That's my point. 180-degree gravity turns are ineffective because the only way to make a 180-degree turn is to enter the SoI at near-zero relative velocity to that body. Which results in the scenario you originally stated above, and which I explained doesn't actually help you by any appreciable amount. You've described a scenario (enter at high speed and do a 180 degree turn) that's physically impossible. It's not merely impractical-- it's mathematically impossible. We are in that realm. We're in a simulator with a simple patched-conics model. There's no friction, there's no burn at all, everything is perfectly spherical. Heck, it's not even N-body; KSP's patched-conic approximation means that at all times it's just a simple two-body problem that is precisely solvable with basic algebra. This is, indeed, the ideal theoretical case. It doesn't get any more ideal than this. And it still doesn't work. Because even in the ideal case, the math says it won't. You can't have it both ways. It's physically impossible to encounter a body at high speed (i.e. substantially in excess of its escape velocity) and make a 180 degree turn, if you're not doing a burn. You can do one or the other. Pick one. You make a 180 degree turn if you encounter it right precisely at escape velocity (which, in KSP-land, translates to "enter its SoI with near-zero relative velocity"). If you're going higher than escape velocity (i.e. if you enter its SoI with a relative velocity substantially higher than zero), then your orbit past it will be a hyperbola rather than a parabola, and the deflection angle will be less than 180 degrees. The higher the excess over escape velocity, the less the deflection angle. Thus spake Sir Isaac Newton, over three centuries ago, and he's still right.

Agreed. It does. However, if you hit Tylo's SoI with the right geometry (so that you're approaching it from "behind" in its orbit around Jool), then Tylo's own orbital velocity helps you, here. It's fleeing you at over 2000 m/s (its orbital velocity around Jool), so your velocity relative to Tylo is 2000 m/s less than your velocity relative to Jool, upon your arrival at Jool's SoI. That's helpful, since it increases your dwell time in Tylo's gravity well as you use it for the gravity assist. Yes and no. Simply dwelling in Jool's SoI doesn't help you capture to Jool. It is of absolutely zero use in a passive-trajectory situation. (You could use it to your advantage if you go for an Oberth maneuver, i.e. if your trajectory takes you to a low Pe over Jool and then you do a burn there. That's a valid navigational approach, though in my experience a Tylo assist works to do the capture and is absolutely free in terms of dV, no burn required.) Dwelling in Jool's SoI would help you if you were using Jool for a passive gravity assist to go somewhere else (e.g. if you're just swinging past Jool for an assist to elsewhere in the solar system). But that's not what we're talking about here. However, dwelling in Tylo's SoI does indeed help for a passive capture to Jool, as you describe. It gives Tylo's gravity more time to act, in order to bend your trajectory and thereby affect your Jool-relative speed. Arriving at Jool with lower relative speed does help, but not for this reason. Hanging out passively in Jool's SoI will affect your Sun orbit, if you swing past Jool without burning or encountering its moons. But it won't help with capturing to Jool itself. If you enter Jool's SoI with some speed, and don't burn, and don't encounter any moons, then you will leave Jool's SoI with the same relative speed. Conservation of energy and momentum. However, it does help, not because you're increasing your dwell time in Jool's SoI, but rather because it means you can increase your dwell time (and get more path deflection) in Tylo's. (Or Laythe, which also can work well in the same way as Tylo. It has different advantages and disadvantages, depending on your intended mission profile.) True, but it's a much stronger statement than that-- "more effective" isn't quite the phrase I'd use. If you approach Tylo from behind and pass in front of it, then its gravity will retard your speed relative to Jool and help you capture thereto, which is what you want. If you approach Tylo from in in front of it and pass behind it, then its gravity will accelerate your speed relative to Jool, and fling you out of the Jool system even faster than you arrived. In other words: doing the latter is "less effective" in the strict technical sense, I suppose, but a better way of putting it would be that it does the exact opposite of what you want. Here's how to think of it: Picture your path going past Tylo. Draw an arrow. The start of the arrow is right at your Pe marker on your path past Tylo. The head of the arrow (i.e. the direction the arrow is pointing) is at Tylo's center. That arrow is the overall velocity change, relative to Jool, that Tylo is giving you for free. Whether Tylo helps you or hurts you, and by what amount, depends on the direction of that arrow relative to Tylo's motion around Jool. The ideal best case-- where the Tylo assist helps you the most-- is when that arrow is pointing directly opposite Tylo's motion around Jool. The worst case-- where it hurts you the most-- is when that arrow is pointing directly in the same direction as Tylo's motion around Jool. In between those two cases-- where the arrow is perpendicular to Tylo's orbital path-- is the "neutral" case that neither increases nor decreases your speed relative to Jool. It does, however, affect your direction, i.e. increasing or decreasing the eccentricity of your orbit around Jool, which may or may not be helpful depending on what kind of navigation you're trying to do. Everything I've said up to this point (including my previous messages in this thread) is based on actual real-world physics, so it applies to the real world just as much as it applies to the simulation inside KSP. In addition, however, there's another effect that you can leverage, which is an artifact of KSP's imperfect simulation (basically, an exploit of the patched conics model that KSP uses). Details in spoiler. Absolutely true on that one.