OhioBob

Do you mean when they started varying thrust rather than fuel flow rate? (I had forgotten all about that until you just now reminded me.)

Yeah, I was working on GPP at the time 1.2 was released. I didn't want to do what Squad did and have a bunch of weird surface gravity numbers, so I instead just let the values of GM change. That changed a bunch stuff, but GPP was in early development and didn't have that many users at the time, so it wasn't a big deal. I've too read somewhere that that got fixed, but I can't swear to it.

As of version 1.2, KSP uses G = 6.67408E-11 m3/kg-s2, and go = 9.80665 m/s2. Prior versions used G = 6.674E-11 m3/kg-s2, and go = 9.81 m/s2. The above change is why Kerbin has the weird surface gravity of 1.00034160493135 g, rather than 1 g like it use to have. Note that, GM = g*r2 When v1.2 was released, Squad didn't want any of the bodies' GM to change, because that would have changed things like orbital periods, geosynchronous altitudes, spheres of influence, etc. So they kept all the bodies' surface gravities the same, but measured them to a new "standard gravity". That is, Kerbin's surface gravity remained 9.81 m/s2 like it has always been, but in units of standard gravities it became, 9.81 / 9.80665 = 1.00034160493135 g While GM didn't change, mass did (because the value of G changed). But like you've explained, that really doesn't matter. Mass isn't used in any of the calculations, GM is used. Something else to note is that mods that use Kopernicus to create new planets or modify existing ones can provide the needed gravitational data in one of several different ways. The mod creator can specify either the body's surface gravity (geeASL), its mass (mass), or its gravitational parameter (gravParameter). Only one of those is needed to calculate the others. If more then one is given, it's possible the mod creator could unwittingly provide conflicting values. I'm not certain but I believe priority is given to gravParameter, then mass, and lastly geeASL. That is, if all three are given, the last two are thrown out and recomputed from gravParameter. Most mod creators specify geeASL. So if you look in a body's configuration file and you see radius = 500000, and geeASL = 0.8, you can compute GM thus, GM = (0.8 * 9.80665) * 500000^2 = 1.96133E+12 m3/s2. And although you don't need it for any calculations, M = 1.96133E+12 / 6.67408E-11 = 2.938727135E+22 kg.

@hoanghieu, as Foxster said, HyperEdit often causes terrain to weird out. I think it has to do with the textures loading too fast or something like that. You can fix it just by returning to the Tracking Station and reselecting your vessel. This should cause the textures to reload correctly.

@Gordon Dry, there's nothing about Realistic Atmospheres (RA) that should be causing the problem you're describing. I've never experienced the problem and no one else has ever reported it. I also don't see anything in the logs that suggests a problem related to RA. I suspect there's likely something else causing the problem. But you have about 200 mods installed, most of which I'm unfamiliar with. I can't begin to suggest what might be at fault.

There are some things about GPP that are not particularly realistic, but where we could provide realism without detracting from the fun of the game, we at least made an effort to get it right.

I'm the one who gave Ciro its properties. It was sized specifically to place it on the curve of an H-R diagram. I used the mass-radius and mass-luminosity equations found in this article, i.e. R / Rsun = 1.06 * (M / Msun) 0.945 L / Lsun = 1.02 * (M / Msun) 3.92 There were also properties of the home world (Gael) that I wanted to maintain. Specifically, I wanted Gael to have an orbital period of exactly 426 days (to match KSP's built-in calendar), and a solar constant of 1360 W/m2 (to have earthlike temperatures). The problem had to be solved by iteration, Assume an initial value for Gael's semimajor axis. From Gael's semimajor axis and solar constant, compute Ciro's luminosity. From Ciro's luminosity, compute its mass using the equation above. From Ciro's mass and Gael's semimajor axis, compute Gael's orbital period. If orbital period <426* days, increase SMA, and if >426* days decrease SMA. Repeat steps 2-5 until orbital period equals exactly 426* days. From Ciro's final mass, compute its radius using the equation above. From Ciro's luminosity and radius, compute its surface temperature using Stefan-Boltzmann law. Of course all these computations where made using real life sizes and masses. After completing the computations, everything was reduced to stock-size proportions (0.1 radius/distance, and 0.01 mass). (edit) * 426 days is the orbital period at stock-size measured in 6-hour days. When performing the calculations at life-size, the orbital period must be adjusted. Scaling stock-size up to life-size we increase semimajor axis by 10 and mass by 100, so the orbital period is increased by SQRT(10^3/100) = 3.16227766. And if we measure it in 24-hour days, we divide by 4. So when performing the steps above, the actual orbital period that I'm trying to achieve is, 426 * 3.16227766 / 4 = 336.78257 days. This will, of course, equal 426 six-hour days when scaled down to stock-size.

I've tinkered with similar changes to make the stock system a bit more realistic. Many of my proposed changes are the same as yours. Although this is not a complete list, these are some of the more egregious things that I think need changing: Sun's radius and surface gravity are way off from what they should be for a main sequence star. Eve is too dense (surface gravity should be ~1.2). Jool is not dense enough (surface gravity should be ~1.2). Mun is too close to Kerbin (Kerbin would be tidally locked to Mun at current distance).

Below is what I use to determine the properties of a fictional gas giant. It is a graph of Jupiter, Saturn, Uranus and Neptune fitted with a trendline. From this we can estimate the radius and mass of any size gas giant, assuming that it falls on the trendline. Below are the expected properties of gas giants at various sizes: Mass Radius Gravity Density (kg) (km) (g) (kg/m²) 1.898E+27 69,911 2.642 1,326 9.184E+26 65,000 1.479 798 6.353E+26 60,000 1.201 702 4.700E+26 55,000 1.057 674 3.580E+26 50,000 0.974 684 2.763E+26 45,000 0.928 724 2.141E+26 40,000 0.910 798 1.653E+26 35,000 0.918 920 1.263E+26 30,000 0.955 1,117 9.466E+25 25,000 1.030 1,446 6.874E+25 20,000 1.169 2,051 I always assume that KSP stock-sized planets are 1/10th the radius and 1/100th the mass of their real life counterparts.

RSS uses real life values, so Jupiter is truly Jupiter-like, with a surface gravity of about 2.68 g. All the scaled-down versions of RSS, like SSRSS, use the same values. Outside of Jupiter, the other gas giants in our real life solar system all have surface gravities around 1 g, so it's really not abnormal that many of the planet packs would have gas giants with gravities and densities lower than Jupiter. One way to estimate approximately where a gas giant should fall is to plot a graph of Log(radius) vs. Log(mass) for known real life gas giants. Doing that we find that gas giants tend to cluster along a curve. If we place a planet the size of Jool (assumed 10 times its stock radius) along that same curve, we find that its surface gravity should be closer to 1.2 g rather than its actual value of 0.8 g. This tells us that Jool is less dense than it should be for its size. If other planet packs have based their gas giants off of Jool, then this could help explain why densities/gravities are lower than you were expecting.

One more thing I forgot to mention. The variable a is the vertical acceleration. If the vehicle is pitched over, as might be the case if you are trying to kill both vertical and horizontal velocity, then the vertical component is, a VERTICAL = a TOTAL * SIN(thrust angle) where thrust angle = 0 if horizontal, 90o if vertical. In most cases the thrust angle equals the pitch angle. Also note that z is altitude above terrain.

I can give you a simplified answer. Ignoring drag and assuming constant acceleration, the equation is t = (v + SQRT(v2 – 2*z*(g+a))) / -(g+a) where v is the current vertical velocity, z is the current altitude, g is the acceleration of gravity, and a is the acceleration from the engines. Suppose we have v = -100 m/s, z = 1000 m, g = -9.81 m/s2, and a = 14.8 m/s2 (upwards is positive). The time to impact is, t = ( -100 + SQRT((-100)2 – 2*1000*(-9.81+14.8))) / -(-9.81+14.8) = 19.14 seconds Note that if 2*z*(g+a) > v2, the equation will fail because you're trying to take the square root of a negative number. When this occurs it means that the vehicle will stop and start traveling upward before reaching the ground (i.e. too much upward acceleration). Of course the time to impact is really "time to impact at the current speed, distance, and acceleration". As long as you make it so the time to impact constantly updates, the closer you get to the surface, the more accurate the calculation becomes. If you want to take drag into account, that really complicates things. There's no simple equation in that case. But if you're only worried about the final moments of a propulsive descent leading to a soft touchdown, you're probably traveling slow enough that drag isn't really an issue.

The config looks to me like it ought to work anywhere in Gamedata. Of course I really don't know much about sunflares. The limit of my knowledge has already been reached. If you need more help it's probably going to have to come from someone else. Also the sunflare in your screenshot doesn't look like the stock sunflare. Are you sure that's not the way it is suppose to look? (Or am I seeing the stock sunflare superimposed on the scatterer sunflare?)

SunFlareFix.cfg ought to do it for you. It detects whether or not Scatterer is installed, and, if so, it disables the stock sunflare.

@Tuko, I think you just have to put this anywhere in the Gamedate folder. However, GPP already includes this if you install the folder GPP_Scatterer. https://www.dropbox.com/s/ua5ty5hnbtpidym/SunFlareFix.cfg?dl=0

OK, that's not good when using Nerv engines. The Nerv will use up the liquid fuel, and when that's gone, it will stop running. The oxidizer is nothing but a bunch of useless ballast that destroys your performance. You should redesign using liquid fuel tanks (the ones that don't have any oxidizer). Of course you still need oxidizer for any stage using a chemical rocket engine. Also, if you're using fuel cells you will still need to carry a small amount of oxidizer for those.

I would suggest that you think about what you might want to do as a long term goal, and then approach it incrementally. If there are any parts of the long term goal that you don't feel you currently have the skill to perform, design smaller simpler missions that will allow you to acquire the missing skills without biting off more than you can chew at one time. As far as mods are concerned, I also recommend that you do it incrementally. The first mods I started out with were utility mods, i.e. tools that make playing the game easier. Examples of these are Kerbal Engineer Redux, Kerbal Alarm Clock, Precision Node, etc. You can then start moving into part packs, planet expansion packs, environmental enhancements, etc. Just pick what interests you.

No to what? My question about oxidizer? The number of Nervs (I assume you are using the stock engine LV-N "Nerv", not NERVA) doesn't make any difference. ISP is not additive. Also, please explain where the 1700 m/s number came from. That number doesn't mean much to us it we don't know from where it was derived. It would also be helpful if you could post an image of vessel. A lot of problems can be diagnosed from a simple picture.

There's something more wrong with your math than just leaving out the natural logarithm. Neither one of those equations equal the answer you got. If you have a starting mass of 17.5 t, an ending mass of 10.5 t, and an Isp of 800 s, then the delta-v is, dV = 800*9.80665*LN(17.5/10.5) = 4008 m/s If you are really getting only 1700 m/s, then there is something else wrong. That's why I asked if you might be including oxidizer in the calculation.

If you are using a Nerv, are you using tanks that have both fuel and oxidizer? If so, then that's also part of your problem. A Nerv uses liquid fuel only, so oxidizer is just dead weight. The ISP of two Nerv is the same as one. The only time you have to worry about figuring out combined ISP is when you have multiple engines with different ISP.

Yep, calculating delta-v is really not very difficult. If the orbits and gravitational parameters of the bodies are known, then it is pretty straightforward. And the orbits and gravitational parameters can be determined by observing the movements of the bodies, measuring distances and periods, and applying some math. There may be some minor bodies that are difficult to observe for which good information is hard to come by, but for the moon and the major planets, we knew a great deal before ever going to space.

Orbit, yes. Home, no. I usually budget about 1400 m/s to get to orbit from the surface of Duna. That's not going to leave you with enough to escape and return to Kerbin. However, getting to orbit will make a rescue easier if and when you can mount one.

Your comments have gotten me thinking about something. In GPP we made the delta-v map part of the KSPedia. Because of its size, it's broken down into several separate pages. I wonder if there is a way to reveal portions of it as a player works his way through the tech tree. Perhaps better yet would be to reveal parts of it as certain goals are achieved . I know very little about the KSPedia, so I don't know if such a thing is possible*. If it is possible, however, it might be a good way to deal with the issues you've raised. * I only did the math for the dV map, others get credit for the artwork and KSPedia.

@Cpt Kerbalkrunch, I learned the lesson the hard way as well. I had a similar situation to yours, where I had a Mun base (landed in one piece) and a separate rover that was suppose to dock to it. Fortunately the misalignment wasn't too bad and I found that if I just kept trying, I could eventually get them to dock. It was a good way to learn a lesson without totally losing my mission. This makes me think of an idea for a new part. Landing gear that include jacks to raise, lower, and/or level the part after it has been set in place.

The ascent dV for airless bodies I was able to determine using computer simulations. I could have also done launch simulations for the bodies with atmospheres, but that gets a lot more complicated and I didn't want to do it that way. Instead I just did series of test launches and measured the dV directly, i.e. before - after. The one thing that really simplified this process is that I edited the config of the home world to give it the size, gravity and atmosphere of the body for which I wanted to determine the launch delta-v. This way I could easily perform all my test launches from the KSC launch pad without having to transport my rocket to the actual planet.