OhioBob

I've always wanted to name a Kerbin mountain Krakentoa.

Maybe there should be an RR-lite version that just does resource allocation? And then a full version that includes all the desired features? I think the coordinates of the launch sites are hard coded. The Woomerang launch site should be located at 45.29 N, 136.11 E.

@JadeOfMaar, I have to say that I completely understand where @Snark is coming from. When Rational Resources was first added to JNSQ, I thought all it was going to do was to distribute resources in a semi-realistic way, where the abundance of certain resources depends on the type of celestial body (rock vs. ice, etc.). But it seems it has grown into much more. To be honest, I don't even understand what RR is anymore. But since I don't use any resource mods anyway, I just play without RR. I agree that the explanation at the beginning of the thread can use an update.

My inner astronomer doesn't like things like that not being correct. Something else I did in JNSQ was to make sure all the tidally locked moons have their prime meridian facing the planet. It's a little thing that most people wouldn't notice, but to me it's important. That's the way it is in the real world, so that's the way it is in JNSQ. In GPP we took a different approach with the clock. It gives the local time at KSC. So 0:00 is midnight at KSC, 3:00 is local noon, etc. Of course I would have liked to change it from reading "UT" to something like "LST" (local standard time), but we never made that work. For JNSQ I kept it universal time. At this point it's just an idea, I'm not sure I'm going to do it. But if I do implement it, the settings would be in Kronometer.cfg. The end user could edit the settings (either directly or via a MM patch), provided they know what they're doing. It's been changed. (Stock) Kerbin now has a 6-hour solar day. Sunrise and sunset should occur at the same time every day.

That's effectively the same as changing the initial rotation. It would put universal time out of sync with the solar day (unless the initial rotation were changed to compensate, and then we're right back where we started). And it would have save breaking consequences because it would change Kerbin's starting position in its orbit.

That would require offsetting all the textures, and it's too late for that. We're committed to what we currently have as far as the textures and terrain are concerned.

So am I, which is why I haven't done anything to change it. I don't like the game starting at sunset, but I'd be even more put off if 0 UT didn't occur at midnight on the prime meridian. KSC is located at 91.8 W, so when the game starts at 0 UT, it's just before sunset at KSC, as it should be. Moving KSC is not an option at this point. Maybe an alternative would be to start the game at a different time of day. For instance, if the game started at 9:00 UT on Day 1, then it would be about noon at KSC. (Or if it started at 6:00, then it would be just a few minutes before sunrise at KSC.) I'd have to study it, but I think it might be possible to change the start time using Kronometer. (edit) I think I like the idea of starting at 6:00 UT. That way the player gets treated to a nice sunrise just as the game begins, and then he has a full day of sunlight ahead of him to perform the first day's activities. I'll have to see if I can make it work. I'd have to change both the clock display and the initial rotation. It could mess with some saves, however.

As far as I know, it's just random chance. Galileo made the map, picked a good spot for KSC, and that's what it came out to. I don't like the game starting at sunset either, but I'm not fond of the options for fixing it. One option would be to offset the textures to place KSC further west, but it's too late for that (it would mess too much up). Another option would be to change the initial rotation. But if we did that, then universal time would be out of sync with the planet's rotation. Right now 0 UT occurs when it's midnight on the prime meridian (as it is in real life). Of course we could rotate the planet 90 degrees and just say that Kerbals define 0 UT as sunset on the prime meridian. (I guess there is no requirement that Kerbals do it the same way that we do.) That would make it approximately noon at KSC when the game starts.

You're welcome. I have to get back to working on that site one of these days, there's more I want to add. You can partly blame KSP for my being distracted. lol

FAR should work fine with any atmosphere. The atmosphere model just feeds temperature and pressure values to whatever aerodynamic model is being used, be it stock or be it FAR. Where FAR differs from stock is in what it does with that data.

I'll usually do that when I'm returning from an interplanetary flight. I never bother, however, for a Mun/Minmus flight. I know those are plenty safe without having to provide any extra braking. Somewhere I have a spreadsheet that I once used for planning burns like you describe. I don't remember exactly how it worked, but I'd enter information about my initial trajectory, delta-v remaining, and time of burn. It would then compute the final periapsis. That way I could figure out what initial periapsis I needed to obtain the desired final periapsis. I could then tweak the trajectory using just a few m/s when far out at the edge of the SOI. Then when I got close enough for my final burn, it was all retrograde. I didn't have to waste any delta-v burning radial out to hold periapsis. I'd just let the periapsis drop to ultimately what I wanted it to be. I've thought about polishing the spreadsheet into a more user friendly form and making it available to others, but I doubt there'd be enough demand for something like that to make it worthwhile.

I've found that for orbital reentries, a heat shield is advised, but ablator is not. As I recall, skin temperatures during an orbital reentry generally max at around 2600-2700 K (at the entry angles that I use). This is above the max temperature of a pod (~2000 K), but well below that of a heat shield (3300 K). So a heat shield is recommended just for the temperature rating. But since the temperature stays below what the shield can handle by itself, there's no need for ablator.

I really haven't figured out a good number for JNSQ yet. In stock I generally targeted a periapsis of about 20-25 km. That wasn't for control of heating or g-forces, however. The reason for that altitude was to help predict my landing site. With a periapsis of 20-25 km, my capsule would land right under the periapsis marker. So while still days away from reentry, I could check the time to periapsis, determine how much the planet was going to rotate, and predict where I was going to land. If I didn't like the looks of the terrain (mountains for instance), I could raise the periapsis and force the capsule to land long into a safer area. It should be possible to do the same thing with JNSQ, but I haven't figured out yet what the right number is. So far I've been using a periapsis of about 35 km, which seems to work pretty well as far as heat and g-forces go. Not sure how well that works for landing site prediction, however.

Extrasolar has its own configs that may not be compatible with what JNSQ is doing. Since JNSQ is not recommended for use with other planet packs, we feel no responsibility to provide support. You're going to have to figure how to make it work yourself.

That's a good question in regard to spacecraft, I don't know what would happen. There's a good chance the SOI won't overlap -- there's more to the geometry than just comparing min/max distances, and I haven't done the math. But a simple precaution is to push Valentine's semimajor axis out a little farther. Just a couple percent would assure there's no chance of overlap.

I just did some checking and the red dwarf in Extrasolar has a semimajor axis nearly twice that of Nara. But Nara is in a very eccentric orbit. I didn't check the geometry, but just based in the distances involved, it is conceivable that Nara could wander into the red dwarf's sphere on influence. (The SOI edge is 2.2659E+12 m from Kerbol, while Nara apoapsis is 2.3112E+12 m.) Since Nara is on rails, that probably doesn't matter.

JNSQ was designed with the intention that it would be used alone with no other planet packs. This is primarily because JNSQ is natively 1/4 real scale, so it will conflict in scale with anything else installed with it. That being said, there's probably no reason it wouldn't load with other planet packs installed. But since that's not our intent, no testing has been done in that regard. If you want to try Extrasolar, you'll just have to install it and see what happens. Earlier you said you wanted more clouds. Are you saying now you have no clouds? If you are getting no clouds then you've likely installed something incorrectly. This is what JNSQ's Kerbin should look like in game.

The fewer clouds are by design. We got tired of the look of the heavily clouded home worlds in EVE, SVE, GPP, and other packs. We wanted our Kerbin to look different, and allow you to see more of its surface (we like its surface too much to hide it with clouds). If you want more clouds, you'll need to replace the cloud texture with one of your own.

That's incorrect. The existing temperature and pressure curves are modified by the Atmosphere factor, but the top of the atmosphere is, New height = Original height * Atmosphere * atmoTopLayer So the top of Kerbin's atmosphere at 10x is, 70000 * 1.25 * 1.44 = 126000 meters.

I didn't know there were any anomaly associated contracts. I've never seen one of those. Is that stock?

@DMagic, I've traced the problem down to something with Rational Resources. That makes sense because Rational Resources is a resource mod, and ScanSat is a resource scanner. So there could be some configuration in Rational Resources that's causing the problem in ScanSat. Pinging @JadeOfMaar. Be advised that there is apparently some interaction between Rational Resources and ScanSat that's causing ScanSat's Color Management screen to break.

So I guess what you're telling me is that what I'm seeing shouldn't be. If that's the case, I can do some more investigation to see if I can find a cause.

@DMagic, can you explain what's up with the new Color Management screen. (1) The sliders are now in percentages rather than meters. (2) Both the current and new palettes are white. (3) No matter what I do, I can't get any changes to apply.

Please don't discuss removing the Kopernicus version lock in the JNSQ thread.

Step 1 - Select the celestial body you want to visit. Step 2 - Select what type of encounter you want when you get there, i.e. intercept (flyby), low orbit, etc. These are identified by the different types of icons at each body. Step 3 - Starting at Kerbin, follow the lines until you get to your end point, and add up all the numbers as you go. For example, let's say you want to send a probe to Duna and enter low orbit. The starting point is Kerbin and the ending point is the "low orbit" icon near Duna. Follow the lines and add up the numbers... 3400 + 950 + 130 + 10 + 250 + 360 = 5090 m/s. Note that the number 10 is printed off to the side of the main line. This is the maximum amount of plane change that might be required. It could be as little as zero, but it's probably a good precaution to add it in until you gain the experience needed to minimize it. As Aegolius explained, for the return you just follow the lines back to Kerbin in the reverse direction and add up the numbers as you go. To get from Duna orbit to an intercept with Kerbin, we add up... 360 + 250 + 130 + 10 = 750 m/s. Note that we didn't add in the last two numbers, 950 + 3400. This is because we only need an intercept with Kerbin. We can do a direct atmospheric reentry and use drag to slow down rather than propulsion. However, if you plan to enter orbit around Kerbin upon your return (rather than perform a direct reentry), then you'll require some or all of the 950 m/s (depending on how much, if any, aerobraking you do). The same is true with Mun and Minmus. Getting to Mun orbit requires, 3400 + 860 + 310 = 4570 m/s, but getting back requires only 310 m/s. To return you only need to break Mun orbit and set up an intercept with Kerbin (placing the periapsis inside Kerbin's atmosphere). Be advised that some of the numbers in the delta-v map are aggressive. You should add in a generous safety margin until you get good at it.