OhioBob

FYI, the ISP of the Vector is... Pressure (atm.) Specific impulse (s) 5 193 4 220 3 246 2 271 1 295 0 315

I did play around a bit with the designs in the game. They performed similarly to the simulations, but I couldn't quite obtain the same payload capacity. I'm sure this is because the simulations used a highly efficient and precise ascent profile, which I couldn't replicate in the game. My angle of attack frequently exceeded the values used in the simulations, which resulted in greater drag losses. (From my in-game experiments with the test vehicle, I estimated that the drag increased about 8% for every 1o increase in AoA.) Another problem that I experienced in game was that the 1.21 TWR vehicle was extremely long and slender, making it wobbly and difficult the steer. For this reason I found that a liftoff TWR of 1.3 to 1.4 worked much better, which is what I now target when designing new launch vehicles. Maybe we're computing it differently. For drag loss, I calculated the acceleration resulting from the drag force and integrated it over time to obtain the total velocity change. I then took the total Δv needed to attain orbit, subtracted the final orbital velocity and the drag loss, and called this the gravity loss. Note that the total Δv was an integrated value computed using the actual instantaneous Isp. This value was 3167 m/s, compared to 3202 m/s using vacuum Isp (which is how it is commonly computed). I typically don't worry about any of that. It might be more of an issue with a high TWR rocket, but since I'm typically ≤1.4, I just put the throttle at 100% and go. To me, drag losses are over rated; they just aren't that big. Just make a rocket that is reasonably aerodynamic and don't worry about it. It's not a big enough problem to overthink it. If you are designing for minimum Δv, then reducing gravity loss is more important. Of course my design philosophy is to maximize cost efficiency, so I'm not overly concerned about gravity loss either. I pack on the fuel to increase my payload capacity and just accept the fact that I'll incur high gravity losses. I don't use Mechjeb, so I always do it manually. I've also observed that launch vehicles using 1.25m parts always require more Δv to attain orbit. I usually budget at least 3600 m/s, and as high as 3800 m/s if I have a non-aerodynamic payload. With a 2.5m rocket, I'm usually right around 3400 m/s. I usually don't pay too much attention to either velocity or altitude. I just start the turn when it feels right. Since I try to design all my launch vehicles to a standardize set of guidelines, they usually fly similarly. What I try to do is keep the angle of attack as small as possible throughout the turn.

I few months ago I performed a bunch of launch vehicle optimization simulations. If you're interested, you can read the results here: Launch Vehicle Optimization Test Results One of the interesting parts of those simulations was that I was able to compute the losses due to gravity and drag. For the three different launcher configurations that I tested, here is what I got: Liftoff TWR = 1.90 ---> gravity loss = 669 m/s, drag loss = 210 m/s, total = 879 m/s Liftoff TWR = 1.46 ---> gravity loss = 765 m/s, drag loss = 152 m/s, total = 917 m/s Liftoff TWR = 1.21 ---> gravity loss = 968 m/s, drag loss = 118 m/s, total = 1086 m/s Of course these numbers will vary depending on the aerodynamic characteristics of the vehicle and the ascent profile.

Most of the time when people around here discuss the Δv of their launchers, the numbers are based on vacuum Isp. Although this practice overstates the actual Δv, it's just easier to do it that way. I doubt if the difference is any more than 100 m/s.

I've found that I get a better answer by averaging sea level and vaccum Isp for the first stage.

I've heard rumors that it's been done for under 3000 m/s, though I've never tried it myself. Trying to see how little Δv you can get to orbit for may be a fun challenge to chase after, but as a practical payload delivery system, it's a bad design. The lowest that I've ever done it for was somewhere around 3350-3400 m/s (with the current version). I just don't design for minimum Δv. If minimizing Δv if what you really want, what I've heard is that you want a high TWR, need to pitchover quickly, and peg the throttle to punch your way through the atmosphere with minimum gravity loses.

If you need RCS and have only a small Δv requirement, then using monopropellant makes great sense. You can use one monopropellant tank to fuel both RCS and main propulsion. If you went with bipropellant main propulsion, then you'd have to have two tanks and likely more propellant than you need. Of course you could use the slider to reduce the propellant load, but then you have more inert mass than you need by carrying oversized tanks. On the other hand, if you have a large Δv requirement, then the greater Isp of bipropellant makes having the two separate fuel sources worth it. There is probably a breaking point in there somewhere that swings the advantage from monopropellant to bipropellant.

I've yet to find a use for a Kerbin space station, other than to fulfill a contract. Of course I usually do one-off missions, i.e., I've yet to build up any kind of space infrastructure. Perhaps in the future I'll discover some useful purpose for a space station, but so far I don't see it.

I use single-use expendable spacecraft and rockets. I always do a direct reentry on my return from Mun/Minmus.

The old career mode is the new science mode. The developers implemented science/research before they did contracts/funds. So before contracts/funds existed, career mode had only science/research. When contracts/funds was added to career mode, science mode was created.

Just learning about maneuver nodes made a world of difference in the ease of game play. If you haven't already done so, it's worth your time to read the Wiki article. Although you can do much with maneuver nodes, after a while I started to become frustrated using them due to my inability to place them exactly where I wanted and my inability to dial in the exact amount of velocity change that I wanted. I then tried a mod called Precise Node and loved it. I now consider Precise Node an indispensable addition (along with KER and KAL). I don't necessarily recommend that you get it immediately (I think it's good to learn the stock way of doing things before adding a bunch of mods), but it's something you might consider in the future.

They did improve it quite a bit in 1.0.5 by thinning out the upper atmospheres of Eve and Jool. Eve's atmosphere is unchanged up to about 45 km, but after that it's a little thinner than pre-1.0.5. For instance, at 80 km the air pressure is 63.5% of what it use to be. Jool's upper atmosphere is much thinner than pre-1.0.5. There's not much change up to about 30 km, but at 123 km it is 74% of what it use to be, and at 150 km it is just 20%. (eidt) Note that the above indicate reductions in air pressure. On Jool, the air density is reduced even further because the molecular weight changed from 2.8 to 2.2 kg/kmol.

I prefer for Career mode over Science mode. I've only played one Science game, but it seemed not to be much of a challenge and I worked my way through the technology tree pretty quickly. After that it was just like playing Sandbox, so I felt like I should have just started in Sandbox mode and saved myself some time. Career mode, on the other hand, offers greater challenges and provides more things to do; and the need to acquire and manage funds continues throughout the game. In the future I'll probably play either Career or Sandbox depending on my mood.

I'm not a FAR user, but it's my understanding that FAR uses the same atmospheric properties as the stock game. That is, air temperature, pressure and density is the same in both FAR and stock, but the way the two models computes things like drag and lift is different. The mod that I came up with changes the atmospheric properties so that pressure and density fades with increasing altitude in a much more realistic way.

But the 50/50 split is the common practice that almost everybody does. It's even built into KER, with the time to burn being the time to maneuver node less 1/2 the burn time. Correct, which is why almost everybody doesn't bother to work it out and just does the 50/50 split. If you do what almost the entire KSP playing community does, than there is less trajectory error by following the maneuver node marker than there is by following the prograde marker. And the Δv that one saves by following the prograde marker versus the maneuver node is likewise trivial. For a measly 20 m/s or so, I'd rather split the burn 50/50 and burn to the maneuver node marker. It's quick and easy to figure out and the ejection error is reasonably small and easy to correct. Burning prograde either needs a more complex method to determine the burn start time or, if the 50/50 split is used, there will be greater error.

Yeah, but the Δv loss is minor (≈20-25 m/s). If you split your burn 50/50 around the maneuver node, then following the maneuver node marker results in an ejection trajectory that is much closer to the planned trajectory (i.e. the maneuver node trajectory). Following the prograde marker results in greater deviation from the planned trajectory, therefore necessitating a larger course correction. There was a thread discussing the pro and cons of this about a month ago. Below is a graph that I produced from a simulation that illustrates the path of the two trajectories in comparison to the theoretical maneuver node trajectory.

That was my situation when I started playing. Even though I knew rocketry and orbital mechanics quite well, there was still a learning curve just to get familiar with the UI and the in-game tools. For instance, I probably played for a month before I learned about these things called maneuver nodes.

When I first got KSP, I played for several weeks before I learned about maneuver nodes. Life definitely got much easier after that.

The mass of a Kerbal on EVA is 94 kg and he/she has 5 units of EVA propellant. However, a Kerbal's mass does not change as EVA propellant is consumed (it always remains 94 kg regardless of whether the EVA pack is full or empty). This makes the ISP infinite (which makes the OP's question moot). However, if we assume that his/her mass does decrease, then we can compute the ISP. We don't know the density of "EVA propellant," but if we assume it is the same as monopropellant (4 kg/unit), then we have 20 kg of propellant. This means that the ISP is, ISP = 600 / (LN(94/74)*9.80665) = 256 s

I've actually modded my atmospheres to obey the gas laws and to be more lifelike. Kerbin's atmosphere is basically the same, but the others are significantly different. I had just completed the mod and was starting to experiment with it when 1.0.5 was released. Since Squad claimed to have made some atmosphere changes, I switched back to the stock atmospheres. I want to know how the new stock atmospheres behave so I can have a good comparison when I switch back to my modded atmospheres. I'll probably eventually make the mod publically available, but I want to first have that comparative experience so that I can intelligently discuss the differences.

Where is JoeSchmuckatelli by the way? Hasn't replied since the opening post.

I've used a method similar to yours to compute the payload capacity of various designs, but I've found that averaging the ISP for all stages isn't very accurate. The best results seem to come when averaging the ISP for all engines that ignite on the ground, and using the vacuum ISP for any subsequent stages that are air lit. The air thins out fast enough that the ISP penalty fades away quickly and doesn't need to be considered for upper stages. The calculation only gives an estimated payload capacity. The only way I've found to determine an accurate value is to test launch the vehicle with ballast to simulate a payload. Adjust the amount of ballast until you find the maximum that the rocket can lift. This method can be a time consuming grind, but doing things right and accurately is rarely always fast and easy.

If you can reach your lab with another ship and dock to it, then the power generation and battery capacity of the two vessels is combined. I just recently had a similar problem in which I didn't have enough battery power to last the eclipse phase of my orbit while I was performing research. I just made sure that when I ferried my next crew up to the lab I included a big battery bank. Problem solved. Or course that may not be feasible in your case.

Thanks. Back to the drawing board to design my station.

I have a contract to build an orbital station around Kerbin. It includes the requirement "have 4,000 units of liquid fuel in your station." I have two questions about this: (1) By "units" I assume this means volume units, not mass units. Is this correct? (2) By "liquid fuel", does this mean literally "fuel" only, or does "oxidizer" also count? I just launch a station that included 4800 volume units of fuel+oxidizer and was not awarded credit for completing the contract. I assume this is probably because the oxidizer doesn't count.