John Cochran

Let me guess.... You have autostruts turned on? I will say that if you can keep that thing flying and perhaps even land it, I will be extremely impressed.

What I would suggest with relays using HG-5 's is to place a little trio of them orbiting small moons and such to allow communication on the far side for probes and rovers. For the Mun, having 3 of 'em orbiting at about 250 km would allow one of them to get a signal from KSC and the rest pass the signal around to the far side of the Mun allowing for coverage everywhere except for about 30 degrees around the poles (if you deposit another three in polar orbit, then the poles also get covered completely). Same applies to Munmus. After you have that in place, you need to make Kerbin a reliable transmitter and receiver. I think that 5 relays can handle that all the time fairly cheaply. First, you want a little trio of relays in equatorial orbit capable of always seeing Kerbin and relaying the signal among themselves with 100% signal strength. Not sure if an HG-5 is capable of doing that, pretty sure that a RA-2 can handle it. The purpose of those three is so that a signal from KSC is always visible for your main relays. They are a pair of extremely powerful relays in polar orbit 90 degrees out of phase when each other. That way at least one of them is always visible either above or below Kerbin's poles. For those two relays, you're going to eventually want them to be RA-100's. Now, let's assume you wish to do a lot of research near Duna. Place one or two high powered relay(s) in the Duna system in high polar orbits. Their purpose is to pick up a signal from Kerbin. Then place a few constellations of cheap HG-5's around Duna and Ike. The result will be near complete coverage of the Duna system (unfortunately, you won't be able to communicate when the line of sight between Kerbin and Duna is blocked by the Sun). Either deal with it, or perhaps setup another relay in another system. You may even eventually setup some powerful relays in a solar orbit unassociated with any planets. The idea is to have a few powerful relays pass the signal long distances and the forward those signals to cheap constellations of lower powered local relays to handle probes, rovers, and bases. I suspect that KSP 1.2 is going to cause quite a few players to study up on resonate orbits.....

The HG-5 is rated at 5.00 Mm. The range between two antenna is the square root of the product of each antenna's rating. So When KSC is talking to an HG-5, the maximum distance is one of (100 Mm, 200 Mm, or 1.12 Gm depending upon the level of the tracking station). But when a HG-5 is talking to an HG-5 the maximum range is only 5.00 Mm or a mere 5000 km (a bit less than half the distance between Kerbin and the Mun). Looking at your image, the distance between the satellite dead center in the image and any of the other satellites revealed by the Commnet lines from KSC is significantly larger than 5000 km.

Actually, there was a plan some years back by the military about "How can we destroy all the Geosynchronous satellites quickly in case of war?" Their solution was surprisingly easy and quite scary. Launch a missile that goes to the moon and does a free return to a retrograde geosynchronous orbit (same orbital path as the rest of the geosynchronous satellites, but retrograde obviously). Once in that orbit, disperse its payload... Which would simply be a bunch of sand. None of the satellites would be likely to survive being sandblasted at twice orbit speed every 12 hours. The surprising thing was because of using a free return trajectory from the moon, the deltaV cost of such a mission was a lot lower than attempting to enter a retrograde Geosynchronous orbit directly. Another scary part is that such a launch would look like a regular scientific mission to the moon and the free return would be very likely not detected until satellites in geosync started to be destroyed. And by then, it's too late.

Nice Job. And I'll use those figures in updating mu for Kerbin in my spreadsheet. I determined the values empirically simply because I don't have what I would consider a reliable source of information for the actual parameters for G, g0, etc. The wiki has a lot of data, but doesn't bother to state what version of KSP the data is valid for, so I consider that source to be close, but unreliable if you're looking for precision. But, alas, because of that conversion to single precision floats somewhere in the chain between the persistent file and Unity, this level of precision is not going to actually be of any use. Just switching to a precisely positioned satellite is enough to cause it to be thrown into a new orbit that's several milliseconds off in its period. Although with the introduction of Commnet, I do hope that someone comes up with a new motor that's made for precise positioning. The Ant when thrust limited to 0.5 percent still packs quite a kick and it's tricky to get a period down to the millisecond unless you've deliberately made your satellite excessively heavy by using an absurdly large fuel tank. Would like to see something with a maximum thrust of about 1 to 20 newtons instead of the 2 kN that the Ant has. And of course, would like said very weak motor to be able to thrust limited down to 0.5 percent for when you're getting really nit picky.

Another method of doing an efficient launch to orbit. Take off vertically and when you get to a velocity of about 100 m/s, tilt over about 10 degrees. Then go into prograde hold on you SAS. Now pay close attention to hold long it is until you reach apoapsis. What you want is to adjust your throttle to keep the time 'til apoapsis at 40 seconds. If it's less than 40 seconds and climbing, just keep your throttle where it is. If it's less than 40 seconds and dropping, increase your throttle. If you're already at max throttle, nose up a bit until it start climbing, gradually drop the nose until you're going prograde again. If you're going prograde and the time 'til apoapsis is greater than 40, reduce your throttle. WARNING: Performing this procedure manually is extremely tedious. It's quite efficient, but also quite tedious. Also you may need to apply more throttle when you're about 40km to get above 50 km before overheating your vehicle too much and exploding. The ideal launch will cause your vehicle to almost, but not quite explode from overheating. The mod GravityTurn performs this kind of launch and you can find the thread on it within this forum. I'm rather surprised that the mod isn't on curse.

Actually you don't need the value of either G or M. What you really want is the product of G and M. Why am I making that distinction? Because in real life, we know the product far more accurately than we know either G or M. For instance, Earth's standard gravitational parameter is 398600.4418 plus or minus 0.0008 km^2/s^2 which is accurate to about 1 part in 500000000. But we only know G to within about 1 part in 7000. And because of the uncertainty in knowing G, we also only know the mass of the earth to within 1 part in 7000.

Nice guide, however you may wish to mention that when you're using a single carrier to insert multiple relays equally spaced, it's perfectly valid to have the carrier craft with an orbital period of (1-1/N) time the desired period of the relays or a period of (1+1/N). The (1-1/N) is for when the carrier takes a faster, lower orbit and inserts each relay at apoapsis. The (1+1/N) period is for inserting the relays at periapsis instead. Nice thing is the the circularization burn the relays have to do is lower if they're dropped off at periapsis with the carrier taking the higher orbit. For instance, dropping off three relays into Munar orbit at 250km altitude can be done with the carrier having an orbit with a periapsis/apoapsis of 36,829km/250km with insertion happening at apoapsis and a prograde burn of 64.5 m/s to circularize. It can also be done with a periapsis/apoapsis of 250km/440.272km with insertion happening at periapsis and a retrograde burn of 31.9 m/s to circularize. In pretty much every case you can imagine, it's better to insert at periapsis to both reduce the circularization burn deltaV and to prevent inadvertent lithobraking. About the only case I can think of where insertion at apoapsis is when the desired orbit is close to the SOI of the body being orbited. In that single case, periapsis insertion would result in the carrier vehicle going outside the SOI so it couldn't perform its job, so apoapsis insertion is the only feasible choice.

The OP is quite right about keeping things precise, but he missed one of the MAJOR issues that cause satellites to drift out of alignment. 1.2 just got out of open beta and I had heard that G and a few other constants changed and I wanted to update my orbit calculation spreadsheet with the new numbers, so I decided to figure them out empirically by using the cheat menu placing a satellite into orbit with a specified SMA and by monitoring KerbalEngineer, see if it's drifting east or west, then adjusting the SMA up or down until I simultaneously determined both the exact SMA for a stationary satellite and the sidereal rotational period for the body I was orbiting. The answer is "Yes, the mu values for the various bodies have changed a bit." For my final test, I inserted into orbit around the eight bodies who's synchronous orbit is within the SOI. I then took note of the longitude each satellite was above and finally did a time warp a year or two into the future. Then looked at the longitudes that the satellites were are and was rather dismayed that they had drifted several minutes of arc when they hadn't even drifted 1 second of arc while I was determining the original numbers. So I looked closer at the figures and was rather unpleasantly surprised and extremely annoyed. The Satellite I left in a synchronous orbit of Eeloo with a semi-major axis of exactly 893589.151 meters and a period of exactly 5h 24m 20.000s had somehow changed to a semi-major axis of 893590.076 meters and a period of 5h 24m 20.030s. That little error of 0.030 seconds will cause quite a bit of drift over time. The SMA I set wouldn't even drift by a second of arc over a several game decades, but the new SMA drifts by 2 seconds of arc every orbit or a bit under 16 minutes of arc per Kerbin year. Since the SMA I set and the SMA I saw when I came back to the satellite after switching to the tracking center only match to 6 digits of precision, I suspect that there's a conversion from double precision to single precision somewhere in the chain of calculations going between the Unity game engine and the persistent save file. And that loss of precision makes it absolutely impossible to setup a precise constellation of satellites. I also did some tests with save file editing and have noticed that the figures for an orbit of a satellite don't change in the save file unless you actually get within physics simulation distance of that satellite. When that happens, the figures lose their precision and things start drifting again. So it is possible to setup stable constellations by save file editing. Just never make those satellites the active craft or get within physics distance of those satellites. For those who are interested, the stationary SMAfor a Kerbin satellite is 3462940.708 meters and Kerbin's sidereal rotational period is 5h 59m 9.434 seconds (figured correct for KSP version 1.2.0.1586). To replicate my experiment, use the cheat menu to place a satellite into Eeloo orbit with a SMA of exactly 893589.151 meters. After doing that, while keeping that satellite the active vehicle, perform a time warp of a decade or two to see that it doesn't drift (Use KER to observe the latitude of the satellite). After confirming the lack of drift, go back to the tracking center at KSC and then switch back to the satellite orbiting Eeloo. You'll see that the SMA and period have changed and if you time warp, the satellite will now start drifting quite noticeably.

Indeed, they are annoying. Just performed a mission around the Mun to setup three relay satellites at 250 km altitude. Got 'em almost perfectly spaced (period of all three are showing the same time down to the millisecond and that time is only 1 millisecond away from my desired period. As mentioned, an almost perfect mission. Only 1 problem.... On the circularization burn for the last relay, my satellite had a too close encounter with one of the stage separator (had two of the darn things floating around right in front of my bus from the previous relays) from the previously inserted relay that destroyed one of its solar panels. Thankfully, the relay had more than enough panels so I can still use it. Have decided that on future relay insertions I won't deploy the solar panels until after I've performed the circularization burn for the relay. After all, they have plenty of battery capacity and ought to last long enough for a mere 30 to 100 m/s burn.

If you don't like the suicide burn landing that MechJeb performs, then actually specify a target instead of "Land Anywhere". The "Land Anywhere" option performs a suicide burn. When you actually specify a target and have MechJeb land at that target, MechJeb targets for 500 meters above the actual target, does a lot of futzing around getting everything "just right", then lands vertically from that location. Although during the futzing around stage, the orientation can be a bit disturbing (sideways, inverted, etc). A quick tap on :"Abort" followed by "Land Anywhere" stops the futzing and causes MechJeb to land immediately.

I don't remember seeing arrows on the version of 1.2pre I was last playing, but the rules for fuel flow are the highest numbered priority drains first. If there are multiple tanks with the same priority, then they all drain symmetrically. Given the priority number you stated, sounds like things are working as planned. I will admit to being a bit confused by the arrows however.

I'd suggest three satellites with good relay antenna. Place them in an orbit spaced 120 degrees apart about 80,000 kilometers from Kerbin. Doing that will cause the far sides of Mun and Minmus to be covered by the satellites. For those rare situations where the Mun occludes Minmus, they also cover Minmus. And since they're outside the orbital radius of Minmus, at least one of them is always visible outside of the Kerbin SOI. So if Kerbin is visible, the dishes at KSC serve. For those situations where Kerbin is occluded, the three satellites provide a backup. About the only thing not served is perhaps the poles of the Mun and Minmus. But I suspect even those would be covered if the orbit of the three relays is inclined. (don't want to incline too much however, or you'll lose coverage of the far side of Minmus from time to time. The when you go interplanetary, drop off two more extremely capable relays in Kerbin's orbit. One leading Kerbin by 120 degrees and the other trailing by 120 degrees. That ought to then cover the entire Kerbol system.

That would kinda work, however there's still the struts. The issue isn't one of "I can't do this" since obviously, I can. But rather, "this symmetry mode makes building things easier". And since the symmetry modes at their very foundation is to make building things more convenient, I mention this as a possible addition. Also I kinda lied about how those fins and struts are constructed, I actually attach both fins to get what I want and then attach both struts. But's it's still a matter of attaching two things when I ought to be able to just make one attachment and be done with it.

I know you've mentioned the various tutorials on rendezvous, but for good measure you really can't beat Scott Manley. So take a look at this video for an example on how to do it. https://www.youtube.com/watch?v=8kJ-z0t_CY0

I frequently build a simple rocket that uses two radially attached boosters and on those boosters, I attach some stabilization fins. I don't put the fins on the central booster since by the time the outer boosters are detached, the atmosphere is so thin that the fins no longer provide directional control and they're simply dead weight that ought to be jettisoned along with the boosters. The rocket is like this: http://i.imgur.com/hemO5VC.png However, placing the fins and the struts to brace those boosters is somewhat annoying and a "mirrored radial" symmetry mode would make both easier and faster. Looking at the base of the rocket under construction, I have to place the reinforcing struts and fins twice to get what I desire. Using 2 way radial symmetry, I place a strut and fin to get this: http://i.imgur.com/Mr4xgI7.png And I then manually attach another strut and fin to get the final rocket resulting in this: http://i.imgur.com/AbaJZtt.png I imagine that a "mirrored radial" symmetry mode would be defined as a normal radial symmetry to handle the 2,3,4,6,8 way symmetry and then mirror each attached item using bilateral symmetry on the attached parent object. Would be quite useful for adding struts to those radially attached objects as well as fins and other objects that you want to have symmetrically attached to substructures radially attached to a central parent.

First question I'd ask is what version of KSP are you using and what version was Scott Manley using for the tutorial? The wheels in 1.1.x are rather ... fragile compared to earlier versions of KSP. Assuming my old eyes are up to the task, I believe Scott Manley's tutorial is using version 1.0.0 where the wheels aren't nearly so fragile.

Just to make the point on how long you would have to wait for the proper Jool intercept. Assuming that you always want the same phase angle for a transfer from Kerbin to Jool, then you'll have a window for Jool approximately every 1.096 Kerbin years. Now assuming that you are willing to accept a 5 degree error on the intercept, that means you need a possible intercept every 10 degrees (that will get you with 5 degrees worse case since you can accept the intercept either in front of or behind the desired point. Worse case is if both possible intercepts have exactly 5 degree errors). So running the calculations, you have a wait of anywhere between 0 and 69 years to get the desired intercept. The largest angular distance between adjacent possible intercepts is 8.9 degrees for a worse case of 4.45 degrees. The average error from the best case of the 63 potential intercepts is 1.73 degrees. So if you go the Jool intercept to use gravity to swing into a polar orbit for the rescue, you'll have a good window sometime within the next 69 Kerbin years. When I don't know, but I will tell you that between adjacent intercepts Jool will advance on average 34.71 degrees each time (won't be exactly that amount since Jool's orbit is a bit eccentric. I'd probably suggest going with one of Snark's options unless you're really patient.

I generally like this idea, however the game would have to actually run physics on the debris or otherwise take into account that the orbit intersects the atmosphere. Can't tell you the number of times I've had a kerbal perform reentry and perform the last stage separation just before hitting atmosphere. Result? One crew module landed on the ground and some debris in an atmosphere intersecting orbit that never decays. If the debris aren't destroyed before getting about 2.5 kilometers away from the manned craft, then the physics engine stops modeling them and they stay in a nice stable orbit forever. When that happens, I'm left with two choices, either destroy them from the tracking station, or "fly them" by selecting them from the tracking station and simply wait, and wait, and wait some more while the physics engine actually has their orbit decay until they impact the ground.

Ouch. I think that would be a rather difficult feature to have GT perform. Reason is that GT doesn't "predict" what the flight path is going to look like, it instead dynamically adjusts the throttle to make an optimal flight path. About the only way I can see getting this feature is to take note of the phase angle to the target at launch and then go through the entire launch and note the phase angle between the target and the AP of the flight. Then revert the flight back to the launch and use the phase angle of the previous launch and target to adjust the phase angle of the new launch by time warping. So you'll have to wait for *two* launches of GT to get the intercept you really want. And given how slow a GT launch is, do you really want to wait for it twice? And those phase angle calculations assume that the target is in a circular orbit.

I do believe that you're going to have lots and lots of fun with that rescue, even if you had MechJeb. I would agree that Jool would be a good place to start. The most efficient method would be to have a Jool interception when Jool is at the AN/DN for its orbit and the station's orbit. Getting the timing correct for that interception is gonna be tricky, but if you do, then before entering Jool SOI, make an adjustment burn so you go over the appropriate pole of Jool to get deflected into an orbit with approximately the same orbital plane as the research station. Then make the same adjustments as you would normally do (match planes, hohmann maneuver, etc). But to be entirely truthful, it just may be easier to brute force the plane change (after all, getting deflected into a polar orbit by Jool isn't all that useful if the resulting orbit is 90 degree out of plane of the research station. Hence the tricky timing consideration). I trust you're using a nuke or other high ISP engine for this rescue? After all once you're actually in orbit, absolute thrust doesn't matter too much, and ISP is the major player.

I know that I'm fairly late to this thread, but the issue with your rocket flipping is that your center of gravity is getting behind your center of pressure. Combine that with the rather shallow ascent and this is happening when there's still significant aerodynamic forces acting upon the rocket. With a steeper accent, the atmosphere gets so thin that you have negligible aerodynamic forces acting upon your rocket by the time the CG shifts behind the CP and so your rocket remains "stable". For 1.1.3 and earlier version of KSP, this situation is made worse by having the fuel burn from the front towards the rear causing the CG to move aft during accent. One way of mitigating this if you're using asparagus staging is to have the fuel transfer pipe connected to the top of the earlier staging so that fuel is being pulled from both the top (because of the engine attached to that stage) and the bottom (because of fuel being drawn from that stage to feed the other engines in use. For 1.2 and above, the problem is mitigated by the fuel priority tweak. I would suggest that when designing your rocket, have both the CG and CP visible and see if the CG remains forward of the CP as you empty the fuel tanks in the order that they would be emptied in flight. You don't need to worry about the CG and CP relationship however, if that stage is only used in vacuum.