Hotel26

KSP Parts lists the LV-N Isp (specific impulse) as 800 in a vacuum, the highest rating in the table and higher than the 345 cited for the LV-909. Quoting the KSP definition of Isp: "The specific impulse (usually abbreviated as ISP) defines the efficiency of an engine. It is linked to the thrust and fuel consumption." Clusters of a dozen LV-N are standard for my interplanetary missions and I have a GP booster designed around them. Only disadvantages are burns take longer, overheating has to be mitigated and there are restrictions on how LV-N are mounted (not directly under an orange tank).

One more upvote for the Puff. Two of them in the xenon/monoprop craft pictured (Gossamer Albatross) is enough to achieve 300 m/sec cruise and then slow to land so I have no doubt it could even make it into Mun orbit. Weight and endurance were critical factors and carrying more than 2 kinds of fuel was not feasible.

I'd like to support those in this (long) thread that have suggested the ability to qualify to "build bases" and I imagine that in something like the way one gets the damaged KSC "repaired". Go to an area and do a number of trips in and out. Mine some resources. Hit some trigger that says, "OK, now you can choose to build a spaceport here". It would allow you to refuel ships and be used as a hub for exploration. Run enough ships in and out of the hub and then be able to build or deploy ships there the way the VAB does at KSC. I have an ion-powered "flitter" capable of transporting 24 tourists in lo-grav environments. (I play exclusively in Sandbox mode.) I'd like to run tours to canyons and interesting peaks and see what gives at the poles, but I'd need mining sites along the way to refuel it. (I'm going to have to cheat with replenishing xenon but my rule will be that if I have the monoprop on hand in a fuel truck to fill it, then I can top up the xenon, too.) More than tourism, I'd find it fun to make settlements all over the Mun and run suborbital flights to move Kerbals around. It'd be fun to set a 5-year alarm on every Kerbal that goes off to say, "Jeb is homesick for Kerbin", and book him a flight back home to see his Mom... I ran a "game" recently to land Kerbals (male & female ) onto every island on Kerbin just for fun. It was fun, too! I haven't really gone near spaceplanes much but it doesn't really feel right to take the stock "heavies" and touchdown on grass. It'd be great to be able to qualify to build an airport (say, when the local population of Kerbals passes some threshold). When I first heard about mining in KSP, I thought, "yeah, that will be boring". In effect, it's been a great reason to practice landings and make 'em close to the fuel truck! I guess I can do all the above with stock KSP but a lot of life now in KSP is becoming more and more about pumping fuel or driving a surface truck from drill rig to drill rig or tending ISRUs... When you've done that enough in one place, it would be great if you could say, "yep, I've earned it, give me a space port here". Well, my 2c fantasy...

One thing that has always impressed me about KSP is: a) the decision to NOT model the true solar system was very wise; (because it allows:) b) it may seem subtle at first, but the more you explore, the more you realize that the Kerbol system is a set of cleverly graded exercises. Two things, really. Changing anything that already exists and that players may have heavily invested in exploiting (e.g. mining sites) is likely to be a dangerously political move. I haven't been everywhere in the system yet but That Day is approaching, so my vote would be "add another planet, [pretty please]" and, yeah, put a different spin on it.

[Ion engines suggested above is a good idea] I found Maccollo's post below very helpful: I ended up actually putting a fuel dump into 6Gmx6Gm helio-orbit at the required 7-degree inclination. And then rendez-vous'ing there to refuel for the Moho intercept. I have considered also using aero-breaking at Eve to pay for some of my descent into the gravity well. (I think Eve is at 8 gigameters, from memory?) In any case, you need a lot of good timing on your side to get to Moho in one shot and then you need a massive deceleration to catch it. So I prefer a multi-step plan. Do scroll down to and read Maccollo's article in the post cited above though. The main point is that you want to go when you can perform the inclination change simultaneously with the transfer burn (Kerbin departure)

@tjt, thank you. You can play with the periapsis you set; typically this approach dumps you out just a kilometer or two above the target. It's not meant to put you directly on the ground. If you overshoot a vertical suicide burn, you have committed suicide. If you overshoot a horizontal suicide burn, you have only overshot your target. The first one I did was over Moho at the strong end of the log-grav spectrum and it was a 51 second burn and I was amazed when it finally pulled up so close to the target. The experience is worth trying once. You do have to watch as your speed picks up as you near the periapsis and you do have to recalculate the trigger distance, but once you've calibrated from the the first approach, you're good. I'm working on using the technique from however a late and steep approach you want. Just draw a maneuver node and end it in the dirt somewhere a kilometer or two past your target. I'm still tuning the details, though... (I've also watched Sirine's video a few more times, as well. )

@Blaarkies, thanks for the comment! I don't know about that because the deorbit burn (Pe 30km down to 6km) performed 180 degrees before the target only lowers speed by a very few m/s. And then the speed steadily picks up especially by the point 90 degrees before the target, which (with 270) is the best place to perform an inclination change, at which time you are also starting to get very busy. And then that inclination change will affect your Pe which may then need to be readjusted. And finally, I only put the inclination change in the list for completeness; the usual situation is that the craft and its target originated from the same station in an equatorial orbit and everything is all aligned. @all, my mistake for entitling this post "Pinpoint Landings" because what is on my mind, as you can tell from the introduction, is "most efficient landings", revisited. And the purpose of my "horizontal hockey stick suicide burn" is not to place you at a pinpoint location on the surface but to set you up in a manageable location very close to the target to allow you then to enter the pinpoint landing phase, performed however you normally do that. Let me put that another way: my usual algorithm had been to use an asymptotic rule at my orbit altitude of 20km to halt my orbital speed directly over the target. Then be in the bird's eye position to spot my landing, right up nice and close as you please. But is it *efficient* to land from miles above, reading the comix while you wait for the lunar gravity to get you down? One more comment: if you spot your landings by flying your lander as if it's a helicopter, your boss is not going to like your fuel bill. Please stay tuned for an announcement...

Thanks for the humor! I have found that waiting 180 degrees to land from a low orbit means you can't warp and who can wait? So I am working on refining this for steeper approaches. Distance from target as a trigger for braking can still be used. And by the same token, if one is in an all-fired hurry to get down, coming down like a fireball is pretty exciting! Pinpoint landings are always going to come from either the Mk 1 eyeball or Mk 1 navball at the final stage, yeah?

I found the following was the last piece in the jigsaw that unlocked those occasions in which I still got stumped; it's definitely only one trick in the armory. If you have two craft in circular orbits with fairly close inclination, I use Kerbal Alarm Clock to tell me how long and how many orbits to the nearest approach. They don't have to be close orbits and, in fact, more distant orbits provide faster opportunities. Then I look at my orbital period: say it is 40 minutes. So then I set a Nearest Approach alarm to go off 40 minutes before the event. When it goes off, that means that sometime in the next orbit will be the time to execute a Hohmann transfer to the target orbit. Set up the maneuver node and then drag it around the orbit ahead of the craft until the intersection markers are closest. Then execute that node. Set another alarm for the newest Nearest Approach which ought to be within a few kms. Target mode retrograde at that nearest distance to cancel target-relative velocity. You're ready for final approach which is gonna be a bit like Putt-Putt. (Or more advanced, "fly the ball".) If your orbits are too close or too many phasing orbits apart, Nearest Approach may not find one. In that case, radically change your craft's orbit altitude. Higher if you are in front of the target. Maybe lower, maybe, if you think you are not too far behind. Higher will always work, eventually, but may use more fuel than necessary. You'll figure out the fine details later.

(Apologies in advance for opening a topic again on something that's been discussed a lot but don't want to reopen old discussions either...) Apologies also if someone has already pointed out what follows... S = 1/2 a.t^2 The concensus in the forum seems to be that the best way (no atmosphere) to take off and the most efficient way to land is expend the greatest percentage of work on the horizontal velocity component to either establish or eliminate orbital speed. This is in line with Newton's idea that if he could climb a high enough mountain and shoot a baseball toward the horizon at a high enough (instantaneous) speed, it would come back to hit him in the head 90 minutes later. The problems with screaming in low and fast for a landing are terrain clearance; pilot reaction time (as this will effectively be a suicide burn which is what makes it efficient); and therefore inaccuracy. I just tried this at my mining camp on Moho and touched down softly 24m from the target. (For those who religiously don't use MechJeb, leave the autopilots alone but MechJeb provides essential displays; in this case: Orbit Info; Surface Info; Vessel Info and Rendezvous Info.) I suggest the procedure is as follows: perform any desired inclination change 270 degrees before the target; lower the periapsis to a few km above the target, 180 degrees before the target; on the first attempt, use the altitude of the highest mountain as your target periapsis to avoid premature contact; watch true altitude for a minimum which will tell you how much you can lower the target periapsis on future landings; your speed will increase as you get lower which means that your orbital speed will serve only as an initial (low) approximation; Vessel Info displays your max deceleration rate. Reducing speed from 828 m/sec with a deceleration of 16.18 m/sec/sec will take 51.2 secs; S = 1/2 a.t^2 suggests that in that 51.2 secs you will travel 21.2 kilometers; when the Rendezvous Info display says you are 21.2 km from the target (or a little before if you are nervous), fire Full Astern; Using a periapsis of 6km above the target, I arrived 2km over the target and a little after the target (because I got distracted and fired late). And vertical and horizontal speed zeroed out approximately together, which is what you'd expect from retrograde. (The MSA for this approach is actually around 5.1km, so I possibly can tune this down near 1.1 km above target.) You exit suicide burn at this time or a little earlier, when your confidence is ready. Then fly the navball in what is pretty close to a short vertical descent. The reputation is that this low, screaming approach is inaccurate, but if you are avoiding terrain anyway, it adds up to "landing" (arrival) a kilometer above the target and then a short walk in the park to get down and dusted off. The hard part is knowing when to fire and this is where the equation above is your friend. A quick manipulation of that equation gives you the following: S = 1/2 v^2/a S = 1/2 828*828/16.18 = 21.186 km (If there's enough interest, I'll make a video.)

I've just had this occur. It popped up asking if I wanted to Delete or Cancel. Because I don't trust such things, I went to my directory for the world I had been playing and made a copy of the quicksave.sfs and then clicked Delete. The action taken then by KSP was to delete the ENTIRE DIRECTORY containing my world and months of work AND my carefully duplicated quicksave.sfs copy. All gone. This was my mainline, production world; all gone. [I'm on Linux Mint 17.2 64-bit and I run directly rather than through Steam. I have MechJeb, Kerbal Alarm Clock, Docking Port and Haystack installed. The upgrade to 64-bits is relatively recent and as a result my normal system backups are not operational, which is why I can't just go and get yesterday's KSP state off another disk.] This happened after a crash and the crash occurred because I had done an f5 quick save and I began typing ahead before it had finished ['Z' for max thrust]. I've noticed in the far past that you can crash KSP by triggering a Quick Save while an Auto Save is in progress which indicates to me that the code around saves[/restores?] is not sufficiently interlocked. And the reason I was doing a quicksave during a very long transfer burn is because as of the last couple of months, the nuke engine heat indicators no longer give you a precise warning of when those engines are going to fail. When the red progress bar for overheat gets level with about the 'v' in Overheat [30%?], the engines explode without warning, effectively ruining your day. This happens in a vacuum [alt:150K] with the 12 running nuke engines being the only source of heat. fwiw, the quicksave.sfs looked normal length. guess the moral of the story is that if you are going to back up anything manually, send it outside KSP's reach. and whenever KSP offers to Delete anything it doesn't want to deal with, fully expect it to take the whole world down irrecoverably. you will be better off in all cases, attempting to do diagnosis/surgery yourself, if you have that capability.

I've been thinking about this post for a long time and finally came looking for it. I'm surprised there aren't more people who've chimed in here. And also surprised the lists seem so esoteric to me. But that is a good thing. I'd start with an honorable mention for the very venerable MechJeb. We have a no-mods policy in my household and when I finally buckled and installed MechJeb, my son (8) wanted to know why. He does question authority. But I'd put Kerbal Alarm Clock as #1. You cannot be a Mission Director (and wear the vest) without it. If one could only have one mod, this would be have to be it. #2 is Haystack. Not very glamourous, maybe, but fills a very huge crater in the UI, especially when the chips are down and you are on a 45-second schedule to pull through... #3 would be MechJeb. In the recent transition from 1.0.4 to 1.0.5, I had to live without it for a few weeks and I did quite very well, thank you. But, long ago, it taught me how to rendez-vous. When I couldn't go any further, I installed it and I took notes. Now it seems pretty mechanical and I turn it off sometimes to do critical pieces (e.g. bypass time-wasting infinitesimal matching of planes or prop-wasting docking maneuvers), but, in the main, it saves me time and allows me to focus on the big picture. I'm gonna review every other contribution here to mine the gems... Thanks.

I may have a slightly different take on this. If you want to land on a pinpoint and use the minimum possible fuel, you'd do what NASA does and let a computer do it. Sure, the math/physics is interesting and you'd need that to program the computer, but that is already done: MechJeb. I am exploring mining operations and efficiency for me is measured in terms of repeatable close grouping of landings of the ore transport lander, to the cluster of drill rigs, the cost being my time to drive the ore transport rover from the drill rigs to the lander... So do you want to do it "by hand"? Well, yeah, baby!! I've been developing a procedure to repeatedly get me within 150 meters of target. I have a standard, multifunction (6) lander that that can carry 15 tons of fuel into low, lo-grav orbit, so fuel on the way down to the surface "empty" is not my problem. On my last try, I crashed into the target , just grazed it, on landing. Don't know yet if it was a fluke, but I've modified the procedure to "detune" the final step in landing. Here's the procedure as it is so far... I start with a 20-30Km orbit around the Mun, about 545 m/s 90 degrees before the target, I perform a rough inclination change to center trajectory over the target. (Yes, maybe this requires an informational target display from Mechjeb; certainly the Surface info panel in Mechjeb is indispensable.) 10-15 degrees before the target, I deorbit by reducing the surface horizontal velocity to 400 m/s, then switch to SFC mode on the navball. I hold attitude stable then and reduce to 300 m/s before 3 degrees before the target; 200 m/s 2 degrees before the target; 100 m/s 1 degree before the target and down to 20 m;/s and less as I approach the target longitude. This I call the asymptotic method. It's not the most efficient but it's compatible with the "suicide burn" and it's manageable for a human pilot Next is "ride the ball" and it is hard to describe and it's what makes this procedure deadly (fireball) accurate. There are 4 symbols on your navball [my notation]: your attitude (+), your retrograde (O), the target (T) and the SFC normal (X) (the middle of the navball)). + (under thrust) drives your retrograde, O, away. Your orbit scrolls from O toward X. O also tends toward X due to gravity! If your target, T, is not inline with O and X, it will scroll past you. So you need to use your attitude to drive your retrograde, O, to be in a line, OTX. Your only control is + which positions O (by driving it away). When O is inline, OTX: O drives T toward X. When you get all 4 coincident (with gravity also somewhat in control), you are descending vertically right over your target (and will hit it and die in a fireball). When you get +OTX close enough (coincident) in a line, use the asymptotic rule again to manage vertical progress to land rather than crash. This is all-attention-consuming so all of these activities get assigned their own phase. Once you start managing the vertical, you have to let go of the target: you are as close as you are going to safely get on this flight. If you did 4 right (too well), you are going to hit the target and die, or at least, lose the tax payers' equipment... So this last step is actually part of 5, the vertical management phase, and it is "detuning the result", As you transition from riding the ball" to "land on terra firma", verify the navball is showing just a little misalignment. If not, work on getting some before it's too late. This explanation is maybe a little cryptic and/or erroneous, so let me know which parts are foggy and I'll do my best. This procedure is still evolving, too, so I'd love to hear better suggestions! Here's a mining site with 7 vehicles, http://imgur.com/nzlPK3v , with a 220m spread N-S and quite a lot closer grouping E-W.

I'll publish 2.0 of my Gossamer Albatross. This machine is superb fun to fly and I've never seen so much of the Mun "up close and personal" as I have in the few test flights of the Albatross that I've conducted so far. [ imgur]eM4DU[/imgur] I've put some materials into a folder on Google Drive for anyone who wants to download it and splice it into a quicksave.sfs and go straight to flying it. https://drive.google.com/open?id=0ByXEkzQMfWSJNm1ud2JFamhJNm8 (In the Read Me, I forgot to mention that the solar panels are on 1 and the toggle for the OMS Puffers are on 2...) I look forward to any feedback, suggestions or better versions!

An update on this: I tried a bit harder and discovered my major malfunction was that, if one wants to mount more Dawn engines, one should use the 1x1 rover plates and more of them to make the base, since each one provides a mounting point. Result is that I got 9x Dawn engines on it which means I can hover on the Mun with two-thirds and one-tick throttle. Should therefore work on Duna, too. But the fuel draw is much more than I thought, so the duration looks like 30+ minutes... not 3+ hours. @Dfthu, Dv dunno truthfully. I suppose it's 9x Dawns running for 30 minutes except I have 2x OMS Puffers on the stern for horizontal propulsion. Use them once to accelerate and again at the destination to slow up. I have 500 units of MP available so that might be enough with the Puffers to get you into orbit and even rendez-vous. (I ain't suggesting anybody try that, though!) @Rocket In My Pocket: sincere thanks for posting the second link which is the photo. I'll use Imgur from now on and thanks. The first link (first post) was the craft file of my 1.0 which sucked. The Google Drive link for that is: https://drive.google.com/open?id=0ByXEkzQMfWSJei1jRVczQ290T2c just for anyone who wants to play with it. I won't post my 2.0 in case anyone out there does want to build their own vehicle, but I'll post it eventually. Incidentally, I got my "airline mentality" in gear and put 24 seats onto Albatross 2.0. That'll make the headlines around the Kerbol system if one goes down in a mishap... Have fun!

I've built a prototype of a VTOL ion-drive "hover-raft" for lo-grav environments up to and including Duna. Gossamer Albatross 1.0 It's dual purpose is local tourism as well as commuter flights over about a 30-degree radius of the reference body's circumference. It could serve for rescue too. "Hover-raft" and "mono-prop commuter" are two nicknames for it. Unfortunately, I think I've reached the limits of my VAB capability with this project, so I'd like to open a competition. (Maybe something similar has been done before? Please let me know and provide a link and thank you!) Otherwise, I'd like to propose a challenge. Take a look at the craft file above. I want an 8-seater (6 or above). VTOL. Stays aloft on ion-power alone. Is only fueled with xenon and mono-prop. Is fun to fly and OK to require plenty of advance flight planning. You may use monoprop, e.g. OMS, to propel to speed or to initiate/augment ascent. It *must* be equipped with a refueling "spoon" (similar to that included in 1.0 above): a standard-size dock facing downwards for mating with a fuel-truck rover. Mono-prop is used for initial acceleration and final deceleration and the usual attitude adjustments. After that it should have at least 30 minutes duration aloft on ion-power. The v1.0 posted here needs weight reduction and I wanted to remove the stack bi-couplers and replace the retract landing gear with lighter-weight fixed gear. One last comment: "form follows function". I don't care how ugly the result is (check out my effort!!) as long as it is fun to fly and good for exploration, tourism and medium-distance commuting. Apologies to resorting to hoping other people would spend their own valuable time, energy and expertise working on this but I know that a) I am at the limit of what I can do with the VAB, and b ) there are rocket craftsmen out there who might revel in a challenge like this and enjoy producing something that I believe will be very useful and fun to a lot of others. Want to take a crack at it? Be my guest! Please post your work back in this topic and get some recognition/kudos for your ability!

If the root tool performs just one function, you have to ask why it provides two clicks. I think it's possible that in splitting two craft apart, designating the root node will specify the direction in which the connection part splits away. But even so, a one-click solution would set the root node and then detaching would work as normal. You would still need a second tool to make a connection node in some cases where the editor prefers the opposite end. It's when these two use cases are combined that things quickly get muddy. This post was the most helpful I had found: http://forum.kerbalspaceprogram.com/index.php?/topic/128626-editor-transparent-parts/#comment-2336425

Excellent; thank you.

(This is not a question; hopefully, it is an answer.) tl;dr: summary: activate the root tool it doesn't operate on anything transparent the first node you click will become the "connection" node the second node you click will become the new "root" node This tool (counter-intuitively combining two separate functions(?)) allows you to a) set the root node in an assembly of vehicles and b ) set some other part as a "connection" part, which makes it eligible (little, green, spherical marker) to have new (transparent) parts or sub-assemblies attached there. After you've operated with the root tool on an assembly, you'll likely have to save it as a sub-assembly and then manifest it in a subsequent edit to use it but then it will have the attachment point you need... -------------------- (This forum has been very helpful to me and I am very grateful. So I'd like to feed back something I've learned. Feel free to critique the above as it may be misleading or incorrect!) I had to edit a craft that is actually an assembly of several craft. You know the deal: a transfer vehicle delivers a lander into the destination orbit; the lander undocks and then deorbits to drop a rover on the surface but then land separately or re-orbit... I wanted to pull the vehicles apart to edit some and then reassemble them. (I use common components across a family of vehicles.) I needed the root tool but -- as has been remarked in this forum -- it isn't intuitive. (Which is pretty much inline with the whole "philosophy" of the VAB. ) There is some talk in this forum about cookbook step-by-step use of the root tool and some consensus that nobody knows how it works or how it is supposed to be used. Forgive me if there are some definitive articles about it, as I didn't find it. Hope this helps someone else. And, as always, I stand ready to learn from the more knowledgeable.

You're right. The Wiki says: "The conversion rate of this module is far less efficient than the bigger Convert-O-Tron 250's. " (I should have read the fine print!) I just converted 478 units of ore to receive 86.51 fuel and 106 oxidizer which is a fuel:oxidizer ratio of 1:1.23 and a yield of 20%, rather than 200%, so fourfa's 10-fold divisor is accurate. Thanks very much all! It's a relief to know what is going on. The ISRU is not strictly necessary on the ground. I thought I could use a smaller fuel budget on the lander but it's cheaper to produce all the fuel in space (OR take a large ISRU to the ground... which would mean a third type of flight system).

@Snark Yes, first time using any kind of ISRU. It's the small ISRU. @fourfa Interesting. The small ISRU is only 10% as efficient as the large ISRU?? woah. Redesign. I'll put the large ISRU on the rover on the surface. Although truth be told, I am now producing so much ore that it doesn't matter much except for pride. I'll run a test but it's credible that I am getting 150 units total of fuel from that 1500. Or should it be 300? Hmmm. I can also send some ore space-side and use a big ISRU up there to see what yield I get. I'll experiment and report back here. Thanks for the help, gentlemen.

I have empty fuel tanks, 1,500 units of ore in a tank. 4x Gigantor solar panels extended, and 4 of the small, passive radiators. I noticed that the radiators did not pick up a glow. (And I should mention that they were on a docked lander whereas the ISRU was on the rover docked to the lander. Nevertheless, the ISRU status said temp OK, 100% efficiiency.) Small ISRU runs quickly and at 100% efficiency at optimal temperature. I see that I *am* getting fuel converted but from 1,500 units of ore I only got about 20 units of fuel. There was a Kerbonaut sitting on a chair on the rover but I understand the presence or not of a Kerbonaut does not effect ISRU performance. This is KSP 1.0.5. So what gives? I expected to get 3,000 units of fuel from that 1,500 units of ore... Thanks for any assistance and enjoy your Holidays!

Well, guys... thank you. I would never have guessed you could make this so easy for me. I have just performed two successful tests. With the Duna Explorer, I made no changes but started an early gravity turn and then let SAS handle it by tracking Surface Prograde. Easy to orbit and lots of fuel left, too. With Neptune Gemini, I added steerable winglets, unlocked all the engine gimbals, initiated the turn before reaching 100 m/s and tracked Sfc Pro. Nice and steady, longer in the fiery atmosphere than I liked but it too orbited to 100K with lots of fuel left. I didn't even put fairings on the payload. I want to thank you all: John FX, Starhawk, Warzouz, paul23, Jovus, Pecan, fourfa, GoSlash27 for your insightful xepertise and professional courtesy. Brilliant, guys, thank you so much!

Thanks! I am very happy with all the helpful response and I will consider everything carefully. Most helpful to my sanity is to know that I am not alone in going through this and that it is a big subject: thanks!! The suggestion to post the craft file so anyone interested can lay hands on it is great. Here it is: https://mega.nz/#!ZsBwFIqB