Jump to content

Search the Community

Showing results for 'gravity turn' in content posted in KSP1 Gameplay Questions and Tutorials.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. 1. Adding fins to the rear of small rockets can improve aerodynamic stability during early parts of flight. This may not be needed if you have engines with a high degree of gimbling instead. Most but not all rocket engines in KSP have quite large amounts of gimbling (this is shown in the right hand side of the part menu in the VAB) 2. In the VAB turn on the Centre of Mass (CoM) and Centre of Lift (CoL) indicators (buttons near bottom left of screen) and check to see that the blue ball (CoL) is lower than the yellow ball (CoM). If you want to be extra thorough check to see if this changes if you empty the fuel tanks. Having the CoL above the CoM will cause the nose of the rocket to be more prone to moving off course if you deviate even slightly from prograde. Conversely, having the CoL far below the CoM may make turning slightly sluggish and the rocket more "determined" to stay pointing in the direction its currently travelling. 3. During early parts of flight, it is generally a good idea not to turn too far away from your prograde vector. A good rule of thumb is to keep your direction indicator inside the prograde vector circle on the navball. Tap controls when turning rather than holding them down and use fine control (caps lock on keyboard) if necessary. 4. Start turning early and smoothly rather than trying to make larger corrections later in flight. This will vary depending on the exact design of your rocket (mostly based on the TWR of your stages), but a general rule of thumb is to fly vertical until you reach about 80-100m/s speed then pitch over 5-10° and then keep pitching over gradually until you reach about 45° at around 25 km altitude and be pointing more or less horizontal by 50km. NOTE: these figures refer to stock Kerbin atmosphere if you have any mods that replace Kerbin or change the atmosphere, then you may need to adjust for those. 5. Don't worry too much about getting to a perfectly equatorial orbit for going to the Mun. An small orbital inclination can be corrected quite easily (and for little cost in fuel) during transfer.
  2. Okay I have noticed this because I watched stratzenblitz75's video on heat shield wings,but I have not rotated the heat shields exactly 45 degrees.Will try that tomorrow! Ohhhh!I thought that they used lift to turn,since drag and lift face about the same direction when I do a pitch turn.(I don't do yaw turns unless I need quick,small adjustments because large yaw turns make the plane not face approximately prograde which is what i thought what a well-designed plane flying controlablly should not do.(they will only get velocity aiming to the sides,and they won't rotate by themselves so that the nose points to where they are flying to now,and planes are designed to point where they are flying to,otherwise the control surfaces aren't doing what they are designed to do))Anyways,I'll stick with using lift to turn,because drag in a dragless craft doesn't fit.I will try to angle the heat shields so that the part in front of the COM gets more lift that the part behind the COM....Or actually,the craft is already doing that,and I can add a piston to push and pull the wing forwards or backwards.That will be my pitch control.Yaw control and roll control=reaction wheels,which I need to make sure to power using RTGs. I have still not solved the problem of the mysterious ~1kn of drag.Where do you think it is?I don't see where the red drag arrow is.Maybe I should try to accelerate it to like 2000m/s at sea level to see where the drag is coming from (half-joking) Airbreathing engines don't work draglessly(intakes) and nervs and dawns work poorly in sea level,so my only option is the inefficient lf/ox engines.So I need the craft to be completely dragless. Okay!That's the plan.I'll correctly angle the heat shields,add a piston between the rear nose cone and the heat shields for pitch control,try to identify and fix the weird drag problem,and try to fly it!I'll do it tomorrow.
  3. Hi, I am wondering if someone can make a list of KEKKJ/KEEKJ gravity assist launch windows (other than year 2 day 160) to Jool. I can't get the gravity assist calculators (like KSPTOT or https://kerbal-transfer-illustrator.netlify.app/Flyby) to work (or please tell me ways to calculate this). I want to know if it is possible to do this at a regular (ish) interval in time. I guess any multi flyby that is <1200m/s is also nice. I've been wondering about this for years... I think in general Jool has to be opposite to Kerbin at launch (or you miss Jool even if you can get it to intersect Jool orbit) but I'm not sure about the specifics? Thanks...
  4. The heat shields have to be angled 45o forwards from the downwards position. That is, the curved part should be facing front-down and the rear part should be facing rear-up. Dragless planes are quite different from regular ones, which use drag to turn. Thus it is normal that a dragless craft turns differently, if at all. If you want more regular-plane-like controls, consider adding a vertical control surface, like an elevon, and a horizontal one, somewhere where they are not shielded. Then you can use them like normal plane control surfaces.
  5. ok now its able to fly for a bit but now there are some new problems 1) it does not turn its velocity when itsself turns 2) it still has a little bit of drag and i dont have any idea why 3) this craft sometimes spontaineously pitches up and sometimes its exerting a torque larger than what the reaction wheel can do 4) idk how to make control surfaces with heat shields 5) the controls just don't feel like a normal aircraft
  6. As many have realized already, sending Kerbals to EVE can easily become a one-way-trip. The high gravity and thick atmosphere present formidable challenges to anyone that wishes to take on the challenge of returning from Eve surface. It requires a staged rocket a stunning 8000dv to even reach the low orbit. So, naturally the question comes to everyone's mind, if SSTO can use Kerbin atmosphere against Kerbin gravity, is there a way to use the EVE atmosphere against its dreaded gravity? As many have already proven, it is possible, but how does one build a craft that accomplishes that and pilot it safely into low orbit? And that is what I will try to explain here. First of all, the Eve Effect. Due to its gravity and atmosphere, even adding the payload by just a tiny bit, the amount of fuel and thrust power increases at a stunning rate. So, when building your first EVE SSTO, most of the weight should come from engines and fuel tanks, anything else should be minimized. One common theme among the Eve SSTO design is that the Kerbonaut is uncomfortably squeezed into a tine service bay with the tiniest probe core alongside a tiny reaction wheel. Another alternative approach to this is the Mk1 cone shaped command pod. It has space for 1 Kerbonaut, capable of storing data, a reaction wheel, and a tiny battery. Be sure to empty out the monopropellant if you choose the Mk1 pod. Weight management and resource management lies at the center of Eve SSTO. The desired result that everything is about just enough for things to function, and the only thing that doesn’t really contribute to the craft’s orbital entry should be the Kerbonauts on board. In order to utilize Eve's atmosphere against its gravity, one must first understand the unique properties of Eve atmosphere. Generally speaking, based on altitude the Eve atmosphere can be divided into 4 parts. Each part has distinct properties which we aim to exploit accordingly. 0m-15000m the thickest of the thickest. High atmospheric pressure renders most rocket engines useless with the exception of KS-25 Vector, Mammoth, and the Aerospike. However, the smarter way is to completely forget about rocket engines. With Breaking Ground DLC installed, using propellers powered by electricity is by far the most efficient way to lift anything from sea level to 15000m. 15000m-40000m the atmosphere is still there, but it is only as thick as Kerbin atmosphere. This means that rocket engines used to lift craft from Kerbin sea level start entering the optimal range. While the usage of propeller starts to require larger and larger wing surface that will generate too much drag later on. 40000m-80000m the atmosphere is even thinner, with a thinner atmosphere, accelerating horizontally would face far less drag. LV-Nerv nuclear engines are starting to become Extremely efficient. Any other rocket engine pales in front of its 800 Isp. 80000m-90000m the atmosphere is almost non-existent. If your AP is above 100000m and your PE is within this range, the atmosphere will barely drag your AP back into the atmosphere. This is almost the equivalent of being in orbit. In the First Phase, electric rotors and propeller blades are used to lift the craft from sea level to an altitude around 15000m. Rotors are best used in pairs; therefore, they can cancel out the torque generated on the craft. Rotors are like engines that don’t consume fuel, even if fuel cells are used to power them, no rocket engine can lift your craft to 15000m consuming less than 1000 units of fuel. They are the key to any Eve SSTO that doesn’t take off from the highest peak. Among all the setups, the R-25 propeller blade and the EM-32 rotor combination is the one that works the best. 8 blades symmetrically attached to the EM-32 rotor provide the best propulsion force while consuming a minimal amount of electricity. Another thing worth noting is that the weight of the rotors can be reduced at the cost of torque. Since we don’t need this craft extremely fast, the rotors can be set to 55-70 percent depending on the total weight of the craft and the wing area. To optimize the propellers, it is crucial to bind the propeller blades to action groups to adjust the pitch angle. Pitch angle slowly goes up throughout most of the first phase. 16-15 degrees is good for takeoff, but a rather poor choice when the craft start to climb higher. If you’ve flown propeller planes very high in the Kerbin atmosphere, you would know that the last 2000m before reaching 15000m can be a long and somewhat annoying process. 15000m is just for reference, for some designs, 14000m is enough for entering the Eve orbit, for designs with larger wings, 16000m is the perfect point switching to rocket engines. This is a tradeoff. Larger wings and more propeller blades can bring the craft higher, but larger wings also generate larger drag. Larger wings and more blades also add to the overall weight. In my case, I picked 14500m as the target altitude for my first phase. As mentioned previously, in order to use propellers, there needs to be electricity. Any part used to generate the needed electricity is a part that provides neither lift nor thrusting power. Therefore, we want to generate just about enough electricity for the electric rotor and other components such as the reaction wheel. Solar panels are a poor choice to use, they have to be attached to the outer surface to generate electricity which adds drag to the craft, and it is usually somewhat cumbersome. Isotope rods can be safely stored away, but in order to generate the amount needed to power the whole craft, a combination of battery and isotope rod has to be used. Usually, upon reaching the 15000m mark, the batteries are almost out of juice. This approach requires one to properly time the rate at which electricity is generated and the rate of consumption so that one doesn't run out of electricity before reaching the target height or add way too much battery which is just extra weight, we do not want spend fuel on. Fuel cells can be a good idea, despite the fact that it consumes liquid fuel and oxidizer, but the amount it consumes is extremely low. In the case of my SSTO, the rate is barely 0.01 per second, It takes me about 11units of oxidizer and 9 units of liquid fuel, and that is negligible in comparison to all the fuel and oxidizer I have on board. However, once the orbit is reached, generating electricity using fuel cells becomes rather wasteful. In conclusion, the best option could be a combination of these methods. Solar panel + fuel cells or isotope rod + fuel cells are both viable paths to provide electricity to your rotors. For wings, the options are rather limited. It must be able to withstand the reentry heating and has a rather large lifting surface relative to its weight. If it doubles as a fuel tank that is an extra perk to it (this will be explained later). This narrows us down to the two wings, both of them are from the Big-S Wing series. (This might seem pretty obvious to anyone who has built an Kerbin SSTO, but I want to make this article as informative as possible so that even beginners can learn too). As for control surfaces, Big-S tail fin is a descent choice, but it is way too big and heavy to be placed vertically. The Big-S Elevon on the other hand is a poor choice if one wishes to place it horizontally simply because it has a smaller wing surface relative to its weight (if you do the math 3.49/0.45=7.76 and 1.16/0.23=5.04, just for reference the Big-S delta wing has a lift to weight ratio of 5/0.5=10). So, for horizontal control surface, you actually want to use the tail fin, and for vertical control surface use the elevon. This conclusion seems counterintuitive indeed, but we cannot afford to have parts not optimized for their purposes. Another option for control surface is Advanced Canard. Despite its poor lift to weight ratio, it is extremely light. With such a thick atmosphere, the control surface doesn't have to be very large. Adv. Canard can serve as the perfect tail fin. (confusing huh? we are using these surfaces with complete disregard of their intended functions implied by their names). The wings not only get us through the entirety of first phase, but wings also play extremely important roles in the second phase. In the Second Phase, the main lifting force will come from wings and rocket engines. However, wings also have their negative effect known as drag, and this problem begins to manifest as the rocket engines accelerate the craft rapidly above Mach 1. The amount of drag generated by wing is directly related to the wings’ angle of incidence and the surface area of the wings. But drag isn’t only generated by the wings, every other part on the SSTO can generate drag too and they don’t even provide any lifting force. So, it is better to have the wings angled rather than having the entire craft forming an angle of attack that generates drag everywhere along the craft body. As for a rule of thumb, 5° is ok to start with, but one really needs a mod, the Precise Editor, to adjust the angle of incidence to make the craft more aerodynamic. This angle can range from 1°-5° with most designs have this number lie around 2°-3°. I set the angle to 3.3°. This is another point where trade-offs are made. Greater angle means that the SSTO has a greater advantage during the first phase of the ascension, and it requires fewer wing parts which reduces the total weight; however, the drag is increased. A lesser angle of incidence has another advantage besides smaller drag. More wings can be a good thing when you need them to function as fuel tanks that generate descent lifting force. Whether the craft is aerodynamically optimal or not directly impact the success of any attempt to enter Eve low orbit. The main body of the craft should point prograde for most of the second phase to reduce drag. Mk2 parts are often regarded as the draggiest parts because their lift generating property comes with extra drag produced as a byproduct. I could not resist the aesthetics of Mk2 parts and placing them vertically would minimize the drag from these parts since they have stopped providing lift. Rotor and propellers must be stored away in cargo bays or service bays to reduce drag after using them to achieve the target altitude and the same goes for any other part that can be stored away. Faring is another option, but anything inside the faring will stay there until the craft is decommissioned. No connection nodes should be left unprotected, even the rocket engines. Using a nose cone to cover up nodes on rocket engines and moving it away from the exhaust vent is an important trick to reduce the drag. The Mammoth engine is an exception because they have one connection node only and that node is already used to connect the engine to the rest of the craft. Lift is the other factor from wings that comes into play. Ideally, there should be just the right amount of lift so that the craft will automatically pitch up when the SAS is set to prograde. The craft needs to accelerate horizontally for a while for this process to happen. Since this horizontal acceleration happens when the atmosphere is still rather thick (around 15000m) the shorter it is the better. A low thrust to weight ratio would extend this process unnecessarily long, making it very inefficient. But the craft also shouldn’t pitch too steeply. A steep ascension would mean that the engines are doing the bulk of the work. In order for wings to contribute sufficiently to this process, this automatic pitching process should not exceed 35° with 30° as an optimal upper bound. On one hand, a very steep angle also means that the craft is not accelerating sufficiently in the horizontal direction. On the other hand, a very shallow angle means that the SSTO has to combat the drag for a longer period. Once again, this is about trade-offs, and one has to weigh the various factors at play carefully. If the TWR is on the higher end, a steep ascension is perfectly fine, with a lower TWR, it is best to let the wings do more of that lifting. A greater wing pitch angle and a faster acceleration process will send the SSTO into a very steep climb. On the contrary, a lesser wing pitch angle and a slower acceleration will keep the craft in the dense atmosphere for a prolonged period. Thus, the wing pitch angle needs to be carefully adjusted according to the TWR of the engine. Speaking of the TWR and the engines, their importance is second only to the aerodynamic features of your Eve SSTO. The smaller and lighter crafts often use the Aerospike. Medium sized crafts use Vectors or a combination of Aerospike and Vector to accomplish the same thing. Vector is more efficient when the atmosphere is denser, but the Aerospike outperforms against the Vector in fuel efficiency when the atmosphere is thinner. Their complementary qualities can be something very desirable when used simultaneously to power the craft. Mammoth is reserved for heavy or super heavy Eve SSTOs, rarely are they used in combination with the Aerospikes. One of the first Eve SSTO ever has been powered by those monstrous rocket engines. Designs utilizing Mammoth often have ISRU capabilities built-in to the SSTO. Both Mammoth and Vector has gimble capacities, this could come in handy since most Eve SSTO only has minimal reaction wheels installed. Most SSTO also need LV-Nerv to enter the orbit. Even though the thrust of LV-Nerv is among the lowest in game, its specific impulse exceeds the ISP of other engines by a long shot. Few Eve SSTO can achieve a dv around 5000 without using nuclear engines, and the one that fly without the nuclear engines are often equipped with the alternative option which is the Dawn ion thruster. Xenon, however, is not a resource that can be generated through ISRU means. Thus, by using Dawn the SSTO becomes more of a non-reusable craft. I personally think that this design is inherently in contradiction with the idea of using SSTO in the first place. In my case, I choose the combination of Vector, Aerospike, and Nerv to obtain a total vacuum dv of 5000. The nuclear stage should never have more than 2000dv. Due to the low TWR of Nerv, it cannot burn that much fuel fast enough to complete the maneuver required to enter low Eve orbit. While in the second phase, the nuclear engine is still not optimal, but one should start the Nervs around 16000m. During this phase, it provides a small but, eventually, crucial amount of acceleration that will eventually send the SSTO into orbit. One cannot simply add fuel to the craft to increase the dv of the stages. There is a point when the TWR of the main stage is simply too low to accomplish anything. The greater the TWR, the faster craft accelerates, and the shorter the amount of time is spent on combating gravity. Once again drag comes into play. If accelerates rapidly, the craft would have to combat extra drag. The lowest TWR around 15000m that I have seen is around 0.40, the highest I have seen is around 0.90, and my SSTO has a TWR of 0.60 at 15000m. The TWR essentially determines how the ascension profile should be tailored to maximize efficiency. After discussing the wings and engines, I can finally go back to the “automatic pitching” process. The lifting force obviously comes from the wings, but there is more to it. The center of the lift and the center of the mass should be extremely close, a lot closer than any other aircraft intended to fly on Kerbin. Throughout the process, the relative position of these centers should stay roughly constant. This can be accomplished through simply balancing the fuel or using a more sophisticated fuel flow priority to establish sequence where the center of mass is unaffected by the burning of the fuel during the second and the bulk of the third stage. Initially, the craft has a positive angle of attack upon entering the second phase. The engine accelerates the craft so that the lift is great enough to initiate this process. By switching to prograde when the angle of attack is 0°, the craft would experience minimal amount of drag during this process. If this ascension were to be done in a manual manner, the drag generated in this process would make the SSTO highly improbable to enter the low Eve orbit. As the atmosphere starts to thin out, the craft will eventually lose the lifting force provided by the wings. This is what causes the craft to pitch down in the process. As soon as the thicker parts of the atmosphere are no longer affecting the craft, the angle should slowly go down, allowing the craft to spend more fuel accelerating horizontally. Thus, we arrive at the Third Phase. At this point, the SSTO has successfully managed to get out of Eve’s thicker parts of the atmosphere. The goal is to accelerate horizontally achieving a target apoapsis height and a target orbital velocity before the main engines shut off due to the lack of oxidizer. I have personally established a few checkpoints to guarantee my ascension path. This is slightly different for every SSTO. Here are my checkpoints. 30° at 30000m, 25° at 40000m, 20° at 50000m, and eventually 15° at 60000m. Depending on the SSTO, this process might or might not happen automatically, but since the drag is getting smaller and smaller, switching to manual pitching wouldn’t create a whole lot of drag either. Feel free to adopt my checkpoints to begin with, and slowly adjust them through trial and error. The main engines should shut off halfway through the third phase. Usually at this point it becomes very clear whether the SSTO has the potential of making it to orbit. There are some parameters that might help. Ideally, when the main stage is done burning, the craft should have an orbital speed greater than 2400m/s and an AP of at least 80000m. If the orbital speed is not high enough, the nuclear stage will not have the time to complete the burn and accelerate into a semi-stable orbit. If the AP point isn’t high enough, the nuclear engines can’t raise the AP high enough so that dense air wouldn’t slow it down preventing it from entering a semi-stable low eve orbit. For the rest of the third phase, a common mistake is to raise the AP above the atmosphere and starting to make a maneuver node. Rather, click to show the in-game orbital info, and keep focusing on the PE and AP numbers. Since the Nuclear stage often has a low TWR, it is important to buy as much time as possible. Raise the AP point and make sure that there is plenty of time to accelerate during the fourth phase. The trick is to keep a positive angle of attack. I usually just leave the direction of the craft unchanged after I reach the 60000m checkpoint. The Final Phase. This is the last phase to enter the low Eve orbit. Unlike other crafts, Eve SSTOs have a unique way of entering stable orbit due to the extremely low TWR of Nerv nuclear engines. As mentioned before, don’t bother setting up a maneuver node. If the AP is around 100000m, it is usually a very good sign. This indicates that it is very possible to complete the entry into orbit in one burn. Even if that is not the case, there is still a chance for a semi-stable orbit. A semi-stable orbit in the case of Eve has an AP above 90000m and a PE between 80000m-90000m. However, there is no guarantee that an orbit that satisfies these conditions will be semi-stable. A semi-stable orbit allows the SSTO to pass through the PE and re-exit the atmosphere. By burning again at the AP point, the PE can be raised above 90000m. So, do not give up just yet if the PE isn’t high enough, there is always a chance. For the entirety of the final phase, keep a positive angle of attack. There is no definitive number as to how high the angle should be. In the most extreme cases, the AoA can be around 75° or even 85° towards the end of the burn. It is all about raising the AP and prolong the time to reach AP. The longer the craft stays above 85000m, the better. Nuclear engines should have plenty of dv at their disposal, all it needs is just a little more time to complete the burn. Quick save the game and practice a few times.
  7. You're looking to, or you've already downloaded @Nertea's shiny, shiny things so the air filters on your Laythe base keep filtering, or so the cryogenic fuel in your Eeloo probe doesn't escape. But how do you use these exactly? How do you balance the reactors, engines, radiators and overall dry mass to get decent TWR, consistent burns and keep the reactors in their prime too? Here is all the introductory info you need to get you going. Topics will be added over time so don't worry too much about things missing from this post. Glossary Reactor + Engine Balance Reactor + Radiator Balance Reactor Longevity Reactor Control Capacitors Capacitor Control Fuel Performance Argon Xenon Refueling Lithium Reactor + Engine Balance When picking a reactor, watch its Fission Generator > Power Generated value and Fission Reactor > Required Cooling value. When picking an ion engine watch its Propellants > EC consumption and you'll find that this consumption will tend to be exact to the output of a given reactor and that there are several more such pairings begging for you to notice them. Reactor + Radiator Balance Once you can keep in mind how much the Fission Reactor > Required Cooling of a given reactor is, it should be easy enough to look at the stock radiators and add or multiply their Radiator Specs > Core Heat xFer values. Once your total exceeds the reactor's Required Cooling value that's it, that's how many of that radiator you need. This is a good setup: 400kW from 2x large static radiator > 300kW from 1x Garnet. Also, never forget that static radiators must be attached directly to the reactor or its parent part or else. I don't need to install a radiator mod to show how to balance a reactor with them, but I would need to install one because stock radiators do have their limitations, and "options" are especially important for ion-powered vehicles that dare to pass through an atmosphere with their reactors running. Reactor Longevity Don't get swept away with the power of a nuclear reactor that you decide to or completely forget to put an RTG or solar panel on your craft. Always include an alternate means of power generation so that the probe core can be kept alive and that you don't waste the reactor's nuclear fuel Enriched Uranium between the last orbital maneuver and the next. In flight there is the danger of the reactor overheating and the loss of core health (separate from core life). Core Health is expressed as a percentage and iirc, once health is lost, total output becomes capped and it can eventually meltdown and become dead and useless (I don't know if it explodes, haha). Core Life is the amount of time you get depending on how full it is with Enriched Uranium and what the output cap is. The output cap is controllable via a slider in the NF Reactor toolbar panel between 0 and full EC/s rate, technically allowing the reactor to run for decades or centuries as an oversized RTG. Reactor Control The final thing about nuclear reactors is, of course, how to operate them directly, especially from the snazzy NF GUI app. Look for this in your KSP toolbar once you have Near Future Electric installed and a nuclear reactor on the active vessel. (It does not show in Map View.) Every proper nuclear reactor mod out there should integrate into Near Future and can be controlled through it, and that makes life good. Such mods (that I know of) include USI Core and Mk2 + Mk3 Stockalike Expansion but exclude KSP Interstellar which changes all nuclear devices in its own way. Do not expect this to control any radiators associated with a reactor. Those must be toggled separately. The UI Elements are as follows: The radio (circle) button under a reactor name is the main switch and lights up when toggled on. The thermometer (with two checkpoint markers) respectively indicate the thermal range, the peak operating temperature, and the overload/shutdown temperature. The number will always be the temperature at a given moment. The three symbolic items above the thermometer represent kilowatt output (not necessary to most of us), the ElectricCharge output (most important) and Core Life (very important). When a reactor is on it will show you the duration in years instead of "Reactor Offline". Basic Controls is the output control slider or reactor throttle (at 100% by default) which lets you finely control the ElectricCharge output. Accordingly, the kW, EC and Core Life values over the thermometer will change. Most of us don't need to click Advanced Controls. I didn't, so I don't even know what that looks like. This screenshot features the 2.5m USI device with its context window open and the NF control window. Note that in both GUI its output slider is set to 25%. Both windows have their distinct advantages, but NF's window shows you what matters right now, and for all your reactors if you have more than one, removing the need to pin all your reactors' context windows if you ever have to access them all at once. You do not want to end up like this! In the odd chance that you visit an infernal planet and decide that solar panels were not necessary...or they are present but useless at the time, make sure to never leave things on that will guzzle the current. In this case I had a life support device on and the ship's radiators were maxed out, causing them to fail to cool the reactor, which in turn led to the reactor gradually overheating, losing output efficiency, and nearing its overheat/shutdown temperature. If it reaches its shutdown temperature and does not receive cooling, it will remain super-heated and its Core Health (the percentage status of the core, not the output duration bit) will start to fall, meaning it's decaying and it will become a metal brick. As long as it is hot it will decay. If there's a separate power source able to feed the radiators and cool the reactor down, the decay will stop. Jebediah! Capacitors As @Supercheese mentions below (which helps me a lot in do this part, so thanks muchly ) installing capacitors instead of a reactor can save cost and weight and increase deltaV by quite a lot. As shown in the first picture, you get 8x the amount of StoredCharge (SC) to ElectricCharge for the same mass and volume of the part. Each part here weighs 0.25 tons but one quarter-ton of capacitor shines brightly against 2 whole dark tons of normal battery. (Stock 2.5m batteries featured here). While that is a great thing, they have their disadvantages. They are not a proper 2-way street like batteries. They cannot "charge while discharging" and their charge rate is very small to avoid possibly bricking a low-specced or unmanned ship. A capacitor can be paused from charging (and when charging it will feed from everything that produces or stores ElectricCharge) but it cannot be paused while discharging (in doing so it will feed everything that stores or consumes ElectricCharge or it will dump and waste its charge). Part powers: Item, Holds, Discharges, Recharges CAP-101, 800 SC, 80 EC/s, 8 SC/s CAP-106, 3000 SC, 300 EC/s, 8 SC/s CAR-1.6, 1600 SC, 160 EC/s, 8 SC/s CAR-8K, 8000 SC, 800 EC/s, 16 SC/s CAR-EXTRA, 32000 SC, 3200 EC/s, 32 SC/s Capacitor Control You can control the discharge rate of a capacitor in the VAB and in flight at the Near Future Capacitor toolbar button. The Capacitor Control Panel is only accessible in flight. In the VAB or in flight, the PAW features the discharge rate slider with a non-zero minimum (50% actually) and its maximum (the default). This can be adjusted on the fly in case of the need to throttle down (or up again mid-burn). In the UI, from left to right the elements are: Master switches: The three lightning buttons are: Blue: Discharge all capacitors simultaneously. This is necessary for large vessels that want to release enormous amounts of ElectricCharge at once. Think hard before feeling the need to press because a discharger cannot be paused. Green: Turn on the recharger for all capacitors. This lights the radio buttons on the far right of each row in the part list below. Red: Turn off the recharger for all capacitors. This un-lights the radio buttons on the far right of each row in the part list below. Item row. There's one for each capacitor in the vessel: Icon (not customizable). The part's title. The 2.5m inline one is indeed called "CAR-EXTRA Capacitor" Blue lightning button. Discharge this part. Speedometer icon and slider: The discharge rate controller. In screenshot they are all set to their minimum rate which means they will produce 1600 EC/s. Battery icon and blue gauge: The fuel bar. How full this capacitor is. When its recharger is turned on it shows how much SC/s (StoredCharge) it is rated to produce, not how much it gets to produce (with respect to sub-optimal situations). Battery (charging) icon: The recharger icon. Radio button: The individual recharger toggle and status light. As shown in the: Argon-fueled stack (left): because the visible ion engine consumes 1999 EC/s I set the discharge rate to just over that to feed the engine and any vital systems. Lithium fueled stack (right): because the 2.5m capacitor releases 1600 EC/s minimum I've chosen to build a test ship with 4x the tiny "LF-1 'Charon' Magnetoplasmadynamic Thruster." Two capacitors have their recharger turned on. Even if for some reason you end up stacking a reactor's weight or more in capacitors (and heavy, heavy solar panels...) on a craft, you're still saving more than just cost. You're avoiding the troubles of nuclear fuel and reactors themselves if you're still skeptical about the things, but you'll remain at the mercy of solar panel efficiency if you're operating very far from a star. The next thing to consider is how many capacitors set at a given discharge rate will afford a consistent engine burn up to a desired maximum length. The reference formula to measure by is very simple: Total StoredCharge / Discharge Rate = Maximum burn time in seconds. Fuel Performance If you're a nut for fuel performance, then here are a few opening stats including engine sizes to help weigh Near Future's propellants in your mind before you read about them below. Argon Engines 1 ~ 54.55 kN, 2800 ~ 5500 Isp 0.6m, 1.25m, 2.5m Xenon Engines 1.4 kN, 4000 Isp (Stock Dawn engine) 2.3 ~ 5.6 kN, 6500 ~ 19300 Isp (Added engines) 0.6m only VASIMR Engines (can halve their Isp for nearly triple thrust, no change in propellant consumption) Xenon mode: 4 ~ 68 kN, 6000 ~ 7000 Isp Argon mode: 2.5 ~ 44 kN, 8500 ~ 9500 Isp 0.6m, 1.25m, 2.5m Lithium Engines 46 ~ 237 kN, 2900 ~ 3800 Isp 0.6m, 1.25m, 2.5m Argon I personally prefer ArgonGas over XenonGas because it's more abundant in-game (as it is irl) than Xenon and is hence easier to harvest from Duna and other planets with atmosphere. Here I modify a probe that was never meant to go far from wherever it's deployed, to (almost) be able to cross SOI. Almost = not enough fuel but there's plenty, plenty room to fix that. Adding a radial Argon tank (or 4) and changing the Garnet to its TopNode subtype so I can attach things to its other end. Xenon Here's a Xenon-powered Duna probe I launched soon before KSP 1.2.0 was even announced. This is 6 tons, 1 TWR in low Mun orbit iirc, and 11km's dV! The Garnet reactor underneath has 2x Radiator Panel (edge), the straight ones with 150kW cooling power directly attached and they're exactly enough (300kW together) to keep it at/within its limits (300kW). The particular Xenon engines on this one have been deprecated so I can't explore them now. Refueling There are two mods I know of that supply a means not just to use Argon or Xenon, but to replenish your tanks. The first is Karbonite, part of USI. Its low-altitude atmosphere scoops come in 1.25m and 2.5m size. They have very poor intake values since they are firstly filter type devices, and they operate better the faster you're moving and the thicker the atmosphere. Strap some of these, a karbonite power cell and a USI kontainer (for Argon) or a stock Xenon tank to your airplane and fly around (if you have the patience or an autopilot mod). Have the scoops filter karbonite too to feed the power cell and even better, feed some karbonite jet engines so you can infinitely fly and refuel faster.... Or you know, spam them on a landed craft and do the timewarp disco. (Forgive me for mentioning so much karbonite.) Then there's Near Future, of course. It provides the AIReS Atmospheric Sounder (Science category) and the M-2 Cryogenic Gas Separator (Utility category) for harvesting Argon and Xenon. The AIReS is a scanner and both parts only work in atmosphere. Unlike karbonite's scoops, the M-2's performance is not influenced by whether it's moving, and it consumes between 12 and 24 EC/s, or 12 + 24 depending on which gas, or both, you're processing. Lithium The story isn't very different for lithium-fueled crafts, except that Lithium, being a solid material is much denser than Argon and Xenon and that makes it better for crewed ion vessels. TWR is much better at the cost of Isp, and empowers heavy landers and even enables Duna SSTOs. I've made Argon-fueled SSTOs (in KSP 1.1.3) but those required very, very tedious mixing and matching of USI and NFT's reactors, karbonite scoops (to refuel themselves), and engines for sufficient dV and TWR. I don't know if it's still possible now. I haven't been at this kind of thing since KSP 1.2 arrived. Sometime perhaps I will post examples of a perfected ion-powered SSTO. Near Future Propulsion adds Lithium modules to the stock drills and stock ISRU (and the ISRU of Kerbal Planetary Base System if also installed). Here we have an Augustus-capable Lithium SSTO prototype. Since I always have Galileo's Planet Pack installed, I have KER set to Augustus, a moon, and it compares as follows: Augustus: 0.35g, 65km atmo, 350km radius. Duna: ........0.30g, 50km atmo, 320km radius. The Garnet reactors have just enough cooling and this Lithium engine pairs it perfectly for EC flow. The 3 tons of Ore simulates precious cargo like LS resources. Full or empty, though, this craft can make it (however, it's not aerodynamically sound). When devising a Lithium-driven vessel and want to make your engine setup controllable, make sure to add this to your procedure: Setup the reactor on its own stack and if possible, attach all the needed radiators to it. Attach its complement engine and if necessary, nerf the engine so it doesn't drain more EC than is produced (this is only necessary for the huge engines). Take that stack now and multiply it with symmetry until you get a satisfying number for TWR. This only really matters if you want to land or launch in atmosphere. With the prototype craft below, 2x is not enough and 4x is even better. But this isn't always the case. Diminishing returns are hard to avoid or control, especially when the payload fraction goes up from here. Here's a mothership I launched from Minmus. It doesn't claim to be an SSTO but it had about 6km/s dV fully loaded and had some LFO and roughly 1.2km/s for its VTOL mode and a tiny chemical rocketed lander. it was rated for operation with the surface gravity of Vall which is greater than that of Mun. It also contained 3x Near Future's 8 ton Prometheus reactor and 6x 1.25m Lithium engines.
  8. There's a lot of factors at play here, the biggest of which is probably your gravity turn profile. The time you spend in the lowest parts of the atmosphere should be short either way, and the amount of time you wait till beginning the turn can make a big impact on dV margins. I think either Matt Lowne or Stratzenblitz came up with this technique for getting consistent turns, but a good way to repeat the same gravity turn profile consistently is to turn to five degrees on your navball right after launch then set SAS to prograde at a certain altitude (or speed, I cant remember but the latter may be better for low TWR launchers). Experiment with when you begin the turn and see what works most efficiently. Addendum: It was Stratzenblitz (3 parts to Duna, Ike and Minmus) and they began the gravity turn at 80m/s. That was for their particular vessel though and it resulted in the vessel intentionally overheating so you may benefit from experimenting with the technique.
  9. Rough is correct, for reasons mentioned above. Terminal velocity is dependent not only on the characteristics of the atmosphere, but on the characteristics of the craft, and can change dramatically over the course of the flight (as a case-in-point, this is how parachutes work, though I admit that I do not know whether this is how their simulation works in the game). I can give you an explanation. That chart was an attempt to provide information that would be useful to players who had to work with few mods, few stock indicators, and a weird atmospheric model. None of those things is still true. It comes from this challenge: If you're not familiar with the Goddard problem, the short version is that it is an efficiency problem. The slightly longer version is that it is the question of how best to control a rocket to get the most altitude out of its propellant while taking into account the drag and atmospheric characteristics. It's of practical use because more efficient control means getting more out of a given load of propellant, but because of the reasons mentioned above, it's very specific to a particular rocket in a particular atmosphere. It's also only useful for a particular trajectory: straight up. Reaching maximum altitude is rather useless when the goal is to achieve orbit: the principles are different and the optimum solutions have almost nothing to do with one another. That being said, KSP is great for simulating these kinds of problems because it offers true reproducibility. It's also terrible for getting practical results from simulating these kinds of problems because it's not simulating other real concerns such as unavoidable variations in manufacturing the rocket, changing atmospheric conditions, or a fully-accurate aerodynamic model, among other things. However, at the time that it was made, that chart did provide some useful information. I'll provide details in the spoiler, mainly because it discusses completely outdated game mechanics and I don't want to create confusion. That being said, I think that this is actually a very interesting piece of KSP history, because this is from 2012 and people were still trying to figure out the mechanics of the game (and for a lot of them, spaceflight in general). Have a look at these cutting-edge graphics: Note the lack of lights, gear, and abort action groups. Also note that SAS was in the staging and had a finite capacity. Note the lack of info panels and KSPedia. Suffice it to say that there once was a time when people got to orbit by launching straight up and out of the atmosphere, then turning over and burning horizontally to make orbit ... hopefully before falling back into the atmosphere. At the time of this challenge, the atmospheric model was something like ten times more dense than what it ought to have been. Eventually, people settled on a hybrid approach to ascend in something (very) roughly approximating a gravity turn. What you see here is some of the experimentation that the players performed on their own to try to figure out those optimal ascent and control profiles. The terminal velocity table came from that. It worked at the time, so it made it into the wiki. After version 1.0 and the new model, someone noticed that a table of terminal velocities and altitudes no longer made sense for general use. It's not a matter of updating the table with new values for Eve: general values simply don't exist. An atmospheric density table would be nice, but density varies with temperature, which varies a lot with latitude and time of day, as well as altitude, so a table probably doesn't make much sense compared to an equation, or at least an algorithm. More pragmatically useful would be a list of good landing locations that combine high-altitude plateaus for launch with proximity to multiple biomes for research. Eve's rotation period is nearly four (Kerbin) days, so there isn't much to be gained from landing at the equator (55 m/s of eastwards rotational velocity instead of Kerbin's 175 m/s), but landing four kilometres above sea level is useful to avoid both the density and the heat of Eve's lower atmosphere. There is the idea that, given Eve's greater and more constraining challenges, the kinds of rockets needed to ascend from Eve's surface will be much more generally similar than the many and varied vehicles that come from Kerbin. In such a situation, you can make simplifying assumptions about the nature of these rockets to get a generally applicable range of solutions to the optimal ascent problem. However, those solutions are still dependent on the type of rocket, not on the planet itself, and so still wouldn't really fit on the wiki. But if you wanted to make a tutorial thread, however, then that would be a fantastic idea.
  10. This is an in-depth tutorial, but still directed to beginner-intermediate players, on how to do a proper launch and gravity turn with the new aerodynamic model introduced as of version 1.0. This tutorial works for versions 1.0 to 1.3. More than giving a script or set of instructions, my goal with this tutorial is for you to gain an understanding of the factors that affect your rocket's behavior during launch, so that you can apply it to any rocket you fly. For that, you'll need to go through the entire post, but I'm also including a TLDR as a "cheat sheet": TL;DR (courtesy of @kBob) 1. Turn ON SAS and set throttle to give TWR of ~1.5. 2. Launch! 3. When your speed reaches 50 m/s, perform a pitch over maneuver (tip towards the East until pointing between 5° to 10°). 4. When SAS stabilizes (i.e. the control input arrows on the bottom left are all centered), turn it OFF. Avoid control inputs and use only throttle to control your gravity turn (throttle up to turn slower, throttle down to turn faster). 5. When your altitude reaches ~40 km, turn SAS ON. Start pitching down manually towards the horizon and adjust throttle to keep your Ap around 45 seconds in front of you. 6. When your Ap reaches the desired altitude, cut your engines, coast to Ap and circularize. ========================================================================================== General Notes on Gravity Turn You all probably know by this point that to get into orbit you need to go up, above the atmosphere, but you also need to go sideways (i.e. horizontally) very fast. To do this, we could launch straight up until we're out of the atmosphere, then point sideways and accelerate to orbital speed. But that would be very inefficient. We want to launch in a way that we gradually turn sideways while we ascend. This is called a gravity turn. The best way is to do a real gravity turn; that is, a turn caused by gravity and aerodynamic forces, rather than one achieved by actively turning the rocket. It is important to keep this in mind. Design Items Before even launching, you need to take these design items into consideration when building your rocket: TWR: Your thrust-to-weight ratio (TWR) at launch should be relatively low, around 1.5. A higher TWR at the beginning of the launch makes it harder for your rocket to turn naturally, as gravity will have less influence on its trajectory, making it fly straight and screwing up your gravity turn. Keep in mind that drag losses are almost negligible in the new aero, unless your rocket is shaped like a brick or you are going extremely fast in the lower atmosphere. Thus, a slightly higher TWR of around ~2.0 in theory is more efficient, but only if the launch profile is flown correctly. The drawback is it makes your rocket less forgiving in terms of control during ascent, and it shortnes your widnow to make a pitch-over maneuver. What usually ends up happening is that you have to force the gravity turn manually, which does generate significant drag (because you expose the sides of your rocket to the airstream anytime you deviate from your prograde vector), and causes steering losses (Dv wasted on changing direction rather than gaining velocity). This reduces overall efficiency and defeats the purpose of having a higher TWR to begin with. A higher TWR also causes increased stress to the craft, inducing wobble and risking a RUD, especially when trying to maneuver. You may experience heating issues too. For these reasons, in my experience, a TWR of ~1.5 is a good sweet spot between efficiency and controllability of the rocket. Smaller and lighter rockets handle higher TWR's better than big and heavy ones and each craft will have its own sweet spot; you are encouraged to experiment. If you find your TWR at launch is too high, either use a smaller engine or just throttle down, and vice versa. As a final note, all rockets will have their TWR go up as the launch progresses due to shedding weight by burning fuel. This is normal and you should manage by reducing throttle throughout the ascent as needed (more on this below). You can check your TWR with the Kerbal Engineering Redux mod (KER) or with MechJeb, or if you're running a stock game, the G Force meter roughly doubles as a TWR meter (if the G Force meter is pointing at 1 your TWR is roughly 1, and so on). Aerodynamic Stability: You want your rocket to be aerodynamically stable. That means that it will have a natural tendency to fly straight, instead of, say, sideways. Any object that flies through the atmosphere will naturally orient itself with its center of mass (COM) facing forwards relative to its trajectory and its center of drag (COD) facing backwards. You can see this in darts, arrows, badminton cocks, etc. Similarly, you will want to have your rocket's COM in front of your COD. To ensure this, add 3 or 4 winglets or wing surfaces with radial symmetry at the base of the rocket, and if possible cover your payload in a fairing to make it more streamlined. If your rocket insists on flipping, you need to add more/larger wings at the bottom. If that still doesn't fix it, it means your COM is shifting back too much as fuel is burnt. The heaviest part of a rocket in KSP is usually the main ascent engine(s), so the COM will tend to move back as fuel is spent. The easiest way to fix this is to add a small fuel tank at the top of the stage that's experiencing the problem and lock the tank in the VAB (right click on the tank and select the green arrows for both fuel and oxidizer). This fuel tank will act as ballast keeping your COM forward. You can unlock it manually in flight when the rest of the stage's fuel is gone so as to not waste it, and then stage as normal. Ascent Profile Once you've implemented the above design items, follow these steps for your ascent: 1. Turn on SAS and set your throttle to whatever will give you a TWR of ~1.5. 2. Launch! 2. As soon as your speed hits 50 m/s, perform a pitch-over maneuver to begin your gravity turn. To do this, tip your rocket towards the East slightly, until it is pointing between 5° to 10°. Don't start pitching over before your speed is ~50 m/s, otherwise you will likely find yourself horizontal within a few seconds, as your winglets won't be biting into the air hard enough to provide stability. The higher your thrust, the more you need to pitch over initially, because higher thrust makes the rocket want to go straight. If you're using a TWR higher than 1.5, your pitch-over should be to at least 10°. 3. As soon as your SAS stabilizes (i.e. the control input arrows on the bottom left are all centered) turn off the SAS. Watch closely for this moment, as you will have only a small window of a few seconds at most before the SAS starts trying to resist the gravity turn. Turning SAS off while it's trying to steer will cause your rocket to become unstable and lose its heading or possibly break up. You should be done with your pitch-over maneuver and have your SAS turned off by the time your velocity is around 100m/s. If you take too long and your rocket is going too fast by the time you're done, it won't want to continue turning (fast rockets like to go straight, remember?) and you'll have to force the turn manually, which is inefficient and causes stress on your craft. As mentioned above, a gravity turn should happen on its own and not as a result of control input. For particularly unwieldy rockets, you can lock SAS to prograde instead of turning it off during this phase. However, stock SAS is far from perfect and it's best to let gravity and aerodynamic forces do the steering for you. If you do use SAS, be sure to disable it before you hit 35 km to avoid you craft from jolting down suddenly when the navball automatically switches to orbit mode, which happens at around 35 km. 4. Enjoy the view while your prograde marker gradually sinks towards the horizon; your rocket will follow on its own thanks to gravity and aerodynamic forces. Try to avoid control inputs during this phase (i.e. no AWSD), just let it fly. If you need to make adjustments, use throttle. Remember, lower thrust means the rocket turns more, higher thrust makes it want to go straight. At about 10 km altitude, you should be pointing roughly to 45° and your speed should be around 500 m/s. If at 10 km altitude you're still pointing above 45°, your TWR was too high and you went too fast and/or your pitch-over maneuver was too gentle. Next time throttle down more or make a more aggressive pitch-over maneuver. On the other hand, if you're pointing below 45° at 10 km, you went too slow and/or your pitch-over maneuver was too aggressive. Next time use higher thrust or do a gentler pitch-over maneuver. If your rocket flips on its end at any point, it's not aerodynamically stable enough. See above under "Aerodynamic Stability" for possible solutions. 5. At around 40 km altitude, turn SAS back on and start steering manually; use pitch and throttle to keep your Ap around 45 seconds in front of you. Any time you're burning above the horizon, you're wasting part of your thrust to gravity instead of gaining horizontal speed; this is called gravity losses or gravity drag. In the initial stages of the launch, you can't help incurring gravity loses because you need to gain vertical speed to get out of the atmosphere. The atmosphere also means you can't steer away from the prograde vector without inducing aerodynamic drag, steering losses and/or destabilizing your rocket. However, by the time you get to ~ 40 km, you'll have enough vertical speed and the atmosphere will become negligible. Thus, at this point you want to begin gradually pitching down towards the horizon. During this phase, you will also start adjusting your time to Ap. It's most efficient to perform your orbital insertion burn right at Ap, so you want to keep it "hovering" only a few seconds in front of you. Of course, you don't want to it to get too close either, otherwise you risk passing it and falling back down into the atmosphere. A time to Ap of ~45 seconds is a good rule of thumb to balance safety and efficiency. To control your time to Ap, use pitch and throttle. If your time to Ap is more than 45 sec, throttle down a bit and point more horizontal, and vice versa. Avoid pitching below the horizon. Continue adjusting pitch and throttle until your Ap reaches your desired altitude, at which point you can cut your engines, coast to Ap and circularize. Note that as you approach orbital speed, there will be a point when your Ap will begin shooting away even if pointing straight at the horizon and no matter how much you throttle down (unless you cut the engines of course). If you reach this point, just let it go until engine cutoff; any efficiency gains from keeping your Ap near you will be negligible by then. Advanced Mode Try doing the ascent and orbital insertion in a continuous burn. This is the most efficient profile (citation needed) and it's extremely satisfying. Easier said than done, though. To pull it off, you need to allow your time to Ap to creep closer and closer during steps 4 and 5, while not allowing it to get higher than your intended orbital altitude. You do this by reducing throttle and lowering your pitch in a more aggressive manner. The closer you are to orbital velocity, the closer you can allow yourself to get to your Ap. You want to hit orbital velocity exactly at Ap. There will be much trial and error and the exact procedure will vary from rocket to rocket, but give it a try!
  11. don't sell yourself short. and don't conflate the difficulty of the task. there's gravity assist and there's gravity assist. some are easier than others. getting a chain of multiple gravity assists is relatively difficult. using a gravity assist to change inclination and intercept a comet is very difficult. but that's not what you are doing here. a basic gravity assist is simple. in fact, you may have done them without even realizing. from low kerbin orbit, make a normal transfer to mun. to go to mun, you will have to make a capture burn at periapsis. stop there. do not make the capture burn. you will pass close to mun, and then you will be shot out of the kerbin sphere of influence. it normally takes 930 m/s to escape kerbin's gravity, but you spent the 850 m/s of a mun transfer, and you still got out. you have taken a gravity assist. basic gravity assists are easy. similarly, when you arrive at jool, aim at tylo or laythe - they are so big, you can find them easily - and you will notice your trajectory change after passing close to one of the big moons. there, that's a gravity assist. with a bit of trial and error you can use that to get captured for free. sure, there's a lot more about gravity assists, and to perform the complex ones you need practice and you need to know what you can and cannot do with them. but don't let yourself be intimidated, it's something you absolutely cannot do. in this specific case of reaching moho, try instead going for eve, and pass close to eve. depending on which side of eve you pass, your solar orbit will get higher or lower. choose the side that will lower your orbit. and there you go, you have lowered your solar orbit without using fuel, with a gravity assist. a single passage like that will not get you to moho. for that you would need to know about intercept speed, and you would have to chain multiple assists. however, your single passage already brought you closer to moho than you were before. it will save maybe 1 km/s, and it's not overly difficult; all you need to do is intercept eve, and you already know how to intercept planets. so it's worth doing, isn't it? P.S. 8.2 km/s is very high, even for moho. did you by chance eject from kerbin into solar orbit, and then lower solar periapsis from solar orbit? that would explain why it's so expensive for you.
  12. I'd argue not quite that bad. We can extract a lot of information from what is show there . If you pay close attention you will notice that ctbram does indeed cut the thrust when the relative velocity is 0.0m/s. At this point we may observe the relative velocity is not constant. Exactly what he want to show us. But what catches our attention is something else: A moment later the engine is reactivated when we are not expecting . That is because ctbram is relying on SAS to point the ship retrograde and he can't do it with speed below 1m/s. "inefficient"? Maybe, but it is not the "mysterious" acceleration ctbram is referring to. It distract us for a moment but as soon we notice what is happening it becomes irrelevant. Let's get back to the situation where Barlin Kerman is chasing the Target and he just cut the thrust. Ctbram's question to us: why, at this moment, the relative velocity is not constant? Considering: K position of Kerbin B position of Barlin T position of Target ab acceleration of Barlin in the direction BK due gravity at acceleration of Target in the direction TK due gravity. db distance between Barlin and Kerbin dt distance between Target and Kerbin Given the angle BKT, make sense to reescribe at as: atcos(BKT)r + atsen(BKT)s where r is the direction BK and s the perpendicular direction to BK within the orbital plane. (For the sake of simplicity let's assume relative inclination is zero.) considering some numerical values for at and BKT: at BKT atsen(BKT) 9.8m/s2 1º 171.033mm/s2 9.8m/s2 0,1º 17.104mm/s2 9.8m/s2 0,01º 1.710mm/s2 9.8m/s2 0,001º 0.171mm/s2 as we can see the acceleration component in the direction s approaches zero as the angle BKT approaches zero. In fact at for BKT = 0 (B, K and T are collinear) we have: atcos(0)r + atsen(0)s == atr But wait. This is acceleration due gravity: g=GM/d2 where GM is constant and d is the distance between the central body (Kerbin) and the orbiting ship. we want to find the situation were ab - at = 0 GM/db2 - GM/dt2 = 0 1/db2 = 1/dt2 db =dt Conclusion: to have exactly the same acceleration due gravity (amount and direction) Barlin and Target need to be in exactly the same position relative to Kerbin. The acceleration you observe is the acceleration of the non-inertial frame of reference due Kerbin's gravity. PS: the special case were both craft are in the same perfectly circular orbit is left as an exercise to the reader
  13. Hello All, I'm new to the forums and just getting into the game. One thing I can't get right is the EVA over Kerbil. When I press EVA he gets out but immediately the rocket starts to turn. This makes manoeuvring extremely difficult as the rocket is constantly turning. All the tutorials show it dead steady when he gets out. I have tried pressing T to stabilise the ship but it doesn't stop rotating. Can anyone help me out please?
  14. Hi, I'm having this issue where my plane is going in reverse AND veering to the left in circles. Anyone an expert on these parts and help me out? I'm currently using Restock+ if that helps. Version 1.12.5
  15. I ask those with experience in real solar system how the gravity turn goes. in the stock game, you generally want to turn very fast, starting already around 50 m/s, being down at a 45° angle already at 500 m/s. that because in stock you orbit at 2200 m/s, you want to be horizontal at that speed. in real solar system, at 2200 m/s you still miss over 5 km/s to orbit. I had experiences where I did start angling down early, and I had to pull up later. on the other hand, I am now trying to go straight up until around 15 km altitude, and while this enables a proper gravity turn afterwards, going straight up at 700 m/s doesn't feel right. it can't be optimized, can it? and orbital launches in rss last way too long for me to want to go by trial and error. any good tip on when I should start turning?
  16. I'm attempting to build a massive SSTO rocket but when I attempt to start turning in the air my rocket instantly explodes. I'm using part clipping to get the diameter of the rocket smaller but from what I understood that shouldnt affect the physics of the craft. The flight log says that there was a structural linkage failure between two adapters high up on the rocket in a random spot. If it helps I'm using vector engines attached to an engine plate onto a 5m fuel tank.
  17. Reaching Kerbin orbit at 7.6x scale requires achieving a surface velocity of about 6200 m/s. No matter how much you optimize the ascent profile, there's no way to get around the fact that orbital velocity is fast. Jet engines are efficient, but their downside (apart from requiring oxygen) is that their thrust starts decreasing beyond a certain speed dependent on the exact engine, and eventually drops to nothing. The Panther engine, for instance, completely loses thrust at Mach 3.5 (≈1100-1200 m/s). Other less efficient jet engines such as the Whiplash or RAPIER are better, continuing to function until Mach 5.5-6 (1800-2000 m/s), but that's it. At stock scale, where you only need to achieve a surface velocity of 2100 m/s, jet engines can take you almost all the way there, and you can get away with having only a little bit of rocket power that pushes you the rest of the way into orbit. Since you're so close to orbit, centrifugal force reduces the TWR requirements considerably, so there are a lot of options: nuclear engines to avoid the need for oxidizer, small LFO engines for lower dry mass, or really anything with enough Δv. At 7.6x scale, the situation is completely different: even 2000 m/s is nowhere close to orbit, and you need to accelerate the remaining 4200m/s (or probably more) with rocket power alone, while fighting drag and gravity without much help from the curvature of the larger planet. The Δv requirements for the one stage practically necessitate nuclear engines, but the TWR requirements (something like 1.0-1.5 g) are difficult to achieve with the stock NERV, especially if you're also using it to carry stuff like wings and payload. There's a reason why SSTOs have never been built in the real world, and the comparatively limited selection of parts in KSP makes designing one even harder. Your 4560-km-radius Kerbin is not quite as difficult to orbit as the 6378-km-radius Earth, but I don't think that this minor decrease in orbital velocity is enough to make the challenge doable without a whole lot of trial and error, and a very small payload fraction. Edit: As @Lt_Duckweed points out, I was neglecting the possibility of continuing to remain at low altitude during most of the ascent, which would allow the plane to use lift to lower the TWR requirement to manageable levels. This requires very precise control over both altitude and angle of attack to maintain just the right amount of lift, and generates a ton of heat at high velocities. However, the somewhat unrealistic wing parts in KSP take zero damage from any temperature below 2400 K, so they might just be able to survive. I have never been successful flying an SSTO like this: either I encounter too much drag and quickly run out of fuel, lose control of pitch and spiral into a crash, or make too sharp of a turn and break my wings off. It's definitely possible, though, and I imagine that an autopilot mod would help reduce the risk of all of these problems.
  18. I have always been scared of gravity assists, but when exploring the Jool system I was amazed to discover that I could get a free capture by flying close to Tylo or Laythe. Up until that point I had thought aerobraking was the only way to achieve this kind of thing. So on my return journey, which was a 1k dv burn from Laythe back to Kerbin (incredible! especially when compared to the dv chart) I decided to do some playing around with the Kerbin insertion. I noticed that when I approach a body from the left (i.e. as if I were to insert into an inverted, or clockwise, orbit) my craft becomes more aligned with the body I'm flying past, as if I had burnt retrograde. It doesn't seem to matter if I'm jumping up (Kerbin to Jool via Tylo or Laythe) or down (the opposite) an orbit. And conversely, if I approach from the right (i.e. as if I were to insert into a normal, or counterclockwise, orbit) then the body is actually adding to my velocity and the gravity assist looks like I burnt to prograde. Is what I found generalisable or is it just working out this way by accident? I managed to time a flyby of both the Mun and Kerbin on my return from Laythe, both pretty close and from the left, which brought me into an orbit with an Ap somewhere between Duna and Dres, which is a pretty big dv saving given that I was coming from Jool! I was impatient and wanted my next Kerbin approach within a year, so I spent about 300dv at that point to get a quick rendezvous but I could imagine waiting some more years and it would have come along naturally. My approach speed after doing this was very very safe for an aerobrake into Kerbin at that point, whereas it would have been touching cloth to have gone straight for the aerobrake first time. However, it occurred to me that when doing an aerobrake it always has to be from the right (counterclockwise) to go with the surface movement. But that's actually counter-productive compared to the non-aerobrake scenario. Are there any situations where it's worth going into the atmosphere from the left, and staying quite high, to get the benefit of both kinds of decelerations at once? The GA effect from the left is definitely my preference when I can do it, because it is just so much safer than risking the craft on a high speed aerobrake. Anyways, that's what I've figured out with experimenting. I'd be really interested in knowing if there are any in-depth tutorials that go into more detail than this. I watched Advanced Orbital Mechanics by Bradley Whistance (undoubtedly the king of gravity assists) but I found it lacking in detail... e.g. the approaching from the left vs right and tricks. On my return to Kerbin I ended up spending a bunch of dv to get an intercept on the followup orbit , but is there maybe a trick to get that for free? e.g. maybe trading off some of the saving to get exactly the right orbital period to come back round again for the next pass (within 2 years), I wasn't able to get it to work. My only remaining challenge in the game is the Grand Challenge, so I'm thinking of using some techniques to avoid having to mine for fuel along the way.
  19. After just getting something into orbit (and perhaps a Mun landing), the next big challenge for a new KSP player is how to dock in orbit. Here's a step-by-step illustrated guide for how to do so. (There are various techniques... and plenty of other guides out there. This is just how I like to do it. I hope you may find it useful.) (Author's note: Please forgive the out-of-date screenshots. This post is ported from a blog entry I made on an older version of the forum software, back in 2015, so screenshots reflect what KSP looked like at the time. The appearance has changed a bit since then, but everything I wrote here still applies.) The big picture Docking proceeds in four main steps: Rendezvous. This is the part where you use maneuver nodes to arrange for your ship and the target to be in the same place at the same time, or at least as close as possible. Careful fiddling with the maneuver node will generally get you a rendezvous within a kilometer or so. Fine tuning the rendezvous. This involves making small burns as you approach the target, in the last few kilometers, so that your closest approach is zeroed in to a few dozen meters (from the kilometer-or-so you got in step 1). This involves close observation of the navball and light touches on the throttle. Kill relative velocity to target, right when you're at your closest approach. Also a navball-and-throttle operation. You're now parked right next to the target, just a few meters away. Actually dock. This involves eyeballing docking port alignments in the camera view (unless you have a mod installed to show docking alignment on the navball, which is a big convenience). This is where you use your RCS thrusters to jockey for position. The following sections go into detail on these steps. Step 1: Rendezvous Navigation tool: Maneuver nodes and map view Control via: Main engine and throttle The first thing you have to do is to send your ship on a course that will put it and the target in the same place at the same time-- or, at least as close as you can get with maneuver nodes. I'm assuming here that you in fact have maneuver nodes (i.e. you've unlocked them by upgrading the tracking station), and also that you're familiar with how to use them. I'm also assuming that you know how to set up a fairly good orbital rendezvous with maneuver nodes, i.e. one that will get you a closest approach within a kilometer or two. This is a big assumption: doing that is actually a significant challenge, and if you're a new player just learning how to dock, there's a pretty good chance you may not have mastered "orbital rendezvous with maneuver nodes" as a skill yet. However, I'm not going into it here, for a couple of reasons: It's a whole complex topic in its own right, and this blog post is about docking rather than general orbital navigation. (I may add a "how to rendezvous" post at some time in the future, in which case I'll link to it from here. If my glossing over this part is frustrating, please let me know so that I can gauge demand. ) Here's a handy guide to rendezvous (not mine). The details of how to set up a rendezvous vary a lot depending on the starting situation (e.g. launch from surface to direct intercept, or two craft already in orbit, are their orbits coplanar or not, etc.). But even though I'm not telling you how to do it here, I can show you what "good" looks like: Exactly what your own situation will look like depends heavily on circumstances. But the important bit is that it's a close rendezvous. You want the closest approach to be as close as you can manage with the maneuver node-- no more than 2 km at most, preferably under 1 km. (In the above example, it's 0.3 km, which is pretty good.) One more side note: See how the target (yellow) line and my own ship's (cyan) line are crossing each other like an X, rather than being close to parallel to each other at the point of intersect? That's actually pretty bad: it means that they're orbiting in significantly different directions at the point of intersect, which in turn means that they're going to have big relative velocity to each other, which means I need to burn a lot of fuel. I've done it that way deliberately, here, so that this guide can show you "how to dock" even if the situation's not perfect. Ideally, you will set it up better than this, so that their relative velocity at closest approach will be smaller, and therefore your job will be easier in the remaining steps. Step 2: Fine-tune the rendezvous Navigation tool: Navball and map view Control via: Main engine and throttle Your eventual goal (in step 3, below) is to coast to a stop so that you're parked right next to the target (as in, just a couple of dozen meters apart). Chances are, however, that unless you're either super lucky or an ace at maneuver-nodes, the rendezvous that you set up in Step 1 above will only get you to within a few hundred meters at best-- perhaps a kilometer or two. You'd like to be closer than that when you match velocities, since your final approach (using RCS) will be very slow, just centimeters per second, and you don't want to have to do that for a kilometer or more. So the way to solve that is to make minor course adjustments with light touches on the throttle of your main engine, using the navball for guidance. Here's how: First things first: Make sure navball is in "target relative" mode Once you get close to the target, you don't care what your orbital velocity is. You only care about your velocity relative to the target. Chances are, the navball is probably in "Orbit" mode when you're in orbit (the game does that automatically, unless you've manually tinkered with it). Normally, when you approach your target within 60 km, the navball will switch automatically to "Target" mode instead of "Orbit": this causes your prograde/retrograde markers to indicate your target-relative velocity rather than your orbital velocity, which is what you want. It looks like this (note the "Orbit" or "Target" indicator at the top of the navball): ...Typically, it will do this automatically for you and no action is required on your part. I only bring it up because it's possible this might not happen, and you need to make sure that the navball is in "Target" mode, or nothing after this point will make any sense. You can change the mode manually by clicking on the label. This will toggle the navball between Orbit, Surface, and Target modes. Why this fine-tuning step is needed As you get within several kilometers of your target, your navball will start to look something like this (again, make sure your navball is in target mode): This looks pretty good: your marker (target relative velocity) is pretty close to your marker (target direction). The fact that these two are close together means that you are heading almost directly towards your target. However, the key word here is "almost". If you just coast towards your target and do nothing, you'll see the marker slide farther and farther away from the marker, like this: That's because you're not heading directly at the target. Unless you got super lucky (or are an ace) with the original maneuver node, your closest approach is likely to be at least several hundred meters away from the target. This means that without any course corrections, you're going to go past it, and the target will slide off the side of your navball in the same way that someone standing beside the road slides off to the side of your windshield as you drive past them. Therefore, you need to adjust your course when you get close by, so that you are sitting right next to your target (and not a kilometer away) when you come to a stop relative to it. What to do When you get reasonably close to your rendezvous (say, when it's 1 minute away, which you can see in the map view when you mouse over the intercept marker), start the process. What you're trying to do is to move your marker so that it's precisely centered on your marker (i.e. so that you're heading directly at the target). To do this, start by lining up your navball so that your crosshairs, , and are exactly lined up in a straight line, like this: Note that the marker is exactly on a straight line in between the navball crosshairs and the marker. Why do we do this? Well, firing your engines "pushes" the marker away from the center crosshairs on the navball. Since what we want to do is move the marker onto the marker, then by lining the navball up this way, it will "push" the marker in the direction we want it to go. Once you've got it lined up, gently throttle up to move the marker. How much throttle you need will depend on your ship's TWR and how big your target-relative velocity is. So just keep a careful eye on the navball, gently throttle up, and be ready to kill the throttle immediately when things line up. As your engine burns, you will see the marker drift towards the marker, like this: When the two markers line up perfectly, cut throttle. (Don't worry if it's not pixel-perfect; all that matters is that it's better than it was. If you're off by a smidgeon, what will happen is that as you get closer to the target, the two markers will drift apart again, and you can do this correction maneuver again. Repeat as needed.) Prograde fine-tuning (if you end up too slow while still far away) In the preceding discussion, we did all our fine-tuning while thrusting close to . I recommend this because it kills two birds with one stone, thus saving dV: not only does it fix our heading to get a close approach to the target, but it also helps kill some of our velocity (since we'll need to reduce that down to zero in the next step). However, it could happen that you end up approaching too slowly while still far away: i.e. your target-relative velocity is very low while you're still at a long distance. In such a case, fine-tuning in the prograde direction is an option. Details in spoiler. Step 3: Kill relative velocity to target Navigation tool: Navball and camera view Control via: Main engine and throttle This is the easiest part of the process, since there's little steering involved. All you have to do is slow down to a stop in the right place. As you approach the target, line up your navball so that you're pointing perfectly retrograde (i.e. the marker is centered perfectly in the crosshairs-- again, make sure your navball is in target-relative mode, not "orbit"). If you have a level-1-or-better pilot, or if you have a HECS-or-better probe core, then this is easy: just choose the "hold retrograde" SAS button (red arrow in the illustration below). But if you don't have that convenience, just do it manually. As you approach the target, the marker will want to drift away from center; if necessary, you can do more correction as described above in step 2. Reduce your speed gradually as you approach the target. If you wait too long, you'll overshoot; if you start too soon, you'll go too slowly and it takes forever to close the distance. I find that a handy rule of thumb is "stay 30 seconds away from intercept": switch to map mode and mouse-over the intercept marker, which will give you a timer countdown to closest approach. Thrusting to slow yourself down will increase the time-until intercept. Just keep that at 30 seconds until your speed gets down to whatever you're comfortable with (I usually go for around 10-15 m/s), then switch back to camera view and you can eyeball it the rest of the way. When you get really close, slow yourself to a stop, 0 relative velocity. You're now parked right next to the target-- if you got things lined up well up to this point, you'll be very close, just a few meters away, like this: Step 4: Prepare to dock Navigation tool: Navball and/or camera view Control via: reaction wheels only First, get roughly lined up. We need to get the docking ports at least approximately lined up (facing towards each other). If possible, the easiest way to do this is to switch briefly to the target ship (using the [ ] keys) and rotate it so that it points its docking port towards your ship, then switch back and rotate your ship appropriately. This is a lot faster and easier than flying your ship around the target to get in the right spot, which is tedious. (Sometimes that might not be an option, if it's not practical to rotate the target-- for example, if your target is a huge, massive, asymmetric space station with random stuff docked all over it. In that case you just gotta fly your ship to where it needs to be.) Next, set your target and control-from to the two docking ports. Right-click on the target docking port and choose "Set as Target": Right-click on your own ship's docking port and choose "Control from Here": Now, get your orientation precisely aligned. That is, you want the axis of your docking port and your target's to be precisely parallel. (They may be laterally offset from one another for now, but we'll deal with that next). There are a couple of ways to do this: Option #1: Use a docking-alignment mod. My personal favorite is Navball Docking Alignment Indicator. It's very minimalistic, uses no screen real estate, stays out of my way when I don't need it. What it does is this: whenever your target is a docking port, it adds a red icon to the navball showing your alignment relative to it. When that red icon is perfectly centered in your navball cross-hairs, it means you're perfectly aligned for docking. So if you have this mod installed, all you have to do is rotate your ship to center that red icon. Your navball would then look like this: ...all you need to do is to rotate your ship to center the red icon in the navball crosshairs. Option #2: Just eyeball the orientation. This is doable but less convenient. Not only do you generally have to monkey around with different camera angles, but it also becomes a royal pain in the dark, since you can't see what you're doing unless the ships are lit up. This is what I did for the first several months (and several hundred dockings) in KSP, until I got fed up and switched to option #1. Really, that mod ought to be part of the stock game, IMHO. Either of the above two options will work. For the remainder of this discussion, I'll use screenshots that have the mod present, not only because that's how I do it when I dock, but also because it makes the screenshots much easier to understand. Next, turn on fine-control mode. This is caps lock by default (on Windows machines; I think it may be different on Macs). Doing this will turn your control indicators at bottom-left from red to cyan, like this: ...The reason why you do this is described in another blog post, but what it boils down to is that it makes your RCS thrusters smarter so that it's easier to control your ship. Next, activate RCS (press R). There, we finally get to use our thrusters! Step 5: Dock! Navigation tool: Navball and/or camera view Control via: RCS thrusters Okay, now the fun part. Thrust gently prograde using your RCS thrusters until you get your speed up to 0.2 or, at most, 0.3 m/s. Slow slow slow. Your ship is now heading directly straight ahead. However, that's not quite right yet, since the target is offset to the side by a bit. We need to apply some lateral thrust in order to get us heading in the right direction. Initially, your navball might look something like this: How to read this: You're pointing in exactly the right direction: the red icon (from the mod I discuss above) is perfectly centered in the crosshairs, indicating that you're aligned correctly. Your position isn't quite right, because the target isn't directly in front of you. The is off to the left, instead of perfectly centered in the crosshairs where we want it. Your velocity isn't quite right, either-- the marker shows that you're moving up and rightwards as you drift forward, whereas your target is off to the left. So now you need to use your RCS thrusters to correct that. Use your lateral thrust (IJKL for up, down, left, right) to nudge the marker to where it needs to be. You want to arrange it so that the marker is directly on a straight line between the marker and the center crosshairs, like this: ...What this means is that as you drift towards the target, you're also drifting sideways so that you're lining up with it. As you get closer, you will see the slide towards the center crosshairs. As it gets closer to the center, you can nudge the marker inwards, too (using RCS), still keeping it lined up: When the marker reaches the center of the crosshairs, use RCS to center the marker there, too. You're now all set up perfectly for docking: Centered red icon = you're facing the right way Centered = the target port is right in front of your port Centered = you're traveling directly towards it Now all you have to do is just let it coast until docking completes. Ta dah!
  20. I'm a bit of a purist, so I don't use Mods, at all, when playing KSP. Using the rotation adjustment with Snap on means that the minimum change in angle that can be achieved is 5 degrees. For making various spaceplanes, especially SSTO's, it is desirable to be able to pick a smaller angle. To do this I have made an Inclinometer that I use for getting precise angle with snap off. The inclinometer has been set with graduations of 0.5 degrees using small solar cells as "markers. I have saved the Inclinometer as a subassembly so I can bring it out as I need it. In this case I'm using it to se the wings for an SSTO cargo carrier. I want to set the wings at 2 percent. I attach an arm made of wing sections to the wing I'm adjusting and move it back and fourth until the arm matches with both arms on the inclinometer. Then I turn snap off and rotate to the angle I want, in this case 2 degrees. Using this I can confidently set an angle within a tenth of a degree. Then I can delete the arm and inclinometer and set the wing to where I want it! Can this be done with Mods? Absolutely, and no doubt more precisely.
  21. KSP Visual Calculator Online calculator tool for Kerbal Space Program Delta-V Planner Click the planets and moons that you want to visit to get a total required delta-v number for the mission A mission can contain multiple checkpoints to visit, each on different planets, moons, and orbital situations (or surface landed) Also provides a step-by-step breakdown for each leg in the journey Shows the delta-v requirements for every possible trip combination (delta-v subway-maps only work when Kerbin is one of the locations) Configure custom preferences such as aerobraking at specific locations, applying a margin of error to your mission, or calculating the most efficient route instead of a direct route Save & export the mission as a JSON file to share with others CommNet Planner Create satellites, relays, rovers, stations, bases, etc. with a custom selection of antennae, then drag those around the screen to see where commnet connections are valid Every craft automatically indicates if it has control or not based on the relay networks it is connected to Use this to plan out communication network constellations, without having to trial-and-error this in-game Set the DSN Tracking Station level at Kerbin to match in-game upgrade progress Set the CommNet difficulty settings to match the settings in-game Add Remote Guidance cores in craft to test a piloted base providing remote control to a rover, even when a connection to Kerbin is out of reach Shows detailed stats such as cost, power rating, mass, transmission speed, etc. for the entire collection of antennae on each craft Save & export the constellation as a JSON file to share with others ISRU Mining Station Calculator Design a mining base by swapping out different parts to see their effects on the system Select the planets or moon for the mining base, adjust the ore concentration, and even add a specific skill engineer onboard Toggle the type of processing that the ISRU will be doing. Only refining Liquid Fuel? Then only turn on Liquid Fuel refining Fuel cells, solar panels, and RTGs can be added for power supply A handy 'Production and Consumption' panel displays the total outputs, and any deficiencies of the system Number sliders control the amount of each part. Use this to adjust the amount of drills, or power sources, or radiators until the outputs are green with no deficiencies Warning messages highlight potential issues in the design, such as not having 'Ore Storage' parts Choose from 73 stock parts Save & export the parts selection design as a JSON file to share with others https://ksp-visual-calculator.blaarkies.com/ Checkout the github repo
  22. Build it like any other rocket, though you may want to preserve the aircraft shape by linking it to the launch stack by the belly rather than the rear, like the space shuttle. The only real problem is that the lifting surfaces the aircraft needs will strongly draw the rocket "upwards," and you'll need to account for that. Give the ship lots of control authority and maybe rotate it so that this trend works in your favor and helps make the gravity turn. Or you can use the really messy fix of making the craft symmetrical by copying the plane part on each side.
  23. When I turn most of my planes and rovers at high speeds, they strongly tend to keep turning faster and faster in the direction I turned, which often results in the craft flipping over. It happens even if I just touch the steering. How can I stop this from happening? Thanks.
  24. In addition to what @Vanamonde said, if your RCS and SAS is active, they sometimes prevent your vessels from self-aligning. It looks like you nailed a perfect docking. Try turning off SAS and RCS right at the moment the vessels start to attract each other. Turn of RCS: 'R' key. Turn off SAS: 'T' key. If you have an excessive amount of reaction wheels, they will hold the vessels in their orientation, instead of allowing the two vessels to self-align during docking. I know this, because I also put a lot of reaction wheels on most of my vessels..
  25. hey all, I have tried to turn on these buttons so I dont have to manually position my ship but to no avail, I have no idea where they are located in KSP settings, could somebody please help?
×
×
  • Create New...