OhioBob

Other than what @Hodari wrote, I'm not sure what advantage there is to it. However, it does make sense to me to use a reference sphere or ellipsoid that most closely approximates the mean surface of the celestial body. I played around with the idea of setting the datum for bodies in KSP at the mean (or perhaps median) surface, but that's when I discovered the radar altimeter problem. My rationale was this... the atmospheric pressure that we define for a body is the pressure at the datum, or "sea level". This makes sense for an ocean world where perhaps half or more of the planet's surface lies at sea level. However, for bodies without oceans, I thought it made sense that the atmospheric pressure we see in the Tracking Station, etc., be the median surface pressure, with some places higher (lower elevations) and some places less (higher elevations). But the way KSP does it, the atmospheric pressure that we see is actually the maximum pressure at the body's lowest surface elevation. We look at Duna and think, ah, the surface pressure is 1/15th of an atmosphere. But no, nearly the entire planet has a surface pressure less than that. The way KSP does it, I find the atmospheric information deceptive and far less useful than if the datum were placed at the mean surface.

While I agree that in real life a body's datum is placed close to its mean surface elevation, it is customary in KSP to place the datum at the point of lowest surface elevation. I'm not sure why that decision was made, but we're pretty much stuck with it. Placing the datum at the mean surface of course means that much of the surface will be at negative elevation. This results in problems the way that KSP is currently coded. While I've heard rumors of certain problems, the only issue that I've personally observed is with the radar altimeter in IVA mode. The radar altimeter is suppose to display height above terrain. It works correctly when the terrain elevation is positive, but when negative the altimeter displays the height above the datum rather than the terrain. This makes the altimeter worthless when landing at a site that lies at negative elevation. The same problem exists with the "height above terrain" readout in KER, and I'm guessing MechJeb as well, though I haven't tried it. I presume these mods simply get the altitude from KSP. It seems that in order to use negative elevations effectively, KSP needs to change.

I don't know what the length of day is in Kscale64, but I doubt they're comparable. Rescale! 6.4x uses a length of day multiplier of 1.75. That should make the synchronous orbit altitude 13,505,312 meters. ---------------------------------------- @Galileo, I just noticed something. Below is what Kerbin's length of day becomes using the current multipliers: 2.5x - 6 * 1.25 = 7.5 hours 3.2x - 6 * 1.5 = 9 6.4x - 6 * 1.75 = 10.5 10x - 6 * 2 = 12 10.625x - 6 * 2 = 12 Having a day that is not an integer number of hours is kind of messed up. Maybe you should consider changing the 2.5x multiplier to 1.5, and the 6.4x multiplier to 2.

^^^ This. The distinguishing characteristic of a Hohmann transfer is that the burns are performed at periapsis and apoapsis of the transfer orbit were the velocity vectors of the transfer orbit are tangent to the initial and final orbits. For both burns, the initial and final velocities have different magnitudes but the same direction. The fact that no change of direction is necessary is what makes a Hohmann transfer so efficient. Oberth effect has nothing to do with it. For a non-Hohmann transfer, at least one of the crossing points between the transfer orbit and the initial and final orbits is at an angle (usually where the transfer orbit crosses the final orbit). So now the burn requires not only a change in magnitude but also a change in direction. Also note that a non-Hohmann transfer requires that the transfer ellipse be larger, so that makes the delta-v greater to begin with. But the big reason why the delta-v is higher for a non-Hohmann transfer is the angle at which the orbits cross. You can of think of it this way, if one car traveling 100 kph is approaching another car traveling at 80 kph from behind, then the approaching car must slow down only 20 kph to avoid a collision and match the other car's speed. However, if those two cars are coming together at a right angle intersection with one car crossing the path of the other, then the relative speed between them is 128 kph. The following helps to illustrate the difference between Hohmann (Figure 4.11) and non-Hohmann (Figure 4.12) transfers. Figure 4.12 is an example of what is called a "one-tangent burn".

It does depend on how much hyperbolic excess velocity you need. For every transfer there is something called a gate orbit, which is a function of the required hyperbolic excess velocity. The gate orbit is also the dividing line between whether it is most efficient to lower the periapsis to perform the burn or not. If your initial orbit is below the gate orbit, then just burn straight away from the current orbit. Lowering the periapsis in that case is actually counterproductive. However, if your initial orbit is higher than the gate orbit, then you can save delta-v by dropping the periapsis and performing the burn closer to the planet. The farther you lower the periapsis, to more savings there is. Although you can potentially save delta-v by lowering the periapsis, execution can be difficult. You can't just lower the periapsis at any old place. You have to plan it so the periapsis is at the correct location for the placement of the ejection maneuver node. And you have to arrive at periapsis at the correct time. Therefore you have to weigh whether or not the savings in delta-v is worth the execution nightmares.

I haven't seriously studied this issue, so I can't say with certainty what is optimal. However, a typical interplanetary transfer orbit looks something like this: So I think it would be best to launch into a parking orbit that is inclined in the same direction as your eventual interplanetary transfer orbit. That means the line of nodes should point toward the Sun (or at least as close as you can make it). To achieve this you want to launch into the parking orbit when KSC is on either the prograde or retrograde side of the planet, depending on the inclination of the transfer orbit and geographic location of KSC. For the orbit transfer shown in the figure above, and assuming KSC is located in the northern hemisphere, then you want to launch when KSC is on the prograde side. That's my 2¢ anyway. I make no guarantees that there isn't a better way of doing it.

Yes, that's correct. The Tracking Station always displays the sidereal rotation period. Gael's solar day in 2.5x is exactly 10 hours.

Every effort has been may to try to give Grannus lifelike properties. It is based of the data found here for a type M2V star. http://www.pas.rochester.edu/~emamajek/EEM_dwarf_UBVIJHK_colors_Teff.txt Also, if you are looking at surface gravity, that can be very misleading. Grannus's surface gravity is high because red dwarfs are denser than larger stars. What's more important is the star's total mass. Grannus has 50% the mass of Ciro, and about the same compared to Kerbol. Taranis's orbital speed is so high because I placed it really close to Grannus. I wanted to make it an extreme challenge for those determined enough to visit it. It's not meant to be easy. I don't know what you mean. GEP is configured to use Kopernicus just like every other planet pack. It shouldn't be any easier or harder to edit than anything else.

@RocketPCGaming, thanks for the screenshots. The thread needed them, and you got some nice ones showing every planet and moon.

Grannus Expansion Pack (GEP) is an planet pack that turns a single star system into a binary system by adding the red dwarf star Grannus, along with its family of five major planets, two dwarf planets, and seven moons. GEP is designed to provide several installation options. It can be added to the stock solar system, Galileo's Planet Pack (GPP), or JNSQ. It also works in combination with Outer Planets Mod (OPM). And with the optional add-on GEP_Primary, GEP takes center stage as the primary star system, with the planet Nodens as the home world. GEP Download (GitHub) Requirements Kopernicus ModularFlightIntegrator Module Manager Installation Instructions Begin with an installation of KSP version 1.12.2 or later, running in 64-bit. If reusing an existing install, empty the GameData folder of all contents but for the folders "Squad" and (if you own DLCs) "SquadExpansion". If starting with an entirely new install, it is recommended that you run once with no mods installed before proceeding. Download the third party mod Kopernicus. Install by copying/merging the GameData folder from the Kopernicus download to your KSP install. If installing with Galileo's Planet Pack or JNSQ, it is recommended that you download and install those mods first, and confirm their correct operation before installing GEP. Be sure to carefully follow all the GPP or JNSQ installation instructions. Download Grannus Expansion Pack v1.2.8 Install by copying/merging the GameData folder from the GEP download to your KSP install. GEP_Primary GEP_Primary is an optional add-on that turns GEP into a primary star system, with Grannus as the central star and Nodens the home world. If GEP + GEP_Primary is installed in combination with GPP + GPP_Secondary, then GPP is added as a secondary star system orbiting Grannus. GEP_Primary is not recommended for beginner players. To install GEP_Primary: Download and install Grannus Expansion Pack per the installation instructions. Drill down to [GEP Download]\Optional Mods\GEP_Primary\. Copy/merge the GameData folder into your KSP install. For implementation of anomalies, download and install Kerbal Konstructs. GEP_CommNet GEP_CommNet is an optional add-on that increases communications range by adding a level 4 Tracking Station and a powerful additional antenna. With both upgrades, a line of communication can reach between Grannus and the Sun/Ciro. To install GEP_CommNet: Download and install the third party mod Custom Barn Kit. Drill down to [GEP Download]\Optional Mods\GEP_CommNet\. Copy/merge the GameData folder into your KSP install. GEP_Rescale GEP_Rescale is an optional add-on that rescales the GEP solar system to either 2.5x or 10x its normal size. Rescaling is accomplished without the use of Sigma Dimensions (these mods should never be used in combination with Sigma Dimensions). GEP also works with GPP and/or JNSQ using the appropriate GEP, GPP and JNSQ rescale mods to provide size compatibility. To install GEP_JNSQ: Download and install Grannus Expansion Pack per the installation instructions. Drill down to [GEP Download]\Optional Mods\GEP_Rescale\ and select either Rescale_2.5X or Rescale_10X. Copy/merge the selected GameData folder into your KSP install. If applicable, download and install GPP and/or JNSQ and the appropriate rescale mods per their instructions. Delete the Kopernicus cache, i.e. the *.bin files located within each planet pack's Cache folder. It is recommended that for GEP_Primary at 10x scale the DSN modifier in game difficulty be set to 4. Other Optional Mods Install the optional mods of your choice by drilling down to [GEP Download]\Optional Mods\GEP_[mod name]\ and then copying/merging the GameData folder into your KSP install. If using Final Frontier, it must be downloaded and installed separately. Bundled Mods Sigma TweakChutes - Changes parachute behavior so that parachutes won't fully deploy unless the minimum pressure for semi-deployment has first been met. Also corrects a bug that allows the deployment pressure to be set below the intended minimum while in flight mode. Sigma HeatShifter - Required to correctly align minimum and maximum global temperatures to the sun's directional axis for tidally locked atmospheric planets (Toutatis). Planet Pack Compatibility GEP works with the stock solar system, Galileo's Planet Pack, Outer Planets Mod, and Minor Planets Expansion in a variety of configurations, both primary and secondary. Orbits are modified as necessary to assure seamless integration. GEP also works with JNSQ using the optional add-on GEP_Rescale (see instructions above). At present, GEP is the only planet pack known to be rescaled and configured specifically for use alongside JNSQ. Recommended mods with support for or by GEP Environmental Visual Enhancements Scatterer, v0.0772 Distant Object Enhancement ResearchBodies Final Frontier Kerbal Health Flare Replacer PlanetShine (GEP_Primary only) Kerbalism (GEP_Primary only) Kronometer (GEP_Primary only) Kerbal Konstructs (GEP_Primary only) Known Issues PlanetShine works with GEP_Primary only, otherwise disabled. EVE eclipses work with GEP_Primary only, otherwise disabled. SCANsat day-night terminator works with GEP_Primary only, otherwise it is drawn incorrectly. This planet pack is not compatible with Scatterer v0.08+, use v0.0772. License This mod is licensed by Creative Commons Attribution-NonCommercial-NoDerivs CC BY-NC-ND Special thanks goes to @Galileo, @JadeOfMaar, and @Poodmund for their help and support in the making of this planet pack. A thankyou also goes to @darwinpatrick for writing the custom science definitions.

Each subsequent unit of propellant produces more ΔV than the one before. But that's because the vehicle is less massive when the second unit is ejected. The second unit of propellant mass represents a larger fraction of the vehicle's remaining mass than the first, so the ratio mf/mi is greater for the second unit, so it produces more ΔV. I don't think anybody here disputes that. But that's not what you said. You said that an "identical ship" will produce more ΔV if its initial velocity is higher. That is false. If two identical ships both having the same initial mass eject the same amount of propellant, each will produce the same ΔV regardless of how fast the ships were moving at the time they performed the burn. No, acceleration is rate of change in velocity. It is not the same thing as ΔV.

@Geschosskopf, is it possible you could be getting confused with hyperbolic excess velocity (V∞)? V∞ is the velocity left over after a spacecraft has escaped a celestial body's influence. The lower a spacecraft is in the body's gravity well when it performs the escape burn (i.e. the faster it is moving), the less ΔV is takes to produce a given amount of V∞. And since it requires less ΔV, it requires less propellant. Therefore producing X amount of V∞ requires less propellant if the burn is performed at a lower periapsis when the vehicle is moving faster. But V∞ is not ΔV, you could be conflating the two.

Case 1 A 10-ton rocket is traveling 2000 m/s. Its momentum is the product of its mass and velocity, 10 * 2000 = 20,000 t*m/s The rocket ejects 1 ton of propellant at a velocity of -3000 m/s relative to the rocket, which is -1000 m/s in our fixed frame of reference. The momentum of the ejected propellant is, 1 * -1000 = -1000 Since momentum must be conserved, the momentum of what is left of the rocket is the initial momentum minus the momentum of the ejected propellant, 20,000 - (-1000) = 21,000 The remaining rocket has a mass of 9 tons. Its velocity is its final momentum divided my its final mass, 21,000 / 9 = 2333 m/s Which is an increase of 333 m/s. Case 2 A 10-ton rocket is traveling 4000 m/s. Its momentum is, 10 * 4000 = 40,000 t*m/s The rocket ejects 1 ton of propellant at -3000 m/s, or +1000 m/s in the fixed frame of reference.. The momentum of the ejected propellant is, 1 * 1000 = 1000 The momentum of what is left of the rocket is, 40,000 - 1000 = 39,000 The final velocity of the rocket is, 39,000 / 9 = 4333 m/s Which is an increase of 333 m/s. ------------------------------------------------------------------- In both case 1 and case 2 we have the same rocket, traveling at different initial speeds, ejecting the same amount of propellant, resulting in the same increase in velocity. In other words, it takes the same amount of propellant to produce the same change in velocity regardless of the initial speed of the rocket.

No, Case 3 and Case 4 will burn the same amount of propellant. What the Oberth effect says is that Case 4 will increase the mechanical energy of the spacecraft more than in Case 3.

I think you and @Starman4308 have got it covered. My opinion has been registered using the like button.

I'm one of the GPP developers and I don't known were it is either. I'm sure I'll find it one of these days.

I don't know why, but most of the planets I've looked at (including stock and several mods) have shallow oceans with flat bottoms (with maybe just a noise function). I'm closing in on the release of a new planet pack in which my ocean world has nearly as much variation to the terrain beneath the waterline as above it. My deepest point is nearly 6000 meters.

It sounds like we both did the same thing. I was originally going to increase to 16GB but decided to go ahead and max it out at 32GB. I also replaced my crappy graphics card with a GTX 1060. I'm pretty happy now, I can play just about anything and can have multiple stuff running without any problems. I agree it was worth the money.

Kerbin's ocean bottom is really just a flat plain with a noise function. It's therefore sprinkled with a bunch of high and low points, with all the highs being about the same, and all the lows being about the same. However, there's enough variability that some spots are lower than others. I extracted a heightmap and used Photoshop to located three candidate spots (represented by the black pixels in the heightmap). I then used a SCANsat altimetry map to zoom in on those three locations and scan for the lowest elevation. I think I found it at -1393.5 meters, 27.07o S latitude, and 79.00o W longitude.

Note that I just corrected something in my post. The retrograde direction is used when going to a inferior planet (I mistakenly wrote superior). To reach a superior planet you want your spacecraft to be going faster than Kerbin's orbital speed after escaping Kerbin's sphere-of-influence, so you launch in the prograde direction so you're adding to the speed that Kerbin is already traveling. And to reach an inferior planet you want your spacecraft to be going slower than Kerbin, so you launch in the retrograde direction. The ejection angle places the maneuver node at the correct spot so that after the spacecraft leaves Kerbin's SOI, it is moving in either the prograde or retrograde direction. Maneuver node placement must take into account how much the spacecraft will swing around the planet while escaping.

If you just launch eastward from KSC you'll be close enough to zero inclination. I doubt you need to fine tune it anymore than that. This is because KSC is only a tiny fraction of a degree off the equator. A positive phase angle is when the target planet lies ahead of Kerbin in its orbit, and a negative phase angle is when it trails Kerbin. Positive phase angles are used when the target planet has an orbit larger than Kerbin's, and negative angles are used when the target has an orbit smaller than Kerbin's. In the first case Kerbin is moving faster and is catching up with the target, and in the second case the target is moving faster and is catching up with Kerbin. A planet that has a larger orbit is called a superior planet (e.g. Duna), and one having a smaller orbit is called an inferior planet (e.g. Eve). Prograde is the direction that Kerbin is moving in its orbit, and retrograde is the opposite direction. To visualize it just imagine a line drawn tangent to Kerbin's orbit. The line will point in the two directions, with the forward direction being prograde and the trailing direction retrograde. The ejection angle is the angle between the position of the maneuver node and either the prograde or retrograde direction. The prograde direction is used when going to a superior planet, and the retrograde direction is used when going to an inferior planet. Kerbal Alarm Clock is a very useful mod, I highly recommend it. If you want a way to more easily and accurately set up your maneuver nodes, then I also recommend either Precise Node or Precise Manuever. Another mod that really like is Transfer Window Planner, which does everything the Olex Transfer Calculator does and more, but it does it from inside the game. Those four mods - KER, Kerbal Alarm Clock, Precise Node, and Transfer Window Planner - I consider to be my most essential mods.

I don't remember. I just recall doing a study of it a couple years ago in which I concluded that cost per ton of payload was at its lowest with a launch TWR somewhere around 1.2 or 1.25. Increasing TWR above that reduced the delta-v to orbit, but increased the cost per ton. I think delta-v efficiency topped out with a TWR of about 2. I eventually settled on my current design guidelines because they're easy to remember, the designs fly very nicely, and I think it's reasonably efficient. But I stopped paying attention to what the actual cost per ton is.

I only had 8 GB until I upgraded last year. The only thing I had issues with were the visual mods, i.e. EVE and scatterer. With those installed GPP was virtually unplayable. However, I had no problem at all with the 4K textures.

I don't know what the Titan issue is, but I recall reading something about it several pages back. I don't know if a solution was given or not. I suggest you start reading backward through the thread and maybe you'll find something.

That's up to @Galileo, but if he chooses not to, then it falls on you. Just like any other software you'd consider using, GPP has certain minimum requirements. I don't mean to sound harsh, but it's the responsibility of the consumer to meet the minimum requirements, not the developer to lower the quality of the product.