OhioBob

Not very big, really. About 740 metric tons. I like to keep things as small as possible.

@Das_Sheep, if we simplify the problem by assuming circular and coplanar orbits, and by using Hohmann transfers for both the outbound and return trips, then it's pretty straightforward to figure out. You depart when Duna is 44 degrees ahead of Kerbin. It takes 302 days to get there. When you arrive at Duna, Kerbin is now 75 degrees ahead. For the return trip you must wait until Kerbin is 75 degrees behind Duna. This means that Kerbin has 210 degrees of catch up to do, which takes 530 days. When Kerbin has reached the right spot, you begin the Hohmann transfer back home, which again takes 302 days. Therefore the entire journey takes 1,134 days, or 2.66 years.

You can always check it mathematically. One simple check you can do is take the periapsis distance of the outer moon and subtract from it the apoasis distance on the inner moon, then from that subtract to two SOI radii, and that will give you the worst case separation between the edges of the SOI. SOI separation = Pe2 - Ap1 - SOI1 - SOI2 This is the theoretical worst case because it assumes the orbits are in the same plane and that the inner moon's apoapsis aligns with the outer moon's periapsis (i.e. the longitudes of periapsis differ by 180 degrees). In reality this is probably not the case, which means the real minimum separation is going to be greater then this. But if this calculation shows that the SOI do not overlap (i.e. separation > 0), then you know you are good to go. My experience is that if you give the moons realistic orbits, their SOI are unlikely to overlap. If the SOI do overlap, it would probably be best to move the orbits farther apart. If two moons come so close to one another that the SOI overlap, then I suspect that in real life they would probably have unstable orbits.

You don't have to do it by trial and error, you can compute the SOI radii. The formula is, rSOI = a * (m / M)0.4 where rSOI is the SOI radius, a is semimajor axis, m is the mass of the secondary body (moon), and M is the mass of the primary body (planet). If you don't know the masses, you can compute them using one of the following formulas, m = μ / 6.67408E-11 m = g * r2 * 9.80665 / 6.67408E-11 where μ is gravitational parameter, g is surface gravity (in gees), and r is the body's radius (in meters). Which of the last two equations you use depends on what information you're given in the body's config file. If given gravParameter use the first; if given geeASL use the second. If you don't like the computed SOI, you can always assign a custom SOI radius using the sphereOfInfluence parameter.

Here's one that can help get you started... There are others as well. You just need to look around for them.

With respect, you asked two questions: "what mod there are best textures for planet?" and "what mods that alter stock planets textures are there?" The first question doesn't say anything about retaining the stock system.

This happens frequently for me. Not just Lili and not just GPP.

The mod that I think has the best looking planet textures is Galileo's Planet Pack.

@adsii1970, are you using Sigma Dimensions? If so, make sure you are using version 0.9.3. You'll get that error message if you are using the newest Kopernicus with the old Sigma Dimensions.

You don't need any mod. Advanced tweakables is a game setting. https://imgur.com/TZpyS3r

I don't know what RP0 and nonRP0 means. You're obviously using a mod I have no familiarity with. Sorry to bother you, obviously my suggestion is not applicable.

Not temporarily removed, permanently removed. We hope that GPP support returns as part of Kerbalism.

Just change the TechRequired parameter in the part's config file. Or better yet, write a MM patch that changes it (rather than changing the original .cfg). Below's an example. This changes the required technology of the LV-T30 engine (internal name "liquidEngine") to Basic Rocketry. @PART[liquidEngine] { @TechRequired = basicRocketry }

Not hard at all. The science definitions for all the original bodies are in the config to which I linked, so just do the same thing for the two new moons. Should just be a matter of copy and paste, and then change the names. You can reuse some of the existing descriptions or make up your own. There may be, I really don't know for sure. Like I said earlier, I just tested the solar panels. From what I could see, they worked OK at Ciro but produced no power at Grannus.

That's easy enough to fix. Just replace Triton's atmosphere node with this one: Atmosphere { // General atmosphere settings enabled = true oxygen = false maxAltitude = 70000.0 // constants adiabaticIndex = 1.4 atmosphereMolarMass = 0.02801 // Atmosphere Pressure staticPressureASL = 0.00165 pressureCurve { key = 0 0.00165 0 -1.11539E-07 key = 2000 0.00143845 -1.00036E-07 -1.00036E-07 key = 4000 0.00124970 -8.87642E-08 -8.87642E-08 key = 6000 0.00108313 -7.78938E-08 -7.78938E-08 key = 8000 0.000937741 -6.76041E-08 -6.76041E-08 key = 10000 0.000812006 -5.83551E-08 -5.83551E-08 key = 12000 0.000703477 -5.03706E-08 -5.03706E-08 key = 15000 0.000567871 -4.04021E-08 -4.04021E-08 key = 20000 0.000398762 -2.80067E-08 -2.80067E-08 key = 25000 0.000281418 -1.94596E-08 -1.94596E-08 key = 30000 0.000199763 -1.35663E-08 -1.35663E-08 key = 40000 0.000102702 -6.68361E-09 -6.68361E-09 key = 50000 5.44174E-05 -3.36910E-09 -3.36910E-09 key = 60000 2.97893E-05 -1.74504E-09 -1.74504E-09 key = 70000 0 0 0 } // Atmosphere Temperature temperatureSeaLevel = 39 temperatureCurve { key = 0 37 0 -0.0003 key = 8000 36 0 0 key = 70000 43 0.0002 0 } temperatureSunMultCurve { key = 0 1 0 -0.0002 key = 8000 0 0 0 key = 70000 0 0 0 } temperatureLatitudeBiasCurve { key = 0 0.5 0 0 key = 90 -1.5 -0.036 0 } temperatureLatitudeSunMultCurve { key = 0 4 0 0 key = 90 2 -0.036 0 } temperatureAxialSunBiasCurve { key = 0 -2.5712 0 0.053480 key = 40 0 0.069813 0.069813 key = 130 4 0 0 key = 220 0 -0.069813 -0.069813 key = 310 -4 0 0 key = 360 -2.5712 0.053480 0 } temperatureAxialSunMultCurve { key = 0 0 0 0.018 key = 90 1 0 0 } temperatureEccentricityBiasCurve { key = 0 0 0 0 key = 1 0 0 0 } }

#2 computes the amount of delta-v as well as when to launch. If you use #2 there's no need for #1. There is also a mod version... I always use the mod. It's quick and easy and provides all the needed information. It also interfaces with Kerbal Alarm Clock.

A couple moons were added, but I don't think that will break Kerbalism. By the way, I just found the config posted in the Kerbalism thread. If you want to give it a try, you can probably just copy it from there and make your own .cfg rather than downloading an old version of GPP. The only problem I see is that there are no GeigerCounter science experiment definitions for the added moons.

I was just answering a question about GPP and Kerbalism, but it's already been answered. I will add this, however... It's been mentioned that you can remove Grannus from GPP to make Kerbalism work, but I'm not sure that's really necessary. I don't use Kerbalism, but I did do a few solar panel tests awhile back with Kerbalism+GPP. The only thing I noticed to be messed up is that solar panels don't work around Grannus (because Kerbalism doesn't support multiple stars). But if you just want to play GPP as a single star system, I don't think there's really a need to remove Grannus from the system. Just don't expect solar panels to work at Grannus and you might be OK. Of course I didn't do any testing beyond solar panels, so I don't know if anything else is messed up or not. You would just have to try it out and see, but I certainly wouldn't go through the trouble of removing Grannus if it's not really necessary. It's also been mentioned that GPP support for Kerbalism has been removed. GPP use to include a Kerbalism config that added radiation belts, magnetopauses, and maybe some other settings (really don't remember now). But because Kerbalism isn't currently compatible with GPP, we removed it. Supposedly GPP support will return as part of Kerbalism in a future release (whenever that happens). In the meantime, if you want to try to get GPP and Kerbalism working together, you can always try using the Kerbalism config from an old version of GPP. I don't recommend installing the old GPP version, just using the old config with the latest GPP version. I'm not sure it will work, but you can try. You should be able to find the config in GPP 1.4.0. I think the path and file name is, GameData/GPP/GPP_Configs/GPP_Kerbalism.cfg.

(post deleted) Never mind, old thread.

It's there, you just have to expand the information window to show more info. When you hover the mouse over the part you should see an information window pop up. When that happens, right-click and the window expands to show more information. The SAS specifications are shown in the expanded right side of the information window. You'll probably have to scroll down using the scroll bar to see it, the SAS specs are usually toward the bottom.

Command pods by themselves have no SAS capability. The SAS capability comes with the pilot that you place in the command pod. The amount of SAS capability depends on the experience level of the pilot. Command pods can't function without a pilot. Since probe cores have no pilot, they do have SAS capability, though in varying amounts depending on the probe core. Those that you discover later in the tech tree have more SAS functionality.

Launch Window Planner has also been made into a mod, which can be easily use in the game.

Easier yet, if you just want a rough number, memorized this table: Mass ratio Delta-V 2 Isp * 7 3 Isp * 11 4 Isp * 14 5 Isp * 16

Nope, natural logarithm is part of the formula, you can't just take it out. You can always memorize several values of natural log for the range of mass ratios you're likely to be dealing with. Mass ratio can't be less than 1, and in KSP likely not more than 5 or so. LN(1) = 0 LN(2) = 0.7 LN(3) = 1.1 LN(4) = 1.4 LN(5) = 1.6 For values in between you can interpolate. Should get you in the ballpark.

@Splargo, your method has some benefits as far as simplicity goes, but it is very inefficient energy-wise. Others have talked about the Oberth effect and how it is better to perform the ejection burn from low Kerbin orbit. I'll supplement that with a little bit of the math. To do what you suggest required two burns, one to escape Kerbin's gravity, and the other to lower the periapsis of the resulting solar orbit to achieve an intercept with Eve. Let's say we start out in a 75 km parking orbit, from here it takes a minimum of 935 m/s to escape Kerbin's sphere of influence. Now that we're in solar orbit, we have to set up the burn to intercept Eve. Let's say we're able to perform a perfect Hohmann transfer and intercept Eve right at the periapsis of our transfer orbit. Lowering the orbit's periapsis just enough to perform this intercept takes about 755 m/s. In practice it usually takes more because we're rarely able to use a perfect Hohmann transfer. This means that the total Δv needed to intercept Eve is at least 935 + 755 = 1,690 m/s. Another way to do it is to perform one burn from low Kerbin orbit. This time, however, we don't stop burning when we achieved escape velocity. Instead we keep burning until we've give our spacecraft just enough velocity that when it leaves Kerbin's SOI, it's already going -755 m/s relative to Kerbin. There's now no need to perform the second burn because we've already taken care of it. The velocity that is left over after escaping Kerbin's gravity is called hyperbolic excess velocity, which has the formula, v∞2 = vbo2 - vesc2 where V∞ is hyperbolic excess velocity, Vbo is the burnout velocity, and Vesc is escape velocity. We want V∞ to equal 755 m/s, and Vesc at an orbital altitude of 75 km is 3,235 m/s. Therefore we can solve for the burnout velocity, Vbo = SQRT( 7552 + 32352) = 3,322 m/s. The required Δv is simply the burnout velocity less the initial orbital velocity. At an altitude of 75 km, the orbital velocity is 2,287 m/s, therefore Δv = 3322 - 2287 = 1,035 m/s As you can see, this results in a dramatic savings of over 600 m/s. Performing your interplanetary transfer burns from low Kerbin orbit is always going the best way to do it as far as velocity change goes, and hence fuel efficiency. It is well worth the effort to practice and gain proficiency in setting up your maneuver nodes and establishing planetary encounters while in Kerbin orbit.