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. :/