Plusck

I too have had problems with my drill ships shutting off. However it is certainly not something that happens all the time, and I don't really know why. I don't use fuel cells (but I think I'm going to regret sending a miner/converter to the Jool system without one). My ships' designs are all based on much the same core set-up. From memory, the last times they shut down while absent were: on Ike on a 7% ore resource, and on an asteroid. On Mun and Minmus, ore concentrations are lower and I don't recall them ever shutting off. So if I combine that with the hints above, it may well be that my drills were filling the ore tanks too quickly. Drills will happily spin up to 100% efficiency while tanks are prohibited (useful for smaller asteroids so as not to waste asteroid mass) but could it be that this only works while the ship has focus? As for the stock mining system, I have no complaints about it. The instant survey could maybe benefit from a slight time-based requirement (e.g. you have to click the survey button twice with at least one orbital interval) for the role-players amongst us, but since the result of the survey is so general anyway that doesn't bother me. Any other problems I've had with the stock system have been entirely my own doing: a great one is my habit of forgetting to put antennae on my survey craft. :/

I initially didn't understand why you have the Mk1-2 pod + heatshield + stack separator on top there. Since there is no propulsion system attached to them, you're going to have to bring the mobile lab all the way back to Kerbin and then ditch it in the atmosphere if you want to bring anyone back. If you really need to bring the pod home, it is possible to add the smallest 2.5m fuel tank + radially mounted twitches to the command pod and have it lift off the top of the lab on the surface of the Mun. Alternatively, bring the top part down to 1.25m scale and just have a single-occupant command pod lift off (much easier on weight and fuel). If your contract imposes a 5-kerbal capacity, you can always add lander cans or command pods. Just don't forget the docking ports (radially on the MPL works fine). To land an MPL on the Mun, I always use four radial rockets (similar to Snark's suggestion, except I generally put an X-200-8 on the bottom of the MPL and radially attach four FL-T200 tanks to it, with terriers underneath and fuel lines to keep them supplied from the centre tank, although this gives you far more fuel than you need). If you need more kerbal capacity, you can attach these in pairs and put lander cans or command pods on top of one of the pairs, and leave it all behind when you go back home. The other advantage of reducing the Kerbin-return section to the 1.25m form factor is that it completely solves the Science Jr. issue, since you have a 1.25m section to house it (and even bring it home safely if you want). The other options would be under the docking port or in a 2.5m service bay: it does fit. And finally, to future-proof the lab if you leave it on the surface, add batteries, solar panels (the retractable ones) and antenna to it. Then you can leave a scientist on it to generate science points, and come back later in the game to pick him up. If you don't have a spare scientist, just dump the lab on the surface and then come back to it once you have more staff. Whatever you do, you will not regret having plenty of batteries. You could also future-poof your lab to make it possible to complete a potential "expand your outpost" contract. On the Mun, that generally means leaving a docking port fairly low down at a pre-defined height (the centre-line of the biggest landing legs is a useful indicator) so you can drive a future rover up to it. Be prepared for pain and frustration in the process though... For the Kerbin ascent part - I never build so tall, because that means I'm lifting a huge amount of fuel + unused rocket engine above a single engine. My centre stack tends to be X-32 + X-16 (or rarely a single orange) with Skipper underneath, then asparagused 1.25 stacks (generally two side stacks of 2x FL-T800s) with Reliants or Aerospikes. That gives a relatively cheap and reliable (and efficient) middle stage for a wide range of payloads. Then add asparagus 2.5 tanks (with bigger or smaller engines, depending on payload) and/or boosters to get out of the lower atmosphere.

I've had a few of these contracts. The thing that should have struck me as suspicious the first time around was the huge amount of cash they were offering just to go to one location that was so close to where I had a landed Kerbal on Minmus. First rule of contracts in KSP: read carefully and check for the catch. So I was forewarned when I had the same on interplantary missions. I was wondering if the purpose was to lead me to one of the game's easter eggs, but if it did I missed them : D

Really? Wow, ok. I didn't think he'd made any KSP videos in the last year or so. My bad then.

Turn the whole craft, place object, turn the whole craft back? Not sure I understood the premise but... And anyway, I really don't know if the SPH (or VAB) will agree to do what you are asking it to do.

Ah well, you were much more thorough than I was. It didn't even occur to me to look at the staging icons, which was a bit stupid. I placed an OKTO under the parachute since that's what it sort-of looked like and that's what I would do. Since there was no sign of solar panels, I crammed the service bay full of the basic battery. Stupidly, I didn't bring up the resources window during flight, so I wasn't watching electricity levels. However, you are right that it is not tier-4 tech. It is tier 5. However since I couldn't work out what that top white section was, I suspected that it might have been unlocked... I accidentally sent up Valentina on the first flight, so she had piloting abilities not necessarily available at that level in career. However, the steering was so excessively overpowered that I ended up shutting her controls off and doing it myself very early on. : D edit: P.S. as you might have guessed, your analytic post wasn't at all visible while I was writing mine. Luckily in fact, because it was so exhaustive I'd probably have given up in disgust ; )

To be honest, I don't know what I can add to that. To Snark - I think we agree. : D To Warzouz - UI problems (endless VAB frustration, painful manipulation (or inability to place) manouvre nodes) are my main gripe, but that isn't the subject here. However, I'm not sure that TWR and dv would necessarily be a help in stock, because inexperienced players can rely on the figures and create problems for themselves rather than figure out what should work. But again that isn't the subject here. : D For the Klaw though, is detestable.

It seems nobody has said it yet but: Scott Manley's videos are now completely out of date. [edit: my bad - I see he has done a few videos since version 1.0 came out dealing with the aero changes. Still, I think it is important to view his videos in the context of the development of the game, so a lot of what he does in them will not work quite as expected in the latest version. That said, I stand by the following: ] Use them for ideas, yes, but not for things like how to deal with the atmosphere. Anything that you see that is prior to 2015 that talks about how to do a gravity turn is virtually guaranteed to be wrong. If your boosters are properly attached near the bottom, maybe with a single strut at the top for very tall stacks, and if you try to stick to prograde all the way up (so you start with a couple of degrees east as soon as you leave the launchpad) then you shouldn't suffer from wobble and you shouldn't need mods to help you get to orbit. I tried building your rocket, without all the struts. KER gave me a dv of about 5700 m/s. There wasn't really a problem with wobble as such (though there was some). There was a serious problem of excessive control with the tail fins. Tail fins are not meant to be used on rockets - they are far too powerful at rocket speeds. SAS was absolutely disastrous with them, so I just deactivated it and went up manually. It was a horrible flight profile but it worked fine. My second problem was working out what you have at the top of your rocket. I tried with a crew cabin, and that was what gave me about 5700 m/s dv. Then I thought it might be a Mk1 liquid fuel tank. That would explain some of the dv loss since it is just dead weight for your rocket: without oxidiser it is useless. So I built a second rocket with the Mk1 liquid fuel tank and changed the tail fins out for the other tech level 4 control fin. It was still massively overpowered but it was better. KER gave me a delta-V of 4,800 m/s. However, in your pictures I don't see any separator under your heatshield or under whatever that top white section is. If there isn't one, you're lucky not to have made orbit since your tourist(s) would have died coming down anyway : D So what can I suggest? First, you don't need mods. They are not good for new players because you need to get a feel of what is happening. Without mods, I don't think you would have built such a huge rocket. It would have been smaller, it wouldn't have lifted off the pad with whatever all that weight is up top, and you'd have found and sorted that problem rather than simply making it huge. You wouldn't have had the dv info, specifically, but your experience with previous builds would have told you that something was wrong. Second, there is no need for such tall rockets until much later in the game, when you have bigger (and stiffer) parts. Using a mod to make your rockets stiffer is not really a help, because a squatter and sturdier design will be cheaper, lighter and get you to everywhere you want to go anyway. And finally, read the parts description! The tail fin is clearly described as being for aircraft. Sure you can put it on a rocket, but 5 seconds of flight should be enough to tell you that it is massively over-steering.

I'm torn between agreeing and disagreeing with this. To agree: I have regretted the absence of four sorts of things in the stock game that make a lot of designs impossible: hinged things: this would immediately make Reactordrone's example into something very similar to what one would do IRL. The basic lander would stay the same, only it would be folded in on itself to fit under a fairing. Once in space, it would be unfolded and locked, and the direction of the hinged joints would automatically give the greatest strength to the direction you're adding the load (i.e. the claw would pull on the hinge, pulling the structure together above it, and the rockets would be moved to the sides to push the joint together too). rotating things: opening up the possibility for swivelling nacelles for VTOLs, space station hubs and suchlike. extending things: just like solar panels, only with some structural strength (good tensile, but obviously not much shear), making landed outposts much simpler to build. EVA-built connectors: i.e. fuel lines and struts that Kerbals can add. And of course there are mods like KAS and Infernal Robotics which deal with these issues. To disagree though: it is a game, and IMO the strictness and simplicity of the rules governing a game are not in themselves a limit to its interest. People can spend a lifetime playing chess. Rather it is the choice of rules, and each of those four examples above would easily lead to a multiplication of "Rube Goldberg" solutions to any given problem. In other words, adding realism and immersion can be a Good Thing for many good reasons (and I don't want to even touch the "procedural parts" debate) but such mechanisms multiply the complexity of the game for the player and for the CPU, and vastly increase the likelihood of unforeseen problems. As the game is now, if it lifts off the pad cleanly then the vast majority of potential structural problems have already been sorted (the Klaw being the obvious exception). With hinges and extenders, a whole world of physics abuses and problems opens up. Being somewhat a purist, I have only recently installed KER and haven't tried any other mods, but the potential for Kraken-like problems with the ones that add structural functionality seems clear. So I tend to find criticism of the game's limitations (and I repeat, I do not want to touch the procedural parts debate at all, at all) to be unfair. A game cannot pefectly imitate real life: a Slinky is a trivially simple device but is good evidence that we are not living in the Matrix, because can you even imagine the processing power you'd need to model it? I would really, really like to be able to fold payloads up. Since we can't, we have to improvise. When I see people's clean and aerodynamic solutions to problems I often have a "doh!" moment. When I see things like Reactordrone's solution I feel better about my own (far uglier) contraptions. However, I'm generally forgiving about the game's limitations because the sheer variety of other people's solutions convince me that there is surely another, better way. TL;DR: I too would like other solutions, but in most cases their addition would add to potential problems. There is almost always an elegant alternative solution with stock parts, but we don't all necessarily come to it on our own!

For this part, I think I must have been unclear. I wasn't suggesting not landing on the Mun (which is essential, as you say, and much less forgiving than Minmus), but rather not using the Mk1-2 pod to do it if you want to travel light. The Mk1-2 command pod (with monoprop) weighs 1.37 tons per occupant. Although it does have a lot of things going for it (space for docking port, decent torque, stability on re-entry, etc.) it is the heaviest option when it comes to landing crew. Mind you, the Mk2 lander can is (inexplicably) not much better.

I've never, ever had a problem getting under safe opening speeds for parachutes in stock 1.0.5 (medium difficulty setting), except in the very early career (I lost Jeb...) with suborbital flights. I have opened parachutes in a mountain valley once or twice, at under the height of the alarmingly-close peaks, but that's it. Maybe I'm just not making my ships long and skinny enough. For Mun or Minmus I tend to set Pe to about 30km, and generally take off 50-75% of ablator in the VAB (though I often forget). I've never used drogue chutes or airbrakes for in-system reentry, only for interplanetary missions. So I'm finding it hard to visualise how it's possible for this probkem to arise. I've also stacked two Mk1 pods to take tourists around, and that worked fine too, although I can imagine that more than that could be a problem. As for suggestions... you could try; - reducing the ablator load in VAB - using landing legs as airbrakes. If your tourists need to land on the Mun, this would mean re-entering upside down, so you'd put a heatshield on top of your lander and deploy landing gear at about 10km on the way back. - not stacking more than two pods, or using an oversized heatshield if you do - getting rid of monopropellant if you don't absolutely need it (which you shouldn't at this stage in career if you're not docking) - finding the perfect re-entry Pe. Basically you want to ensure that you're low enough to have a nice long arc in the 10-14km zone, but high enough to ensure you don't get there too quickly and explosively. 29-32km directly from the Mun or Minmus works really well for me. edit: actually on rereading your OP, I don't quite understand the 55 AP and 55 PE orbit and dropping of engines. You really don't need to use engines to brake for re-entry from the Mun or Minmus. It can actually be counter-productive since your high orbital velocity on arriving at a Pe of around 30km means that you spend quite a long time there before slowly dropping. If you try to brake too much, your angle as you hit the dense lower atmosphere will be higher and you'll spend too short a time there before lithobraking.

If it is successful, what more do you need? 580m/s to land on the Mun is an absolute perfect, lossless landing from an extremely low orbit. I have a station parked in a higher orbit (which has ended up being an unnecessary 40x80km elipse) to make warping possible, and it takes about 750-800m/s for an average landing while aiming for a specific landing site. Therefore, landing a 4-ton Mk1-2 pod is to me the most obvious thing not to do on the Mun to simplify your life in future. I understand that you're aiming to reduce debris and wastage, so bringing your expensive scientific instruments back to Kerbin on your pod is better than abandoning them (especially since you know you'll get better instruments in future, so therefore a permanently orbiting Mun lander that you refuel before using is not yet an efficient option), but heatshields can be added to lander cans for return to Kerbin, cutting weight drastically. As for the heatshield - you're carrying at least 600 Kg more than you need in ablator for a Mun or Minmus return, and you can reduce this with a right-click in the VAB. Finally, nosecones. I've gone through phases of adding them to everything, and not adding them at all. On balance, I think it is always preferable to add them if feasible.

This topic sprung to mind last night as I completed a painful transfer burn to Jool with a 36t payload. The whole ship was an ugly mess: More pics at http://imgur.com/a/AJbkf The transfer stage had a starting TWR of 0.10. Ugh. So the burn had to be done over two orbits, the first using the last of the lifter stage (plus some fuel from the payload, so the final payload is actually more like 33t) and the second an excruciating 13 minutes of mostly prograde burning. After a failed first try, the manouvre node for the first orbit burn was deliberately set too early in the orbit: that meant that the last 600 m/s or so of the second burn, which unavoidably continued well past Kerbin Pe, ended up giving a decent ejection trajectory. In my defence, I launched the ship without KER installed so I gave the transfer stage too much fuel (to be safe) and not enough TWR (because I didn't think it was so low).

The way it is supposed to work is that if the heavy orbiting body catches up with you, you get dragged around it and then thrown out forwards along its orbital path - thus theoretically adding the body's original orbital speed to your own. If you catch up with it, you get pulled around and thrown backwards - thus subtracting its orbital speed from your own. However, in KSP it hardly ever works exactly like that because with few exceptions (Eve, Jool), moons and planets are not massive enough to make such a huge change in your trajectory if you are travelling at interplanetary speeds. So what you want to do is benefit from the most useful part of that phenomenon to help you out. No moon is heavy enough to spin you right round, but many of them are heavy enough to give you a quarter turn or so. So you cut in front of the moon at an angle so that it accelerates you backwards, or you cut behind it so that it accelerates you forwards. And because of the way they form, solar systems are naturally set up to help you out. When you transfer up from Kerbin to Duna, and assuming that you have made the absolute minimum transfer to get an intercept, Duna will be going faster than you and will therefore catch you and throw you forwards after you pass behind it. The opposite should happen for Eve : you catch up with Eve just at the edge of its SOI, so you pass in front of the planet and are thrown back at a slower speed along its orbital path when you return to Kerbol SOI. And the same is true of the moons - when Jool is catching up with you at your Ap from a Kerbin-to-Jool transfer, the closest moons to you should be the ones on the inner edge of the Jool system, and their speed relative to you should therefore be slower than the Jool system as a whole.

Have you accidentally applied roll trim - using Alt-Q or Alt-E ?

Ok, well this part of my post is simply flat-out wrong :/ Testing using KER, when drilling out an asteroid, showed that the combined mass of the ship + asteroid was decreasing while the drill operating efficiency was less than 100%. The mass remained constant when the drill was at 100% efficiency, and stayed constant when I sent the engineer out on an EVA. Therefore it doesn't matter whether you have an engineer on board or not, except in terms of time. The engineer's presence will increase the speed of ore output, but has no effect whatsoever on the efficiency of the drilling operation. When at 100% efficiency, the drill gives a 1:1 "conversion" ratio of drilled resources to ore. So if you're drilling an asteroid, the one thing you really must do is to drill a maximum amount of ore at one go, since you are losing mass (to space?) during the drill's spinning-up phase.

Logically, the data points can only be added to a lab if there's a scientist in it. Therefore, to allocate data to two different labs, you just need to transfer the scientist from one to the other. How the data is allocated if both labs on a vessel are staffed is another matter, and I really don't know how that happens. The only time I've ever had two labs together, I only had one scientist on board.

OK, I'll bite. : D So I made your "not very sophisticated" design. However, since we're talking about landers capable of doing something, I added some monoprop (minimum possible, but enough to allow a fair amount of orbital manouvering), some solar panels (again absolute minimum possible), some batteries (idem), a hex probe core (because we want to send a scientist to do science, or be able to pick people up), and some experiments (everything except for the materials bay, which would have been excessive, so five in all, plus an antenna). I was tempted to add a spotlight but decided against it, to keep to what is strictly necessary for a fully functioning lander (dark-side landings are optional, after all). All of this takes KER's estimate of delta-v from 4000 odd to 3245. I sent it up to my Mun orbiting station, refilled it, then took it down and back up. Since I hadn't flown the vessel before, I think I did about 6 tries on the landing to get the most efficient burn possible. From 3245 m/s dv on leaving the station, this dropped to 3208 after the deorbit burn, and 2501 on landing. Fuel went from 405 to 275 (67%). I then went back up, lost about 40 m/s on fluffing the orbital rendezvous with the station, and spent exactly 1 unit of monoprop manouvering (yes, I'm better at docking than landing, it seems). This took me down to 1766 m/s according to KER, and 172 fuel (42%). Since there was clearly enough to go back down again, I did it all again, getting a best-effort landing with 1050 m/s dv remaining (91.5 fuel or 22.5%) and back up with about 300 m/s dv (22 fuel or 5.5%) left, though admittedly it was somewhat approximate return to orbit since I was just wanting it all to end by that time. I did try to take screenshots at each stage but I'm not sure if it's worth putting them all online. This is a pic of the craft leaving the surface the first time around: So firstly, yes my "rule of thumb" was a bit off. I should correct it: "To get down to the surface of the Mun, you will generally use a bit less than half* of your fuel (assuming your vessel is mostly fuel). Getting back up will generally take a bit more than half of what's left. * NB: If you add even more fuel to your lander, you might make that proportion more one of thirds (i.e. a third to get down, slightly more than a third of what's left to get back up) but you'll end up using a lot more fuel in total. This is a variation on the law of diminishing returns: you can keep adding fuel, but it'll end up only marginally increasing your Mun landing / reorbiting capabilities. At the other end of the scale, you can reduce your fuel mass to slightly more than half your total lander mass, but you'll have no leeway for the slightest inefficiency." To be honest, I still prefer my original rule of thumb. : p

The LV-N / ISRU combination is odd for that. It appears that even though the LV-N generates electricity while running, it also needs to have electricity stored inside the LV-N itself (a tiny amount admittedly) to run properly. For some reason, the ISRU seems to draw the very same electricity that the LV-N needs even if there is electricity available elsewhere on the vessel, so your "Prop" drops. What is even odder in your screenshot is that the LV-N says its internal storage is full. Whenever I've had the same problem it has been at zero. And also it says 33.93% requirements met, but with me (IIRC) it has always been 50% (on one of a twin- LV-N vessel, so logical there).

I would say that this thread should be allowed to die, since almost all of the info in it is wildly out-of-date. I've only checked a few pages but from the first post until page 9 (out of 10) there is wrong info. Among the most glaringly wrong things in the thread for the current version: - one scientist needs to be physically in the lab for it to work, or to add data to it. Two scientists physically in the lab for maximum data-to-points conversion. - having experiments attached to the lab is pretty pointless. About the only one that might be worth having is the gravioli one since it takes different readings for "in orbit over X biome", but that is an expensive addition that would be better on a lander. So really the whole thread should be marked as "no longer relevant".

Well, I'd have to test to be sure, but from experience and memory I would say: - yes, conversion ratio is fixed. For the big ISRU it is 1:1 mass for LfOx. Less for monoprop. I haven't touched the small ISRU due to wiki and forum posts about poor conversion ratio. - energy use is directly proportional to conversion speed. The wiki gives 30 electricity per second for 0.5 ore per second at 100% efficiency, and I have no reason to doubt that. - conversion speed appears to be directly proportional to % efficiency. I'd have to test but I have no reason to think it is anything other than a percentage of those wiki figures: i.e. 10% efficiency means 3 electricity per second for 0.05 ore... - % efficiency is an inverse function of the difference between current temperature and 1000°K, apparently as some sort of sine function. Thus, as temperature rises the % efficiency rises very slowly at first, speeds up in the middle range of 30-70% then slows on approaching 100%. Since the part has a 2000°K heat tolerance, I would guess that exact same efficiency function continues above 1000°K (i.e. slow decrease in efficiency in the 1000-1200° range, speeding up afterwards and finally slowing to 0% as it explodes).

For cooling, it appears that both the drill and ISRU need significant cooling. I've found that a couple of small heat control panels ("Thermal Control Systems") + a couple of 6-panel solar panels on the adjacent part isn't quite enough to stop an ISRU going over its max operating efficiency. However, it takes a significant amount of time to exceed maximum-efficiency temperature meaningfully. I don't think there is any need to worry about too much cooling for either of them: the thermal control system shouldn't try to cool the operating "core" directly, but rather the "core" heats up independently and that hot core then heats the part and adjacent parts, and it is the latter that is cooled by the thermal control system. As for efficiency and power usage: the stated temperature-dependent "efficiency" of the drill and ISRU appears to be merely a question of operating speed. So taking the ISRU, for example, a 100%-efficiency (1000°) core will consume vast amounts of electricity and convert ore correspondingly quickly, while a 10%-efficiency core (can't remember what sort of temperature that corresponds to - maybe 500°?) will consume much less electricity and convert ore slowly. The actual efficiency of the conversion is unchanged. The engineer affects drill output over time, but the drill operating speed and energy consumption depends on its temperature. Therefore it seems that the one place that you don't want to drill without an engineer is The place where the percentage operating efficiency is most significant is when drilling an asteroid, since it will lose mass as you drill, but this mass will only be converted to ore on your ship at a 1:1 ratio when you're at 100% thermal efficiency. If you run out of ore storage space, the drill simply does nothing at all. Therefore the best way to drill out an asteroid while preserving the maximum amount of mass would probably be to prohibit use of your ore tanks until the drill is up to 100% efficiency, then allow the tanks to be filled. This also means you can happily leave ISRU and drills running together (provided you have sufficient cooling) and be sure that you are obtaining the most efficient output. at the same speed* with or without an engineer, but ore output will vary greatly depending on the presence and level of the engineer. * (at least this is what it looked like to me the last time I did it. Unfortunately I don't currently have a good way to check the figures)

Depends. If the base needs 4000 fuel or something like that, then maybe not. Otherwise, probably yes. A Minmus base that doesn't have extreme contractual conditions is generally mildly profitable and generally useful for your future career missions.

No, it's merely annoying. First, I said it is a "rule of thumb". Second I said if your craft is mostly fuel, then... blah blah blah. So you saying "nope" was just stupid and annoying, since what I said is most certainly true, as a rule of thumb, for a lander design where the mass is mostly fuel. What might have been intellgent would have been if you added something interesting, like the average delta v budget of a single-stage lander-type vessel in vacuum that uses neither the LV-N nor ion engines. And I'm guessing it'll be about 2.5x to 3x Mun low orbit velocity.

To be honest, I'm not sure the logs will help much. The stickied thread at the top of this subforum tells you where they are. The Docking Port Sr. is supposed to be significantly more powerful than the standard one, but most people seem to complain about it being not powerful enough. I've hardly used it so I'm not in a good position to comment, but I don't think it should ever accelerate your ship - even a light one - to more than 9 m/s (which appears to be what is happening here). So either it's your mods (and this should really be in the modded installs subforum), or someone else will be needed to help you out. Sorry !