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.