OhioBob

I don't know what's causing your problem, but to answer your questions... 1) Remove the your mods one by one until the problem goes away. To speed up the process you can remove them in groups instead of one at a time. When the problem goes away, start adding back the mods from the last group one by one until the problem reappears. ** 2) I have no idea if removing GEP will alleviate the problem or not. You'll just have to try it and see what happens. As long as you don't have any current missions within the Grannus system, you should be able to delete GEP without breaking your save. ** This method doesn't guarantee that the removed mod is the source of the problem. It could be that some other mod is causing the problem, but only when the removed mod is installed.

Sorry for the late reply, I just now saw your question. I don't know too much about the USI sounding rockets, but I can take a look at them. I wasn't planning on making changes to the sepratrons. Any changes I'd make would probably be insignificant, and besides, people have gotten use to them as they are. I'm also not changing the launch escape system. The LES is balanced to perform a specific task, so I don't want to mess with it. The sounding rockets might be similar scenario. If they're balanced to lift a specific payload, they probably shouldn't be changed. The only thing I want to change are the large general purpose SRBs.

I spent a couple days playing around with the PQSmod VoronoiCraters, trying to figure out exactly what it does and how to modify the settings to get what I want. Since I've got it pretty well figured out now, I wrote up my findings as a tutorial. Here it is if you're interested: https://www.dropbox.com/s/fnd0bblv5otqlhc/KSP_VoronoiCraters.pdf?dl=0

Somebody else just recently asked this same question. Perhaps you can find some helpful suggestions in that thread.

I think something has changed in one of the more recent versions of KSP. A couple years ago I could downsize Kerbin with no problem. But more recently I've tried it and things are totally screwed up. When trying to launch a rocket it just won't build up any speed, like it's experiencing massive amounts of drag. And when we cut the engine, instead of slowing down, the rocket continues to very slowly accelerate. Also some of the numbers displayed in the AeroGUI are nonsense. I'm not the only one who has experienced this; I've had conversations about it with somebody on Discord. We ran some experiments and determined that the problem occurs every time we tried to reduce the size of Kerbin.

Since kg has units N*s2/m, i.e. m = F/a, then N*s/kg becomes m/s. Using mass just gives the effective exhaust gas velocity.

I think @Poodmund may have computed that at one time, but I don't have a link to it. If he has that information, perhaps he can share it. But if you just want to know what the maximum and minimum values could be at their most extreme, do this: Minimum separation = Outer planet's periapsis - Inner planet's apoapsis Maximum separation = Outer planet's apoapsis + Inner planet's apoapsis You can compute the periapsides and apoapsides like this: Periapsis = semimajor axis * (1 - eccentricity) Apoapsis = semimajor axis * (1 + eccentricity) You can get the semimajor axes and eccentricities from CelestialBodies.pdf packaged in the GPP download. The above method is only approximate because it doesn't take into account the longitude of periapsis and the inclination of the orbits. EXAMPLE What's the maximum possible separation between Gael and Gratian? Gael apoapsis = 13,982,767 * (1 + 0) = 13,982,767 km Gratian apoapsis = 39,156,200 * (1 + 0.06) = 41,505,572 km Maximum separation = 13,982,767 + 41,505,572 = 55,488,339 km

I don't know the current status of RSS because I haven't been involved in it for a couple years. But back in 2016 I created the atmospheres for RSS. These particular spreadsheets weren't used because they didn't exist yet, but the method was essentially the same.

Home worlds do not have to be a Kerbin equivalent. I'm only familiar with GPP and GEP, so I don't know what other planet packs do. In GPP, the home world, Gael, is equivalent to Kerbin. But in GEP, with the GEP_Primary option install, the planet Nodens becomes the home world. Nodens is not a Kerbin equivalent. It has radius of 700 km, a surface gravity of 1.1 g, and an atmospheric pressure of 2 atm. (edit) I do recall there being some issue with home worlds that are smaller than Kerbin. It causes some sort of physics glitch that makes the game unplayable (rocket launches from the home world are totally borked). However, home worlds that are larger than Kerbin seem to work fine.

It sound to me like that would require modeling a new part. Snark has said that modeling new parts is beyond what he wants or is able to do. The only new parts that this mods provides are those that can be made by cloning and resizing existing parts.

OPM has science defs, but they're not all unique; it looks like many biomes share the same description. I have no plans to add science defs to GEP. As far as I know, science defs for GPP were never completed simply because of the sheer volume of work.

I estimate that's there's somewhere around 5,000 individual science definitions. Are you volunteering to write them for us? If not, it's not happening.

I have no idea what cfg you're talking about. If you're using a cfg that didn't come packaged with the current GPP download, then don't expect any support from us in trying to make it work.

@Darkspace, try replacing this file, GameData/GPP/GPP_Configs/GPP_Science_Defs.cfg with this one, https://www.dropbox.com/s/xn1f6z5jq87290m/GPP_Science_Defs.cfg?dl=0 I think that should restore the Gael science definitions to what they use to be.

Technically, the laws of physics didn't change. KSP used the same drag formula both before and after v1.0. What changed were the numbers that got plugged into the drag formula. Starting with v1.0, KSP began using the actual geometry of the rocket to determine the surface area exposed to the air flow, and to compute the drag coefficient. The thing that most significantly affected the delta-v to orbit was the surface area. Prior to v1.0, KSP used a very simple formula that estimated the cross sectional area as a function of mass. For rockets, it was a really bad formula that grossly overestimated the area. This resulted in huge and unrealistic amounts of drag.

Looking at the configs, the only bodies for which I see custom science definitions are Gael, Iota and Ceti, and then only for surface sample, crew report, EVA report, and mystery goo. If those aren't working, then there's a problem. (It's possible the Gael ones might have to be renamed Kerbin.) Otherwise the lack of custom science defs is normal behavior. As far as I know, there has never been custom defs for anything outside the Gael system.

Very little in GPP has had custom science definitions written for it. I think a couple people started working on it but gave up as soon as they realized how much work it was going to be.

I seem to recall the number back in the pre-1.0 days as being about 4500 m/s. They completely redid the aerodynamics with the release of v1.0. The old aero model was just a placeholder. It used some very simple formula to compute factors such as drag coefficient and surface area. The surface area formula was particularly bad, turning everything into a flying pancake. This resulted in huge drag losses, which is why it took so much delta-v to reach orbit. The new aero model is far more lifelike. Drag losses are nowhere near what they use to be, so it now takes about 3400 m/s to reach orbit.

Because there aren't any other good options in KSP. It's really the Vector or the Dart and not much else. The solution to the Vector being too powerful is to use fewer of them, or use the Dart. The only other thing I can think of is TWR. At Eve sea level, the Dart has the best ISP at 230s versus 193s for the Vector. But the Vector has the best TWR at 90:1, vs. 72:1 for the Dart. And, of course, if you need a lot of thrust, the Vector is the more powerful engine. Neither engine is very good cost-wise, as they are both very expensive.

@HebaruSan, in a perfect world, your design would make use of a smaller version of the Vector. Unfortunately, we don't have that luxury in KSP. There is only one version of the Vector, and it is up to us as the designers to figure out how to make most effective use of it. So it's not a problem with the engine, per se, it's a design issue. You may have had different priorities in making your design. For instance, perhaps you prioritized symmetry and stability. There's nothing wrong with that, those are important design considerations. But when one thing is prioritized, something else gets pushed down the list. Maybe making most effective use of the engines was not a top priority. That's OK, but in making that decision you must then live with the consequences.

Sounds to me like you're using too many Vectors. Why are you using so many that you have to throttle them down?

The Vector and the Dart are really the only engines that provide any kind of reasonable performance when deep in Eve's atmosphere. Next in line would be the Mainsail, Twinboar and Thud. Everything else pretty much sucks. The Swivel is the worst. If you need something to provide some steering to go with the Darts, maybe try attaching some Thuds. By the time you get up to an altitude of 10 km, the atmospheric pressure is down to about 1 atmosphere, so at that point you can use the same engines you would on Kerbin. Another possibility is Eve Optimized Engines, though some people might consider that a little cheaty.

I don't remember if it's Porkjet's command pod or somebody else's, but I recall a problem. Somebody's Mk1 pod uses too much curvature on the base of the capsule, such that when a heat shield is attached to it, the bottom of the pod clips through the heat shield and is exposed to heating. If the pod is used for, say, a Mun mission, it will likely overheat and explode on reentry because the bottom is not fully protected. If that's Porkjet's Mk1 pod that I'm thinking of, then I strongly suggest it not be included in this or any other mod. Although it might look nice, it has a serious design flaw.

That was true at one time when the game was still in beta, but not anymore. The game calendar uses solar days, which are exactly 6 hours long. Kerbin's sidereal period is approximately 5 hours, 59 minutes, 9.4 seconds. Accordingly, the sun rises at the same time every day. There are 426 solar days in a Kerbin calendar year, and 427 sidereal days. What is out of sync is the start of a new year in relation to the stars. Kerbin's orbital period is about 426.09 days, so that means Kerbin hasn't quite completed a full orbit when the next year begins. To correct for this, Kerbin should have a leap year about every 11 years. But since it doesn't, the stars that illuminate the night sky on new years day will change over the millennia. This would be more of a problem if Kerbin had seasons, because the start dates of the seasons would change over time.

You misspelled temperatureSeaLevel.