OhioBob

This mod has not been updated to support the new scatterer. There is no timetable for when it will.

This mod doesn't support 1.11.

Transfer Window Planner should work fine for rescaled systems. As I understand it, nothing is hardcoded into it. All the orbital elements are read from game, so it will perform its calculations based on whatever those elements are, whether modified or not. It should also work with planet packs that add or delete celestial bodies.

If you installed Realistic Atmospheres via CKAN, I don't know how it works. So I recommend downloading the .zip file if you haven't already done so. Inside the download you'll find a folder named "Optional", inside of which you'll find a file named DeleteTyloAtmo.cfg. Just copy that file into the GameData/RealisticAtmospheres folder of your KSP installation.

Realistic Atmospheres includes an optional config that deletes Tylo's atmosphere if you don't want it.

@PocketBrotector As you say, the last group of parameters are all obtainable from the configs, and they are exact values. Most of the other stuff is derived, as follows: gravParameter (m3/s2) = geeASL * 9.80665 * radius^2 mass (kg) = gravParameter / 6.67408E-11 orbital period (s) = 2 * pi * SQRT( semiMajorAxis^3 / gravParameter [primary body] ) Rotation periods are unchanged except for tidally locked bodies (where rotation period equals the orbital period), or if specifically changed in GEP_forJNSQ.cfg. If there's anything else you need, please ask.

I don't recall Hox changing specifically, but I do know that several planets and moons were redone as GPP evolved. It certainly appears that the screenshot from the Wiki is an outdated early version of the planet. What you see in game is what Hox is now suppose to look like. The only thing you could possibly do is go back and download the oldest version of GPP you can find replace all of Hox's configs and textures with he old ones, but I don't recommend that. GPP is pretty complex there's no telling how reverting to old files could mess things up. If you start modifying GPP, expect no technical support from us.

What's different about it in the Wiki versus the game? Is it the light level that you're referring to? If so, you can remove the following file: GameData/GPP/GPP_Configs/SunCurve.cfg That should make the light level the same across all planets with no drop off in intensity.

I don't know. You can try it and see what happens.

What are you using to compute your sine and cosine? Pocket calculators usually take angles in degrees, but something like Excel requires angles to be in radians. So if you're using a spreadsheet, you might have to convert the angles from degrees to radians. In Excel you'd have to write that equation like this, =COS(RADIANS(0.0575))*COS(RADIANS(-91.805))

To enter the coordinates into the formulae I gave you, it is necessary to convert to decimal degrees. The conversion is, decimal degrees = degrees + (minutes / 60) + (seconds / 3600) The answer is positive if north latitude or east longitude, and negative if south latitude or west longitude. For example, say the coordinates from KER are: latitude: 0o 03' 27" N longitude: 91o 48' 18" W We convert to decimal degrees (note that longitude is west, therefore negative): latitude = 0 + 3/60 + 27/3600 = 0.0575 degrees longitude = - ( 91 + 48/60 + 18/3600 ) = -91.805 degrees We now compute the X, Y and Z values: X = COS(0.0575) * COS(-91.805) = -0.0314979665Y = SIN(0.0575) = 0.001003564151Z = COS(0.0575) * SIN(-91.805) = -0.9995033121 Therefore, this object should be the one in Kerbin's config having the following position vector: repositionRadial = -0.0314979665, 0.001003564151, -0.9995033121 Your computed values and those in the config won't match exactly because you were likely not be at the exact center of the object when you recorded the position, nor are seconds an adequately precise measurement, but the error should be small. It should be close enough to figure out which object in the config is the one you're trying to locate. (Note that the coordinates I used in this example are just made up and do not represent any actual object.)

You can drive out to the palm trees that you want to remove and note the latitude and longitude. From that you can compute the position vector using the following: X = COS(latitude) * COS(longitude) Y = SIN(latitude) Z = COS(latitude) * SIN(longitude) You can then find that palm tree in the config as its "repositionRadial" will equal the X, Y, Z values computed above. (Note that latitude is positive N and negative S, and longitude is positive E and negative W.)

By "thicker" do you mean taller or denser? While the JNSQ atmospheres are taller, they aren't any more dense than stock. But in either case, that's not the reason why JNSQ is more challenging from a reentry heat standpoint. The thing about JNSQ that increases the heating are the higher velocities. For instance, Kerbin escape velocity in stock is about 3.4 km/s, while in JNSQ it's 5.6 km/s.

Running out of ablator is really not a big problem. I run out all the time. All that ablator does is lower the temperature of the heat shield. When the ablator runs out, the temperature will increase. But as long as the increased temperature stays below the 3300 K maximum of the heat shield, you'll be fine. We just need the ablator to last long enough to get us through the most critical part of reentry.

@ble210 and @eberkain, something definitely looks glitchy there to me. In neither case did KER ever show the critical part as that which exploded. I don't think it's a JNSQ problem.

I haven't had that problem playing with normal settings. I usually set my periapsis at around 25-30 km, but the results would be about the same at 35 km. I typically use full ablator the first time, then if I have some left over I'll reduce it for the next trip. Have you increased the heating difficult settings, or are perhaps using a mod that affects heat?

That doesn't sound right. Grannus' periapsis is suppose to be 1,200 gigameters. That's about 13 times Eeloo's distance in stock, and about twice Plock's distance.

JNSQ is complete as far as the number of bodes is concerned. There could be some further changes, however. For instance, we'd like to update some of the biome maps. If or when it happens I have no idea.

You can add a patch to delete them. This ought to do it... @Kopernicus:AFTER[OPM] { !Body[Urlum] {} !Body[Polta] {} !Body[Priax] {} !Body[Wal] {} !Body[Tal] {} !Body[Neidon] {} !Body[Thatmo] {} !Body[Nissee] {} !Body[Plock] {} !Body[Karen] {} } It's also possible to change the light so that it reaches farther.

Obviously at some point we will need to remove MyRocksAreBiggerThanYours from JNSQ and other planet packs that use it. But in the meantime, will having both MyRocksAreBiggerThanYours and the latest Kopernicus (1.9.1-14 or BE) installed at the same time cause any problems? If so, we may need to put out a notice instructing players to delete it.

You just have to add more keys/values. You can make the curve do whatever you want it to do. I don't know what else to tell you unless you give me some specific example of the issue you are dealing with. And linuxgurugamer is correct, I never saw your post. If you want to get someone's attention you need to ping them so they get a notification. Just type @ followed by the person name.

The only place to look up the numbers is in the configs. However, to make it easy I list them below (altitudes are in meters). The space threshold is simply 1/2 the body radius, except for the three potatoroid moons, where it's 1/2*R+5000. The flying threshold follows a more complex formula that's based on aerodynamic conditions. Flying Altitude Space Altitude Threshold Threshold Sun 500,000 3,000,000,000 Moho n/a 325,000 Eve 27,000 1,025,000 Gilly n/a 20,000 Kerbin 21,000 800,000 Mun n/a 200,000 Minmus n/a 80,000 Duna 10,000 400,000 Ike n/a 105,000 Edna n/a 130,000 Dak n/a 15,000 Dres n/a 180,000 Jool 285,000 7,000,000 Laythe 23,000 550,000 Vall n/a 275,000 Tylo 11,000 450,000 Bop n/a 95,000 Pol n/a 65,000 Lindor 230,000 4,000,000 Krel n/a 75,000 Aden n/a 150,000 Huygen 75,000 335,000 Riga 10,000 375,000 Talos n/a 250,000 Eeloo 10,000 300,000 Celes n/a 100,000 Tam n/a 10,000 Hammek n/a 225,000 Nara 85,000 1,800,000 Amos n/a 160,000 Enon n/a 350,000 Prax n/a 55,000

I've never found it to be a problem, nor has anyone else reported it as an issue. An 100 km equatorial orbit around Kerbin should place a satellite in darkness for about 18 minutes in JNSQ and a little under 11 minutes in stock. I certainly don't see that as anything excessive or unmanageable. Players have also been using up-scaled solar systems for years and I've never heard this described as a problem before. You can certainly patch batteries yourself if you feel it necessary, but I see no need to do so for JNSQ.

I don't recall where I read it, but that's my understanding as well. It's now built into Kopernicus.