Horn Brain

So are Rubbish and Junk.

RESOURCES. Also, more easter eggs/things to find and do in the game. Building things is fun, but when I get to a planet once, there isn't much motivation to do a similar mission again. If we had resources, at least I would have some bases to build. Maybe in career mode we can get missions like "return samples from these coordinates on Duna", and then the devs could spend extra time making those particular sites on Duna interesting places to land/walk around. That would save them having to add crazy fine detail to the entire surface of multiple planets. Maybe you should only be able to see the coordinates of the sample return locations once you've mapped the planet and sent some rovers or something as part of other, simpler missions.

Also, when you get to Moho, check the burn time and start early because you will be burning for a while. That's a long burn. I actually think that when I did it, I went around the Sun a few times and brought my aphelion down to Eve's orbit or lower before my encounter with Moho so it would be less dV.

Good luck, and I hope it works for you. One thing I'll tell you is that you don't need 8 solar panels, just 6 (even at Kerbin, unless the solar panels got nerfed since I did this an admittedly long time ago). Also, if you arrange them around the pitch or yaw axis of your spacecraft instead of the roll axis, they are easier to orient towards the Sun (because you can roll the spacecraft while maintaining a constant heading, so unless you're burning right at the Sun or away from it, you can always have nearly full exposure).

And as luck would have it, we finish discussing our grand idea just before 0.21 and subsequent vacations by the dev that would be implementing this. No way Harv saw this. Sad face. Anyway, I think we've got it worked out pretty well if we can get two bodies to orbit their barycenter properly. The one thing that remains is how do we implement this in the game? I think you would have to include a barycenter object with the mass of both bodies, then set each of the two bodies to orbit the barycenter with the ratio of their SMAs determined by the mass ratio (I think it goes a1/a2= m2/m1) with the same eccentricity. However, if that's all it was, then their periods wouldn't match up and they would be out of phase immediately (except for the case of m1=m2). This is unfortunately the pain in implementation that would make this modification so hard to do. You would have to rewrite the whole orbit determination code to handle a proper two-body problem, where objects orbit on the ends of a vector pinned at the barycenter, with the vector determined by the mechanics of the full, mutually gravitating two-body problem (the vector is the position of a satellite orbiting the barycenter which has mass m1+m2). That would be the issue. Once that was worked out, my system would be trivial to implement.

In career mode they will let you achieve missions to orbit Moho and other dV-intensive missions for very cheap (even if they do cost three mainsails, you can launch one with one big SRB, some fins, and a small tank with an LV-909 on it and get at/near Kerbin escape velocity). This will probably be a good way to earn a lot of money quickly. Right now, they are good for the same purpose. If you're sending a mission to Moho, Dres, Eeloo, or even Jool, they are super easy to get the required dV (solar panel effectiveness does not drop off as 1/r^2, so with six of the six-pane solar panels you can still use them out at Jool). You can even do Gilly sample return missions with them since they can land on Gilly. If your burn times are days-long, then you're doing it wrong. Just use the lightest probe, and use the six-pane solar panels (NOT the gigantors, those are too heavy), along with a few instruments and antennae and one tank of Xenon and one ion engine. That should be able to go anywhere in the game from LKO. Just use 4x time warp and make sure you put your solar panels on in such a way that you can face the Sun with them when doing your burns and the time should be less than five minutes for any burn that isn't ridiculous (like Moho capture). Also, make sure you can do your burns on the day side of wherever you're going.

You were saying arbitrary binaries can't be implemented without checking eccentricity, and I assumed he meant procedural generation, didn't notice you were talking about mods. That's interesting, but the modders will have to obey some rules. Even in the current system, you can already imagine a planet that has a moon that crashes into it over and over just by setting the eccentricity high enough. Certainly the current model doesn't handle THAT scenario, and yet that isn't "checked for". What you're asking of my model is to enforce common sense in everyone that uses it. I wish I had that power. As for the hand wavey-ness of my implementation, how exactly do you think the spherical SoI assumption could be hard-coded into the program? The simplest way to do it would be to just check the distance between a craft and any body that it could potentially be in the SoI of at several future times and see if it comes closer than r_SoI. In my model, you do the same thing, except there are a few extra if statements if you are within r_SoI of a barycenter object. Done. The cost of getting the distance from one point to another in 3d space (square three differences, add, and take square root) is far more than the cost of checking my rule (multiply pre-calculated mass ratio^(2/5) by one distance), so it would be a trivial performance drain. I don't think we should even worry about this, because neither of us knows what the code is actually doing. That's for any of the devs that read this to decide whether implementing this would be a nightmare or an if statement. I don't think dynamic VoIs are necessary; you can just choose to have circular orbits for the handful of bodies that use this logic, anyway. My point is only that they are simpler to implement than fixing the VoI sizes by using the average position of each body (based on the SMA), which would require calculating distances to new, special points in space, rather than just to the bodies themselves.

You can't do highly elliptic binaries with this method without dynamic VoI calculations. The inner/outer region boundary would pulsate in radius, with the VoI's inside scaling with that radius (they won't change shape, just size). That would be just using the distance from each body and my rule to determine which VoI you're in, and using the current distance between the bodies (times some potentially mass-ratio dependent factor) to set the inner/outer boundary radius. This would be highly confusing if you didn't know what you were doing, obviously. As far as having a dynamic VoI, I don't think that it would be much of a pain to code up, honestly. The current system already has to check the distance between your craft and any bodies in the same SoI at each point (or many points, rather) along your orbit to determine if you get an encounter with that body, using this system would just mean taking those distances and plugging them into my rule to see if there is a transition. One measly extra calculation. There would be weird behavior if you were going very slowly across the VoI boundary when the inner/outer radius was changing rapidly (when the bodies were closest together), but it would only be if you were going very slow and isn't any different than what happens if you're moving very slowly across SoI's in the current system.

The easy way to enforce circular/low-eccentricity orbits is to just not make binary pairs with high eccentricity. From a programming perspective, it's as simple as limiting the range of the random number that gives the eccentricity to less than 0.2 (or something like that) when the mass ratio is lower than a certain amount (say 20), which is when you would be using my system instead of the current system. Since KSP uses orbital elements to calculate on-rails bodies' trajectories, presumably the procedural generation process would be selecting random numbers for the mass ratio, primary mass, eccentricity, SMA, etc. This makes it trivial.

Someone will correct me if I'm wrong, but I think we almost certainly do not have a binary companion. If we did, it would have shown up really obviously on one of the many infrared surveys used to look for distant objects like Kuiper belt, scattered disk, etc. There is this crazy theory that we have a dim brown dwarf or possibly very small red dwarf companion star (called "Nemesis") which is responsible for what proponents claim is a periodic bombardment of the solar system by comets disturbed from their orbits in the Oort cloud. No such star has been seen in the surveys I mentioned, either. It falls in the same category as Vulcan, Planet X, and the supposed "anti-Earth" that was proposed might orbit exactly opposite the Sun from us: I call this category the Looney Bin.

I can't remember. I know I got it before 0.17 because my first mission after that came out was straight to Duna with a nuclear lander (that worked the first time and had enough fuel to return! Beginner's luck, no doubt). I remember flying through the Sun before it had an insta-kill surface around it. Does anyone know what were the main features of each update?

Yeah, that's the outer region of my model.

If you have an orbit that intersects Dres' orbit, and you want to wait out an encounter, then just set up a maneuver node to burn prograde or retrograde when you get there to change your orbital period so that the next time you come back, Dres will be there. That's the easiest way. Other than that, just try and read the interplanetary guides. You need to do a plane change to meet Dres usually, so read about that as well.

He's right. The devs probably saw "N-Body Physics" in the title of this thread (if they saw it at all) and ignored it. They've heard so much nonsense about N-body stuff I don't blame them for assuming that this thread is useless. I really want to see a double moon, though. Or at least Pluto/Charon with a lower mass ratio.

Realistically, it's much easier to just put humans in LVO and send a robotic mission to the surface with remote controls to find some samples for return. The only reason we want to put people on Mars is because we want to eventually live there, same with the Moon, potentially. No one wants to live on the surface of Venus in the remotely near future. If that's what we're doing, then I would opt for the bathysphere architecture. Build a rigid but light structure that is buoyant and just float down to the surface, using small thrusters (probably ducted fans to save propellant) for maneuvering, you could scan a reasonably large stretch of surface before you had to turn back, and potentially scoop up/drill up a sizeable sample cache. When it's time to go back, use the buoyancy to climb as high as possible, then deploy an inflatable balloon to climb even higher. Once the balloon reaches a suitable height, deploy the ascent stage with the sample cache as the sole cargo. The crew vehicle can then capture the cache and return home. I'd shape the landing legs of the bathysphere like the soles of boots so we leave bootprints too.

No system proposed can "handle" three similar-massed bodies in a realistic way. For Jool or Kerbin-Mun-Minmus, the primary (Jool or Kerbin) is large enough that even if you implemented my system it would look very much like the current system, except there would be VoI boundaries between the "inner" region and the "outer" region for each pair of bodies that essentially did nothing. That's why I think we should leave any planetary system with mass ratios above Duna/Ike levels alone and use the current system, since implementing my system there would only add extra VoI transitions which didn't act very differently at all from the current system. It would just be confusing for no reason. If (for an example of how this would work, I'm not suggesting this)you made the Mun much more massive, you could implement my system for the Kerbin-Mun pair, since Minmus would be in the outer region and would just orbit the barycenter with no difficulties. You could also (although this is probably unrealistic from a stability perspective) have smaller moons orbiting either the beefier Mun or Kerbin such that they stayed within the VoI of one or the other. Think of Minmus in low Kerbin orbit. Another hypothetical: What if we gave one of the forthcoming new gas giants a binary moon system? It could have two moons of equal mass orbiting one another very closely as their barycenter orbited the gas giant. As you approached this binary mun from orbit around the gas giant, you would first transition to the binary mun's barycenter's SoI, which would be determined exactly like the current system using the mass and semi-major axis of the binary pair's orbit about the gas giant to determine it's size. Then as you got closer, you would transition to the "inner" region of the binary and my system would be used to determine which VoI you were in. Yet another, even more wacky proposal would be to have one large body and two smaller ones - say Duna and two Ikes. If you put both Ikes in orbit around Duna separately, you could use the current system and it would be ok. But imagine placing the Ikes in a binary! Their combined mass would make the mass-ratio about 8:1 (Duna to Ike+Ike), which would be perfect for using my system. So on an incoming trajectory from interplanetary space you would enter the Duna/Ikes barycenter VoI first, then (assuming you're going to aerobrake at Duna) you enter the inner region of the Duna/Ikes system on the Duna side and you are only affected by Duna's gravity. You aerobrake to be captured but your leave your apoapsis high enough that you enter the Ikes side of the Duna/Ikes inner region and enter the VoI of the Ike/Ike barycenter object. Then, as you approach one of the Ikes, you enter its inner region and solo VoI. That would certainly be confusing, and the conic patch draw limit had better be set pretty high or it will be hard to see what's going to happen next, but it would work perfectly well in my system. So basically, you can do whatever you want with my system so long as you have at most two mutually-orbiting objects (barycenters included) in any given system which share a given order of magnitude of mass.

I love Duna by itself. Mostly because it looks like I'm really on Mars. If you include the celestial scenery, I suppose it's hard to beat Laythe or Vall.

Hard to see what the actual peak error is. Could you plot all of these as 2d contour plots with a colorbar so we can see the magnitudes more clearly? If not, maybe just upload profile views of each so we can see the peak values.

Additionally, it should be noted that none of this changes anything for any of the planets in the game (except possibly Duna and Ike, if you wanted). It will all still work exactly the same except when the player enters a binary planet system, which presumably would mean they knew what they were getting into. To be clear: You would use the current system (primary-dominant) for all systems with mass ratios above a certain value, say 15, or 50. You would only turn on this barycenter system for planetary systems like Pluto/Charon (MR= 8.12) or some exotic double moon that the devs wanted to put in orbit around one of the new gas giants.

I don't think my rule (or any reasonable rule) is going to work for more than two bodies of similar masses in a system. You could have other (smaller) bodies in the outer region orbiting the barycenter, or you could have smaller bodies orbiting close to one or the other of the two large bodies.

I got the formula from here: http://en.wikipedia.org/wiki/Sphere_of_influence_(astrodynamics) If you do the math it matches with the SoI's of the various bodies in KSP perfectly. My limiting rule is NOT what I gave in the post (I've corrected it now, but r and m were switched, my mistake). It's easiest to use it in this form: the boundary is given by r1/r2 = (m1/m2)^(2/5), where rX is the distance to body X and mX is the mass of body X. My apologies.

These figures should help. Sorry I didn't have time before. The Red area is the VoI of the large body (large cyan dot on the right). The Blue area is the VoI of the small body (smaller red dot on the left). The location of inner/outer boundary (outer region is the green) is arbitrarily chosen to be about 40% further from the secondary body than the L2 point. This is just what I picked. It turns out that matching the SoI currently used by KSP in the infinite mass ratio limit will always mean swallowing the L points, unfortunately. Choosing the L2 point to be on the boundary means that the VoI of the secondary does not become an island (it does not avoid the inner/outer boundary) until very high mass ratios (Kerbin/Mun wouldn't do it, and I think Duna/Ike is the only system where you might want to consider using this new model). Hopefully this helps you guys visualize what's going on.

To get captured doesn't mean to end up in a circular orbit. To get captured is simply to bring the apoapsis of your orbit within the SoI. If you're just trying to get captured, lower is always better. You are of course right if you add the constraint that you want to get into a roughly circular orbit. However, if you're coming in very fast, you're probably best off coming in low, slowing down to get captured at periapsis, and then adjusting your inclination out at apoapsis before settling into your final orbit anyway. Unfortunately the forum monster ate a post I did that would have been helpful in showing all this, but unless you're coming in very slow, the savings from insertion directly into a higher orbit are usually trivial when they exist at all. If your goal is to land, you should always go as low as possible when getting captured. Also, lower orbits have lower energy, it's the difference in energy between that and your flyby trajectory that is large.

I have a way to improve the hemispherical model which is quite simple (one if statement) and which actually generalizes the selection of VoI boundaries over the whole range of mass ratios between the two objects. Simply use the following rule when in the "inner region" to determine which VoI you are in: Let 1 denote a quantity pertaining to the more massive body, 2 to the lower. r is distance from spacecraft to a body (r1 or r2). m is mass of a body. The craft is in the VoI of the body with the greater quantity m^2/r^5. So the rule would be: if m1^2/r1^5 > m2^2/r2^5, then the craft is in the VoI of body 1, otherwise it is in the VoI of body 2. The form of the rule comes from the definition of SoI radius used by KSP currently: R_SOI = a (m/M)^(2/5), where R_SOI is the SoI radius, a is the semi-major axis of the secondary around the primary, m is the small mass and M is the large. If you plug in some values, you can see that for the case of m1=m2 (or m=M, equivalently), then the rule I give reduces to choosing the closer of the two bodies, and the boundary between their VoI's would be the plane equidistant between them. If you use very large mass ratios, then the SoI is a sphere centered around the secondary body with radius R_SOI. This means that in the limit of very different masses (think a planet and a star), the rule behaves the same way it currently does in KSP! The variation is smooth between the two cases (it looks like the plane curves away from the primary and translates towards the secondary until it is a small sphere completely enclosed within the "inner region"). I'm at work, but I can do some figures later. The problem is that since this relies on the distance to the two bodies, it would only work for circular orbits, otherwise the VoI boundaries would move as the distance between the bodies changed. This could be fixed by using the average position (based on the sum of the semi-major axes of the two bodies' orbits) of each body instead of its current position (at least for low eccentricity orbits, like Ike and Duna). Tell me what you think. I think this rule makes the hemispherical model the natural extension of the current system. Further, if you choose the "inner region" radius correctly, you could have craft in orbits that approximate L2 and L3 orbits for some binary planets with very similar masses.

All hail conic patch draw mode 0, the only mode that is actually useful from an orbital mechanics design point of view! Seriously, when you're doing a preliminary estimate of dV requirements, you use conic patches in the frame of reference of the locally dominant gravitational body because it lets you get information about your orbit visually: inclination, eccentricity, periapsis, turning angle, exit angle to prograde, etc. Mode 3 is pretty, and that's all it is. If I were going to write an article in popular science about my mission, I would use it. If I were going to show my supervisor my initial plans for a trajectory, I would use Mode 0.