sciguyCO

I noticed there's a new version, so this may be moot, but here's a small bug I noticed with 0.51a: I accepted the "Build a new orbital station around the Mun", put it together, launched, and got completion of the "Put your station in orbit of the Mun" as soon as I crossed into the Mun's SOI. Shouldn't that only be marked as completed once a stable, non-escaping orbit is achieved? I know the stock "explore {body}" contracts require that, so it must be possible, but I wasn't sure if you expect to have the necessary orbital parameter checks to handle that (in which case they're not firing properly), or if you only check the station being in the proper SOI.

Ah, sweet relief of viewable data. When I saw the KER display erorring out after updating the 0.24 I started to twitch. BUG REPORT (minor): In the VAB, the "COST" column does not take into account tweaking the amount of monoprop, liquid fuel, or oxidizer. KER's display always shows the "full up" cost, even if you reduce resources stored in parts. In case they're not available as constants in the KSP API, here are the per-unit costs I found: * Monopropellant: 1.2 * Liquid Fuel: 0.8 * Oxidizer: 0.18

If this is a career game, the "built in" passive antenna isn't unlocked on probes until you research "Unmanned tech". Though I would've thought they'd be missing the RTAntennaPassive module completely in that case (as opposed to having the range set to zero). I checked two of my saves; one with that tech unlocked and my new 0.23.5 one without it. In the save without the tech, the RTOmniRange of my probeCores are zero.

The remote-tech download includes a "RemoteTech_Squad_Antennas.cfg" that modifies the stock antennas to work as RemoteTech enabled ones (such as disabling science transmission unless a signal can be relayed to KSC). If you remove the dll, the modifications no longer work, and the stock behavior is still disabled.I think you can bypass that by renaming that file to an extension other than ".cfg", or removing it. That will revert the part.cfg definitions for those parts back to stock, which should re-enable stock transmission functionality.

Your save (including flights in progress, saved ships in VAB/SPH) are under your KSP\SaveGames\{nameOfSave} directory, so copying that whole from your current directory to Steam's install directory will migrate your existing career / sandbox. The upgrade from 0.23 to 0.23.5 should be straightforward. My old saves created in 0.23.0 got updated after installing 0.23.5, and they now have the new asteroids and parts. There was a glitch in that immediately after 0.23.5 was released, but the current version on Steam has a hotfix that removed that problem. If you have a pure vanilla (no mod) installation it should "just work". Any mods you have could make it more complicated depending on their support for 0.23.5. Oh, I think there's also a glitch with the mainsail engines and orange tanks in career saves, since they moved which tech tree node they were in. You will have to go and "purchase" the moved parts if you have a career save where you had already researched that node.

Handy tip if transmission is an issue: when an EVA kerbal does a "gather data" from a command pod containing a crew report, and then "stores data" back into the pod, the crew report is moved from the "report" slot to the general experiment pool. This lets you do another crew report (from a different location, otherwise it's redundant) on the pod. I do that in my RemoteTech modded save when my Kerbals are in communication blackout but a new crew report opportunity presents itself.

Well, there's a scenario (or more, can't remember) from the main game menu related to asteroid rendezvous / capture. Or just start tracking, rendezvousing, capturing in your current game. Though I think if you got hit with the "save corruption" bug (which should have been hotfixed) asteroids wouldn't show up in that save.

I love this as well (though I almost always used Kerbal Alarm Clock to track my nodes anyway). It also seems to persist nodes in a quicksave.I also really love the "next/previous" orbit buttons when you right-click the node. Makes planning rendezvous easier when I need a couple orbits to catch up to my target. Previously I'd create "zero-burn" nodes back-to-back to get a couple orbits ahead.

I designed a lander for a "Grand Tour" of the Joolian moons. The mission profile was to use a single landing vessel to visit them in order of descending delta-V required for landing + takeoff, so Tylo (since it doesn't have an atmosphere to help with landing) was the first stop. Here's what I came up with. Though that must not be a screenshot of the final configuration, since it doesn't have the parachutes used on Laythe and struts appear to be missing. It's intended to land, obtain science, then return to the mothership for refuelling and scrubbing of the goo / science bay with the mobile lab. A few design notes: All seven tank stacks use the Rockomax 48-7s engine. It's designed for a single staging event on each moon, so the KER numbers aren't completely accurate. It required some hand-calculation to make sure it would work the way I wanted, but I'm landing on Pol tonight to finish the tour so I got most of it right. Tylo was truly the biggest hurdle of the bunch though. My Tylo landing was planned with a 5000 m/s delta-v budget (using the numbers from this map). This led to some problems, but were eventually surmounted. The tanks are asparagused in 3x symmetry: the 3 "tall" tank stacks feed into the 3 short stacks which feed into the center tank. The tall tanks are intended to last until just before touchdown before being jettisoned (hence the lack of landing legs on those). The Tylo landing was eventually successful, but I did resort to quite a few "training simulations" (i.e.: quicksave / quickload). The mothership handled most of the de-orbit burn, putting periapsis at about 6km, releasing the lander, and then boosting prograde to re-circularize. My first landing used way too much fuel; the three outer tanks were about half empty and I grossly underestimated how long they'd last on ascent, leading to losing TWR too soon. Even moving fuel from the center out didn't help. I originally thought staging those outer tanks as an "abort plan" for Tylo launch would be sufficient (scrubbing my Laythe visit), but the loss of thrust made that problematic, and would've required also scrubbing the Vall visit. I knew my problems were piloting, so I kept at it. The next attempts were with a "constant altitude" descent profile; keeping my retrograde marker on the horizon line by thrusting slightly up to increase time spent killing horizontal velocity. However, a couple of hills on the descent path kept popping up leading to unexpected lithobraking. Finally, I got a successful landing. There were a couple close calls with hills, I think I skimmed one at about 300m above terrain while still going ~1500 m/s. And it was a hard landing, all six landing gear broke but the engines survived and the gear was repairable. A flag was planted, EVA report and surface sample obtained. I moved fuel from the center tanks into the outer ones (to keep all four engines fueled), and orbit was achieved. Rendezvous was handled with the last fumes from the tanks and RCS. I then refueled the lander, scrubbed the science parts, and took the remaining stages to Laythe, then Vall, then Bop, then Pol. I currently have over 100 science reports in the mothership's command module (with "landed on Pol" yet to do), no idea how many science points will be rewarded on return to Kerbin. It's a moot point, since I've already finished off the tech tree. But this has been my most ambitious mission in KSP to date and it feels damn good to be close to finishing it off.

I've currently set myself the goal to map (using the SCANsat mod) every body in the system. I currently have full maps of Kerbin/Mun/Minmus, Duna/Ike, Eve/Gilly, and Dres. A 5-sat cluster is en route to Jool now for its moons. My Moho mapper went screwy (I didn't realize the delta-V differences in trying a capture at Moho's periapsis vs. apoapsis) and is in redesign. And the Eelo mapper is in the design phase for a transfer window in a game-month or two. It's the Eve/Gilly mapper that really made me impress myself. I figured I'd use the same tactic I did for Duna / Ike: map the parent planet, then push the orbit (still in polar inclination) out to the moon for a capture. Um, yeah. Vastly different situation. Ike has an SOI radius of about 1000 km and is in a flat, fairly circular, fairly low orbit around Duna. Gilly's SOI is ~120km, and its orbit is inclined, much farther out and really eccentric. To make matters worse more challenging: Remote Tech 2's signal delay (about 4 minutes) and I used these mappers as prototypes to try out ion propulsion. My acceleration was about .3 m/s2; a 120 m/s maneuver required burning for six minutes. My first try went horrible. I forgot the lesson from Moho, and just tried extending the satellite's apoapsis to the ascending node. Which was close to Gilly's periapsis. Capture burn would've been ~650 m/s (over 30 minutes of burn with a 5 minute encounter window). I tried expanding the satellite's orbit in stages to keep each burn reasonable while also allowing for a rendezvous in a couple orbits. Then I ran out of fuel. One quickload later, I aimed for a rendezvous at the descending node out towards Gilly's apoapsis. I also adjusted inclination a little to try to come in more "along" Gilly's path than across it. Got a crossing, then tweaked the semi-major axis to get in phase with Gilly. Got close, then a small radial + normal maneuver a quarter orbit away got an encounter! Still only about a 10 minute window from entering to leaving SOI... Set up a maneuver node on the encounter's Gilly periapsis, then plugged the heading and burn numbers into the flight computer to start before entering Gilly's SOI. It was close. I think the recalculation on the SOI switch shifted the satellite's periapsis a bit, so after the burn it was on a collision course. The maneuver was supposed to leave apoapsis near the SOI boundary. But a quick prograde burn straightened that out, followed by an inclination tweak and I was in mapping orbit! The craft has about 100 m/s of delta-V remaining, but it's not moving ever again. In all, I spent a few hours of real time tweaking maneuvers, executing burns (making extensive use of physical time warp), calculating phasing the orbits, and finally circularizing around Gilly's poles. A smart man would've started with mapping the moon first, then de-orbited to the parent planet. Much easier, since you don't have to deal with rendezvous (well, ok, the first rendezvous, but that can be done with matching inclinations); just burn when the polar orbit in in-line with Gilly's orbit and prograde is pointed towards Gilly's retrograde. I'll keep that in mind next time.

As sweet as the Orion is, when news started coming out about it, my first thought on hearing the name was that it was going to be this design. Now that would be doing spaceflight the Kerbal way. And of course there's a mod for that.

A couple of things: 1) Hitting "R" while on EVA activates your Kerbal's jetpacks. So if they do float away, you can get them back to your capsule. Use WASD to go forward / back / left / right and Shift / Ctrl to go Up / Down. Space re-orients the kerbal to be in-line with the current camera position (his back to you). Once you're close to the hatch, you can hit "F" to grab on and "F" again to re-enter the pod. 2) The root cause to your "letting go" problem is probably stuff mounted too close to the hatch. With nothing around that, when you go EVA the Kerbal should always be attached to the little ladder built into the command pod. Hitting the space bar lets go to do a full EVA. But if there's something by the hatch, when the Kerbal exits and "spawns" outisde the ship, there's some collision that takes place. The best-case scenario has them just let go of the ladder and float there in range to hit "F" to grab on. The worst case I've seen had the little green guy get flung violently away from the ship. I run into this a lot becuase I like to have the little sensors (thermometer / gravioli / etc.) close by the hatch to retrieve the science easier. I now always do some launch pad tests to make sure they're far enough away to remove the possibility of clipping.

If I understand correctly, the fuel flow is in units "tonne / second", and counts both fuel and oxidizer. Fuel and oxidizer both mass at 1 tonne per 200 units, and are consumed at a 9:11 ratio. So burning one tonne of fuel + oxidizer = 90 units of fuel + 110 units of oxidizer So your burn time should = unitsFuel / (90 * flowRate) Plugging in 3600 units of fuel and 0.5436 flow rate comes out to 73.58 seconds, which matches Flight Engineer. Does that help?

From my understanding, if you're not leaving the Mun's SOI, there's really no concept of a "gravity assist". You can use the Mun's gravity + orbital velocity to change your Kerbin orbit by encountering it "in front/behind" the Mun, but if you're doing an orbital insertion, the amount of delta-V required is pretty much the same regardless of which side your peri-Mun sits. And I'm also pretty sure that radial/normal burns have the biggest effect when you're 90* in your orbit from what you're trying to move (in this case your Munar periapsis), so doing those mid-course seems the most effective to me. Prograde/retrograde burns have the largest effect 180* around your orbit. In general, the latitude under your periapsis before your orbital insertion is what determines the inclination of your final orbit. So I try to get that roughly where I want it during a mid-course correction, then do final tweaks just after the SOI switch. I used this method to put some scanning satellites around the Mun and Minmus for Kethane and ScanSAT, aiming my periapsis as close to a pole as I could long before the insertion burn.

You need two pieces of information: how long it takes for your transfer orbit (well, half of the orbit since you'll be getting captured on one end), and how far the target planet moves in that time. 1) The period of any orbit (in seconds) is: 2 * pi * sqrt ( a / mu ) where a = semi-major axis of the orbit = (apoapsis + periapsis ) / 2 mu = Gravitational parameter of the parent body. In this situation, "a" will be the average of the two planet's orbital radii (since your transfer orbit has periapsis at one and apoapsis at the other) and "mu" will be the Sun's gravitational parameter 1.1723328 * 1018 m3/s2. Half of the period will be the time required for the transfer. 2) Now to figure out how long the target planet will move in the above amount of time. If you can get the semi-major axis for the target planet, you can calculate it's orbital period (call it P) and use that in a ratio with the above (call it T for transfer time), then multiple that ratio by 360 degrees. I haven't used planet factory, but I'd imagine you can get that in the map view from either the planet info button (little circle icon on the right of the map) or from it's "height" information when it's targeted? Phase angle = 360 * T / P That angle should be "behind" Kerbin if the transfer is moving inwards towards the sun and "ahead" of Kerbin if moving outwards. Final caveat: the above assume near-circular starting and ending orbits. Orbits with a high eccentricity throw complications in that make it difficult to give a single all-encompassing equation.

Well, the wet and dry mass values are given on the tanks in the VAB. I have always assumed that the fuel weight was the difference between those, and using that and the amount of Fuel+Oxidizer does give you the 5kg / L value (under the assumption that the fuel units are Liters, which may not be explicitly stated anywhere). I set up a similar equation to what you describe, here's what I use: Inputs: M: Ship's *current* mass (from map view, click the "i" button) F: Ship's current fuel + oxidizer (from resources tab) in "liters" I: Engine's ISP, From the engine's stats. dV = I * 9.8 * ln(M / (M - (F * 0.005) ) ) That seems to give me reasonable numbers though I haven't verified against something like Kerbal Engineer. I used that calculation during a self-imposed ban on the flight engineer part (though I still used the one the VAB) to improve my non-instrument piloting. What kind of numbers are you seeing in your testing? Are you using the ship mass info from the info screen, or something else?

I'm not even sure launching is necessary. The fuel tanks should give that information in the VAB (maybe requiring a right-click in the part selection palette). It gives fuel and oxidizer separate, so they'll need to be added together. The only thing I thought you were checking was whether those numbers were in liters or some other unit. For most stock parts, you can even go by the tank's name. All the "FL-T###" tanks' capacity is their "###" value (so FL-T100 has 100 units total fuel+oxidizer, FL-T200 has 200, etc). The rockomax tanks are all "X200-#", where their capacity is 100 units per # (so the -8 has 800 units, -16 has 1600 units, etc).

Assuming all engines are firing at once: Thrust(total) = Thrust1 + Thrust2 + Thrust3 + ... So this craft would have 220kN of thrust with all three firing. Isp is a little more complicated. I found this equation from the KSP wiki: Isp (total) = (Thrust(total) / ( Thrust1 / Isp1 + Thrust2/Isp2 + Thrust3/Isp3 + ...) So you'd have: 220 / (120/400 + 50/350 + 50/350) = 220 / (0.3 + 0.14 + 0.14 ) = 220 / 0.58 = 379s Again, that's assuming that they're all firing in the same stage (and probably being fed by the same fuel supply). To account for staging in delta-V calculations, you have to do each stage independently (treating all non-firing engines / fuel as "dead weight" for each) and add them up to get the craft's total delta-V.

I'm 95% sure that the numbers for fuel & oxidizer in the "resources" display and in the fuel right-click display is in Liters, regardless of tank. Plus that's what the wiki labels the tank capacity as. I suppose one way to check would be to make a rocket with a command pod +FL-T100 + engine + launch clamps. Start by viewing the total fuel + oxidizer (should be 100) and initial mass (from the info box in map view). Fire the engine without releasing the clamps until you're out of fuel. If the {units} equals liters, then your final mass should be 0.5 tonnes less.

To cover more of your question in #1: A Kerbal on EVA can retrieve science from any part that can store it, including the command modules. So to move your surface samples, EVA, right-click the command module, and then "retrieve experiments" (I think that's the wording used). All the science results are now "stored" with the Kerbal. When he enters a command pod, all the science with the Kerbal automatically gets stored in the pod (I think this includes the lab). I had a similar setup in a previous save. I had a "science station" that had fuel tanks, the science lab, and a lander. In addition, I had a return vessel to handle refueling the station and bringing science back to KSC. My process was: 1) Send lander down. Gather all the science readings, EVA reports, surface samples, and crew report. Only transmit the crew report. 2) Launch and dock with the science station. 3) EVA the kerbal, retrieve all the science from the command pod, sensors (making them ready for re-use), goo containers (making them inoperable), and sc9001 (making it inoperable). 4) Send the kerbal to a second command pod which is my Kerbin return vessel, storing all the data there. As far as I know, there's no "data limit" in modules, so you as long as there are no duplicate results, they get stored. So the pod can hold "temp reading from Mun Highlands" + "temp reading from Farside Crater", etc. You cannot have two "temp readings from Highlands" though (this gives you the "dump experiment" dialog). 5) Use the mobile science lab to clean the goo cannisters and SC9001. You can do this by right-clicking each component, or I think there's a "Clean experiments" option on the lab that resets all science components docked with the station. This does require electricity (make sure your solar panels are deployed) and having two Kerbals inside the lab. I don't bother "analyzing" the results for transmission since the plan is to take everything back. 6) Refuel the lander's tanks and EVA a Kerbal back to it. 8) Repeat from #1 at a new biome until the station can no longer refuel the lander. 9) Send return ship back to kerbin with all the science in its command pod. Retrieve it for science. 10) If desired, send up another "return vessel" to refuel the station to continue lander missions to the surface.

Let's take those in reverse order: d) delta-V required to land on Mün. To land on the Mun from 14km requires basically the sum of two maneuvers: 1) Hohmann transfer from 214 km orbit to 200km (where 200km is the radius of the Mun) 2) Zeroing out horizontal surface speed at periapsis to come to rest. #1 can be calculated from the "delta V1" equation in the Calculating Transfer Maneuvers section of the KSP wiki page you linked to. Since you're orbiting the Mun, you use its gravitational parameter (6.51x10^10). r1 will be 14,000 m, r2 will be 0 m, and R will be 200,000m. This works out to just over 9 m/s. #2 will be your "orbital" speed at periapsis with a 200 x 214km orbit plus or minus the Mun's rotational speed of 9 m/s. Orbital speed is sqrt(mu * (2/a - 1/r) ). In that equation, "mu" is the gravitational parameter of the Mun, "a" is the semi-major axis (PE + AP)/2 and "r" is the current radius (PE in this example). That works out to 580 m/s. If your ship is coming down west-to-east (counterclockwise orbit), the 9 m/s rotational speed of the Mun is subtracted to get the delta-V required; since you're going in the same direction, you have to decelerate less to "match" it. Coming the other direction would require adding the rotational speed. In the case of the Mun (and that orbit height), the rotational speed matches the de-orbit delta-V pretty closely, hence the "580" on that first map. As an important note, this gives you the minimum delta-V for a landing. We can't do instantaneous velocity changes, and surface variability means that we can't come in perfectly horizontal at PE. You can get a little closer to these numbers at launch (which is basically a landing in reverse). At launch you don't have the "oh god the ground is coming at me!" factor which always causes me to brake too soon / often, adding to gravity drag. c) delta-V required for Münar orbital insertion at 14 kilometers Um, after a bunch of typing / editing, I don't think I understand this leg enough to explain it. From the Mun's frame of reference, you're on a parabolic orbit that you need to circularize, there's gravitational acceleration going on that I'm messing up somewhere, and you're entering the SOI with some relative speed that I'm not accounting for right when I try to work it out. Let's move on... delta-V required to transfer to the Mün Simple Hohmann transfer from 700km orbit to 12,000km orbit (both numbers include Kerbin's radius, PE reported in game will be 100km, AP will be 11,400km). Since this is done within Kerbin's SOI, you use its gravitational parameter in the equation. a) delta-V required to make Kerbin orbit Ok, you know how I said a launch is a reversed landing? Let's start from there and ignore atmospheric drag. The maneuvers this time (starting at the launch pad moving at 174m/s east relative to Kerbin's center) 1) Go from 174m/s to the PE speed of a 600 x 680km orbit (where 600km is the radius of Kerbin) 2) Circularization burn at AP to go from 600 x 680 km orbit to 680 x 680 km The speed at PE for a 600x680 orbit around Kerbin is 2501 m/s, so you need to gain 2501 - 174 = 2327 m/s horizontal. The circularization delta-V works out to be about 73 for a total of about 2400 m/s. That's obviously way lower than you see during real launches because (1) That calculation assumes you've already gained the horizontal speed in step #1 and (2) drag. The atmospheric drag (plus some buffer) adds the extra 1100 m/s requirement to get to the magic 4500 number needed to get to space. There really isn't any way to calculate this from other constants, since it depends on things like TWR (which determines how long you stay in atmosphere), timing of your gravity turn (turning sooner = more time in atmosphere = more drag), throttle management (pushing past terminal velocity increases drag) and probably size of your craft (since KSP calculates total drag by summing up each part).

Here's a delta-V map I use from reddit, and in the comment thread the poster goes over the methods used to get the numbers. From my understanding, when you ignore atmospheric drag, the launch number is basically just a hohman transfer from zero height to orbital radius, plus circularization, plus what "orbital speed" is at height 0, minus the rotational speed of the body. So for the Mun, a transfer from radius 200,000 (Mun's radius) to 210,000 ("low orbit" on that map is defined as height where you get 50x time accelleration) is about 10 m/s. Circularization is another 9 m/s. Orbital speed at 200,000 is 571 m/s. Rotational speed is 9 m/s. 10 + 9 + 571 - 9 =~ 580 m/s delta-V required to launch from the moon and settle into a 10km orbit. Numbers are from a spreadsheet I put together to use KSP body information and the equations from here Similar methods were used to get the escape numbers (transfer orbit from start to edge of SOI) and interplanetary transfers. When launching through an atmosphere, there's drag to take into account, which requires more delta-V. I'm guessing this has to be done experimentally. It might be possible to figure out with KSP's simplified drag model.