Chocki

I almost feel the same way, but I got formulas, and understood most of it. I am at least headed in the right direction. That, and I'm awsome at plug and chug math.

I need to figure out 2 orbits to deploy 4 com sats. The main orbit should be a high Mun equatorial orbit, the second should have an Ap equal to the main orbit, but be a quater of the main orbits orbital period. The point is to allow me to deploy a sat, and circulaize at Ap, leaving the deploy vehicle to make 1 orbit and be ready to deploy the next sat at a 90 degree angle to the first. 4 orbits, would mean a 4 sats equally spaced along the main orbit. My question is how would I go about figuring out what orbits would work, without using trial and error. I know the orbital period needs to be a 1/4 ratio (deploy orbit / final) but I am lost as to what figures, equations I would need.

If it is in Kerbin SOI, you will need to target a satellite, only once you change to Minmus SOI will the targeting Minmus work.

A pic should be enough. I think I would be done if it wasn't for me not wanting to strand a Kerbal on the mun to attach hoses.

I have never understood the super vocal anti MJ group. If this was some type of mmorpg, I could understand the complaints. MJ would be akin to many early WoW mods that reduced playing a class to mash 1 button. But this is a sandbox game. You play it for what you enjoy. I know my piloting skills suck, so I let MJ do the accents, and long (ion) burns. I even use the maneuver planner, and editor to adjust the node. It doesn't cheapen the game for me. My game is can I get x done by designing y ship to do it. I still have to deal with all the basics, fuel, power, balance. I do give credit to those that fly, as they have a skill I can't seem to master.

I am a builder. I have spent the last 3 days designing, testing, scrapping, redesigning a 3 vehicle setup to mine kethene and send it to an orbiting converter. All done via remote (no kerbals). I am currently stuck trying to figure out a way to transfer resources from a ground based miner to a lander storage vehicle. Lazer systems would work, but feels "cheaty" to me. Docking ports are problematic considering uneven terrain. I started to try the lazer robotic arms, but they cause a huge unbalanced effect once in orbit. Next up for testing is combo of KAS and damned robotics to see if I can make a simple arm to drop an attachment point onto another attached to the lander.

I like that the team seems to be getting into it, writing Bobs whole narrative. Just awsome. They do need to be told that Jeb is the default crazy test pilot.

Starting it from a circular orbit helps, but if you time the launch right you can go for straight rendezvous. Just be aware of the processes MJ will use. If you are off on the launch, it may try to plan a phasing orbit. I haven't tried using the timed launch, with a direct autopilot to rendezvous to dock. Theoretically, it should work. The target being in a circular orbit helps, but again is not needed. You just won't have as many transfer windows available, but time warp solves that.

I wasn't bitching about the actual responses. The repeated correction of an already pointed out spelling error, no matter the possible cause is what I was referring to. The responses I got that where more then "I think it's xxx" I am very greatful for, espically maltesh's.

You guys are worse then reddit. Hohmann is autocorrected to Hofmann on my phone, deal with it. Bi-elliptic isn't considered a word according to old Android systems. I figured that converting to KSP measurements and physics would kill any benefit gained. So, in reality (game wise) any type of bi-ellpictic transfer just isn't woth it, either by timing or the small savings in delta v.

Anything but Kerbsomething. Isn't it confusing enough with Kerbal, Kerbin, Kerbol? How about plain old Galaxy K.

I was reading up on diffrent orbital maneuvers when I saw bi- elliptical. Basically, it is rasing your Ap to a point higher then your target orbit at Pe. Then burning at new Ap to raise Pe to target orbit, and then burning (retrograde) to lower your Ap to target orbit. At times, this is more efficient then a direct Hofmann transfer (when the ratio of final semi major axis to initial semi major axis is 11.94 or greater according to wiki). The reason it is more efficient is because of the Oberth effect (rockets function better the faster they are moving). So, I wanted to apply this to some basic things in game. Like setting an orbit close to the mun for escape or mun encounter. According to wiki Mun has a semi major axis (SMA from now on) of 12,000,000. Assuming an initial parking orbit of 85,000 after launch the ratio would be (11,000,000 / 85,000) 129.41. Meaning, that a bi-elliptical orbit change would be better (save delta v) assuming you don't go crazy with your first Ap change burn. After some more napkin math. Int SMA / Fin SMA > 11.94 flop the equation around to Int SMA /11.94 > Fin SMA should give us the change in altitude for when bi- elliptical can possibly become more efficient. Starting from an initial orbit of 85,000, calculates to 7118.92. Again, assuming you don't go crazy with that first Ap kick. In my example, I would guess a 12,000,000 Ap would be fine. Now, I am no math, or orbital flight master. I would still need to figure out what a Hoffmann transfer would cost, then figure out the total cost of the bi- elliptical (3 burns) then compare. I want to assume that my math for when bi- elliptical can possibly become better then Hoffmann is incorrect. 7119m just seems so small, but delta v isn't figured. Is my math or theory on this incorrect? I still haven't been able to do delta v calculations (not sure of the formula or its factors, and I'm sure mass will be a major portion which I currently don't have access to realistic test numbers). But please, pick it apart.

I just toss a small decoupler between docking ports to get delta v. Eng redux will also display delta v by stage, and in relation to what ever cestial body you choose. You just need to not keep it in compact mode. Mechjeb has a nicer layout and look (along with tons of customization), but lacks the delta z in relation to another body. Helps a ton when wanting to know the delta v and twr of a lander while it is still being designed.

Here is an album of what I have been up to recently. http://imgur.com/a/gl8IC

The maneuver node integration is awsome, but it needs to be complete. Every auto pilot should make a node. Every auto pilot should also have an accurate text indicator of what it is trying to do. It also seems to want to be too accurate with maneuvreaers. Like a simple phasing orbit. It will fight to get that last .2 m/s to make a154k orbit, when in reality, being at 153.8k is fine. If you leave rcs on, it will eat the fuel like it is at a buffet during maneuvers. It feels like loosening up its accuracy tolerances would help. Along with using rcs a bursts rather then on or off. I'm sure it isn't easy to code, and 2 is a beta of sorts. So it preforms wonderfully for the stage it is at. The new custom window editor is a great feature for just displaying what you want. Maneuver planner and editor are a good addition for when you just want help with what the best route is, but not the execution.