Claw

Yeah, I tend to agree. You'll have to look at the orbital energies. I have been thinking of a simplistic equation, but you probably have to start with the energy equations and simplify to what you want for your script. What maccollo said in that last post.

Here's the long answer: http://en.wikipedia.org/wiki/Orbital_resonance The short answer is that a resonant orbit is some multiple of each other. So if you had Satellite A in a 6 hour orbit, a 1/2 resonant orbit for Satellite B would be 3 hours. Satellite B makes 2 orbits for every 1 orbit of Satellite A. What I think Taki is saying is to use an elliptical resonant orbit to deploy your satellites. Put your satellite launcher in a resonant orbit of your 750km orbit. Release Sat A at apoapsis and burn it to circularize. When your satellite launcher does 1 orbit, your Sat A will be on the other side of the 750km orbit, thereby allowing you to launch the second (opposite) satellite as you requested. If you sent up a launcher that had all 8 of your satellites, you could set up a 1:8 resonant orbit with your launcher and release a satellite every time it reaches apoapsis. They would all be spaced 1/8th of an orbit apart. The real trick with orbital networks in this game is that the satellites will drift. You need to work really hard to get the orbital periods (the time it takes to do a full orbit) as close to the same time as possible for all of your satellites. I mean get them within 1 second if possible. Many people use ION engines or RCS to do that. Orbital period is more important than getting matching AP/PEs. If you do it right, you can get the orbital period within a fraction of a second and you won't have to touch your satellites for a couple months.

If you're launching fuel from the Mun, it will obviously cost you more dV to get it up there than launching it from Minmus. However, that wouldn't effect your interplanetary craft directly. 100 m/s is a rough guide and it'll probably be slightly more of a difference than that. The exact amount will depend on how low in orbit your refuling station is for Minmus/Mun, etc. But for the most part, you get most of the dV benefits with much fewer drawbacks when using the Mun compared to Minmus. Consider that it's only about 70 m/s more to get to Minmus than Mun (from LKO). You'll also have to burn a bit more dV to escape Mun and do your Kerbin pass than you would to escape Minmus for your Kerbin pass, but the Mun also doesn't require an inclination change. In my opinion, the real savings is that it's a lot easier to align your departure window from Mun, which will save you dV on the interplanetary burn. I'm sure someone could do all the exact math, but to me the ease of coming from Mun outweighs the small dV benefit from Minmus.

Oh thanks. Good luck on the finals!

Yes it's cheaper, but oh so much more painful... You'll need Minmus nearly "in front" of Kerbin in relations to Kerbin's orbit around the sun. You'll actually want to drop a bit before that, but you may need to play with the exact placement to give you the best angle toward Jool. To compensate for the inclination, you can try to adjust your aim at Kerbin (on the inward leg) and let gravity sling you around a bit straighter. You should also be presented with a chance along the way to adjust the inclination, where your craft is passing through Kerbin's equatorial plane. Assuming the AN/DN nodes happen away from LKO, the dV to adjust the plane should be pretty small. I think you already covered the major headaches. Also realize that it takes several days dropping in from Minmus to get to Kerbin. You'll need to factor that in to your decision on "when to go" to meet your Jool window. Personally, I think you'd be better off periodically hauling that fuel to Munar orbit. Dealing with starting your inward journey from the Mun is a lot easier than from Minmus, for all the reasons you're asking, and the difference in dV between the two is only around 100 m/s. The windows occur more often, and the inward journey is only a few hours long, instead of days. Although there are some people who don't mind dropping in from Minmus.

While your question may get addressed in here, your best bet for a quick answer about mods will be to post on the mod's specific thread. Or in here: http://forum.kerbalspaceprogram.com/forums/13-Add-on-Requests-and-Support Here is a thread that is tracking most mod updates: http://forum.kerbalspaceprogram.com/threads/74457-ARM-Pack-0-23-5-Mod-Compatibility-Thread Also, I think you double posted.

While your question may get addressed in here, your best bet for a quick answer about mods will be to post on the mod's specific thread. Or in here: http://forum.kerbalspaceprogram.com/forums/13-Add-on-Requests-and-Support

Awesome thread!! I went through every post in this tread because it's so awesome. I don't know if this technique is worthy but I didn't exactly see it. Hopefully someone finds it useful. Larger Station Modules So I wanted larger station modules and the new large parts gave me a way to do that. Unfortunately, the large parts don't have a corresponding gigantic docking port so I made some modules that neck down to a Sr Port size. The core of the module is a girder segment for strength and can be adjusted to suit the desired length of the module. The outside can be pretty much anything you want for labs, habitats, or whatever. I threw MechJeb on there so you can see the weights/part counts. By adjusting symmetry and depth placement, you can create quite a variety of looks. The module's core modular girders provide the structural support, so the external components don't have to carry the load. This makes the modules strong but also customizable. By the way, you can also flip the ADTP-2-3 over and clip into it for other interesting effects. That works well if you are connecting one of these modules to a size 3 part.

No sweat. You are far from the first person to lose a kerbal in deep space. I had my first experience by warping through Kerbin's atmosphere during an aerobrake which flung my pod and command module interstellar. After a year in orbit, I managed to return him but the poor guy died when he reentered Kerbin at a ridiculous speed, resulting in parachute failure...

You still have to have enough dV to "catch up" to the craft dipping into the atmosphere. I would also guess that chances are that craft will be traveling faster than the typical circular orbit speed because it would need to be in an elliptical orbit in order to ensure escape from the atmosphere. So while you would need less dV to get up to orbit, you would need more dV to catch up to the mothership's orbital speed. You could conceivably have a ship in a close orbit, but outside of the atmosphere. The lander could take off and rendezvous at the top of it's parabolic launch. The ship in orbit could slow down to catch the lander, grab on, then accelerate away back into orbit. I'm not sure how much this would "save" you in total, but I suppose you could set it up so that your lander needs less mass to escape from the surface.

You can use multiple pods if you want to return more than one sample from each location. It sounds like you figured that much out with the rest of this post. What I will also say is be aware that in v0.23.5 there is a bug that occurs when you decouple multiple manned pods at the same time. If you were to separate all four pods, say at the last minute, then the game will not allow you to quicksave/quickload/revert/recover or return to the space center. You would have to land them all together, or separate them one at a time.

There's not an easy way to do so in the VAB/SPH with stock KSP. You can, however, launch it and go to the map. In the map there is an icon on the right side. Click on that and you can find out the ship's mass.

Thanks Pecan. That would be excellent. All updated info is good info. I've done quite a few experiments, but quite frankly they're relatively uninteresting. I'm still deciding how best to show any examples that are useful beyond simply illustrating the point.

Hmm. I will have to think about this a bit. I'm certain there's a simpler equation you can use. It might be as simple as V = Vescape + dV for all speed in excess of Vescape, but there's a bit more to it than that.

Also, if we're just talking theoretical and discount KSP's inability (as stated in the OP), all of the Lagrange points would be effected by the existance of Minmus in the Kerbin-Mun system. The Lagrange points in the wiki are built off a two body system with a dominant main body and the secondary body (as well as the satellite that sits in L-points, but it is negligible.) If you throw Minmus into there, all the points would be effected and some of them might be even less stable than they already are. L4 and L5 would probably shrink to relatively small areas, if they would even exist because Minmus would tend to pull objects out and drag them forward in orbit. L5 objects would be thrown into Mun and L4 objects would be deflected into a higher orbit.

Are you trying to calculate it for an arbitrary point along the orbit? Or at the PE?

If you're dealing with the orbital energy, then you might be able to back calculate the dV required using the Oberth equations. You should be able to calculate the escape velocity, then figure out how much excess energy you have. The Oberth equations should allow you to figure out the dV required at PE burn to cancel that out.

You know, I've never even looked to see if the stars are constant. Have you verified that much? It's possible that they're generated during game launch. Although as I'm typing this, I sort of recall seeing seams in the starfield. I don't know if that's because it's using textures, or just that it's repeating a procedurally driven sky.

Would what be possible? n-body? I'm not versed on Unity, but I don't see why not. Internal to KSP it was a matter of choosing how to implement physics, and Squad chose SOIs. I don't know how easy that is to override (in a similar fashion to FAR overriding stock aerodynmaics). Although I suspect a lot of fidelity will be lost in the floating point errors. KSP is pretty hard on the CPU already, so I don't know how much worse doing n-body would be... I would say it's not a matter of being "lazy." Spheres of Influence is considered a valid form of simplification for orbital mechanics. It works pretty well in most cases. Lagrange points is one big failure. Also, craft won't experience orbital tides. But then again, it's just a game and it probably isn't the extra physics load to elongate a craft's orbit ever so slightly. (Especially when my cooling fans run at full speed constantly already...)

I just did a happy dance inside.

Since the basics have been covered, I'm going to go out on a limb and say it is all Bob's fault to begin with. He's not as much of a whiner as Bill, but sometimes he forgets and leaves things on. Especially that pesky SAS when parked on a hill. So sometimes the module spends all it's precious electricity while sitting stationary on the slope. So while that may not help Bob out in his current predicament, perhaps he can take that knowledge forward and turn SAS off after landing unless it's really needed to keep from sliding off a steep hill. (I'm not sure if you did leave SAS on after you landed, but it will drain your battery pretty fast on the ground.)

Unfortunately you can't hotkey the data windows (not that I have found anyway). For just about every piece of science equipment, about all you can hotkey is turning it on, taking the data, resetting it. And oddly enough you don't really need to turn them on (toggle displays, etc) in order to "take data." But in case you didn't know, you can right click on the modules and review the data. If the data is gone (collected or transmitted) then there won't be any data to review.

The best you can do to simulate Lagrange points in KSP is with L4 and L5. If you put a craft just in front (or just behind) the smaller body's SOI and put it in the same orbit at the same speed, it will sort of act like an L4/L5 point. Unfortunately it isn't "stable" and you'll still have to station keep. From there, you can simply bump the craft's orbit out slightly (if in L4) or in slightly (if in L5) and you can enter the smaller body's SOI. This will allow gravity slingshots but that's about it. I believe someone is working on an n-body plugin.

Glad you got it fixed. You can edit the first post, then click "Go Advanced." There is a dropdown where you can mark it as answered, then save.

Unfortunately action groups suck if you have several science parts set up with symmetry. Realize if you use the action group, all the symmetric copies will also take readings. You can reject the duplicates if you want. Then if you use the action group again, only the experiments that are "ready" will run. It will not automatically overwrite your previously saved readings unless you have an action group set up to "reset" them all. If you're not using symmetry (i.e. only have one of each type of experiment on board), then action groups work great.