OhioBob

ALL delta-v maps are abstract, imprecise and risky to use. I don't know if you've ever made one, but I really struggled with the one I made for GPP. Not because I was incapable of the computations, but because there is so much variability. I had trouble deciding what number, out of myriad possibilities, to put on the map. Eventually I had to say that I was going to base the map on some particular set of circumstances and then compute the numbers accordingly. So that means there is an extremely high probability that the your particular set of circumstances are going to be different than those upon which the map is based. At best it just provides a rough idea of what it should take. That's why I don't like delta-v maps and rarely use them. I take every one of them all with a grain of salt. I think pre-space age Kerbals would be able to produce a delta-v map that is nearly as good as any other because they are all pretty crappy, IMHO.

They would have computed the delta-v map themselves just like the real-life guy who made the map. You don't have to go somewhere to learn a great deal about it. Observations from Kerbin would tell Kerbals all they need to know about the size of the solar system (assuming they have the equivalent of Newtonian physics). Humans new the orbits, sizes and masses of the planets before we ever left earth, so I assume Kerbals would also know. Granted, the precision of our measurements got better as we explorer and gained more information, but a first draft delta-v map is possible even with crude information. I derived the numbers for GPP's the delta-V map, and did almost the entire thing computationally using just a few known facts about the bodies that Kerbals almost certainly could have learned for themselves through Kerbin-based observations. The only thing I didn't do computationally was the ascent delta-v for bodies having atmospheres. That is something that would likely take some close up investigation to figure out, but everything else could be computed without ever leaving the ground.

I want to add one further comment about this. Not only can the terrain make it difficult to dock components together, but also the difference in gravity between one body and another can mess things up. For instance, suppose you build all your components and test them on Kerbin and it all works perfectly. You now fly them to Minmus and try to assemble them on one of the flats. What you now discover is that landing gear and rover wheels are not compressed by the same amount as they were on Kerbin because of Minmus' lower gravity. So what lined up before might not line up now. One thing you can do to prevent this is to hack Kerbin's gravity using ALT+F12, making it the same as the body on which you plan to land the base. You can then test everything in conditions that simulate the final destination. Also be sure to reduce fuel loads to account for any burn off you might have prior to landing. If you don't get the weights correct, you could have some docking port misalignment.

In addition to what others have said, I also recommend that you use a lower periapsis. At 82 km all you're doing is skimming through the thin upper atmosphere where you are generating a lot of heat but almost no drag. It may seem contrary, but you have to actually pass through that thin upper part quickly and get down to some thicker air where it can actually do some good and start slowing you down. Why don't you try a periapsis of about 50 km and see if that helps? I agree with the others that it sounds like you may need some design changes, but the shallow entry certainly isn't helping either.

Most contracts say that the vessel must be new, so landing an existing space station probably won't fulfill the contract requirements. Assembling the base in parts is typically allowed by the contract system, so you can certainly do it that way if you want to. How you do it depends on how much capability you want the station to have and how big it is. I always favor the fewest launches possible, so if I can land it in one piece, that's what I do. Only when the single launch approach is unfeasible do I start to break it down into smaller dockable parts. Something you can try doing is to build everything you need to fulfill the contract into the first part so you get all your money right away. But at the same time make it so you can expand and build on to the part.

Also note that even though tidally locked moons do have day-night cycles, the days and nights can last a long time. Pol, for instance, has an orbital period and day with a duration equal to about 42 Kerbin days. This means you will have 21 days of sunlight followed by 21 days of darkness. The long nights is something you have to take into consideration when planning something like a moon base. Even Mun, with is relatively short period, still has night that lasts nearly 20 hours, compared to only 3 hours on Kerbin. If you are using solar panels for power, you must be certain to provide enough battery capacity to power the station through the long night.

It will also move east-west by a small amount if the moon's orbit is eccentric. This is because the moon's orbital angular velocity is variable (faster at perispsis and slower at apoapsis), but its rotational angular velocity is constant. So for a tidally locked moon in both an inclined* and eccentric orbit, the parent planet in the moon's sky will oscillate in both north-south and east-west directions, resulting in the planet tracing out a small figure 8 pattern. This also means that even for a tidally locked moon, it's possible to observe more than half its surface from the parent planet. At times in a moon's orbit, parts along the moon's limb that were previously hidden from view will rotate into view, while parts on the opposite side will rotate out of view. This is called libration. From Earth we can, over time, see about 59% of our moon's surface. Of course we can never see more than 50% at any one time. (edit) * Technically it's not the inclination of the orbit that matters, but the inclination of the moon's rotational axis relative to its orbital plane. In KSP, however, it's one in the same. All bodies in KSP have axes that are normal to the ecliptic plane. So if we incline the orbit relative to the ecliptic, we also incline the axis relative to the orbital plane normal by the same amount.

There are many things I haven't mastered. But if we eliminate the things that I'm at least adequate at, and list only the things I downright suck at, I would say the list includes, Pretty much anything haven't to do with aircraft. So far I've been almost strictly a rocket guy. The few times I've tried aircraft, I'm terrible at flying them. Controlling Kerbals on EVA using a rocket pack. I don't know why, but I just can't get the knack of it.

The first thing you have to do is define "efficient". Efficiency can mean different things. For instance, do you want to perform a particular thing using the least amount of delta-v, or do you want to design a vehicle that can complete a particular task using the smallest package, or do you want to complete the task for the least cost? How you answer that question will drive your design. For example, when designing a launch vehicle, many beginners believe they are being most efficient when they reduce the amount of delta-v it takes to attain orbit. But if you are looking at it on a cost basis, that's a big mistake. Getting to orbit using as little delta-v as possible requires using a high TWR to reduce the gravity loses. But attaining a high TWR means using big expensive engines. You can reduce cost by trading in those big expensive engines for smaller cheaper engines and a lower TWR. Having a low TWR means the gravity losses will be greater, so you'll have to add some propellant to give the rocket more delta-v to overcome the greater losses (propellant is cheap compared to engines). These changes will result in a launch vehicle that is less efficient in terms of delta-v to orbit, but it will reduce the cost per ton of useful payload delivered to orbit. When you are playing a career game, cost efficiency in generally one of your most important considerations.

The MPL can also be used to "Level Up Crew". Normally a Kerbal that has gained new experience on a mission won't level up until they return to Kerbin. But with the MPL you can level them up immediately.

I would be in favor of doing away with Nero's wobble (precession) if we can do it. Although it looks kind of interesting, it's totally unrealistic (I think it's the mostly unrealistic part of GPP). Planetary axes do wobble like that but not with such a short period. (Earth's axis has a precession period of 26,000 years.) If we want to talk about this further, we should move the conversation to the messenger so we don't hijack the Kopernicus thread.

That's mainly because almost all cryogenic engines are designed for use on upper stages. Engines that have been adapted to work in a vacuum will always have a much broader range of Isp than engines adapted to work near sea level. It's not really a function of the fuel per se. The Rocketdyne RS-68 (Delta IV) is the only LH2/LOX engine that I can think of that is designed exclusively as a first stage engine. Its sea level/vaccum Isp is 365/410 s, which is about the same range* as other first stage engines that use different propellants. * The range might be a smidgeon larger than some other propellants, but the ratio is about the same.

The following doesn't have anything to do with KSP, but it does provide some explanation of real life rocket propellants. If describes some of the pros and cons, gives physical properties, and compares performance. I haven't used any mods that provide different propellant types, but I presume all in some way attempt to reproduce at least some aspect of real life performance. http://www.braeunig.us/space/propel.htm

I started out in an equatorial orbit on initial approach. But while near the edge of the SOI I transitioned each satellite into a trajectory that took it over the poles, one north and one south. Although the orbits were polar, the periapsides were not over the poles. The satellites passed over the poles and reached periapsis when over a latitude of about 45 degrees. That's how I ended up the configuration I described. Roughly what I got is, Commsat #1 (northern trajectory) inclination = 90o longitude of ascending node* = 0o argument of periapsis = 135o Commsat #2 (southern trajectory) inclination = 270o longitude of ascending node* = 180o argument of periapsis = 315o * These numbers are just for illustrations purposes; I don't know what the real longitudes were.

Unfortunately there's not a definitive answer to that question. When I resize things, whether it's atmospheres or something else, the equation I typically use is, FR = R^log(F10) Where R is the resize factor (1 for stock-size and 10 for life-size), FR is the factor at R, F10 is the factor at R = 10, and it is assumed that F1 = 1. So for example, I use an atmosphere factor of 1 for stock-sized and 1.25 for a 10x system (I'll explain why in a moment). Therefore, if I want a 2.5x system, I'll usually set @Atmosphere equal to, F2.5 = 2.5^log(1.25) = 1.093 The above assumes we're upsizing a 1x system, which is normally the case. If were going the other way, e.g. sizing RSS down, then the factor is, F2.5 = 1.093 / 1.25 = 0.874. The reason I use atmosphere factors of 1 and 1.25 at 1x and 10x goes back to what Squad did when they created the atmosphere of Kerbin. Before the current method went into effect (with KSP 1.0.0), atmospheric models were very simple. Each body had a surface pressure and a constant scale height. Atmospheres extended upward until the pressure reduced to 1/1000000th of the surface pressure. Kerbin's scale height was 5000 meters, so this gave its atmosphere a height of, Zmax = -5000 * LN(0.000001) = 69,078 meters. When KSP switched to its current method, Squad based Kerbin's atmosphere on the U.S. Standard Atmosphere. This model of Earth's atmosphere goes to a height of 86 km. Since players had already gotten familiar with having an atmosphere with a height of about 69 km, Squad factored the altitude scale of the USSA by, 69078 / 86000 ≈ 0.8. The final maximum height was rounded up to 70 km. I've since used this same 0.8 factor for every atmosphere model I've done. I compute the atmosphere based on a life-sized body (10x) and then multiply the vertical scale by 0.8 to fit it to a stock-sized body (1x). Therefore when I upsize a stock-sized atmosphere to 10x, I have to reverse the 0.8 multiplier, i.e. 1 / 0.8 = 1.25. What number to use for @AtmoTopLayer is less clear. If you want just one number to use globally, you could use the same equation as before to determine the max altitude at different resize factors. For instance, Earth's atmosphere in RSS (10x) is 140 km height, or 2 times the height at 1x (assuming Earth = Kerbin). Therefore, at 2.5x we might try this, F2.5 = 2.5^log(2) = 1.318 That would be the factor for maximum altitude, not AtmoTopLayer. But since max altitude = Atmosphere * AtmoTopLayer, we have AtmoTopLayer = 1.318 / 1.093 = 1.206. Or when sizing 10x down to 2.5x, AtmoTopLayer = (1.318 / 2) / 0.874 = 0.754 Unfortunately I've found that not all atmospheres rescale exactly the same way. I always end my atmospheres based on the drag and heating effects they have on an incoming body traveling at escape velocity. This gives every atmosphere common boundary conditions that prevent either the "wall of air" effect, or a needlessly overextended atmosphere. When I take the time to re-compute every atmosphere at different resize factors, I find that a global AtmoTopLayer factor doesn't really work. This is why SSRSS has planet-specific AtmoTopLayer factors rather than using a single globally applied factor. However, I'm a lot more particular about my atmospheres than most people. I think in most cases a global factor is good enough. If after gaining some game-playing experience it's determined that some particular atmosphere isn't working just right, it can always be changed. By the way, the reason Earth's atmosphere is as deep as it is in RSS is for a couple of reasons (if case you didn't know, I did the atmospheres for RSS). Based on drag and heat alone, it doesn't need to be that deep. One reason we made it 140 km was to force players to use higher orbits. Orbiting at, say, 100 km just isn't realistic. At that height drag would probably cause the orbit to decay on the first pass. Another reason is because NASA defines "entry interface", the altitude at which the atmosphere is considered to begin, as an altitude of 400,000 feet (121,920 meters). Therefore we extended the atmosphere realistically up to that height. Above 121.92 km we began to slowly taper the pressure off until it reached zero at the upper boundary. After some discussion we settled on making the max altitude 140 km.

According to the config posted in this thread, @Tyko is using the following multipliers: @Atmosphere = 0.88312 @AtmoTopLayer = 0.75 (for all bodies except Kerbin) @AtmoTopLayer = 0.6875 (for Kerbin only) For an explanation of what those multipliers do, see this and this. The maximum heights of the new atmospheres will be the original RSS height times both of those factors. So for Kerbin, Max. atltitude = 140000 * 0.88312 * 0.6875 = 85,000 meters And for all other bodies the maximum altitude will be reduced from its RSS value by a factor of, 0.88312 * 0.75 = 0.66234.

You can really make sunAU anything you want, but you have to make sure it's consistent with brightnessCurve. I always like to set sunAU equal the the semimajor axis of the home world, and then use that same value for all stars. Each star's brightnessCurve then has to be written to use that measurement.

@Ouega, I just played around with the scenario a little bit and I think you have enough delta-v in each satellite to put them on separate trajectories if you want to give that a try. But I couldn't get their Pe to be directly over the poles. I don't know the exact conditions of your approach, so I couldn't reproduce it. So I just assumed I was coming in along Jool's equatorial plane. I ended up with one commsat with its Pe at about 45 N latitude, and the other with its Pe at about 45 S latitude. Although that's not exactly what you want, it ought to still work fine. @Kryxal's suggestion also works. Start out with them in essentially the same orbit, but with one satellite having a lower Ap. The one with the smaller orbit will have shorter period and will start to move ahead in its orbit compared to the slower one. Just monitor them until one satellite has moved 180 degrees ahead of the other. Then perform a burn (doesn't matter which satellite) to equalize their orbital periods. From that point forward, when one satellite is moving through Pe, the other will be near Ap. They don't have to have their Ap on opposite sides on the planet.

I suggest that you try to get the Pe as close to where you want it to be as possible. If it's ends up near the equator, don't worry about it. Then just wait until you cross into Jool's sphere-of-influence. Immediately after crossing into Jool's space, set up a maneuver node and adjust your trajectory, moving the Pe over one of the poles. When you are that far away out near the edge of the SOI, it should take only a small adjustment to alter the trajectory to something that satisfies your needs. You should be able to get the first commsat into position, but I don't know about the second. 1600 m/s should be plenty to capture into an elliptical orbit. Let's say you come in low over the north pole. You can perform a burn and capture into an elliptical orbit with the Ap high over the south pole. You've effectively already put the first satellite into its final orbit, so you should be able to detach it without having to perform much if any further adjustment. But now you have the other satellite in an orbit exactly opposite of the way you want it. You have to circularize the orbit by dropping the Ap all the way down to just over the south pole, and then raise a new Ap on the opposite side high over the north pole. That will take a very large amount of dV (about 5500 m/s) and I doubt you have enough based on what I see. The other thing you can try doing in separating the two commsats while out at the edge of the SOI and fly them in on separate trajectories, one with a Pe over the north pole and the other with a Pe over the south pole. You then perform two separate insertions burns. I don't know if each individual commsat has enough dV to do that or not.* The other potential problem is that you need to make sure the commsats arrive at their insertion points at different enough times that you'll be able to control them both. While you're focused on one, the other is on rails, so I don't think it's possible to have both burning at the same time (though I've never tried it). I believe you'll need to start and complete one burn, then switch vessels and perform the second burn. * Working to your advantage is that you just need to perform enough of a burn to capture and get the Ap inside Jool's SOI. You want the commsats in highly elliptical orbits, which is good. That may not take more than few hundred m/s. If you had to circularize into a low orbit, that would take a few thousand m/s, which clearly you don't have. Another possibility to consider for the future is aerocapture. However, that's not a possibility in this case because you don't have a heat shield(s). Heat shields are essential at Jool because the entry speeds are so high that you'll overheat and explode without them. Hopefully you'll get some other (i.e. better) suggests.

There was a time when I thought sunAU was part of the solar flux calculation, but after many experiments I've determined that's not the case.* So far I've been unable to find any other use for sunAU outside of its role in computing the distance part of brightnessCurve. If adjusting sunAU allows you to modify the apparent size of the scatterer sunflare, then I know of no other consequences that should prevent you from doing so. * Solar flux calculations use the distance of the home world from its star as the AU.

I have no idea why the stock curve has a negative value, there's really no need for that. We should be able to give the first key a distance value of zero. The zero line is an asymptote of the reciprocal of the distance. That is, the farther and farther away we get from the sun, the reciprocal of the distance gets closer and closer to zero, but it will never equal zero. The value at zero is the size of the sunflare at infinite distance. I see no reason for starting out with a negative value, but it doesn't do any harm either. All that will happen is that any part of the curve that's negative won't ever be used. (FYI, the brightness curves I wrote for GPP start at zero.) I don't know too much about scatterer, but it's my understanding brightnessCurve has no affect whatsoever on the scatterer sunflare. @Galileo is far more qualified to give an answer on this than I am, but I think I remember him telling me that there is no way to scale the size of the scatterer sunflare with distance.

That a good point by @Galileo. Everything that I explained was to change the size of the stock sunflare, assuming you are not using scatterer. If you are using scatterer, then you just want to remove the stock sunflare altogether (scatterer does not remove it). To do that, do what Galileo said. @KerikBalm, you weren't specific about whether you were using scatterer or not, though is does look like it in the first and third screenshots (I should have figured it out). Nonetheless, what I posted is still useful information that somebody might be able to make use of.

If you are not using scatterer... You can install the mod Kopernicus and then write a .cfg file to modify the sun's "brightnessCurve". The .cfg should look something like this (where the values shown below are the stock values): @Kopernicus:NEEDS[Kopernicus] { @Body[Sun] { ScaledVersion { Light { sunAU = 13599840256 brightnessCurve { key = -0.01573471 0.217353 1.706627 1.706627 key = 5.084181 3.997075 -0.001802375 -0.001802375 key = 38.56295 1.82142 0.0001713 0.0001713 } } } } } The brightnessCurve determines the size of the sunflare, i.e. the bright disk of light you see emanating from the sun (the part that disappears during an eclipse). In each key, the first number is the distance, the second is the size of the sunflare, and the last two are the in/out slopes for that point. The distance is kind of weird, it is actually the reciprocal of the distance measured in AU, were 1 AU is defined by the parameter sunAU. So for example, for the second key the distance is 1 / 5.084181 = 0.1966885129 AU, or 0.1966885129 * 13599840256 = 2,674,932,355 meters. At that distance from the sun, the sunflare has a diameter of 3.997075. I have no idea what those units are, but it's all relative. If you want the sun to have 1/2 the current size, then divide the number in half. A modified brightnessCurve that would make the sunflare appear exactly half its current size would look like this: brightnessCurve { key = -0.01573471 0.1086765 0.8533135 0.8533135 key = 5.084181 1.9985375 -0.0009011875 -0.0009011875 key = 38.56295 0.91071 0.00008565 0.00008565 } Note that the slopes have also been reduced by 1/2. You can play with the numbers until you get something that suits your taste. You can also change the apparent size of the sunflare in the game by adjusting the value of sunAU. For example, if you set sunAU = 7000000000, then the game is going to think Kerbin is 2 AU from the sun instead of 1 AU, and the sunflare will consequently look smaller when viewed from Kerbin. However, I prefer to set sunAU to its actual value (the home world's distance from the sun) and modify brightnessCurve. If you are using scatterer... Do what @Galileo says in the next post.

@Sigma88, I found it... KSP_x64/Launcher_Data/output_log.txt I always start KSP using Launcher.exe rather than KSP_64x.exe, so that probably why it's in that folder. I'm I launching KSP incorrectly? I seem to recall that I needed to use Launcher.exe in order to get my mods to install.

That's unfortunate. Terminal velocity is higher on Laythe than Kerbin, so you have to take this into account in your designs. Generally speaking, you need about 30% more parachute on Laythe to have the same impact velocity that you have on Kerbin. (Because air density varies with temperature, the actual percentage depends on when and where you land.) So if you have a design that works on Kerbin, add about 30% more parachute and you should be good. For example, if experiments show you can land safely on Kerbin with three parachutes, use four.