maltesh

That should probably work; At least, I don't see any obvious problems without trying it.

I'd been working off the assumption that the satellites had little to no delta-v on their own. Yeah, it will work if you kick off the satellites when you get back to the target orbit. Come to think of it, that's even simpler, because you don't have to go through the effort of re-plotting the phasing orbit for the bus after each deployment.

You can use the KSP UI to create your resonant phasing orbits /without/ calculating orbital periods and semimajor axes. You can use the close-approach UI, the fact that the close approach is /always/ shown after the last maneuver node in your future, and the ability to push maneuver nodes multiple orbits into the future with a click, to create a phasing orbit with no calculations necessary. Wound up throwing together a tutorial here: Phasing Without Calculation: One Weird Trick to Spacing Satellites Using Just the KSP UI

This has probably come up before; It's a fairly obvious use of the KSP UI, so I'm probably not the first one to stumble across it. But it provides a way to set up a simple, equidistant satellite array, using just the KSP User interface, without having to calculate orbital periods. As I understand it, the typical method for, say, spacing four satellites in a circular orbit is to do the following. Launch all four satellites on a single bus vehicle, reach the desired circular orbit, and circularize. Release the first Satellite. Based on the period of the original orbit, calculate the semimajor axis of a new orbit that has ¾ the period of the original orbit (5/4 also works, but we'll use ¾ for the example) and burn to put your bus in that orbit. Go around that orbit once. When you return to your starting point, recircularize. Assuming you used the ¾ period orbit, you will now be at a point 90° ahead of the original satellite. Release the second Satellite. Repeat steps 3 through 6 for the other two satellites, then head home. What we'll be doing here is eliminating any of the calculation of step 3: As long as your initial orbit is circular, you can use KSP's maneuver node and close-approach UI to evenly space out your satellites, without calculating delta-V, and without calculating the details of your phasing orbit. To do this, we have to come to realize two things; KSP's Close-approach markers are /always/ shown based on your presumed orbit after the last maneuver node on your path. By right-clicking on a Maneuver node, it will pop up a pair of buttons marked - and + that allow you to advance or retract a node one orbit at a time. What this allows us to do is the following: Deploy First Satellite and Target it. Create Node 1 to Roughly Estimate Phasing Orbit. Create Node 2 at 0.0 m/s for manipulating Closest Approach. Use Node 2 to Advance the Phasing Orbit. Fine-Tune Node 1 to refine the close-approach. Execute Node 1, Phase, and Recircularize. So here's an example, beginning to set up a four-satellite constellation using the above method. 1. Deploying the first Satellite Once the spacecraft reaches its target circular orbit, deploy the first satellite. It is then necessary to set the first satellite as a target in the KSP UI, so its close-approach markers can be used. 2. Create Maneuver Node 1 Create a maneuver node far enough in the future that you are comfortable manipulating it without catching up to it. I believe the one I've created here is about 10 minutes ahead of my spacecraft. Adjust the PRO and RETRO handles on the maneuver node to create a phasing orbit that has /approximately/ the phasing you want. It's fine if it's a rough approximation, because we're going to refine it later. 3. Create Maneuver Node 2 (0.0 m/s) Now create a second maneuver node further along the path of the phasing orbit. This maneuver node will have a 0.0 m/s value, and will be used to help refine Maneuver Node 1. 4. Use Maneuver Node 2 to advance the Closest Approach After placing Node 2, the Close-Approach Markers in the UI will show the closest approach after one orbit. Activate Node 2, then right-click on it to bring up the Orbit-advance buttons. (Upper-left image). Since we're doing 90° spacing, We'll want to click on the advance button three more times (Upper Right, Lower left, and Lower right) to show the spacing after four rounds of the phasing orbit. 5. Fine-Tune Node 1 to refine the Close Approach Now go back to Node 1 and adjust its Prograde and Retrograde handles to fine-tune the close approach. By doing this, we're adjusting the period of the phasing orbit to get it closer to ¾ the period of the target orbit. Once the markers match up, you're golden. 6. Execute Node 1 and Phase. Now you're ready. You can kill Node 2 now if you so desire; it's still at 0.0 m/s. Execute node 1 to enter the phasing orbit, go around once, and re-circularize when you reach the starting position. Once done, things look like this: The red and green lines solid lines are actually generated by the AntennaRange mod, here, they also serve to highlight the final positions of the Bus (where the green line crosses) and the fisrst satellite (where the red line crosses.). The bus is now 90° ahead of the target. You may now deploy Satellite 2, and repeat. And that's basically the method there. Note that I haven't checked the periapse or apoapse altitudes of the phasing orbits, everything was just done with the maneuver node UI. This method can similarly be used to space any number of satellites; If I'd needed to space five satellites, after placing Node 2, I'd crank it forward four more orbits in step 3. For Six, I'd need to crank Node 2 forward five more orbits, and so on. This method will also work if the phasing orbit is /larger/ than the target orbit; If I'd done the method above with a larger phasing orbit, I'd wind up putting the second satellite 90° behind the target. It also has its utility for Rendezvous; Make your orbit cross the target orbit. Place Node 1 where your orbit crosses the target orbit. Pull prograde or retrograde to spend as little delta-V as you feel comfortable using, and use node 2 to crank the intercept forward orbits until the close-approach markers are close enough, then go back to adjust Node 1's Prograde and Retrograde handles. Execute Node 1. On the orbit where Node 2 now exists, you'll have your close-approach. Hopefully, this has been helpful. Any questions?

I don't currently fly spaceplanes often enough to remap my xbox 360 controller, but when I did, this was the map I used. As for why Action Group 2 and Action Group 5: I use an Action Group Scheme that switches things on or off depending on what the spacecraft is currently doing, rather than concentrating on particular parts or types of parts. 2 is "On-orbit, Maneuvering" which would do things like close intakes, shut off atmospheric engines, and activate rocket engines. Action Group 5 was "Atmospheric Descent mode", which for spaceplanes, would shut off rocket engines, turn on atmospheric engines, and open intakes.

Another option (assuming you're sufficiently far up the tech tree) is an External Seat; Kerbals in External Seats can take EVA reports, and (assuming that you have sufficient power, an antenna, and a link back to KSC) transmit them back immediately.

"Jettison" doesn't detach parts. It gets rid of fairings. At least, that's the way it works with engines, and presumably it works the same way with heat shields.

From what I can recall from Wednesday's viewing, though, he never actually uses any other feature of the device except the camera (assuming that it has other features.)

There's an answer in the time travel situation presented in the first movie: The effects of changes in history take time (for want of a better word) to affect objects or people not in their native time; When Marty prevented his parents from meeting, he had up to a week to fix things before the timestream changes erased him. It may also be that time changes that are large move at a different rate than small time changes; Marty's parents not getting married is a small change in history, took a week to erase Marty. Marty's parents being successful people is a larger change, but still not that significant; Perhaps it might take a few days before Marty's memories realign. Biff becoming a millionaire results in a Hill Valley dystopia and significant other historical changes, including a fifth term for Richard Nixon.That time change ripples through fairly quickly. Marty and Doc and Jennifer happen to be time travelling as those echoes ripple through 2015 I imagine they also cause Old Biff to disappear; his Sports Almanac only goes to 2000, and I don't see him staying alive another 15 years after that.

Given that the time trip takes place five minutes into the film, I figure I'll just start watching Back to the Future Part 2 (Amazon Prime Streaming has all three films up in the US) at 7:24 PM EDT tonight. Since Hill Valley is in California, and the arrival's at 4:29 PM PDT.

For what it's worth, the ore tanks themselves have an inferior mass ratio to the stock LF/O tanks. With that taken into consideration, it remains (slighly) more difficult to haul ore than fuel.

MoarDV and Diddly Feelerino worked together to create a configuration fix for the Near Future Spacaecraft two-man pod in the Near Future Spaceraft thread, back here: http://forum.kerbalspaceprogram.com/threads/52042-1-04-Near-Future-Technologies-(04-09-15-bugfix-for-NFE)/page495?p=2183145#post2183145 Based on that, I threw together a Modulemanager .cfg that works for me, which you can find here: https://dl.dropboxusercontent.com/u/4057920/KSP%20Shipshare/notovny_NFS.cfg Since it's based on that post, though, it only fixes the Navball for the large forward screens.

It doesn't, actually. Jool has about the mass and radius of Venus, and a density of about 4.7 g/cm^3. Earth is more dense than Jool is. (And, now that I look at it, Earth is more dense than Titanium as well.) It's like Jool is a regular terrestrial planet in some kind of bizarre witness protection program. Gilly also just scrapes by in the realm of known metallic elements, at 13.5 g/cc, that's about the density of Mercury or Plutonium. All the other planets and moons are more dense than Osmium at STP.

In the book, as I recall, he had to do it to get the oxygenator and the water reclaimer from the hab into the pressurized compartment of the first rover. Don't quite recall that being explained in the movie, but wasn't deliberately listening for it, either.

It's used to power the ISRU gear for fueling the MAV, as I recall. By the time the crew arrives, the MAV is full of fuel, the humans can unpack and maintain the solar panels on the hab, so they tow the RTG off for disposal, so there's zero chance of accidentally breaking it open during a disaster.

I wasn't annoyed by the depicted simultaneity of that, as there wasn't actually any obvious direct communication between Mission Control and Mars in those scenes. What did kind of irk me was the conversation between Kapoor and Watney, where Watney asks "What did the crew say when you told them?" and waits while Kapoor hesitates apparently for several dozen minutes, trying to figure out how to answer the question, long enough for Watney to follow up with an "Are you receiving me?" Yes, it's his first human contact in months, and I guess Watney doesn't actually have anything to do other than sit in the rover and watch those 70's shows with some sort of countdown clock to let him know when he should be expecting a reply, it just felt a bit odd.

Duna windows are also the least common, occurring about one every 230 earth days, so when I throw to Duna, I tend to throw everything I think I'm going to need at once. That said, 20 spacecraft was entirely too many. I generally limit myself to six to twelve these days. But I'm a long-time devotee of Kerbal Alarm clock, and throwing multiple spacecraft at once gives me the time to scamper to the top of the tech tree and train decent multiple crews before that first Duna Window arrives on Earth-Day 60 or thereabouts, and when /that/ mission arrives at Duna, the first Eve window is opening, and when /that/ mission arrives, it's a short amount of time before the almost-too-perfect-to-miss Second Dres Window (Dres is passing through Kerbin's orbital plane on arrival, and the return window is about 10 days after that), and the missions from the previous two destinations can arrive while that one's in transit.

If you leave the SOI with a low relative velocity, moving in the world's prograde direction, not only are you at your closest point to the world in question, but you're moving faster than the world around the sun, which means your apoapsis is going to be further from the world's orbit than the radius of the SOI. Similarly, if you leave the SOI with a low relative velocity, moving in the world's retrograde direction, you're again at your closest point to the world in question at the SOI boundary, and moving slower than the world in question. Your periapse, by necessity, is going to be further from the world's orbit than the radius of the SOI. Can I ask if this is something you've successfully done in KSP, and which worlds you've tried it out with?

For a darned good guide, see this post: Paydirt: FInding Good Ore Deposits, by Geschosskopf For what I actually do (in collusion with SCANSAT): 1) Use the (orbital) Survey Scanner. THis will give very, very general information about the ore in the biomes. 2) Throw multiple Surface-Scanning Module carrying probe landers, one into each Biome I'm considering landing in. Running an analysis in the biome corrects the orbital scanner values (Especially the ones in the SCANSAT Map). 3) Drop a rover with the Narrow-Band Scanner and the Surface Scanning Module into the best candidate, and drive around looking for a good flat area with high ore. 4) Put the mining base there.

Indeed, your rocket is not aerodynamic, and that causes a host of issues in 1.0+ The lift profile I usually use is this one (assuming aerodynamic issues have been dealt with) About 45% turn shape. Limit Acceleration to 18 m/s ^2. Begin Gravity Turn Immediately. I usually, but not always, use corrective steering, and limit AOA to 5°

Near as I can tell, although it /looks/ like the node turns with the new plane of the post-burn path, the burn direction caused by pulling the node doesn't actually change. As a result, you are indeed increasing your spacecraft's speed, which results in a larger semimajor axis, and eventually, an escape trajectory. Some of this can be mitigated by making your plane-change burn ,bu pulling the normal handle a bit, then the retrograde handle a bit, and alternating between the two to keep your apoapsis where you want it to be. That seems to work up until about 90° plane changes. For plane changes of more than that, you're going to have to fiddle with four handles (Prograde. Retrograde, Normal, and Antinormal) to keep your apsides where you want them to be.

If you leave the miner running on the asteroid and go do other things, from what I gather, the code that runs the drill checks when you reload does not stop when you run out of storage space for the fuel or ore. So,when you reload after sufficient time, the asteroid can wind up completely depleted.

Light carries momentum and energy without having mass.

Surface-mount a Clamp-O-Tron Jr, and then use the rotate gizmo to make it parallel to the thrust vector, and use the "Control From Here" option on it when preparing to burn?

By using Modular Fuel Tanks to convert standard tanks to all-liquid-fuel, and Kerbpaint to give them a red color scheme so I know which tanks are LF-only in play.