OhioBob

All engines in KSP have a specific impulse vs. pressure curve. At some point the specific impulse goes to zero and the engine will stop producing thrust. All the stock engines go to zero long before ever reaching the surface of Venus.

There seems to definitely be some people out there still using 1.0.5 because one of my mods is still getting downloads of the old 1.0.5-compatible version. I think there has been about 20 downloads of the old version since I released the newer 1.1.x-compatitble version. I still have my 1.0.5 installed just in case I need it to test something, but I've switched to playing 1.1.2. Once all the mods are updated and I'm sure everything is working correctly, I'll delete 1.0.5.

Once I'm in space, then generally no. On a couple rare occasions I put into orbit a very large and unwieldy interplanetary vessel that lacked adequate reaction wheel torque. In that case the gimbaled engines helped to get and keep the vessel properly orientated for and during the ejection burn. That and during launch are really the only times where I've found engine gimbaling to be really useful. (I don't fly planes so I can comment about that.)

I use gimbaled engines during launch so that I don't have to have a lot of other control authority.

I don't know much about FAR, I don't use it, but that certainly doesn't sound right. At 60 km the air density should be about 0.00032 kg/m3.

Although the RSS atmosphere extends to 140 km, the upper part of it is much thinner than anything you'll experience in stock. By the time you reach the upper atmosphere, you'll probably not notice much in terms of aerodynamic effects. One way to tell is that if you can't high-speed time warp, then you are inside the atmosphere.

@NathanKell, I have some suggested fixes for you. First, after looking at Pluto I noticed that the terrain features in RSS are reversed from what they should be. Below is a map of Pluto: And here is a screenshot that I took from the game: As you can see, the screenshot is a mirror image. The textures should be flipped left to right. Furthermore, Pluto's initial rotation (currently set to 0) is off just a bit, making it's surface incorrectly oriented in relation to Charon. It looks like that setting initialRotation = 12 places the anti-Charon point in just about the right spot (dot in center of screenshot). Of course that should probably be re-checked after the image is flipped. I also found an error in Moon.cfg. The parameter listed as "LAN" should be changed to "longitudeOfAscendingNode". (edit) I've reverse my textures and it looks good. However, in making the mirror image it threw off the anti-Charon point. Setting initialRotation = 19 seems to fix it. If it will save you any time, I can provide a copy of the updated files.

That's a nice Δv map, but I'd like to point out that the orbit and periapsis altitudes and outdated. The new atmospheres in OPM 1.9.5 are deeper than the old ones. If you plan a flyby of Sarnus at 314 km, as shown in the Δv map, you'll be inside the atmosphere. Everyone just needs to be careful to check the new atmosphere heights before planning anything that will take you close to a planet/moon.

There is also this option:

I think I have some of this figured out. If you want to change Earth's solar day to exactly six hours, then add the following to GameData/Settings.cfg. @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Kerbin]] { @PlanetDimensions[3] = 0.250142477247968 } } (For some reason Earth's internal name is "Kerbin". Don't ask me why.) If you want to change Pluto's rotation so that it is tidally lock with Charon, add the following to GameData/Settings.cfg. @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Pluto]] { @PlanetDimensions[3] = 0.316227766016838 } } And if you want to make the length of each planet's year equal to its real life number of days, then add the following to GameData/Settings.cfg. @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim] { @Body:HAS[#name[Sun]] { @PlanetDimensions[4] = 1.59668824903153 } } Beware, however, that the above will increase interplanetary delta-v requirements. Also be advised that if the third change is made, do not make the first change. Changing the length of year will also fix the solar day.

I just learned something I did not know. KSP computes orbital periods taking into account the mass of both the primary and secondary bodies. For some reason I was under the impression that, for simplification, it used just the primary body. Perhaps it does that for spacecraft (since the spacecraft's mass is negligible), but that's clearly not true for planetary bodies. It is especially obvious in the Pluto-Charon system. It looks like I'm going to have to go back and take a another look at some of my calculations.

I've been playing around with the numbers and it looks like the increase in Δv is rather significant. For a spacecraft orbiting the Sun, any change in orbit will require a 26% increase in Δv. I also estimated at how much the Δv would change for an ejection burn from LEO. This can vary a lot, but for a Hohmann transfer to Mars, I estimate that an extra 75 m/s would be needed. That's not too bad, but for a Hohmann transfer to Jupiter the number jumps to about an additional 500 m/s. As much as I like the idea of having a 365-day Earth year, I'm reconsidering it. I think the extra Δv is too great and needlessly increases the game difficulty.

I just noticed something else that doesn't work quite right with the way things have been rescaled. Although Charon is set to be tidally locked to Pluto, Pluto is not tidally locked to Charon. This is because Pluto's rotation period doesn't match Charon's new orbital period. Assuming we want to keep the mass and dimensions of the Pluto-Charon system as they are, the easiest solution is to change Pluto's sidereal rotation period. If it's possible to change this parameter, I think this would fix it: rotationPeriod = 174791.289816996. Both Pluto and Charon have an initialRotation parameter. This parameter probably needs to be adjusted to make sure that the bodies have the correct hemispheres facing each other. That part I haven't figured out.

I had a somewhat similar problem in the past. The solution was to delete a .bin file in the cache. If you go to the following folder, GameData\SSRSS\RSSKopernicus\Cache\ You will see a bunch of .bin files. You might try deleting the one that's giving you the problem and allow it be recreated. However, make sure you can revert back because I can't guarantee I know what I'm talking about. I also see that there's a cache in the Sigma folder. If the above doesn't work, you might try playing around with the Sigma cache. I would use caution though.

There are many factors to come into play. Most importantly, which planet are you talking about? Also your incoming speed and the aerodynamic characteristics of your vehicle make a big difference. I performed a bunch of tests on this a while back. I used three different test vehicles, all with a 2.5m heat shield but with different masses. The first had a mass of 6410 kg (or about 1306 kg/m2 of heat shield), the second had a mass of 19,910 kg (4056 kg/m2), and the third had a mass of 37,910 (7723 kg/m2). I also tested approaching at two different hyperbolic excess velocities, which represented the approximate minimum and maximum that would be expected for a interplanetary transfer between Kerbin and the destination planet. For Eve I used hyperbolic excess velocities of 800 m/s and 2000 m/s, for Duna 740 m/s and 960 m/s., and for Jool 1600 m/s and 3000 m/s. Generally speaking, If you are coming in slow with a low mass, you want a high periapsis. If you are coming in fast with a high mass, you want a low periapsis. And for each set of entry conditions, there is a range of periapsis altitudes that will work - from just barely capturing inside the planet's sphere of influence, to just barely avoiding getting swallowed up by the atmosphere and not being able to pull out again. There are also other limiting factors, such as overheating to the point that the ship explodes, or losing aerodynamic control. In one case at Duna I found that I couldn't set my periapsis low enough to aerocapture without crashing into the terrain. In rough numbers I found that the minimum and maximum periapsis altitudes at Eve ranged from about 53-75 km, with a median of about 62 km. Of course that doesn't mean that you can pick a number anywhere in that range. If you have a lightweight ship you'll probably want to be somewhere around 66 km or so. For a heavyweight ship you'll need to be closer to 56 km. It is best to experiment to find the periapsis altitude that works best for your particular circumstances. At Duna the periapsis altitudes ranged from about 6-22 km, with a median of about 13.5 km. At Jool the altitudes ranged from about 144-171 km, with a median of about 155 km.

Actually, no. SSRSS applies a 0.7 factor to the RSS atmosphere heights. Therefore Earth's atmosphere is 140 x 0.7 = 98 km. There are two exceptions to this: Venus' atmosphere is factored 0.8, and Titan's atmosphere is factored 0.2. If you don't know or don't remember what the atmosphere heights are, they are listed in the planet information panel in the Tracking Station.

05:59:01 is Earth's sidereal period. It's the solar day that should be 6 hours. Unfortunately that is off a little bit too, with a length of 05:59:48. SSRSS is currently using a length of day multiplier of 0.25, which is applied to the sidereal period. The length of the solar day depends on a combination of the sidereal period and the length of the year. Because of the way the body sizes and orbits are factored, Earth's year in SSRSS works out to a length of 461.54 six-hour days. This is what's throwing off the length of the solar day. Although SSRSS uses global factors to resize the planets and orbits, It looks like it's also possible to override the default and assign specific values. If my math is correct, I think that Earth's sidereal period needs to be 21553.3011496082 seconds for the solar day to work out to exactly 6 hours. That's assuming no other changes are made. Alternatively, I like the idea of changing the gravitational parameter of the Sun so that the orbital periods of all the planets are equal to 1/4th of their real life values. This would make the orbital periods of the planets in the game equal to their real life orbital periods when measured in days. In the game it would be 6-hour days and in real life 24-hour days. Therefore, we would have Mercury's period equal to 88 days, Venus 225 days, Earth 365 days, and so on. This would also correct the length of Earth's solar day to 6 hours without having to change its sidereal rotation period. I compute that changing the Sun's gravitational parameter to 2.11899690905473E+18 would make Earth's sidereal orbital period exactly equal to its real life value of 365.25636 days. This changes makes the solar day equal to 21599.9998099882 seconds. We can make this equal 21600 seconds exactly by making a slight adjustment in the sidereal rotation period to 21541.0249148984 seconds. To summarize: For Sun, gravParameter = 211899690905473E+18 For Earth, rotationPeriod = 21541.0249148984 One drawback of this idea is that, because it increases the mass of the Sun, it will require more delta-v to travel between planets. That might outweigh the convenience of having a familiar 365-day year. If we do not change the Sun's gravitational parameter, then to get a 6-hour solar day the following change should be made, For Earth, rotationPeriod = 21553.3011496082

I can't speak for others but, in all of my conversation, I'm assuming that we're making an efficient gravity turn. I find that I usually get my best results when I have a liftoff TWR in the 1.3-1.5 range, and a second stage start TWR in the 1.1-1.3 range. I'll accept higher or lower TWR if I have too (there are only a finite number of engines to choose from), but I try to keep as close to the desired range as possible. I don't have a problem with a higher liftoff TWR as long as I can get the rocket to turn and follow a good trajectory. I don't like highly lofted trajectories that require an early shut down and a large apoapsis burn. I think the most efficient trajectory is a flat one with a long burn time and a very small apoapsis burn. The problems I have with high TWR is (1) rocket may resist attempts to turn it, and (2) it's hard to fly a flat trajectory without excessive heating. This places an upper limit on what I consider to be an acceptable TWR, though I haven't seriously explored what that value is. As long as I stay close to my 1.3-1.5 target, I know I'm good. I think the lower limit on TWR is 1.2, below which the gravity losses are just too great.

I have on a few occasions made an upper stage for a small payload out of a FL-R10 fuel tank with some rearward facing "place anywhere" RCS ports. It was highly efficient in older versions of KSP because the RCS ports were massless. That's not the case anymore. My old v0.90 command seat Eve launcher had an RCS upper stage that could deliver something like 2000 m/s dV.

My experience is that strap-on solid boosters are not very cost effective. Not because of the solid motors per se, but because the cost of decouplers and nose cones are disproportionately high in KSP. A Hammer cost 400 funds, while a TT-38K radial decoupler and aerodynamic nose cone together cost 840 funds. It seems nuts to me that the accessories cost more than double the motor, but that's the way it is in KSP. Solid motors are very cost effective if you can use them inline as a first stage, but when strapped on to the side, my experiments have shown me that they actually hurt cost efficiency until we get up to the size of a Kickback. That being said, I still use them in practice, but generally only when they allow me to get by with a smaller liquid fuelled engine then I otherwise could. One good way to make a comparison is to compute the total impulse that we get from a pair of Hammers versus adding more propellant. Each Hammer has 2.81 25 tons of solid propellant. For the specific impulse, let's use an average of sea level and vacuum values. Therefore, the total impulse we get from a pair of Hammers is, 2 x 2.8125 x (170+195)/2 x 9.80665 = 10067 kNs On the other hand, let's say we add a Rockmax X200-8 Fuel Tank, which has 4 tons of liquid propellant. How much impulse this will deliver depends on the ISP of the engine. Let's use 295 s, which is an approximate average of the 2.5 m engines most likely be used in this application. Therefore, the total impulse we get from the extra propellant is, 4 x 295 x 9.80665 = 11572 kNs We see that we get more impulse from the extra fuel tank, plus it cost only 800 funds versus 2480 funds for the Hammers + accessories. So as long as the first stage liquid fuelled engine has enough thrust to handle lifting the mass of the extra propellant, we're money ahead by adding more fuel versus adding a pair of small strap-on solids. We're almost certain to have greater gravity losses by adding the extra fuel tank (due to lower TWR), but we can afford to pay for that. (edit) One possible argument in favor of the strap-on solids is that we get to jettison their empty mass earlier in the flight, while we have to carry the inert mass of the fuel tank all the way to the end of first-stage burnout. This is true, but from the start the empty fuel tank weighs much less than two Hammers. The dry fuel tank has a mass of 500 kg, while the inert mass of two Hammers + accessories is 1610 kg. So with the fuel tank we carry less mass for a longer period of time, while with the SRBs we carry more mass for a shorter period of time. I'm not sure which option works out better.

Adding propellant increases the mass ratio, which increases the rocket's Δv. By lowering the TWR we will increase gravity losses, but overall it is a net gain. That gain can then be used to carry a bigger payload. And since the added propellant is cheap, the cost per ton of payload goes down. For example, let's say we have a rocket that can both deliver 3400 m/s and can reach orbit using 3400 m/s. We now add on propellant to the point that the rocket can deliver a Δv of 3600 m/s, but in doing so we increase the losses to the point that it now takes 3500 m/s to reach orbit. We have a net gain of +100 m/s. Since we don't need this extra 100 m/s, we can increase the payload mass until we bring the rocket's Δv down to the same 3500 m/s that we need to reach orbit. Generally speaking, the percent increase in payload size will be greater than the percent increase in launch cost, meaning that the payload unit cost goes down.

I haven't tested every scenario but, for the most part, I agree that the only reasons to ever "dial back" a rocket are to (1) maintain control, and (2) prevent overheating. Other than that, if you've got it, use it. That being said, I subscribe to the school of though that small engines and low TWR are better than large engines and high TWR. However, when I'm forced to select an engine that delivers a higher TWR than I would normally choose, I run it at as high a throttle setting as I can. For instance, I prefer a liftoff TWR in the 1.3-1.5 range. I obtain this TWR by packing on as much fuel as the engine can handle. However, if I have a rocket that will deliver a liftoff TWR of, say, 1.8, I would never throttle it back to 1.5 just to get it inside my desired range. I would only throttle back if I'm flipping out of control, can't make my gravity turn, or overheating. Lowering TWR by using a smaller and cheaper engine is a good thing, lowering TWR by arbitrarily throttling back is a bad thing because it needlessly increases the gravity losses.

RCS thrusters have a vacuum ISP of 240 s, therefore, using the rocket equation, we have Δv = 2354 * LN( total vehicle mass / (total vehicle mass - RCS fuel mass) )

You can land on Laythe with parachutes, so there's not much mystery to that. However, to achieve the same fall rate on Laythe that you would have on Kerbin, you need more parachute area. Laythe's gravity is 0.8x Kerbin and its air density is about 0.6x Kerbin, therefore the parachute area ratio should be 0.8/0.6 = 1.333. In other words, if you need 3 parachutes to attain a safe landing speed on Kerbin, you will need 4 parachutes on Laythe. As for getting off of Laythe, my experience isn't applicable since I haven't done it since v0.90, which was before the stock aero changes. However, it will clearly take less delta-v to attain orbit around Laythe than it does around Kerbin, i.e. ΔV<3400 m/s. I've seen delta-v maps that give numbers ranging from 2600 to 3200 m/s. And since Laythe has a substantial atmosphere, you will need to streamline your launcher to at least minimal standards. One thing that might be tricky is obtaining aerodynamic stability for both entry and takeoff.

I don't think having Realistic Atmosphere installed will break anything, but I'm not sure whether or not the 1.33x factor will be applied to the RA atmospheres. From my experiments in the past, it looked like BodyLoader applied all its changes after the Kopernicus changes. If that sequencing is correct and BodyLoader overwrites what Kopernicus does, then you may get RA atmospheres without the 1.33x factor. You'll just have to try it and see what happens. I tried to run my own experiment but I couldn't get this 64K mod to work. I don't know why it didn't work, but I just got all the stock planet sizes and orbits. By the way, you can also rescale planets, etc. using BodyLoader. If you download BodyLoader from @NathanKell, rather than as part of RA, there are some examples showing how to do this. (edit 1) OK, I got 64K working (didn't have Sigma Dimensions installed). Realistic Atmospheres works with it but, as I feared, the 1.33x scale factor isn't working. We get the RA atmospheres but at their normal heights. Let me play around with it and see if I can get BodyLoader to rescale the RA atmospheres. I'll get back to you. (edit 2) Got it. Just copy the following code into a cfg file and save it to your GameDate/BodyLoader/ folder. I named my file RescaleAtmo.cfg. though I don't think the name really matters. It will rescale the RA atmospheres to the intended 1.33x factor. @CELESTIALBODIES { %globalRescaleAtmo = 1.33 }