OHara

Looks like you are on the right track. This looks similar to the Molniya orbit shown on the Principia front-page (link) as seen in an Earth-centered Earth-fixed reference frame, which is one of the plotting options that Principia provides. The Sun appearing to orbit the Earth in your image makes it clear that the plots are made in a rotating frame, so inclined orbits will look strange.

4096 in what units? If it is m/s of delta-V you can use one of the planning-tool webpages (link) to find the right time to make the most efficient transfer. It is no fun to copy the 'transfer details' onto console (nor is it on PC) so you aim to make the transfer orbit look like a Hohmann transfer that reaches Kerbin parallel to Kerbin's orbit, as the @ManEatingApedrew above. You need to leave when Pol is about 16° before it is between Joon and the Sun (the link above says 90°+16°=106° to the retrograde direction of Jool's orbit) on whichever orbit of Pol is closest to the your chosen best transfer-date from the planning-tool. Then aiming so you leave in the forward direction of Pol's orbit gives you most advantage from Pol's speed, and should get you close to the desired Hohmann transfer. You will surely need a correcting maneuver while still far from the Sun, to reach Kerbin parallel to Kerbin's orbit and low enough to aerobrake. The tool says it takes 1260m/s of delta-V to leave an orbit around Jool near Pol's orbital altitude. You will probably need more to correct for Pol's inclination, and various other reasons, but that might leave you 2800m/s to slow down at Kerbin You can use a gravity assist from Tylo to leave Jool (at the same time and in the same direction as you would have left from Pol). Then you have more fuel for slowing down enough to aerobrake. And, Tylo gravity assists are fun. The Kerbin-Kerbin-Kerbin . . . pattern of gravity assists can slow you down relative to the Sun, but as you noticed you keep returning to Kerbin at the same speed relative to Kerbin, just at different angles each time, which doesn't help.

The word 'Dot' in KSP parameters means the cosine of the angle between the vectors, so I interpreted Physics.cfg as commNetDotForBlackoutMin = −0.866 = cosine 150° // between velocity and link direction for comms to start blacking out from plasma commNetDotForBlackoutMax = −0.5 = cosine 120° // between velocity and link direction for full blackout multiplier Then 180° minus those angles give the smaller angles between the link and retrograde. The word 'Dot' for cosine only makes sense if you have leaned the names of the vector-math operations, because the cosine of the angle between vectors a and b is a·b /|a| /|b| involving the 'dot-product'. I don't know how blackout works. I just assumed some things based on those //-comments and the behaviour requested in the original thread. I assume for any communication links further forward than 60° from retrograde get the maximum blackout effect, because then the 'Dot' would be more than 'commnetDotForBlackoutMax'

Maybe your relay was in just the correct spot, when you hit Jool's atmosphere. The original request for the plasma effect mentioned how the US Space Shuttle worked around it with the Tracking and Data Relay Satellite System. There are parameters like 'commNetDotForBlackoutMin' in Physics.cfg with comments that indicate the plasma effect fades away for communications directed between 30° and 60° of retrograde, and has no effect at all if the link is within 30° of retrograde to the craft.

You might be thinking of Venus. Venus rotates backwards, and conventionally we consider 'north' there to point roughly the same way as Earth's north. So the sun rises in the West on Venus. We just say Venus has a negative rotation speed so we can use familiar direction. RSS has Venus rotate backwards as well, so you would want heading 270° if you are one of the very few people able to attempt a return from Venus in RSS. For Eve, heading 90° helps, a little.

That is a forward gravity assist in your image. KSP shows your orbit relative to the Mun, around the Mun in its current location. KSP just shifts your orbit relative to the Mun to the current Mon position, with no rotation. When you reach the Mun at the bottom of your image, your closest approach Pe to the Mun will be to the left of the Mun. So, the Mun moving 500m/s or so to the right pulls you along with it and gives a forward gravity assist. KSP offers other modes for drawing these partial orbits, in the in-game settings options. Most are the obvious choices, but the last one 'dynamic' makes no physical sense. The default 'local to body' is the most useful, once you get used to the idea that the body will have moved before you reach it. The wiki on free-return trajectory is just saying that when you exit the Mun's influence you want to be falling nearly straight at Kerbin -- so they mean you need small 'angular velocity' around Kerbin which is probably obvious; I don't see the point of bringing it up right there. That means that as you leave the Mun you need to be going left relative to the Mun at nearly its 500m/s orbital velocity. If you meet the Mun at the bottom of the KSP map-screen, then, your orbit relative to the Mun will look like an upright very flat 'V' shape, with the Pe directly below the Mun. I find the free-return rather tricky to get in KSP.

Could you give us an example of your numbers? What Snark says about scale height varying is true, but I did not think it would vary that much. For example, suppose p_70 = 100 kPa on the runway at 70 m above sea level p_770 = 90 kPa flying at 770 m above sea level I don't know exactly the value of p0 in the formula, but I can divide it out 90 kPa = p0 exp[−770/H] 100kPa = p0 exp[−70/H] 0.9 = exp[−700/H] H = −700m ÷ log(0.9) = 6600 m

This would be a very interesting mod to write for KSP-1, or KSP-2. At first it makes me think of 'Lambert's problem' to find the orbit joining the maneuver node to the desired destination-point (the problem the transfer-window finders solve, including probably HerbaruSan's). But, the interactive dragging might work better with an iterative solver, making a incremental changes on the maneuver node to chase the desired point on the post-maneuver orbit. I guess we want a three-axis (six-handle) gizmo for the dragged point on the orbit. At first I thought you wouldn't need to drag along the orbit, but once you start dragging, the orbit changes shape, and the gizmo would rotate enough that we would probably want to slide along the adjusted orbit and then drag again. So I am imagining a constrained optimizer, with five free adjustments: prograde, radial, and normal components of the burn, time of the maneuver, and time of arrival. The dragged 3D point gives three constraints. The remaining two degrees of freedom allow a choice of what to minimize -- delta-V being the obvious choice. Adjusting the time of the maneuver is usually free, so maybe let that time vary freely. I'll boldly guess that two steepest-descent steps will be good enough, for each incremental drag of the destination in the UI. I'm assuming the routine finds and caches the Jacobian matrix of changes to the destination upon selection of the maneuver node. We would usually expect that the time when we reach the dragged point changes as we drag the point, so maybe we don't care about the precise time we reach the desired point. On the other hand, if we are doing a rendez-vous or encountering a planet, we have to get to the point at the same time as our target does. Having two modes of operation starts to complicate the UI. Maybe constraining the arrival time when you drag along the target orbit, leaving it free when you drag the orbit, would work? Experimentation would probably give surprises.

I think that what you see is just an unwanted consequence of how KSP divides the part into coarse chunks in order tracks the heat (link). I see similar behaviour in version 1.3.1, except that the service bay was bigger back then so it feels the heat. The slightly-sticking-out part has exposed area about 1% the area of the heat shield, so it gets about 1% of the 'convection flux' which makes sense (70kW being about 1% of 7800kW in my image). That heat warms just 1% the thermal mass of the skin (1% of 54kJ/K being 0.5kJ/K in my image) so that bit of skin heats up about 70/0.5 = 140 K/second. The skin can dump heat to the internals, but not fast enough. In effect, that 1% of the skin experiences very close to the heating you would see if all of that part's skin were facing the shock-compressed atmosphere. You can cheat the system by wiggling around a little. Then the fraction of skin exposed goes up briefly, tricking KSP into spreading the heat over a larger thermal mass. I think that effect is why nobody has noticed during the past five years in enough detail to report a bug. The simulation of heat that came with KSP 1.0 is in many ways just detailed enough to be mysterious.

No, not the same problem as version 1.8 had with the Terrier engine. The dimensions of the (base of the) fairing are correct in PartDatabase.cfg You can use alt-F12 debug options to show the temperatures in KSP thermal simulation, if you are so interested. The debug output is not completely self-explanatory, but there are people on the forum who have figured it out. KSP keeps track of the temperature of the exposed portion of the skin, and the conduction of heat from the skin to the insides is quite slow. So it does not matter much what fraction of skin is exposed; the exposed portion of skin can fail with little help from the rest of the part. It still seems strange that the exposed skin on those tanks survived better than the exposed skin on the fairing. To figure out why, I think you would have to look at the debug numbers.

It is not just you. My fairings also sometimes destroy my solar panels, when I build the fairing close to the payload. (I never considered it a bug, since the now-free fairing pieces really could hit other parts.) I started leaving more room inside the fairing. Other people use the 'confetti' style of deployment. I'll try the time-warp suggestion.

I have intended to get back to my RSS save, after struggling to land on the Moon, but never have gotten beyond that point. Everything takes much longer. Acceleration to orbital velocity with tolerable g-forces takes 3× as long as stock KSP. In theory I can time-accelerate, but in practice I do not, probably because everything is more difficult so I have to fly more carefully. I'm not saying I'm against this, though. I am not completely sure what your suggestion is. leverage (as verb, chiefly US, slang, business) To use; to exploit; to manipulate in order to take full advantage (of something). The modders who made RSS/RO did take full advantage of the modifiability of KSP1. RSS/RO also includes a lot of significant additions--- such as engines for a real-scale system as opposed to Kerbal scale. Players of KSP1 have been suggesting to incorporate the configurability provided by Kopernicus, some of the physics-based aerodynamics of FAR, etc., into KSP2. I've even suggested to remove reaction wheels. These suggestions would give more tech to 'leverage' for a real-scale version. But, if you mean 'leverage' in the business sense, the smaller number of potential customers will need to offer a few hundred $US per copy to make the business case.

That "Show Vessel Labels" option controls whether the box is visible at first -- F4 always works, for me, to toggle the box visibility. If you are 100m away, and had yellow markers until the EVA, that is the situation @paul_c explained above. You have to somehow re-target your goal from the point of view of the Kerbal, to get the yellow box. To me, that part of KSP a frustrating. If you drift 200m away, then at least KSP will show the magenta box.

Somebody saw a similar symptom here https://forum.kerbalspaceprogram.com/index.php?/topic/181384-* and https://bugs.kerbalspaceprogram.com/issues/20934 That time it was because of sentinel probes, but maybe their workaround will work for you: letting KSP run at 1× speed (no time-warp) gradually reduced the number. (Or, if you are good with programmable text-editor, you can remove all the VESSEL blocks for spaceObjects from your *.sfs file) Year 187 is a large 'UT' measured in seconds, so I can imagine you found a bug with the expiration clock the KSP puts on these undiscovered asteroids. [Edit: I noticed your flight has lasted 187 years, so I suppose your calendar time could very well be year 233, which is 231 seconds, which would be the largest number of seconds in the common-size integer in a computer, which opens the door to programming bugs.]

Four satellites in Draim's irregular tetrahedron are in a 90-kB KSP save-file here (link) This seems to be the closest one can have to a stable tetrahedron, changing shape somewhat as it tumbles, but staying reasonably non-flat. I sized the orbits to be Kerbo-synchronous --- which is low enough that from some places on Kerbin all satellites lie below the horizon sometimes --- because that case is interesting to watch. {Edit: the minimum dimension for the four satellites' orbits that keeps all of Kerbin covered is SMA = 4381634 ]

I hope the original poster has been happy to tolerate this deviation from his original question: "are lower or higher starting orbits better for interplanetary trips?" The answer: lower is better . . . unless you have the option to refuel in orbit, in which case Zhetaan points out that the 'gate orbit' is the ideal altitude for your asteroid or other refueling station. To be quantitative, the specific energy (energy-per-mass) of a craft, in orbit at distance r from central body with mass M, is v²/2 − GM/r. This energy is negative for bound orbits. The trick with gravity assists is to bounce off an assisting body that has orbital velocity vassister. Suppose we approach the assisting body with relative speed vrel, measured when the assister's gravity has not affected the crafts velocity, so in KSP when the craft is barely inside the assister's SOI. It happens to be true that the interaction with the assister only changes the direction of vrel, so after the assist the craft has velocity around the central body v = vassister + vrel using bold-face to indicate the sum of vectors. So the idea is that the full potential of the assist is had when the relative velocity of the craft vrel is in the same direction as the orbital velocity vasssister, and that full potential is to reach a specific energy (vassister + vrel)²/r − GM/r in the case where the magnitude of the sum of the parallel vectors is the sum of the speeds. For the case of Kerbin assists as in Kerbin-Eve-Kerbin-Kerbin-to-Jool, the gravitational parameter GM of the Sun can be found in the wiki, but maybe a more intuitive way to understand the size of GM is to use another fact from Newtonian gravity: for circular orbits v² happens to equal GM/r, so for the sun GM = (vassister)² rassister= (9285 m/s)² 13600 Mm, figured from parameters of Kerbin's orbit. This way it is easy to see how gravity assists, if we can approach the assisting body with relative speed comparable to its 9285m/s orbital speed, have the potential to give us a v² big enough that v²/2 can overcome −GM/r --- enough to escape the system. For an example, the craft might exit Kerbin's SOI at 2500m/s relative to Kerbin. (A burn of 1800m/s in low-kerbin orbit would give this speed at SOI-exit.) Depending on the direction of that SOI exit, the specific energy in orbit of the Sun is between ( vassister − vrel)²/2 − GM/r = (9285−2500)²/2 − ((9285 m/s)² 13600 Mm)/13600 Mm = − 63'190'000 m²/s² for a retrograde exit, and ( vassister + vrel)²/2 − GM/r = (9285+2500)²/2 − ((9285 m/s)² 13600 Mm)/13600 Mm = − 16'768'000 m²/s² for a prograde exit An orbit with semi-major axis a has specific energy −GM/(2a), so the energies above correspond to orbits with 2a = 18550 Mm, one end at Kerbin 13600Mm the other at 4950Mm just below Moho, and 2a = 69920 Mm, one end at Kerbin 13600Mm the other at 56300Mm not quite at Jool. The idea discussed above is that repeated encounters with Kerbin alone will have the same 2500m/s speed on each entry into Kerbin's SOI, so the potential for final orbits around the sun is between the bounds above.

Got it. That can be true while it is also true that "when you leave Mun with a certain velocity, you'll encounter Mun with that same velocity". When encountering the Mun from a near-stationary apo-Kerb we enter the Mun's SOI at 325m/s and leave at 325m/s in a different direction. After a months orbit we enter the Mun's SOI again with the same 325m/s speed and direction as we left it with, and let its gravity bend our path again. Often we can combine those two small bends into one big bend. Sometimes the surface gravity of the assisting body isn't enough to bend our path in one pass. Sometimes we don't want to spend the extra m/s to adjust our first encounter.

That seems like a very safe assumption. When the craft's elliptical orbit returns to the same point, it has the same velocity, because orbits under central gravity are periodic. The same holds for Kerbin, so I expect the same relative velocity. (There are two intersections, and if both orbits were significantly elliptical you could leave one intersection and then re-encounter the other, but that opportunity does not come up often.) Substituting Kerbin->Mun, I would expect if your craft leaves Mun with some speed, and does no burns, the next encounter will have the same relative velocity. Given that, I need help to understand the intended message in the image: It looks like the elliptical purple orbit leaves the Mun and re-encounters it at the same point on the Mun's orbit. The Mun is in a slightly different position on the second encounter, so the craft goes much deeper into the Mun's SOI, has a higher speed at Mun-periapsis, and gets a much larger assist on the second encounter. Is that the point? Usually, you can plan how close to fly-by to choose the strength of the first assist. The exception is what you mentioned above, "when you can't bend your trajectory all the way around with just one assist." The image could be an illustration of that exception, simply choosing to stay far from the Mun on the first assist. For its use in planning gravity assists, the expectation "you come back with the speed you left" still seems to hold.

The algebra for this case is not too bad. The algebra didn't inspire any intuition for me, but maybe somebody else is inspired. (Extending it to figure the relative velocity of the satellites was almost inspiring to me.) If the relative inclination of the orbits is I, and the angular coordinate of A along its orbit is υ, then in the coordinate system with the orbit of A in the x/y plane, then position of A : R (cos(υ) sin(υ), 0) position of B: R cos(υ+Φ) (1, 0, 0) + R sin(υ+Φ) (0, cos(I), sin(I)) and after some algebra the distance between them is |A − B| = R sqrt[ 2 − 2 cos(υ) cos(υ+Φ) − 2 cos(I) sin(υ) sin(υ+Φ)] after more algebra |A − B| = R sqrt[ 2 − 2 cos(Φ) + (1 − cos(I)) (2 cos(Φ) sin²(υ) + sin(Φ) sin(2υ)) ] The distance varies, as the angle υ increases with time, unless cos(I) = 1 This case is easier for my intuition. When the satellites cross the equator, they are 2R sin15° apart. When they simultaneously reach their highest latitude of 45°, they are closer, 2R cos45° sin15° apart. In this case I can imagine the inclination varying from 45° up to 90°, and at 90° inclination it is easy to see how they meet over the pole.

Today was National Cat Day

If we also suppose the configuration of satellites is stable, meaning the distance between any pair of satellites is constant, then each satellite moves in a circle around a common axis of rotation. . . . because motion of a rigid assembly of points always consists of a common translation, plus rotation about an axis. I'm sure there's some convincing formal proof of this in some kinematics textbook, but right now I can't think of a convincing argument -- it is too deep in my instinctive assumptions about how things move. That's why I thought immediately of the axis of rotation -- not necessarily any axis of symmetry of the arrangement of satellites, but some axis. Then for a tetrahedron it was obvious to me that not all those circles could be centered on the center of gravity.

Well, the title of the thread indicates interest in a "stable tetrahedron" Of course independent satellites (that is, with no 6-Mm rods holding them in place relative to each other) will not stay in such a shape, unless they are all in a single plane. I think the question is "why not?" (maybe more Science and Spaceflight than Gameplay) The stable, rigid, shape would rotate about some axis, so each satellite needs a force to accelerate it toward that axis. Gravity pulls to the center of the orbited body, not along the closest direction to the desired rotation axis, so the tetrahedron collapses.

Hotlinking to an image hosted at kerbalspaceprogram.com https://bugs.kerbalspaceprogram.com/attachments/55504/hatch.jpg Hotlinking to an image hosted elsewhere :

There is a recent bug (link) where, if you use the EVA selection on the portraits of the Kerbals, you get that message. But if you put your mouse over the hatch itself, click there, and select EVA, the Kerbal can exit. http://bugs.kerbalspaceprogram.com/attachments/55504/hatch.jpg

That is a bug that appeared recently with version 1.11.1. Many of us here play an older version when new bugs annoy us. I think that all the places who sell KSP make earlier versions available, The bug tracker has reports, but no good work-around https://bugs.kerbalspaceprogram.com/issues/27162 https://bugs.kerbalspaceprogram.com/issues/27166 https://bugs.kerbalspaceprogram.com/issues/27169