OhioBob

I just looked at the data again and realized that Nodens year is only 270 hours long. There are four sidereal days in Nodens' year, but only three solar days. It takes Nodens 67.5 hours to complete one 360-degree rotation on its axis. But because during that time Nodens is also revolving around Grannus, it takes an extra 22.5 hours for Grannus to return to the same spot in Nodens' sky. That is, if we measure the time from, say, sunrise to sunrise, the day is 90 hours long. So we have, 1 year = 67.5 * 4 = 90 * 3 = 270 hours. A planet always has 1 more sidereal day in its year than it has solar days. For instance, Earth's solar day is 24 hours and there are approximately 365.2425 solar days in a year (there are 97 leap years every 400 years to account for the decimal part). With one more sidereal day per year, this means that Earth's sidereal rotation period is, (365.2425 * 24) / 366.2425 * 3600 s/hr = 86164.09073 seconds. Officially the number is 86164.09053083288 seconds.

I agree that would be useful for a deorbiting engine. There's already enough monopropellant for that in the pod, so just slap on a small engine to make use of it in situations where only a small amount of delta-v is needed. Of course what I've sometimes done in those cases is just add a couple Place-Anywhere RCS thrusters and angle them forward or aft to be used for deorbiting.

Here's a couple screenshots from my most recent mission to Sirona and her moons.

The only place I can see using puff engines is, (1) you need to carry monopropellant anyway for RCS, and (2) you need something that will produce high thrust but only a small amount of delta-v. In that case, since you only need a small amount of delta-v, adding a bipropellant tank and engine just isn't worth it. You have the monopropellant already, so use it. And the lower specific impulse doesn't hurt you much when you don't need much delta-v. However, I've never really found a need to do this. I've found that when I need to perform a low delta-v burn using monopropellant, such as for a rendezvous or a deorbit, I can do so adequately simply using the RCS. I also think the fact that the puff is radially mounted hurts its usefulness. It typically needs to be used in pairs to keep mass and thrust balanced. In the places where perhaps I could have used a monopropellant engine, I've rarely needed two of them. I think I'd find more use for a small inline monopropellant engine. Maybe something like a 1.25m attachment with four small spherical monopropellant tanks surrounding a center engine. The monopropellant could feed both the small maneuvering engine and the RCS.

A vessel should fall about 1.65 times faster on Duna than it will on Kerbin. The equation for terminal velocity is, Vt = SQRT( (2mg)/(ρACd) ) m, A and Cd are all characteristics of the vessel and parachute, so if we assume those are the same regardless of where we are, we can delete those terms and simply say Vt ∝ SQRT(g / ρ) That is, terminal velocity is proportional to SQRT(surface gravity / air density). Duna's surface gravity is 0.3 times Kerbin, and it's air density at the surface is about 0.11 times Kerbin. Therefore, Vt_duna / Vt_kerbin = SQRT(0.3/0.11) = 1.65 So just test it on Kerbin and then you can compute what it will be on Duna.

Kopernicus is version locked, meaning that each version of Kopernicus will work with only one specific version of KSP. The version numbers must match, i.e. with KSP 1.4.3 you must use the Kopernicus version numbered 1.4.3-x. (The "x" is the release number. There may be multiple releases that will work with a given version of KSP. You should use the most recent release.) You can't use Kopernicus 1.4.3-x with KSP 1.4.4. If there is no Kopernicus version that matches the current KSP version, then please just be patient and wait for Kopernicus to catch up. Mod authors have real life demands that take precedence over updating mods, so things don't always happen as quickly as you might like. It also doesn't help that Squad releases one KSP update and then immediately announces that another will soon follow. That is very frustrating for mod developers. Many mod authors choose to just wait until the second release so they don't have to update their mods twice. That seems to be what's happening here.

There's a simple trick that makes getting to Belisama easy. Check out the spoiler if you want to know.

Outer Planets Mod is a good choice.

(edit) I just posted this to be funny. I'm not criticizing. I appreciate what you've done.

Looks like you're the guinea pig who gets to test that out.

According to Sigma Cartographer Kerbin Lowest Point LAT = -27.0750000000008 LON = -79.0030000000053 ALT = -1393.52263545198 Highest Point LAT = 61.5959999999995 LON = 46.3599999999941 ALT = 6768.58602164045 Eve Lowest Point LAT = 40.0869999999993 LON = -14.739000000006 ALT = -1866.22036640497 Highest Point LAT = -24.9950000000008 LON = -158.475000000001 ALT = 7541.23703519918 Laythe Lowest Point LAT = 29.3139999999994 LON = 7.32799999999408 ALT = -2799.93785459863 Highest Point LAT = -17.5780000000007 LON = 172.566999999989 ALT = 6079.1484591373 I don't know about Eve and Laythe, but Kerbin's heightmap has a flat ocean bottom. The bumpiness is added height noise (using a PQSmod). As a result, the ocean floor has a bunch of low spots that are all about the same elevation. Cartographer found the lowest of the low.

In addition to installing Cartographer in your GameData folder, you have to write a .cfg file to tell it what to do. It then runs automatically when you launch KSP (there is no in game interface). Here's what the cfg should look like: SigmaCartographer { Maps { body = Kerbin // the name of the body (default = Kerbin) width = 2048 // the total width of the texture (default = 2048) tile = 1024 // the width of one tile (default = 1024) exportFolder = MyMap/1/ // path for the export folder leaflet = false // export in folders divided by columns and rows (default = false) heightMap = false // export height? (default = false) normalMap = false // export normals? (default = false) slopeMap = false // export slopes? (default = false) colorMap = true // export color? (default = true) oceanMap = false // export ocean? (default = false) satelliteMap = false // export satellite? (default = false) biomeMap = false // export biome? (default = false) oceanFloor = true // include the ocean floor ? (default = true) normalStrength = 1 // strength of normals (default = 1) slopeMin = 0.2,0.3,0.4 // color for 0° slope (default = 0.2,0.3,0.4) slopeMax = 0.9,0.6,0.5 // color for 90° slope (default = 0.9,0.6,0.5) LAToffset = 0 // offset latitude (default = 0) LONoffset = 0 // offset longitude (default = 0) // if you want to print only selected tiles // add as many of these as you want // if you don't add any of these // all tiles will be exported printTile = 0 printTile = 1 } Info { // List all the bodies for which you want info on // the lowest and highest point on the planet body = Kerbin body = Mun } Just edit the cfg as needed and drop a copy somewhere in GameData. Start KSP and then exit after you get to the main game window. (There will probably a delay in the loading time as Cartographer runs in the background.) After closing KSP, look in the Cartographer folder and you should find your maps. When finished, be sure to delete the cfg or it will run every time you start the game. I'm not sure if Cartographer works with KSP 1.4.x. You might have to use 1.3.1.

@aimeilian, you'll definitely need ScaledVersion textures. If not, you'll just get the template. As Adstriduum said, you can use KittopiaTech to extract those. Or you can try Sigma Cartographer. https://github.com/Sigma88/Sigma-Cartographer/releases

Question #1 - Unfortunately, no. You can fake axial tilt by inclining the ecliptic plane, i.e. planets will have axial tilt relative to their orbits, but that's as close as you can get. And in that case all the planets will still have their axes pointed in the same direction. Question #2 - The first thing I'd suggest is to delete your Kopernicus cache. An old cache file could cause you to see the old shape of the body prior to your changes. The cache files have a .bin extension. If you haven't specified the cache location, you'll find the files somewhere inside the Kopernicus folder. Deleting the cache will just force Kopernicus to recreate it the next time you launch the game.

It could also be that you're using some other mod that's broken. If a mod, such as a planet pack, that uses Kopernicus has an error in it that prevents Kopernicus from loading it correctly, Kopernicus will display an error and will warn you not to open your saved games. So just because Koprnicus is producing the error message, there's a good chance that Kopernicus is not the problem. You may have to do some further debugging to try to isolate the cause of the error.

You're right, I forgot that it's only 1333 W/m2. I originally had it at 1360 with Nodens' orbit a little closer to Grannus. But when I decided to make GEP_Primary, I wanted Nodens' day and year to work out to some convenient number of integer hours. So I ended up fiddling with Nodens' and Belisama's semimajor axes to make Nodens' solar day exactly 90 hours and its year exactly 3 solar days. That pushed Nodens a little farther away from Grannus and lowered the solar constant. I'll make the change as well for my next update. Thanks for reminding me.

While the long days and night are a bit inconvenient, it was pretty much out of necessity. Under normal conditions, Nodens should be tidally locked to Grannus. But I didn't want a planet tidally locked to its sun, so my solution was to give Nodens a large moon. Nodens would them become tidally locked to its moon rather than its star. However, Nodens is somewhat tidally locked to Grannus in that it has a spin-orbit resonance of 4:1.

@Pleb, I didn't take it as criticism, just an observation. I agree that Nodens does look a little bleak due to the lack of greens and blues. But this is my way of trying to make it look more like it might under a red sun. I originally had it so that Grannus' light was red, but that looked horrible. It just zapped the color right out of all the planets, making everything look dull and lifeless with none of the colors that I intended. So I changed Grannus' light to white. To compensate, however, I took some of the color out of Nodens by design. For instance, instead of having blue oceans and blue sky, everything tends toward gray. I based it on the following image. Grannus' surface temperature is 3550 K, which makes Nodens' sky a very pale blue, almost gray. https://imgur.com/wkdcQKw

I actually envision Nodens as having lush vegetation in the warmer climates. The impression that it's bleak comes from a couple things. First, much of the surface lies at high elevations and/or latitudes where it's too cold to support much plant life. And, second, there are none of the familiar greens on Nodens. I did this on purpose because Grannus is a red dwarf star that radiates most of its light in the red part of the spectrum. Under those conditions plants will evolve differently than those living under a yellow sun. I've read that planets might actually have black foliage because they must absorb all wavelengths of light to get enough energy to survive. I thought black looked too weird, so I went with the lavender color. So wherever you see the lavender, that is suppose to be areas covered in vegetation.

Kopernicus by itself doesn't change anything. It's a tool that allows other mod developer to add and change planets. It should be safe to add Kopernicus, but there's no reason to do so unless you plan to add some other mod that uses it. So the question should be whether or not the other mod break your saves. The answer to that is, it depends. Some will and some won't.

Yes, it's W/m2. The real life number at Earth, called the solar constant, is ~1360, though I've seen the exact number vary a little bit depending on the source. Grannus is much dimmer than Ciro, but I've moved Nodens much closer to compensate. So Nodens and Gael have the same solar constant. Now that I think about it, if you are also playing with GPP_Secondary, I have to make a change to Ciro as well. Find the following file: GameData/GEP_Primary/GPP_Secondary.cfg And add the line "@luminosity = 44000" as shown below: @ScaledVersion { @Light { @luminosity = 44000 !IntensityCurve {} !ScaledIntensityCurve {} !IVAIntensityCurve {} ... The way it works is the "luminosity" of the home star is the solar constant at the home world. And the luminosities of other stars are in proportion to the home star. So in regular GPP, Ciro's luminosity is 1360, so the solar constant at Gael is 1360 W/m2. And the luminosity of Grannus is 42, or about 1/32nd as bright as Ciro. But in GEP_Primary/GPP_Secondary, we have to make Grannus' luminosity 1360 so that the solar constant at Nodens is 1360 W/m2. And then Ciro's luminosity becomes 44000, or about 32 times brighter than Grannus. Obviously I overlooked these changes when I set up the GEP_Primary configs. :-)

@Norcalplanner, I started playing a little bit of GEP Primary today and I discovered a bug. Solar panels are way underpowered around Nodens. To fix it, find the following file: GameData/GEP_Primary/Grannus.cfg Find the "luminosity" parameter in the config and change it to the following: luminosity = 1360 The number I had in there works for regular GEP but not GEP_Primary. I have an update planned that includes several fixes, but I'm holding off until Kopernius updates.

Apparently there's also a stock bug that causes rocket parts to be misaligned when the system is rescaled. It's my understanding that Squad is fixing it for the upcoming 1.4.5. But from what I've heard, it makes rescaled games pretty much unplayable at the moment.

I suspect it might be measuring not from where you started in relation to the planet's topography, but from your starting point in a celestial frame of reference. As you've been traveling eastward, the planet has also be rotating. So you might be halfway around the planet when measured from KSC, but since you've also been moved along by the planet's rotation, you've traveled through an arc of over 300 degrees from where you started when measured in relation to the stars. At least that's my guess. (edit) @CrashyMcCrashFace, let's see if the numbers work out. You say you've traveled 3,201,959 m, and Kerbin's circumference is 3,769,911 m. So that means you've traveled an angular distance of, 3201959 / 3769911 * 360 = 306 degrees And you say you're about halfway around the planet from where you started, so let's call your position 180 degrees east of KSC. So if you've moved 306 degrees in relation to the stars, but only 180 in relation to the planet's surface, then that means the planet has rotated 126 degrees during the time you've been flying. Since Kerbin rotates 1 degree per minute, then that means you've been flying for 126 minutes. And if you've traveled 180 degrees in relation to the surface, then that means your average ground speed has been, 3769911 * (180/360) / (126*60) = 249 m/s. Do those number sound about right? You've been flying for about 126 minutes at a speed of about 249 m/s?

Interesting that you came up with this because I had a very similar storyline in mind. I also envision Gael as the original Kerbal home world. But several generations ago there was a global catastrophe that force evacuation of the planet. Part of the population managed to reach and colonize Nodens, which became the new Kerbal home world. In the years since their arrival, Kerbals have poured all their effort into building a new home on Nodens. Thus the space technology that brought them there was lost, along with the first generation of colonists. Now, many years later, Gael has healed from whatever disaster befell it. Kerbals are now trying to build a new space program so they can eventually return to the planet of their origin.