impyre

I've been having this problem with the large drill as well. Not the smaller ones, just the large USI drills. No placement works at all, it's funny because they worked fine at first. Also, and this is more of a note really, the planetary logistics were making me miserable. Took me an hour to figure out why my water converters were sucking all my power continuously, but every time my water started to get near full it jumped back down. Turns out I dumped something like 1.5million units of water, 3 million units of raw uranium, among other stuff into the void. While my base can sustain max power draw for a while, it wasn't designed to do it continually. I had to manually turn off planetary warehousing on every container. Thanks to everyone that helps with this mod. I appreciate it. PS: if anyone else is using this with Extraplanetary Launchpads and finds themselves using survey stakes more than they'd like, I'd recommend getting some of the welded asphalt tiles from kerbalhacks. They include a couple of really nice pads, and turning them into actual launchpads use-able for off-world construction is quite easy. Add the launchpad module and then a spawn offset height of .4 or .5

I doubt that it's doable for the reason you listed. FAR atmosphere is still thinner. You'd need an appropriate chute mod (like RealChutes by StupidChris) if there are any updated for that version of FAR/KSP, it gives much more control over the chute's area/drag and opening characteristics. @Moar Boosters Odd, I've never had problems with vertical retrieval below 8km, only when you start to get much higher. But I guess that probably partly depends on how much rocket he's trying to bring down in one piece.

Personally, I simply turn penalties down, but leave everything else at max difficulty. The most grindy thing about the game right now is the insane building costs (especially if we're assuming that someone playing on "hard mode" has a good idea as to what they are doing)... doing missions without patched conics isn't that difficult, working within limitations imposed by lower tier buildings is interesting... until it prevents you from moving further out... the problem is that in order to make the money you have to perform miraculous tasks with few resources and parts... multiple times. Doing it once is fun, just to show "I can do this!"... but you shouldn't have to jump through the same hoop so many times just to get to the next "level". Turning penalties down allows you to upgrade buildings in a timeframe that makes more sense given your accomplishments, while keeping rewards low helps give that extra incentive to run an efficient operation.

I agree with moronwrocket; the normal vector will always be pointing "up" from the perspective of your orbital plane... when your plane is equatorial and prograde, this is polar north... when you are retrograde and equatorial, this is polar south. Adjustments can easily be made by watching prograde marker through at least a half orbit... make a note of its maximum deviation from the horizon, the next time you hit the point of maximum deviation will be at the next node (ascending or descending). Even getting in the ballpark (plus or minus a few degrees of phase) will allow you to create a fairly equatorial orbit with only a single adjustment. This method works even for elliptical orbits. (Though I make no promises about efficiency) @Redironcrown, I'm pretty sure he's talking about the fact that normal vector shows inclination, since navball polar alignment is always correct.

I believe adinfinitum is correct, consider that if you add two vectors to implement a change, you are essentially negating each by some ratio (depending on the angle)... so the total energy required is greater. Following the normal or anti-normal markers is like adding an infinite series of vectors with changing magnitude and direction. Those that come after the target point will be detracting from some of the work done by some of the earlier vectors. It gets pretty messy mathwise, but suffice it to say that it is most efficient to decide how much work you need to do and in what direction, and do that directly... anything else will create losses.

I spotted some odd objects the other day that were blinking at me (i have distant objects enhancement also). I puzzled over what it could've been for quite awhile, as there were no planets in that area of space. I hadn't yet unlocked unowned object tracking, but I came to the conclusion that I was looking at an asteroid. Later on I saw my station "blinking" at me from 100km distance, so I'm pretty sure it was an asteroid.

I've noticed this as well. I theorize that the dots are most accurate, and are representative of "point samples"... whereas the "cloud"-like displays are interpolations of the same point samples and thus prone to interpolation problems (especially on a spherical surface). I haven't tested this yet, but I plan on it. You'll notice if you look closely that the dots near the poles seem smaller and closer together, which fits with samples taken at regular intervals of latitude and longitude.

nekogod and alistone are on the right track. The fact is that dV is a function of work, which can be represented as "the area under the curve". Since fuel flow rate is constant, the "curve" is a straight line with positive slope... which gives a triangle. So to find the perfect time, you'd need to find the point, t, at which the dV on the left and right are equal. This is analogous to splitting a right triangle into two odd-shaped portions. On the left is a shorter similar triangle, and on the right is a taller more narrow quadrilateral. The fact that it's narrow is representative of the fact that it takes less time to burn the same amount of dV (due to increased acceleration). Doing the integration shows that the midway point is depends only on total burn time, the proper midway point in terms of time is given by: T-midpoint=(.5*(T^2))^1/2, where T is the total burn time and T-midpoint is found in seconds after starting the burn. So to get burn start time, you'd subtract T-midpoint from t=0 to get the proper time to start (EG: -35 seconds). This formula gives a linear relationship between total burn time and midpoint time. T/(sqrt(2)), or approximately .707*T. So aiming for about 70% of total burn time before the node will be a very good approximation. Of course, if you know the acceleration at the beginning of the burn, you can use the same integrals to solve for total burn length as well (but simple geometry is easier and faster). Last but not least, bear in mind that maneuver dV is an estimation based on assumed "impulse" maneuvers in which all dV is burned at once. The longer it takes you, the less efficient the burn will be and the further off the estimate will be. Also, burning longer than intended can throw off timing significantly. Keeping burn times short reduces the penalties for incorrect burn midpoints and helps keep estimates accurate. I'd say that if your burns are long enough where burning 50/50 produces noticeably different results than burning 70/30, you're taking far too long anyhow.

I was able to launch an unmanned "crew return module" that had a Duna encounter and 2300m/s of dV. It was able to establish capture around Duna, get a Kerbin return encounter, and establish Kerbin capture all without any aerobraking. Add the encounter dV (which was on the transfer stage, not on the return module) of around 1080 and it comes to a total of about 3400m/s. Probably could've done a little closer to the listed amount of 3314, but I like to play it safe. This was in 1.0.2, using only stock parts. The 2.5m poodle engine specifically. That said, that won't allow you to do any landing or orbital maneuvers (including rendezvous) once there, you'd need other craft for that purpose. For rv maneuvers, you may want an extra 500-1000m/s. You could go with less, but intercepts would be long and annoying. I sent crew return modules, landers/exploratory vehicles, fuel/supplies, all in separate crafts/launches. That 1700m/s estimate seems a bit low, even with aerobraking... it'd be a challenge to manage.

WOO, donations for you sir! Thanks KospY! Show some love ppl!

I always refine on the ground. As others have stated, it's a bit closer to what would happen if this were irl ISRU situations... mostly because it's extremely convenient to be able to collect and refine at the same site. Then the final product is the only thing that is "shipped". Also, transportation becomes much simpler when you're transporting fuel. You don't have to worry as much about dV (since if you need to ship it further you just use up some of the "cargo"). I used to find docking to be a pain while on the ground, but I now use a rover-based system. Basically I have a sub-assembly that is a rover with docking ports on the front and rear. Since the docking ports and wheels are part of the same assembly, all modules will connect easily since all docking ports are at the same height. Just build whatever you need and slap a wheeled base under it... once on site just roll up and dock.

If I had to guess... I'd say the problem is integrating a complicated ever-changing equation in a very short amount of time. Often only analytical solutions yield the exact answer. Sometimes formulae can be used to get a good approximation, but it's likely that one doesn't exist for the various situations in KSP and that instead the only solution is to find a good infinite-sum representation and then add an arbitrary number of terms... though even in that case there are situations where it can be much less accurate. I imagine it is based off of terrain altitude at the predicted landing site (or directly under the ship... which is even worse)... in which case as the terrain changes the estimate will change depending on slope. This makes sense if you think about it, considering that KER can't possibly keep track of everything all the time, it operates procedurally with limitations on tick time. With changes in terrain and such... even integration would prove less than reliable in some situations.

No Cephalo... I just do that so that I know the ships are aligned without having to use a docking port alignment mod. IE: if they have the same orbital characteristics (which they do if you're about to dock.... or at least... I really hope they do) and then you align one to point at the normal vector, and the other to point at the anti-normal vector... then you know they are perfectly aligned. This way, you only have to use translation to line up and close the gap. You'll already be oriented correctly.

KER's suicide burn info is available but must be installed in an existing display or a new HUD you create. It will show suicide burn altitude, burn duration, burn dV, and time until beginning suicide burn. Time til burn is the one you're really most concerned with as it tells you when to press "z". I still don't trust it 100%, but I've used it without ill effect (but my velocity wasn't that high either... I basically used it in conjunction with my method of cancelling horizontal velocity just above landing area).

I was gonna say to check your USB cord... my pc sits near the tv, and a long usb cable connects my keyboard... sometimes my dogs sit/lay/trip on the connector and it wiggles loose and my craft suddenly stop responding. :/

Yes, kerbal orbital movement on eva is locked to equatorial plane. If you have camera mode on orbital mode... before going on eva, adjust your ship so that it is nose-up and appears to be aligned to 90 degrees regardless of which way you pan the camera (if you're equatorial it will be pointing toward your normal vector (or anti-normal if your orbiting the other direction). This makes EVA orientation *much* easier and it doesn't take long to get the hang of it. I also use this method to easily align ships for docking (except in this case I often align one to point to normal and the other to point to anti-normal and don't take equatorial into consideration at all).

That is an interesting problem. Does restarting KSP resolve? Or perhaps going to space center and reloading vessel?

Well, a couple things. 1) Yeah, early career is tough. You have to redesign often as better parts become available, reaction wheels, elevons/wings, separators. But launchers generally only require a handful of parts, and once you unlock those you're pretty much set. 2) As Garius pointed out, TWR issues can be a huge problem... *especially* during launch. So how much dV drops during ascent is *not* linear. It depends on TWR, ascent profile, and payload mass.... *not just payload mass*. TWR can have a huge impact if it goes too low. 3) There's not really a good reason to be concerned with how much dV will be left after attaining orbit. Once in orbit, payload should be detached (IMO). This allows those stages' dV's to be calculated accurately for vacuum only operation (which is appropriate for most space operations, and much much simpler than concerning yourself with atmospheric dVs). Once the payload is detached, it's a simple matter. The remainder of the launch vehicle can be recovered if you're clever and compensate for that in your design process. And lastly, 4) There's no quick answer since everything depends on how you build and how you fly. You just have to keep doing it until you get a feel for it... but be aware that trying to operate outside what might be considered "nominal" can have unpredictable (and often *fun*) results. Sorry if I haven't helped out much. I'm just not sure there's a satisfactory answer I could give you that would be correct. Calculating vacuum dV and comparing to that may help you get a feel for it over several launches.

I design "standardized" launch stages using a dummy weight to represent the payload. For a given mass in tons it doesn't matter what the payload is. Just make sure your payload isn't contributing fuel to your launch stage. Other than that, build then test, then tweak then test. Once you get it perfect, save it as a subassembly. I use names like "RLS, 20t" for my recoverable launch stage designed to lift 20 tons. I design all of mine to be able to lift rated payload to 250km circular orbit (where my station is parked). So payload can go over rated mass for lower orbits. Once you have a whole set (I have a 5t, 10t, 20t, 30t, 50t, 80t, and 100t so far), you generally won't need to keep redesigning launch stages. Just look at the mass of whatever you're building in the VAB and pick the best launch stage to slap under it. EDIT: do *not* include fairings in your standardized launch stage... if needed at all, include them in the payload... as the weight of the fairing will vary depending on size/shape of payload. This way you can still use your launch stages the same way every time, regardless of whether a fairing is needed or not.

Solid fuel in SRB's is already tweakable.

We *used* to be able to land on Duna on rocket power easily. It remains to be seen (for me anyway) whether the fact that rocket engines (especially lander stage engines) get less thrust in atmosphere will prove annoying on Duna. I imagine a combination of chutes and engines will work best, as it has for me in the past. - - - Updated - - - I'm sending up a Duna mission now, so I guess I'll find out soon enough. I included enough fuel to land without atmosphere at all, so I'm hoping that chutes+engines will be overkill.

I imagine, for the sake of playability, that if they add life support... it'll take the form of the Snacks! mod or USI's new life support mod. In both cases, life support is basically reduced to a single resource that can be produced in-situ (for considerable effort and cost) to extend viable mission lengths. Also, in both cases, running out of life support resources is non-fatal... it just isn't particularly good either. In the case of USI's life support, if you run out of "supplies" for more than 15 days, most kerbals will refuse to do anything remotely useful other than complain. In the case of Snacks!, you take a hit to your rep... after all... who sends kerbals to delicious-looking planets without any snacks? Both provide an excellent way (IMO) to add the consideration for supplies to be consumed over longer time periods without adding complexity that doesn't add to the game in any significant way. I used TACLS for the longest time, but I use USI-LS now. From a gameplay perspective they are virtually identical. TACLS offers water, oxygen, and food... but they come in containers that automatically portion them out in such a way that all three run out simultaneously... so all you end up really caring about it "how many days to I have right now". The two mods I mentioned above add that same functionality with less complexity. The only thing unique to TACLS is that you can recycle water, recycle air, produce water/oxygen from LFO, etc... such that you could in theory carry less of one or another by extending those that you can re-use with more devices and more power... but even that in the end simply ends up being a method to "give you more days". For a fictional species in a fictional universe... I think it's safe to speculate about what they may or may not need for survival. I feel like the Snacks! mod is more "kerbal", but since I use USI-everything... I may as well use their life support also. EDIT: If there were to be a stock life-support... I'd like it to be most like Snacks! in its implementation, but most like USI-LS in its consequences for running out. IE: No Snack = No Work... aka will work for snacks!

There are two ways to do it efficiently. The suicide burn is efficient (if difficult). Lowering your periapse as much as possible over the selected landing area and cancelling horizontal velocity just over the landing site is also efficient. Probably most people use a little of both. Keep periapse high enough to avoid terrain, and use suicide burn once horizontal velocity has been mostly killed. That being said, "efficient" doesn't always mean "best". Best is usually a compromise between brutal efficiency and ease of implementation. Suicide burns are called that for a reason... TWR changes when burning fuel, so calculating a suicide burn accurately requires integration, not something most people are willing to do while plummeting toward the lithosphere... but for small burns at low velocities/altitudes, a guesstimate is usually good enough and errors are kept small so they don't affect the overall mission very much. I always come in low and fast, and kill horizontal velocity a bit at a time... just enough to keep from overshooting my target. I don't flip vertical until maybe 100-200m altitude (when my shadow becomes "solid" and doesn't flicker). - - - Updated - - - That's not the only efficient way to land. There are others that are equally efficient from a math standpoint. You fail to consider whether a method can truly be considered efficient if the implementation is so difficult that a person cannot do it effectively. If you are flying your rockets by hand, trying to perform a "suicide burn" and end up having to let yourself down gently so you don't go crashing into the surface, you've just turned an "efficient" method into the worst possible way to land.

As SanderB said... mass is important. Drag produces force, and force = mass * acceleration. So with a given force due to drag, if you have less mass (like a tiny probe/satellite-shaped object behind a huge heatshield) then your acceleration (or technically deceleration in this case) will be greater. The ratio of mass to drag is basically the ballistic coefficient (mass/[drag coeff*cross sectional area])... for a given drag profile / AoA, higher mass results in higher ballistic coefficient. High ballistic coefficients result in craft that slice through the air with less deceleration, while something with a low ballistic coefficient behaves more like a ping-pong ball. You'll have to experiment to figure out what's required. I use sandbox mode for such experimentation. I consider it to be analogous to combining experimental data with simulators... this allows you to figure out how things *should* behave in a given situation.

I totally agree... especially for those that don't read disclaimers. ;p Seriously, there's nothing you can do but estimate.