OhioBob

Dude, what kind of entry angle are you coming in at? You're averaging 10g on a return from Mun? No wonder your reentries go by in the blink of an eye. There's nothing wrong with the game, I think you're just coming in way too steep. Shallow your entry angle and you'll decelerate more slowly, and the reentry will last longer. For a return from Mun, I generally like a trajectory that has a periapsis altitude of about 20-25 km above Kerbin. This usually generates a peak deceleration of about 3.5g. And the reentry takes several minutes. Set the periapsis to 35 km and the reentry can last a very long time.

UPDATE Version 1.0.2 Changelog Revised RealPlume.cfg to fix conflict with JetSounds. See opening post for download link and instructions.

I'm not going to add a config for something that's not complete. When an official 1.4.x version is released, then I'll take a look at it.

Is the latest version of Vens still 1.9.6? If not, can you link me to the latest. (edit) I just discovered that Vens doesn't play nicely with BetterSRBs. It retextures my retextured SRBs.

That sounds about right to me. My first reaction when looking at the design was to take away fuel tanks from both the upper and lower stages and remove one SRB. I'm glad you took the extra step to actually test it.

I don't know where you're getting those numbers. Based on the looks of your design, I assume your mission is to orbit Mun and return. That should take, Launch to Kerbin orbit: 3400 m/s Transfer to Mun: 860 m/s Mun orbit insertion: 310 m/s Return to Kerbin: 310 m/s TOTAL: 4880 m/s (plus any safety margin you'd like to add) Your rocket has 6674 m/s, which is over designed. You don't need a rocket anywhere near that size for a Mun orbit mission. I'd start by removing most of the fuel in the upper stage. You probably don't need more than one FL-T400 tank, which would give your upper stage a delta-v of about 2000 m/s. And the reduced weight up top will increase the delta-v and thrust-to-weight ratio of the first stage and SRBs. It wouldn't surprise me also if you could reduce the number of strap-on SRBs from 3 to 2.

Already been done. I've given both the Thumper and Kickback, as well as the added SRBs, a small amount of thrust vectoring.

Yep, it sure is. Fortunately that's not an installed folder, so it really shouldn't cause anybody problems. Nonetheless, I've fixed it and updated the file on GitHub. No version update is necessary. Thanks.

Why enter with the bottom as the leading edge? When you enter bottom first, the vehicle must be aerodynamically stable in one direction during entry, and then it must be aerodynamically stable in the other direction during ascent. That can be difficult to engineer. Why don't you consider having it enter the atmosphere nose first with the heat shield on the front end. Then whatever you have to do to stabilize during it entry (mass in front, drag in back), will be the same things that will stabilize it during ascent. After you've entered and bled off most of your speed, you can use parachutes to flip it around so it lands bottom down.

There's no way to make a biome end precisely at the ocean's edge. The maps just don't have the resolution to do that. The best that anyone can do is have the shoreline snake its way through the shore biome, so that the biome extends a little ways inland and a little ways out to sea. Having both landed and splashed conditions within the shore biome really isn't all that bad. We can think of "shore" simply as a narrow strip of land having edges that straddle the shoreline. What is probably worse is to have landed/water or splashed/lowlands. That's what could happen if the shore biome is made too narrow to where it doesn't complete contain the shoreline. (edit) I suspect that GPP is probably not very good in regard to its shore biomes. First, I believe the shore biomes were made only one pixel wide, which is probably not enough to assure that the shoreline passes though it. It's also possible that PQSmod changes have been made since the biome maps were completed. Changing PQSmods could alter the location of shoreline and push it outside the area defined in the biome maps. My personal opinion is that all the shore biomes in GPP should be redone, but that's probably not likely to happen. I doubt anyone on the team has the motivation to do it.

It should be, hg = v^2/2.

The physics of the game is, for the most part, realistic. So you could do calculations if you wanted to, though I think most people probably do it trial and error. I haven't done many of the types of contracts that you're referring to, but for the ones I've done, I haven't found it especially hard to meet the conditions. I think the contract parameters are generally set at values that you should be able to meet if you perform a normal launch, reentry, etc.

Then I'm afraid I don't know what the problem is.

Then you must not have installed it correctly. Kopernicus usually says that when it can find something, such as textures missing or being in the wrong place. Check again, you did something wrong. If you need any help beyond that, you're going to have to provide more information.

Wow, I actually found my equations. It's not real simple, however. There are two equations, and they only apply to the time that the engine is burning. The first computes the velocity of the rocket at burnout, v = Ve * LN[ M / (M - q * t) ] - g * t and the second computes the distance traveled by the rocket during the burn, d = Ve * { t + t * LN[ M / (M - q * t) ] + M * LN[ (M - q * t) / M ] / q } - g * t2 / 2 where Ve is the exhaust gas velocity, t is the burn time, M is the initial mass of the rocket, q is the propellant mass flow rate, and g is the acceleration of gravity. The equations assume the rocket is traveling straight upward, there is no atmospheric drag, and g is constant. Once the engine burns out, the rocket is in free flight and you can use the equation from my previous post to compute how much higher the rocket will go. Just use v from the equation above for the initial velocity. And if we say that the radius at the launch pad is R0, then we have R1 = R0 + d. The total height reach is R2 - R0.

If a object is positioned at a radial distance of R1 from the center of the planet, and we want to give it an upward velocity that will propel it to a radial distance of R2, the require initial velocity is, V = SQRT[ 2 * μ * (1 / R1 - 1 / R2) ] where μ is the gravitational parameter. So in your example, we know V and R1, so we must solve for R2. Rearranging the above equation, we get R2 = 1 / ( 1 / R1 - ( V2 / (2 * μ) ) Of course this is not exactly what you're asking for. V is the initial velocity that you must give the object, which is not the same as the ΔV of a rocket. I think I derived an equation for this like about 20 years ago. I might still actually have it somewhere. If I can find it, I'll post it.

Try deleting your cache. Go to the folder GameData/GPP/Cache/ and delete all the .bin files. When you restart KSP, Kopernicus will recreate all those files. I'm not sure that's your problem but it's a good place to start.

It's a shame these mods don't play nicely together. I really like what Kronometer does, but I just rely too much an KAC and TWP that I can't use it. It saddens me.

For GEP to work, you must have at least the following installed in your GameData folder: GEP Kopernicus ModularFlightIntegrator Squad ModuleManager.3.0.7.dll The problem with solar panels is that KSP does not natively support multiple stars. Everything that allows the existence of multiple stars is done through Kopernicus. Kopernicus includes it own solar panel module that allows panels to track and receive power from stars other than "the Sun". Right-clicking on the solar panels brings up an options menu that allows you to select the tracking body. If set to Auto, the panels should track the brightest nearby star. But if this bugs out and isn't working correctly, you can select specifically which star you want the panels to track. Kerbalism is a separate mod that has conflicts with Kopernicus' solar panel module. To resolve the conflict, Kerbalism simple disables Kopernicus' solar panels. In this instance, only "the Sun" will power solar panels. You will receive no power at all from any other stars. Kerbalism is, therefore, not recommended for use with any planet pack that adds stars.

The solar panels are suppose to track the brightest light source, but I believe it's a bit buggy and doesn't always worked right. If you right-click on the solar panels you should be able to select the star that they track. If you select Grannus the solar panels should point in that direction. Also, according to the screenshot of your GameData folder, you don't have ModularFlightIntegrator installed. ModularFlightIntegrator comes in the Kopernicus download and must be installed for Koperniucs to work.

I ran into the same type of issue recently while playing GEP_Primary. I ended up uninstalling Kronometer. This meant the clock wasn't in sync with the home world's actual day and year, but at least the game clock matched the readouts of KAC and TWP. I found the latter to be most important for game play. It was almost unplayable to have the game clock using one method of timekeeping, and KAC/TWP using another method. (edit) The best solution obviously is to fix KAC and TWP to be compatible with Kronometer. But as you say, there's no sign that's going to happen anytime soon.

I can't help you without more information. But as @4x4cheesecake said, if you're using Kerbalism, then that's your problem. Kerbalism does not work with any planet packs that have multiple stars. You'll have to decide between one mod or the other, but you can't use both. If you're not using Kerbalism, then I have no idea what your problem is. You haven't given me enough to diagnose the problem.

Just don't install Kronometer and you'll have a clock/calendar with 6-hour days and 426 days per year. The game clock will then measure time in the same units as mods like KAC and Transfer Window Planner. By changing the dayLengthMultiplier you can reset Gael to have a solar day of 6 hours. However, Gael's year at 2.5x will not be 426 days. Measured in 6-hour days, its year will be 673.333 days. There's nothing you can do to change that. At 2.5x, Gael takes longer to orbit the sun than it does at 1x, and that's just the way it is.

I don't know if such a planet could exist in real life, but in theory, yes, it's possible. We actually had this issue with Lili, were players couldn't land at the equator because centrifugal force exceeded surface gravity. To find where the two forces balance we just set them equal to one another, v^2 / r = go We know go and r, so we solve for v, from which we can compute the rotational period. For Gael at 2.5x, the rotational period would have to be less than about 41 minutes.

Changing Gael (Kerbin) back to a 6-hour day shouldn't break anything. The easiest way is probably to open the file 2.5xKSP.cfg, find the following code, and change the dayLengthMultiplier to 1. @Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim,GPP] { @Body:HAS[#name[Kerbin]] { @SigmaDimensions { @dayLengthMultiplier = 1.66666666666667 @landscape = 0.58 } } } As far as whether the rotation period is sidereal day or solar day, it's different depending on the body. For the home world, the rotation period used in the cfgs is the length of the solar day, from which KSP computes the sidereal day. For all other bodies, the period is the length of the sidereal day.