OhioBob

I don't think I've ever entered into an orbit on a return from anywhere. I've always just done a direct reentry. The method I described works just as well for predicting the landing site for a return from deep space. Only in that case there's much less control over where the vessel is going to land (for instance, we can't loiter in munar orbit waiting for a better landing site to rotate into position). On a return from deep space I'm just trying to avoid landing on a steep mountainside that will result in somebody dying. If the landing site looks dicey, then I do what @bewing suggested and just raise or lower the periapsis to change the range over which the vessel will travel during reentry. Lowering the periapsis will cause the vessel to land short of the prediction, but with limited effect (generally can't shorten up the range by a whole lot). Raising the periapsis is more effective, causing the vessel to land long. It is even possible to produce a "skip" and land a good distance downrange of the initial periapsis. However, both raising and lowering the periapsis too much can have undesirable consequences. Coming in low means higher peak temperatures and g-forces. If the critical part spikes above it's max temperature, kaboom. On the other hand, coming in high means the vessel will soak up more total heat because it spends more time skimming through the upper atmosphere at high speed. This results in the vessel burning off more ablator.

Yeah, that's way too high. You're not going to get much aerobraking at all at that height. I ran a bunch of Jool aerocapture tests and I found that the ideal periapsis altitude varied between about 145 km and 170 km, depending on the circumstances (velocity and BC) and desired outcome (apoapsis).

I've just been playing around with the numbers. Based on your vessel's current orbit (semimajor axis = -96,707.733 km), I compute that's its velocity when crossing Laythe's orbit will be 4,869 m/s. And it looks like it's crossing the orbit at roughly 90 degrees. Laythe's orbital velocity is 3,224 m/s. If they cross at right angles, then the relative velocity is SQRT(48692+32242) = 5,840 m/s. In this scenario the excess hyperbolic velocity is equal to the relative velocity. I also guesstimated the ballistic coefficient by taking a inflatable heat shield and putting fuel tanks behind it until I got something with the same weight and roughly the same shape as your vessel. I then hyperedited it to space and ran it through Kerbin's atmosphere at high Mach with the Aero GUI window open. The BC varied, but it was around 1,700 kg/m2 and the time of greatest aerodynamic deceleration. Not a really accurate number but hopefully in the ballpark. Based on those numbers, I'm guessing you need a periapsis of about 34-35 km. Of course there's a lot of uncertainty in these numbers. You should definitely quicksave first. I'm also not clear on whether you're trying to aerocapture into Laythe orbit, or are you just using Laythe to aerocapture into Jool orbit. You need to shed more velocity for the former than you do the latter. I just hope your vessel can maintain stability. The test vessel that I slapped together wanted to flip around when I got deep in the atmosphere.

The method I described does have one potentially big drawback. If it happens to be nighttime where the periapsis is, then we can't see the terrain beneath it. When that happens I just try to estimate the position of the antipode and work it out from that.

I did a bunch of simulations to estimate aerocapture periapsis, but that won't be much help unless we can obtain more data. My numbers are a function of hyperbolic excess velocity and ballistic coefficient. Right now we don't know either of those. I would suggest initially setting your Laythe periapsis to about 35 km. Right after you pass into Laythe's sphere of influence, pause and make a note of the vessel's altitude and velocity. From that we can compute hyperbolic excess velocity. That will give us an indication of how fast you're coming in. The faster you're going, the lower you'll have to set the periapsis in order to achieve a capture. The ballistic coefficient we may just have to take a guess at. If you had known ahead of time, you could have opened the game's Aero GUI and read the BC as you passed through Jool's atmosphere.

What I do for a return from Mun or Minmus is to set the periapsis at Kerbin at about 22-24 km. At that height I find that I usually land at a point that is just about directly beneath the periapsis. Of course it depends on the aerodynamic characteristics of the reentry vehicle, but if we're using anything like a Mk1-2 command pod, we'll be pretty close. After setting up the maneuver node for the transfer back to Kerbin, I check the time to periapsis. Let's say the time to periapsis is 1 day, 1 hour, 45 minutes. Although we expect to land directly beneath the current periapsis, the terrain beneath the periapsis at the time of landing is not what it is now. We have to take into account Kerbin's rotation. In one day Kerbin will return to its exact current position, so we can ignore the number days. What is important is the hours and minutes, because that represents how much Kerbin will change from current. In this example we have 1:45, or 105 minutes. Kerbin rotates one degree per minute, so in 105 minutes it will rotate 105 degrees. Therefore the landing site is going to be 105 degrees west of the spot that is currently beneath the periapsis. You can estimate the 105 degrees by eyeballing it, or you can use a map like that below. The white vertical lines are spaced 15 minutes (15 degrees) apart, with the longer lines being 1 hour (60 degrees) apart. Just find the current spot under the periapsis and move the appropriate distance to the left to find the predicted landing site. The time to periapsis that you read with the maneuver node may not be the same as you get after completing the burn (there's always going to be some error). Therefore it pays to double check the landing site after you've completed the burn to make sure it hasn't change by a lot. If you don't like the looks of the predicted landing site, then just delay performing the transfer burn for a later orbit. Let's say you're orbiting Mun once every 45 minutes. That means waiting one orbit to perform the burn will shift the landing site about 45 degrees to the west. This way you can plan ahead and schedule the burn for the time that will place the landing site right where you want it.

Altitude at Jool or at Laythe?

I don't know exactly what you're trying to do, but I do know that many diagrams showing the pressure profile of gas giants are plotted as temperature vs. log(pressure). You can do that using my spreadsheet if you want. You would just have to produce the temperature profile as a function of log(P) rather than as a function of altitude. That will allow you to use the spreadsheet to generate the model. However, temperatureCurve doesn't take logs, so you can't use that temperature profile in your planet config. For temperatureCurve you'll have to produce a curve as a function of altitude. You can extract the points for temperatureCurve from the spreadsheet using the same method that I describe for producing pressureCurve. Pressure is a logarithmic function too, but we just approximate it using a float curve. You can also use my spreadsheets that automate most of the work for you:

My craziest "I can't believe that actually worked" moment was a couple years ago as part of a tiny rocket challenge. My goal was to build a rocket out of 0.625-m parts and land it on Minmus using nothing but the bare essentials. It didn't have landing gear so my plan was to do a quick touch and go, i.e. touch the ground just enough to satisfy the challenge, and then liftoff before the thing toppled over. To my surprise the rocket was quite stable and stood upright on its engine after landing. That's when I noticed that I still had a considerable amount of delta-v remaining. I thought, what the heck, let's see if I can fly it back to Kerbin. Since I hadn't planned for that, it had neither a heat shield nor a parachute. If I could just get the probe core back in one piece, I'd consider it a success. Getting it back to Minmus orbit was a snap. Immediately after performing the ejection burn to put me on a trajectory back to Kerbin, I noticed that I messed up big time. The landing on Kerbin was going to occur in the middle of the night. I didn't think that through very well, but this entire extended mission was being performed off the cuff so there were bound to be hiccups. I was determined not to revert, so I was just going to have to live with the consequences of my blunder. The next big hurdle was reentry. There wasn't anything I could do but sweat it out and hope my vessel didn't overheat and explode. Without a heat shield I knew it was going to be a close call. As I watched the temperature rise I thought for sure I was a goner, but somehow my luck held. The vessel got to within just a few degrees of critical temperature, but thankfully it started to cool just in the nick of time. That was really close! I lost my solar panels but everything else survived. I was now plummeting toward the ground in total darkness. I couldn't see a thing! All I had to go by were instruments. As if this weren't already a white knuckle situation, I looked at KER and it told me I was landing in a mountain biome. I frantically started scribbling some calculations. I needed to figure out when to fire the engines in order to null my velocity by the time I reached the ground. I knew gravity and TWR, and I guesstimated velocity, so I was able to ballpark engine start time as a function of height above terrain. The estimate was crude and correct timing would be difficult. Couple that with the fact that I had no idea what the terrain looked like, and this was going to be a miracle if it worked. I just kept my eye on KER's height above terrain readout. When I reached the right altitude, I hit the throttle and prayed. I don't know how fast I was going when I hit the ground, but there was an explosion. I had no idea what just happened, but miraculously part of my vessel was still intact and under control. It eventually settled onto the ground and came to a stop. I would have to wait until sunrise to assess the situation because I was still in total darkness. When sunlight finally arrived I could see that I blew off the bottom half of the rocket (engine and 3/4ths of the fuel tanks). But the uppermost fuel tank, battery pack, probe core, and nose cone survived. Survival of the probe core was enough to declare this a successful recovery. So many things could have gone disastrously wrong with this mission, but somehow they didn't. I don't know if it was more skill or luck, but at least on this one occasion it worked.

It looks to me like we have a vessel currently at an altitude (above terrain) of 83,413.2 km moving toward an apoapsis of 90,887.7 km. The blue orbit line passes through apoapsis and then moves toward periapsis (-450 km), where the vessel will impact Kerbin. Despite the inevitable encounter with Kerbin, the orbit line continues on the other side and moves toward an encounter with one of the moons (hard to tell which one). The vessel passes through the moon's sphere-of-influence (brown orbit line), and exists to have a new orbit (purple line) with a second apoapsis. The problem, however, is that the vessel is currently just inside Kerbin SOI, while the apoapsis is outside the SOI. The blue orbit line should show the vessel leaving Kerbin's SOI just past the its current position. We should not be able to see an elliptical orbit around Kerbin having an apoapsis higher than Kerbin's SOI. Also the indicated speeds are all messed up (82.74 m/s vertical and 24,483.56 m/s vertical). I did a quick calculation of what the vessel's speed should be and came up with 83.6 m/s total. Something is definitely glitchy here.

8 GB will run GPP if you don't use the visual mods. I had only 8 GB until just recently. I was able to play GPP just fine provided I didn't install EVE and scatterer. EVE particularly killed my performance to the point the game was unplayable. If you want to play GPP + EVE, you should definitely increase your RAM. I'm now at 32 GB, but I've heard 16 GB is enough (perhaps somebody else can verify that).

A glitch. Weird things happen sometimes. I wouldn't worry about a one time freak occurrence.

Yes, but the numbers used range 0-1 rather than 0-255.

To those asking about the compatibility of this mod with other mods... To the best of my knowledge, Realistic Atmospheres should be compatible with just about everything. Realistic Atmospheres is pretty benign in what is does, and I can think of no mods with which it would conflict. So if you want to give it a try, just go right ahead; you should be OK. But if you do have a problem, please report it to me. Realistic Atmosphere modifies the atmospheres of the stock planets only, so clearly it won't work with planet packs that delete the stock planets. That would be the only caveat.

It sounds like you are trying to get rid of the stock sunflare, which is the bright light seen emanating from the sun when viewed from a distance. When you add a scatterer sunflare, that doesn't disable the stock one. To do that you have to change the sun's sunLensFlareColor to 0,0,0,0, which will make the stock sunflare invisible. Just install Kopernicus and add the following config somewhere inside your GameData folder. That should do it. @Kopernicus:NEEDS[scatterer] { @Body:HAS[@Template:HAS[#name[Sun]]] { %ScaledVersion { %Light { %sunLensFlareColor = 0,0,0,0 } } } }

GPP is calibrated to be dead-on balls accurate.

Here's another way of doing it, which might be easier in some cases. If you know the synchronous orbit, which is often documented, then you can compute the semi-synchronous orbit thus, Semi-synchronous altitude = 0.629960525 * (synchronous orbit altitude + body radius) - body radius The numerical factor comes courtesy of Johannes Kepler, who figured out that Period2 is proportional to Distance3. Therefore, Dsemi-synchronous / Dsynchronous = (Psemi-synchronous / Psynchronous)2/3 = (0.5)2/3 = 0.629960525

I appreciate you saying that. I'm always happy to share whatever little tidbits of knowledge I've gained over the years. It also helps being retired, I've got plenty of time on my hands.

Yep, that's normal. Every planet has what is called a synodic period, which is the time between successive conjunctions of the planet with the sun. The synodic period is also the time between successive launch windows. The synodic periods for the stock planets are: Moho - 135 days Eve - 680 days Duna - 910 days Dres - 527 days Jool - 467 days Eeloo - 453 days This is the same reason why NASA launches missions to Mars about once every two years.

@AG5BPilot's explanation is correct. All the rotation periods that you see in the Tracking Station are the sidereal periods. This is the time is takes a body to rotate 360 degrees on its axis in relation to the stars. Gael's solar day, i.e. the time that it takes the sun to return to the same meridian in the sky, is exactly 6 hours. There is always one more sidereal day in a year than there are solar days. Gael's year is exactly 426 solar days, or 427 sidereal days. Since it's solar day is 6 hours, or 21600 seconds, it's sidereal day is, 426 * 21600 / 427 = 21549.4145 seconds = 5h 59m 9.4145s The value of the rotationPeriod parameter in Gael's config is different than it is for all the other bodies, so that may be causing some confusion. For every body but Gael, the value of rotationPeriod is the sidereal period, but for Gael it is the length of the solar day. This is either because (1) Gael uses a Kerbin template, or (2) Gael is defined as the home world. I haven't figured out which of those two is the governing factor, but rotationPeriod is hardcoded differently when we have a Kerbin/homeworld planet. This is because for the home world we are more interested in the length of the solar day (as this is what clocks and calendars use). So rather than having to do some math to figure out what the sidereal period must be to produce a specific solar day, somebody just coded it so the value entered is the solar day, from which the sidereal period is calculated.** ** This wasn't always the case. There was a time when Kerbin had a 6-hour sidereal period, which gave it a solar day a little over 6 hours. This made the solar day out of sync with the game clock/calendar. Squad realized their mistake an fixed it, but I don't remember which version it was.

@Sigma88, it appears Kronometer isn't working with version 1.3.1. I've got GPP installed with Galileo's 2.5x SD config, which should give me 10-hour days, but I'm getting 6-hours days in the game. If you need logs I'll provide them.

OK, so it sounds like you're probably going to want to go the RSS/RO route. That's not my thing, so the RSS/RO guys are going to have to help you. We're getting out of my comfort zone.

I have no idea. I've never played at 6.4x and I've never used DRE. As far as I know, no adjustment is made - you just need to budget in more ablator. I suggest you ask that question in the KScale64 or RSS threads, where the participants likely have more experience playing at those larger scales.

Depends on what you mean by real. Several people have suggested RSS (Real Solar System), but that replaces all the stock planets with our real life solar system (Earth, etc.) at real life scale. Is that what you mean? Or do you want to keep the stock planets and just make them more realistic? Also by "real" do you mean you want to make the celestial bodies feel more realistic, or do you want your rockets and spacecraft to be more realistic? For instance, are you more interested in a visual makeover of the planets, or are you looking for rocket parts that more closely resemble real life, or perhaps both? Do you like the scaled down size of the stock system, or do you want to play at real scale? Or do you want to play at a scale that feels more lifelike but still uses stock-sized parts? For us to give you a proper answer, you really need to explain better what it is you are trying to achieve. For instance, if you want to keep the stock planets, then you can ignore all the responses about RSS. You need to help us focus our responses on the right thing so we can point you in the right direction.

I generally don't have more than two or three missions going on at the same time, and I always try to schedule them so I'm not juggling concurrent activities. I think there has only been one or two times when I've had two vessels that required user input within minutes of each other.* In most cases I've been lucky enough to have at least a day or more between events. * This doesn't include rendezvous and docking where the vessels are within physics range of each other.