OhioBob

Good point. I've edited my post to hide them in a spoiler box just in case anyone doesn't want to look.

In addition to the Mohole, here are the locations of the other anomalies for anyone who wants to test for them.

The "Ram" from BetterSRBs and the "Stomper" from Missing History are both just copies of the "Thumper", though the Stomper is shorter (only 1.11x in length rather than a full 1.5x). Even though the Stomper is shorter, at the time I created BetterSRBs, I thought they were just too similar to keep two copies of the same thing. But you make a good point that has me reconsidering. We also now have the "Pollux" (for those who own Making History), which falls between my SRBs in size. So if I brought the Stomper back, we'd have four 1.875-m SRBs that would cover a good range of sizes: Stomper > Ram > Pollux > Lance. If I were to bring the Stomper back, I'd redo its stats using the same calculations that I've applied to all SRBs. So the Stomper would not have the same performance that it does in Missing History. It would end up being slighter larger than the Kickback in fuel load and total impulse, but slightly lower in thrust.

@NathanKell, thanks. I did something very similar regarding the extinction issue. Thanks also for the temperature curve data. The problem that Kopernicus is struggling with right now is getting solar panels to work properly when there are multiple stars. I'm not real sure what the current status is, but I know it's been a headache for those working on it. Although I've helped out a little bit with testing and suggestions, I'm not one of the Kopernicus devs. @R-T-B has been working on it.

If you've installed everything correctly, the GameData folder of your KSP installation should include the following: CTTP Kopernicus ModularFlightIntegrator OPM Squad SquadExpansion (if you own any of the DLCs) Module Manager OPM & CTTP come bundled in the OPM download, and Kopernicus, ModularFlightIntegrator & ModuleManager come bundled in the Kopernicus download. Make sure the Kopernicus version number matches your KSP version number. For KSP 1.9.1, use Kopernicus 1.9.1-1. Use the one that comes with OPM, and do with it as I show above.

Not without changing/adding/deleting a bunch of configs. You can do it if you want, but I doubt anyone is going to do it for you.

There's no reason for you to uninstall HeatShifter. It serves one purpose, and that is to correctly model tidally locked atmospheric planets. By default KSP builds in a 45-degree offset in a planet's day-night temperatures so that the hottest time of day occurs in mid-afternoon. That's fine for a rapidly rotating body but not a tidally locked body. HeatShifter allows that 45-degree offset to be removed so the hottest location on a planet is the sub-solar point. There is only one planet in GEP (Toutatis) that is affected by HeatShifter. Other than that, HeatShifter has no affect whatsoever on any aspect of game play.

Just remember that if you remove those extra bits, then you're not experiencing the planet packs as intended. For instance, the only stock body that TweakChutes affects is Duna, and you'll only notice the effects when landing at the higher elevations, about 50% of the planet's surface. While that's certainly not insignificant, there are celestial bodies in GEP and GPP that are designed to provide a specific game playing experience that is destroyed by removing TweakChutes. So your dogged determination to make certain that nothing in stock is changed allows you to, in my opinion, cheat when it comes to GEP and GPP. Besides TweakChutes, what other bits are you talking about?

What's up with asteroids? Back in June I did a bunch of experimentation with asteroids and wrote down my results. Maybe it will help. https://www.dropbox.com/s/lag8opde3zimjqc/KopernicusAsteroids.pdf?dl=0

I've probably tried it with all the planet packs I've been a part of - GPP, GEP, JNSQ and Tidally Locked Kerbin. I pretty much gave up on Kittopia months ago after I couldn't get it to work. Though just a few days ago I decided to give it another try and it still didn't work. I have no ability to recompile, so I've been using v1.8.1-1, which is the last official release.

I haven't been able to get KittopiaTech to work since 1.8.1. The UI opens in later versions, but I can't seem to be able to apply any changes.

That's correct. The rim glow should probably be pointed in the direction of the brightest light source, as determined by ScaledIntensityCurve. ScaledIntensityCurve is a float curve defines how light intensity varies with distance. If a celestial body is X distance from star A and its ScaledIntensityCurve returns a value of 0.8, and Y distance from star B and its ScaledIntensityCurve returns a value of 0.1, then the rim glow should point to star A in this case. If ScaledIntensityCurve isn't used (unlikely for a multi-star system), then it should probably point to the star with the greatest scaledSunlightIntensity. ScaledIntensityCurve and scaledSunlightIntensity are either/or. One is a curve and the other is a static value (no change with distance). FYI, Kerbol is actually almost due right. It just looks bottom-right because there's more contrast between the blue and the darker planet in that direction.

I just reported a bug in prestja's Kopernicus Continued thread. Since the bug occurs in both 1.9 and 1.10, I'm referencing it here as well.

I have to report another multi-star issue. In ScaledVersion it is possible to use either a Gradient or rimColorRamp to add an atmospheric glow around the rim of a planet. When a planet orbits a secondary star, the rim glow points in the direction of the Sun (Kerbol) rather than the brighter nearby star that it orbits. Below is a screenshot illustrating this problem. This is a planet from GEP that orbits the secondary star Grannus. You can see that the planet is lit from above from the direction of nearby Grannus. However, the rimColorRamp (the blue glow around the edge of the planet) is pointed to the right in the direction of Kerbol. The rimColorRamp should point in the direction of the brightest light source, which in this case is Grannus in the upward direction. I've tested this in multiple versions and the result has been the same in each case - 1.8.1-1, 1.9.1-8, 1.10.1-8 and 1.10.1-9. Although the example in the screenshot uses a rimColorRamp, the problem is the same when using a Gradient. The issue also occurs with both planets and moons.

Deleted - accidently responded to an old issue.

UPDATE Version 1.0.3 Changelog Reduced orbit of Gilly to keep it inside Eve's SOI. See opening post for download link.

Of course Kerbalism doesn't support multiple stars. Can't hurt to try though.

I don't use RemoteTech so I have no idea. Sorry. Perhaps somebody with some RemoteTech experience can offer some advice.

Yes, but they're included in the Kopernicus download. Make sure you have ModularFlightIntegrator and ModuleManager installed. Also make sure the version number is correct. If you're using Kopernicus 1.8.1-1, then you should be playing on KSP 1.8.1.

TweakChutes just adds a module to the parts that can be easily removed with a MM patch. @PART:HAS[@MODULE[TweakChute]]:FINAL { !MODULE[TweakChute]{} }

GEP is pretty nonintrusive. It's designed to plugin simply with other planet packs without really changing anything. The only thing I can think of where you might see a difference is that GEP includes a plugin called Sigma TweakChutes. It fixes what I think are some bugs in the way stock parachutes work. The only place it might affect you in stock KSP is landing at high elevations on Duna. Stock parachutes full deploy when they get to a certain height above the terrain. They do this whether the pressure limit for semi-deployment has been met or not. TweakChutes stops this. Parachutes won't full deploy unless they have first semi-deployed (just makes sense). This is used by GEP because one of the GEP bodies is designed so that drogue chutes work, but not main chutes. It's intended to create a Mars-like landing experience. I always manually install. I tried CKAN once and didn't like it. I trust myself to do things right more than I trust CKAN.

I'm quite certain it hasn't changed. For instance, Kerbin's semimajor axis is 13600 Mm, which equates to an altitude of 13338 Mm. One of the small steerable solar arrays has a chargeRate of 1.64. Using NathanKell's math, it should produce an energy flow at Kerbin of, 1.64 / (13338 / 13600)^2 = 1.705. That's typically what a see for one of those solar panels around Kerbin.

That's not JNSQ. While the stock bodies all exist in JNSQ, they are completely redone with new stats and textures. Rational Resources in JNSQ is optional. You don't have to install it. In addition to what other have said, there's also Grannus Expansion Pack. It adds a second star with a family of planets and moons. It can also be used with the stock solar system and OPM. An installation of OPM + GEP adds OPM to the stock solar system with GEP as a binary star/solar system orbiting Kerbol.

That explains why I'm always off a little bit when I estimate power output. I've tried calculating it using either radii or altitudes, but I don't think I ever tried altitude/radius. It's not in the PART cfgs, so it must be buried in the code. There's no mention of this in the cfgs. To my knowledge this is not enabled in stock.

@NathanKell, hello. It's been a long time since our last conversion. I hope everything is going well. Since you're here, I have a question. I just happen to be in the middle of working on something with the new Kopernicus devs that you might know something about. Can you tell me anything about how atmospheric extinction works in KSP? It's clear that a solar panel produces less power if it's beneath a planet's atmosphere. It's also clear that the sun angle also has an affect on power output - i.e. less power output when the sun is on the horizon vs. high overhead. I've been working on my own equations for it, but if there's anything you can tell me about how KSP does it, that would be most helpful.