impyre

I know this wasn't your original plan, but I recommend the "wagon train" method I like to use. If carefully planned, it's almost as efficient as using one large vehicle. Basically, send several modules instead of just one. Good TWR's will be easier to obtain, payloads will be easier to control in terms of attitude, smaller launches are more manageable, and failure of a single module doesn't wreck the mission (assuming you send spares). The overall fuel cost is still related primarily to TWR (which is itself often related to engine mass), payload mass, and destination. These can be kept the same regardless of how many launches you use. On my last mission to Duna, I basically sent up everything I needed to build a large orbital station around Duna, with some spares. Refuelling, life support, science, return capability, etc. I plan on leaving everything else (including spares) for future missions... I've even considered refuelling all the modules and sending them on to Jool direct from Duna. That way when I get around to Jool missions, I'll only need to send crew and life support (and a couple of modules filled with equipment specific to the Jool system). I know this isn't really a "solution" to your problem, but it's a decent enough workaround I think.

Just FYI, http://wiki.kerbalspaceprogram.com/wiki/Key_bindings lists out all key bindings and even explains different keys for different systems. Most (if not all) of this info is also available in game through the options. So next time you're playing, if you need to figure out a key, you can check there without having to alt-tab.

I have to speak up here. I trust Roverdude to implement a balanced and wonderfully Kerbal solution. Apparently, so do the devs. (...yes, I'm a fanboi... wanna fight about it? ) But in all seriousness, ISRU is not unrealistic (for those of you who tout realism)... and it *can* be fun (for those who may say that realism and fun are mutually exclusive). In fact, a planned mars mission used on-site production of oxygen to reduce fuel and life-support costs for the trip there. It's not impossible to find the raw materials needed to make rocket fuel on other planets. The issue here is how much money does it save you? This has to consider the cost of lifting up said refining/collecting equipment and landing it on a distant planet. That's not cheap, and the *real* reason to do it is because you intend to use it more than once. This said, if you are only planning a single mission, forgo the extra weight of ISRU equipment (you'll save time, fuel, money, and potential mishaps [like dropping your mining unit on its head and being unable to return])... but if you're planning multiple missions, or an extensive on-site campaign with multiple objectives... perhaps it will be worthwhile. Seems like it may take some thought and will *not* be just another "make it easier" patch. Of course this all depends on implementation, but as I said at the beginning of my post... I have faith in these guys.

I asked myself this same question a few weeks ago. I decided to go ahead and start anyway. My thinking is "I'd rather not play without my favorite mods, K&W... KER, KAS, USI, and more... they will take time to catch up after 1.0 is released... so I won't be playing 1.0 right after release anyway. As for difficulty, I personally like TACLS, DRE, and NEAR. Ultimately, it's easier to get to space... harder to get back in one piece (and thus harder to complete missions). I also tweak game settings to pay out less for contracts, so I have to be more budget conscious and accept contracts very carefully. I think it keeps the basic feel of KSP while also adding extra layers of difficulty. I'm struggling in career mode right now with getting a working temporary heavy launch vehicle. I'm mid-tier, so I'm making more and bigger launches... and designing new rockets every time is becoming less and less appealing, but my heavy lifting tech is a bit limited... so I'm trying to find something that works. Oh, also I use stage recovery (that's the big reason I decreased contract payout).

LOL... I thought I was slow for doing this so many times. Glad I'm not the only one.

The "dV needed" assumes an "impulse" maneuver... which is one that happens all at once. Obviously this is impossible, but for most cases where burn time is less than 45 seconds or so (depending on orbit shape and semi-major axis when the burn is started) this is a pretty close approximation. Close enough that you don't notice the difference. For vehicles with such a low TWR, it's not uncommon that maneuvers take much much longer. The problem with this is the loss of advantage gained from the oberth effect... as you burn, you raise your apoapse... and the periapse will move with the vehicle (meaning that you pretty much stay at the fastest point in the changing orbit, burning more efficiently). If your TWR is very low, you will pass your periapse (and maneuver node) while burning... and more of the fuel will have to be spent constantly correcting for your ship being where it's not supposed to be (if you'd completed the burn in an instant you'd be much higher than you currently are). In effect, you're fighting against orbital mechanics instead of working with them. - - - Updated - - - As noted earlier, the only real solution to this is to implement the maneuver in increments... maybe 30seconds to 1 minute per burn. In my opinion, the best solution is to simply have enough TWR to complete maneuvers in *no more than* two "kicks"... it gets a bit tedious otherwise. You also have to consider the potential fuel cost for correcting mistakes (more kicks = more chances to mess up).

This depends a lot on how the two orbits relate to each other. If you want to use the "multiple-orbit" method to get a closer intercept, I can share what I've done. I get an orbit that's similarly shaped and inclined with a single intersection point, get to that intersection point, then burn pro-retrograde until I will get a close encounter on the next pass. If you have the target set, you can watch the target position marker move as you burn.

I'm using KAS 0.4.10, and the fuel pipes are giving me grief. I've tried on several occasions to use them to connect two vehicles for fuel transfer. Unless one of them is quite small (like a single seat lander) then they both begin to oscillate wildly until one is ripped apart. SAS is disabled on both prior to linking... on my most recent attempt I even went so far as to manually disable all reaction wheels. Relative velocity is dropped to below .1 m/s (as close to zero as humanly possible). One of the main reasons I've used KAS is for this fuel pipe. What am I missing here... is this broken? The physics of it don't make much sense, is this a problem with KSP .90? In the absence of external forces, all oscillations eventually cease... they don't get worse. It's as if some external magical force is attacking... is this the legendary kraken?

The ground track for an anti-normal synchronous orbit would appear just like any other ground track for non-synchronous orbits. The only difference is it's movement relative to the surface would appear to be much higher than other satellites at similar altitudes. Of course, the same holds true for anti-normal orbits when compared to normal orbits at all altitudes.

Yes, it's possible. You'd need a virtual machine though, so it would have access to all the OS functions it needs. https://www.virtualbox.org/

I've stubbornly tried to master this exact thing for a great many hours. Sadly, it's nigh impossible. As everyone else points out, there are far too many variables. If your angles or velocity at *any* point in your ascent is even slightly off, your timing will be different. Also consider drag, weight, TWR, staging... all factors which can vary from one ship to another (especially as your technology improves). If you use NEAR/FAR and fairings, have attained top tier techs, and have designed a general purpose launcher capable of delivering decent payloads of various shapes/sizes to LKO.... *then* you may want to consider mastering this (but I still say it isn't worth the trouble). A parking orbit at 250km is what I use for my stations... it's low enough that it's easy to get to and high enough that I don't have to wait very long for an intercept burn.

@Dixi: You're better off forgoing the second outrigger altogether honestly. The extra pieces won't make it any stronger, and by adding more joints you're actually *decreasing* stability. Just use the outriggers at the main attachment point (and use as few as you can get away with). Also, placing struts can be somewhat strategic. Try to place some above and below the main attachment point and parallel to the outrigger, also try to place some on diagonals to help dissipate torsional forces. Having too many is better than to few... once you get it strong, you can start experimenting to see what you can take away. "perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away" - Antoine de Saint Exupéry

Geosynchronous and geostationary are two different things. Geostationary orbit is a special case of geosynchronous orbit; one in which the inclination allows the satellite to orbit while maintaining position over a certain geographical area. Geosynchronous orbit is simply any orbit with a period equal to the rotation period of the planet (accounting for orbit around the sun of course). Thus, geosynchronous orbits can happen at any inclination... they are just considered less often because they aren't usually as useful for line-of-site properties.

I believe you're right.

On doing a bit more research and reading... the conclusive answer is that for an arbitrary vessel, *having just been refuelled in a pre-set orbit*, the orbit that will allow the vessel to leave kerbin and reach the destination with the most dV possible can be described as: 1) as eccentric as possible (though this can making rendezvous more difficult) 2) having as low a periapse as possible 3) having as high an apoapse as possible (without escaping). This doesn't consider the cost of fuel spent for the purpose of refuelling said vehicle, it's concerned only with how much fuel that vehicle is able to leave with after the refuelling and ejection burn. Of course, having a disposable transfer stage renders the entire conversation a moot point... since the payload will get intercept without spending any fuel that way also... but it basically works exactly the same way. As a side note, the advantage gained from increased speed during burns does begin to generate smaller returns after a point due to reduced propulsive efficiency at speeds higher than exhaust velocity... although I'm not sure if KSP considers this at all. At speeds below the exhaust velocity, increases in speed improve efficiency due to both Oberth effect and increasing propulsive efficiency... once vehicle speed exceeds exhaust speed, propulsive efficiency begins to drop again. The Oberth effect probably dominates the equation both above and below exhaust speed though. Propulsive efficiency is related to the amount of propulsive energy you get from a given mass of fuel. So if exhaust speed is 3500m/s, and you aren't moving at all, the spent fuel is getting a large portion of that energy (and being accelerated in the retrograde direction)... if you're already moving at 3500m/s exactly, then the fuel leaves out going 3500m/s to your relative retrograde... but it's speed relative to the parent body will be almost nothing (you kept all the kinetic energy gains). If your vehicle's speed was 5km/s, the exhaust particles would be moving with the same prograde (relative to parent) as your vehicle, and still have 1500m/s kinetic energy left over... that's energy you can't use now. I don't think KSP models propulsive efficiency (or at least kerbal engineer redux doesn't) because the dV readouts don't seem to change with velocity. Unlike gains from the Oberth effect (which don't change a vessel's dV but the amount of energy gained from a given amount of spent dV) gains from changes in propulsive efficiency (since it deals almost exclusively with kinetic energy[at least in lower orbits]) should probably be noticeable in the dV readouts.

You need to ensure that your center of lift is aligned (vertically) with your center of mass. Try selecting the entire rocket (in the VAB) with shift-click, then rotate the whole thing 90-degrees around its vertical axis(i think that's q/e)... see if the problem changes. If so, there's an alignment problem somewhere. I've had problems with the tri-coupler causing mis-aligned center-of-lift in the past. The best solution in my opinion (and this is what I do) is to go from a single stage to a three-sym stage by using radial decouplers and struts rather than using the tricoupler. Your overall profile should be somewhat sloping, not thin and pencil-like. This design won't be as tall, and will be much more aerodynamically stable.

For what it's worth, I don't think you're doing anything wrong. This happens to me ever since the latest changes to the stability assist system... specifically, hold prograde is the worst. You might try and see if it happens in stock for you (or the without the SAS). I regularly design my launch stages with a TWR around 2-2.5, but I don't go full throttle either.

@Kryxal and TheXRuler: I'd have to do some math, but I'm certain there's a point of local maxima where the benefit of higher orbit is maximized and losses from giving up the Oberth effect are minimized... especially since the Oberth effect is proportional to v squared, and total orbital energy is proportional to orbital period. Since this is the case, there must be a point where one function stops dominating and the other picks up the lead. It may be that the best of both worlds is indeed to establish an extremely elliptical orbit with a very low periapse and as high an apoapse as you can manage, and then refuel in that orbit right before doing the ejection burn... although the elliptical orbit will likely make rv'ing a pain in the neck. And thanks TheXRuler, sorry if I was impatient.

I voted bulb for the same reason as the others... it's only really suited for low-g planets, and even then the design severely limits your landing options. I use a tri-engine lander, it's pretty low-profile and has the option of ditching the three engines and their tanks and using a tiny engine for emergencies when you really just need a bit more dV. - - - Updated - - - You can get inflatable heat shields. The way I figure it, even if heatshields couldn't realistically *inflate*, there's no reason at all they couldn't unfold. I have large deployable heat shields for my oddly shaped vessels... but I don't even use them that often honestly. I find that it's easier and more reliable to simply create a ship designed to stay in orbit (with lander attached), and use separate pods for reentry. USI's Survival pack has some really nice escape pods that are KAS compatible, so you can attach them to a ship when you refuel it, do the mission, come back, and hop in the pods to get back on the surface. Other large equipment that must be returned is returned by itself.

Sortof on topic (if you think about how fire works in microgravity): I overheard a teacher at a community college explaining to a group of 5th graders (who were there for some kind of summer program) why a fire in a jar causes an egg to be sucked into it (after performing the experiment). Her explanation was thus: "The fire is trying to get the air because it needs air to survive... so it pulls it in." I'm 100% serious. - - - Updated - - - I've argued this point with my s/o on many occasions... she thinks money spent on space exploration is a waste. Granted, it's pretty subjective (and some intelligent arguments can be made on both sides), but I still *believe* that it is a necessary expenditure and in the best spirit of human and kerbal tradition.

I said this in my other posts too... but I'll say it again... Ejecting from lower orbit is more *efficient*. Ejecting from higher orbit allows you to take more fuel out of the SOI with you. Higher orbits are *never* more efficient, I was just offering an alternative perspective of which orbit is "better". This obviously will depend on mission parameters and personal preferences. If efficiency is your top concern, eject from as low as possible. If carrying more fuel and dV with you to the destination (_*at the cost of efficiency*_), then eject from as high as possible. Also, to clear up an earlier misconception, ***if you are refuelling and trying to simply take as much fuel out of the SOI as possible for a given vehicle size*** the orbit with the greatest stored energy is absolutely the best. This means the orbit with the greatest orbital period (as the energy associated with any orbit is directly proportional to orbital period) will afford you the greatest advantage. Since the SOI is in the shape of a sphere, this orbit will be a circle right at the edge. Also... this method assumes you are refuelling (or the vehicle is already full) once the vehicle reaches the parking orbit... if you are ejecting without refuelling, the lowest orbit is always best. - - - Updated - - - Such a trajectory does indeed exist... it will be a hyperbolic path with the periapse within the planet.

I can sympathize with your love of your mods... (I love all of my many mods as well). I feel like squad has been more wonderful than 98% of devs out there when it comes to encouraging modding and contributing to the wonderful and vibrant community in which this discussion takes place... honestly, I've played games from a lot of terrible devs... more than I care to admit. I've also seen a lot of *great* game ideas suffer a premature death at the hands of an inactive community... I'm glad that's not happening here. I'm also extremely grateful to Squad for including the modders in the development of the stock game... I've never even heard of this happening on this scale before KSP... it's a fantastic way to get them involved, encourage new modders, and reward excellent development and dedication to the game/community. I'm ecstatic that modders (like Roverdude and Arsonide) were given a chance to contribute to the stock game. I assume they were fairly compensated, and again I'm super happy that they were able to get that. I will continue to support those mods and modders that I love, and I will continue to encourage Squad in their intimate involvement in this active community... *especially* when it comes to taking great ideas from here... from us... and putting them in the game. That said, I hope (with all my heart) that my favorite mods are continued by their creators, especially if those functions are attempted in stock. After all, the great modders are continuously updating and adding to their creations at a rate that Squad just cannot match (with their much broader focus on the game as a whole). I really doubt that mods being "endangered" by encroachment from stock is *really* something you need to worry about... honestly. More mods have died from lack of interest (on the part of the modder) or busy modder lives than anything else... fear that instead (and maybe donate to your favorite modders:)).

mattkuae, I've had this same thing happen to me on a modded system and an un-modded system. It's usually after timewarping and/or changing from map to ship view. I can't say which exactly, but I feel like it's more closely related to time warp. It happens so sporadically that it's completely unpredictable and difficult to reproduce reliably... but I know it happens (with a pilot, power, and SAS). I have to load the space center and re-load the vessel to fix it... and it *only* happens to kerbals that have other abilities (like hold prograde/retrograde)... it seems like it sometimes gets stuck in stability assist mode.

Staying in the lander until you're in the area isn't optimal fuel-wise, but it's the easiest. Just click on the nav-point in map mode and click "activate navigation", locate the point in question on the nav-ball and fly there. That's what works best for me. - - - Updated - - - That's awesome... I hadn't heard of it before now.

I'm not certain you'll save anything that way, it may even be more expensive in terms of dV. Think of it like a rendezvous; how much energy it takes to establish capture is directly tied to your velocity relative to the target. To establish capture around a body, you'll have to kill a chunk of that relative velocity (not necessarily all though). By raising periapse before doing transfer burn, you're ensuring that you arrive at apoapse with some horizontal velocity already. If you are approaching your encounter going the opposite way as the body you are intending to be captured by, you'll have to burn off quite a bit of velocity to establish orbit... that's why we approach heading the same way as the target in its orbit. It catches up because we are moving slower than it is... even in this case, relative velocity is still high enough that some must be burned off for capture. If you burn straight there without raising periapse, you'll have almost no velocity (so the target will be approaching at greater relative velocity). I'm not sure whether this increase in dV required to establish orbit is enough to offset the savings by not raising periapse before transferring, but it will be interesting to research. - - - Updated - - - Or for that matter whether it's more efficient to establish orbit before landing...