Laie

@Death Engineering: that's not a script, just a snippet of config. You know how to make simple MM patches? If not, drop me a line. Just by the way, TACLS assumes "astronaut food": freeze-dried, single-serve, shrink-wrapped. That's how one Kerbal can subsist on a bit under 44kg of food/year, and why they need so much water to go with it. In that context, a greenhouse turning "waste" into "food" is actually growing MREs from plastic wrappers. The converters that come with the K&K basebuilding kit require copious amounts of electric charge and some ore -- this may actually be apt. I don't think I want to operate them, though.

The general approach may well be general, but requires two expensive maneuvers in solar orbit. In my use case, that turns out to be more expensive than my special solution of dropping do a deeper PE, doing only one other maneuver, and arriving 360 days sooner than strictly necessary. Oberth, I guess: first around Duna, and then from being at a (comparatively) low solar PE. Still surprising, though; 360days is ~85% of a Kerbin year. I'd really have thought that this could be utilized, but cannot find a way. 360d is also more than one Eve year, so I expect one should be able to pick up an assist of some kind somewhere along the way; I expect that this would make quite a difference. Didn't even try, though.

...as in my case, where I want to have the tug back at Kerbin in time for the next ordinary Kerbin-Duna transfer. For that, I simply lowered my PE around the Sun, then put a maneuver at the PE to bring AP down to Kerbin's altitude. It's not hard to find the right PE where things work out to a Kerbin encounter. This method has two benefits: it's pretty easy to plan without any tools, and it minimizes dV at capture. The latter may be of no interest if you can count on aerocapture. In that case, just picking the desired arrival time from a porkchop plot may be the best choice.... well, let's say "the easiest". My transfer returns me to Kerbin much sooner that would be strictly necessary, by over 300 days -- it stands to reason that there should be a solution that requires less propellant and is still on time. I wouldn't know how to systematically look for it, though.

I've heard about changes in drag wrt the 1.8 update, but not 1.9. Generic suggestion to anyone suffering from unexpected drag: turn on drag values in the PAW and look if something sticks out.

The word "reasonably" is doing a lot of work here. Personally, I'm quite interested in alternate transfers, trading travel time against deltaV. However, I usually have a dV budget to start with, or a deadline I'd like to meet. I assume that this defines what is still "reasonable", and what isn't. Otherwise we're at @purpleivan's straight line. Here's the last faster-than-usual transfer I've done. Duna-Kerbin on Y2D025 -- about 300 kerbin days behind the last opportunity, and 600 days ahead of the next one. It's for a vessel that pushes cargo to Duna on every standard transfer opportunity, and returns unburdened in the time between. 1460m/s to a sub-Eve PE 860m/s to Kerbin-Like AP and encounter not visible: ~15m/s plane change an final adjustments that's a total of 2340m/s to Kerbin 1100m/s to capture into 180km Kerbin parking orbit. Because of reasons, aerobraking at Kerbin is out of the question. Factoring in capture at Kerbin, going through two transfer orbits is cheaper than a single direct transfer.

The shuttle is supposed to do the prescribed Duna-Ike trip but that's that farthest it's meant to go. It still needs a crew module to go into the cargo bay, and probably some extra fuel tanks as well. It has no life support converters that would allow for an extended stay, and won't get any. It can certainly carry enough food and water for a Kerbin return without converter, but that's no contingency plan I ever considered. Regarding the converter, it's actually two rolled into one: a) condensate from the air condition is filtered and reclaimed as potable water. b) other wastewater, that can't be easily filtered, is electrolyzed for oxygen. That's Salyut--level technology, and MIR too. The soviets reclaimed some 75-80% of their water (depending on source) and created excess oxygen from electrolysis. TACLS doesn't distinguish between different kinds of wastewater, though, and having two separate converters, you could end up reclaiming all water while running out of oxygen. That's why I combined the two systems into one converter. If you want to copy the system, here's the code:

In my particular case, it doesn't: I've defined my own converter that reclaims most wastewater, and do not use any of the converters that come with the mod. I may bring down greenhouses for the looks, but those will probably provide no food at all. Thanks By the way, the shuttles don't even have wheels, they VTOL by means of servo-mounted engines -- I don't find landing to be all that difficult.

Glad to see that my rant has been useful

Just a quick update. The shuttles have brought down the last Base parts, a first pod has landed. You can already see where the next is supposed to go. Reactor & refinery have integrated radiators, but as it turned out, these are not quite sufficient. On the last trip, I salvaged the folding radiators from a nuclear shuttle... but, Emergency!, the base equipment shut down from overheating when the lander came into physics range, and by the time it was landed, electric charge was wholly depleted. I had to hook up the base to one of the rovers and use it's fuel cell as emergency power supply, before I could bring everything back online. The rover took a leap when hooked up to the base, that's why it's called "jumper" cables, I guess. No harm done, though. Given the relative size of the shuttles when compared to the base, I'm tempted to dub them Hindenburg and Graf Zeppelin, but a) bad omens and b) how am I suppsoed to call the next shuttle(s)? I expect to have three or four of them in due time.

Not much to say, really. It's a Jool "lander" and that's that. Cost was 14,277. I only brought barometer and thermometer. Two verniers for control on ascent, those are cheaper than control surfaces and work right from the start. Launch was basically "just dial in an initial angle and then follow prograde". I blew extra funds on a fancy probe core so I don't have to use an autopilot mod for maneuvers -- Mechjeb's Smart A.S.S. is open just so you can see that it's inactive. I assure you that throttle was controlled manually on all maneuvers. I used a Tylo assist, but even without that it's under 4km/s from LKO to a safe landing on Jool. With the parachute fully deployed, descent slowed to 1m/s, so I could safely deploy the antenna and start transmitting. Data from the upper atmosphere was stored on the instruments until then, data transmission cost a whole 400 EC. As for pretty screenshots, I can offer this:

Scansat might help you. You still need to launch a satellite and fast-forward until the entire surface has been mapped, but once the data has been collected, the scansat map and it's tools may be the best / easiest / most acessible means of finding suitable sites.

The standard chute that goes on the 1-person pod takes a very long time to deploy. It you're tweaking tweakables, set it to at least 750m -- that's the minimum altitude you can get away with for splashdowns, on higher ground it may take more. If you don't tweak, the default 1000m should be as safe as it gets. +1to cranking up ambient lighting in the gameplay settings -- once you can see, the problem will probably be obvious. If for whatever reason you want to stay in the dark, please take note the last airspeed displayed on the navball. If it's much faster than 10m/s, the chute hasn't fully deployed yet.

Without going there? You may try MechJeb's landing guidance. You can select a position from map view, afterwards the coordinates and altitude will show up in the Mechjeb Gui.

Can't say. Compare local and surface gravity, multiply by burn time, and see how far that takes you. With a low TWR and a long burn time, even half a percent will add up. I honestly cannot check your math. I cannot even follow most of it, sorry: My last integration was some 30 years ago. But. To me it looks as if you're making it needlessly complicated. For example, If you already know the burn time and fuel flow, you know mass before/after. Why not plug that into the rocket equation? That's a tried-and-true solution you can copy verbatim out of a textbook and be done with it. FWIW (digs in old scripts), here's the core of my low-math solution: That was more philosophical than aimed at your problem at hand. The precision of any action cannot be better than however far you're moving between updates -- if you want to stop at altitude X +-0.1m, but start the maneuver while moving 12m between updates, you will have to refine your solution along the way.

(SCNR) You are calculating with surface gravity, yet local gravity changes quite noticeably with altitude. While I'm here, let me add another bit of advice: you cannot do a perfect, pre-calculated suicide burn. Your script only loops so fast, and KSP itself only updates the physics only every so often. So you can only hit the button at a few distinct points in time: one of these is bound to be a little too early, and the next one is already too late. It stands to reason that you should err on the side of caution, but then you have to take measurements along the way and adjust accordingly. Oh, and finally, I notice that you're working with a fixed burnTime = 2.7171 -- that might matter, too.

Yup, one can't possibly work without *that*. For future reference, if the topic ever comes up again: (fun fact: these plots are where .gif works best, hands down) That's data from two tests starting with different air speeds. Timer starts when the parachute is staged, it's almost 2 seconds until it becomes first noticeable. The faster vessel brakes harder at first, but after 3-4 seconds they're even. In terms of actual ground distance covered after deployment (not shown), the difference is a whole 250m, most of which happens before the chute becomes effective. Just by the way, the highest possible precision amounts to however much ground distance one covers between physics updates. These happen 20 times a second, right? No matter how smart your autopilot is, or how fast your reflexes are, you can only rip the cord at a few distinct points in time: one of these is bound to be a little too early, and the next one is already too late. So in my example, for a vessel going 300-400m/s, even the most precise timing of the parachute will only get me to within 7-10 meters of my target (assuming I have it lined up perfectly, which probably is not a safe assumption to make). If the vessel is supposed to land on a post stamp (or a docking port), there will have to be some vectoring in the end. Personally, I'll be content if I can use parachutes to get within 100m of my landing point. It seems as if that should be doable without a full-on aerodynamics simulation.

Situation: lander approaching base. I'd like to time the deployment of my parachutes such that I come down pretty close to the base. Say, dozens of meters. I have kRPC at my disposal to look at relevant data and trigger the chutes with split-second precision. Only, when? If anyone has solved that problem before? I'd be grateful if you would share how you did it.

Next part here. Things don't quite work as I'd like, I had to discard much of the roleplaying stuff and resort to an utilitarian "lets just get this done" approach, but roleplaying would have gone old pretty quick anyway, and besides, stuff not blowing up in your face is vastly more important. It's still shaky enough as it is.

The best meaning I can make of it: OP launched everything to similar orbits (say, as close to 80km circular as he could). Then the whole shebang kesslerized.

A good long time ago, when asked flat out about life support, the answers were evasive. My reading of the tea leaves is that there won't be life support in the sense that kerbals will die if they run out of resources, but that shipments of snacks (or whatnot) may be required to keep a base working. Until it becomes self-sufficient.

Do not confuse Real Solar System (or any realistically scaled system) with the Realism Overhaul mod. One of the gripes I have with RSS in KSP-1 is that there's no good way to play it. You may want to try SMURFF to get a glimpse of how stock RSS might play out. However, that blanket "let's adjust all stats by the same percentage" approach doesn't lead to a sensible whole. In order to arrive at a good game, you'd need to look at all the parts and individually set new, RSS-compatible values. You'd also need to re-think the tech tree. Usually, fixing that would be in the purview of modders, but we already see how this works out: with Realism Overhaul as the de facto gatekeeper, RSS remains closed to most people. Which is a shame, IMO: going to Venus or Ganymede is inherently cooler than Eve or Laythe could ever be. However, I don't see much of a niche for another modpack that doesn't take things as far as RO does. Unless, that is, if it comes as an official DLC from the developer.

Once I found myself capturing a hefty asteroid with as little spacecraft as I could get away with. Well, capture was the easy part -- there's no problem doing two-hour burns while you're out beyond Minmus. But how to get it down into a low circular orbit? With 40mm/s² acceleration (in the more common notation, that amounts to a TWR of 0.004), the usual approach would no longer do. I carry my avatar for a reason, but even I balk at the prospect of doing over 200 passes through periapsis. Even more so as the vessel was also short on torque -- getting it pointed into the right direction after dropping out of warp would take so long that one starts to think twice about going into timewarp in the first place. So, the only workable (I dare not say practical) solution was to figure out how to spiral into a low orbit in a continuous maneuver. This is just a visualization. Actually it was one done in one single burn lasting more than ten hours. Nothing special about the vessel design here, but quite some R&D went into the autopilot.

Mission report about going to Duna, deploying satellites along the way. Oh boy, has it really been half a year already? This stops after arrival in LDO. I've done that in December, actually, and even started putting people on the ground, but then the base blew up. Putting things together with KIS/KAS is tricky at all times (my shuttles have on several occasions shed parts when I removed modules from the cargo bay, and anchoring a base to the ground appears to be a big no-no). I've just unloaded the parts ...again... let's see how it works out this time. As of now, the base likes to jump when loading, but at least I've been spared from RUD so far.

That's the only safe approach in the stock game. When trying to recover boosters, I've seen them disappear right in front of my eyes at relatively short distances, might have been as little as 200m.

Asteroids properly come into existence once you get into physics range (2500m by default). So, save the game while still a bit further out, and try until you get lucky. I've done such saveloading once. I didn't keep track of numbers, and probably didn't do enough tries for a proper statistic in any event, but from my experience and for what it's worth, 1 in 20 seems about right.