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.

I decided too scrap that design, and make a smaller, more efficient design. The fact that the main engines thrust bloom happen to hit the rovers angled solar panels sending it into a spin, forced a redesign. I also found myself holding down rcs (like you would a fps), stopping that habit fixed my rcs fuel issues. I am now at the mun, mapping for a good landing spot. It will be quite a learning experience.

Good thing I asked. I figured sas helped with the non powered rotation. So, the only solution to help a large ship change headings faster is rcs. My hurry is mainly for docking concerns where sas lock "t" can't hold a heading. The large beast just slowly moves away, making facing the docking ports a constant battle. I can leave rcs on, but then it eats fuel with a small wobble back and forth. I guess I just have to get better at designing balanced ships, and docking faster.

We all know large vehicles handly like an cast iron tub filles with lead. I assume this is because of a low sas torque to weight ratio, culminating in a slow non rcs rotational rate. My question is, will adding more sas units, and thus more torque help the rotation (is the proper term transition) rate? I am trying to get a large long ship (puller attached to a probe dock, attached to a lander with rover) to handle better, so I don't have to burn and carry so much rcs fuel.

When using Mechjeb to perform maneuvers, keep an eye on your node heading (the blue mark on the nav ball). It tries to align that point before any time warp, and before the burn. If you have a large ship that rotates slowly, and sas can't keep up to hold that point, it won't be able to realign after time warp before the burn. It likes to keep a node, and be accurate (to the point of trying to adjust an orbit if it is out by 0.2 m/s) If it is not on mark, it tries to rotate, then burn, leaving you way out of postion for planned node. Usually burning late, and then attempting to correct the orbit with weird (but mathematical correct) burns. Your only choice, besides redesign, is to boost the rotation rates using rcs, to ensure that your heading is on mark for the burn. Be aware that mechjeb2 loves to deplete rcs fuel. Also, if you have a multi part docked ship (mun lander upside down on top of a travel booster) that you are controling from the ship facing the correct way (such that main motors are point back, like a normal rocket). Just remember that MJ is trying to fly by math alone. It works well on small quick maneuvering ships, less so on large slow rotaion ships.

I have had good luck learning from mechjeb2's mistakes. First, you need to understand the method of what should be happening. Tutorials will beat it into you. Rendezvous (closer the better), zero relative volcity, align ports (which ever direction is easiest for you), then rcs in slowly. Then, as MJ2 goes through the routine, you can see what it is doing, and what it is trying to achive. You will then see it make a mistake, and you will scream "all you had to do was rcs closer! But nooooo, main engines on full power away was your choice." Then you will only use it to plot a rendezvous maneuver node. Don't start with a large ship, they turn to slow for MJ to fly reliably. Start small, and work up. Be aware that MJ uses rcs like the fuel is unlimited.

Check the flight logs after an explosion. The rockets (9 and nova i think, maybe 7 also) that have monoproplent inside the decoupler often collide with the payload during launch. I solved it by simply adding a 2nd decoupler directly on top of the first. Also, if the payload has a smaller diameter then the main body, I put a structural adapter (not the thin flare one) on top of the lifter with a smaller decoupler directly under the payload. Dont forget struts! I have had good luck attaching struts from the lifters last 2 boosters to the payload. Along with basic 4 or 6 around the main connection.

If you mean advanced s.a.s., "t" by default, it will "try" to hold your headingwith any controls possible. So if you have rcs enabled "r", it will use the jets to steady you. If you want just a burst of a.s.a.s hold "f". You can use it with or without rcs or main thrust. Just don't expect a 20 torque large s.a.s ring to hold an unbalanced 100+ ton beast against the effects of gravity of a pendulum.

Hmm.. I have been using engineer redux. It displays atmospheric, and vacuum. Mechjeb does the same, in fact I'm sure a bunch of info mods display it. I don't know the math behind the physics of it. So I'm not sure what exactly is accounted for. I would assume the only factors are: motors, total weight, and atmospheric pressure / drag.

I am planning a mission to place satellites into orbit around Kerblains moon, but the main puller vehicle is also being tested as an interplanetary tug. It currently has roughly (not at home for exact specs) 9000 delta v with a twr of 0.33 (6 LV-N motors). That is just the tug. Another vehicle ment to postion the probes (inclination + orbit adjustment) will be attached to the tug, supplying 2 additional motors and fuel, but I would like to save that for positioning the probes. I understand that any positive twr will work, lower would take longer (or more) burns. I am courious as to what people use. As Iwould like to avoid 2 hour burns if possible. I know I over killed the required delta v for the 2 moons. But I am trying to think ahead to larger missions. So what is your twr? Settle down ladies, I'm not asking your weight.

I thought about giving the payloads rcs, but that means adding rcs fuel to every payload. My station (Citgo Station I) core already has 2 750 unit rcs tanks, any more would be wasted. My goal, is to desgin 2 types of fuel payloads, 1 being the large orange liquid tanks, the other being a half rcs, half liquid that equals the same weight as the orange tank described above. As much as future payloads haven't been made, I am willing to abide by tolerances that are set by my tug. Honesty, I am worried about 2 things. Will those 3 motors be enough for an interplanetary push? Allowing the tug to double as a station delivery method. Will a small offset of rcs on the tug, during payload delivery, be a big issue for a docking newb? When payloads are attached, and tug docked, K2 (with math powers that I trust) figures the rcs balance should be fine for the complete station.