paul_c

So, with the Minmus campaign I can buy an upgrade. After some deliberation, I chose "Propulsion Systems" which gains me access to the Spark engine. A minor redesign produces this: In time-tested Caveman style, we are after simplification. It has everything needed and nothing it doesn't. And the performance! ~3000 m/s dV in LKO is a good target to achieve, to send it to the Mun, do a landing and re-orbit: I have to relearn to fly with the Spark, it has much lower TWR but safely made it to Mun Highlands with plenty dV to return to orbit and dock later for the science. And of course, I can transmit and re-gather temp and pressure: 16 more trips to go....then 1 dockings and a return to Kerbin. I don't think I'll do crewed missions to the Mun, although I will need to do the sums in case I desperately need to.

You could argue that presenting the info in 7 time zones is not necessary; that one (UTC) is good enough, since it is used worldwide as a standard to avoid confusion.

This may explain better: With the various dockings, the craft I'm flying swaps from forwards to backwards a number of times - it gets confusing! The last-but-one flying input is a retrograde burn (controlling through the opposite-sense-attached controller) then that engine/controller/fuel tank is detached, leaving the original CM with a front/top mounted heatshield, so it flies forwards into the atmosphere so it enters heatshield-first. Then the chutes just underneath the heatshield flip it upside down, which sets the CM right-way-up.

You don't need a fuel pipe - fuel is routed through the docking port and those parts. The only part it can't route through is a heatshield, hence the final "returner" stage needing to include and use its engine the same side as its tank, rather than just being a "fuel tank in the sky" supplying the existing engine like previous modules. The original fuel tank/engine underneath the command module can be detached though, leaving a craft with flying direction in the opposite sense (and a controller in that opposite sense too, making reversing control inputs unnecessary).

Technically, you don't need landing legs to land on the Mun. It can be done directly onto the engine.....landing legs are a blessing and a curse. In KSP, there was a bug where things on a slight slope would slide downhill. Landing legs now include a logic that if it contacts the surface, it "grips" or breaks off. The grip can tip over a craft if the horizontal speed is too much, or overwhelm its SAS/reaction wheel control. If you land with low/no horizontal speed element, the issue dissolves. Needs to have direct line of sight of Kerbin (or a relay sat). Obviously, things in orbit around the Mun can be in the shadow for up to ~half their orbit. The landing is easy to plan - just land on the near side of the Mun. A rendezvous/docking is possible, but much more involved, to plan. It would need to be in comms range for the critical elements of the maneouvring, for example orbital corrections to rendezvous, and/or the docking itself.

Is this your first Mun landing? The advice was based on it being the first, hopefully successful, one. Then you don't need to replicate the Apollo mission profile, you don't need to worry about leaving an orbiter then taking off from Mun again, rendezvous and docking. Those are extra elements. Also, if the lander isn't crewed, it will need to be in comms range to be controlled. If its crewed then its altogether heavier than a 1-crew mission. There are many mission profiles for Mun trips - I've done a bunch of variations myself - I've not done a replica of the Apollo missions though. In KSP, there isn't much advantage in using a separate descent and ascent engine; or having 2 fuel tanks etc. But it can be done.

Just do a crewed land-only mission and transmit data then. Leave the SJ off too if you want. Later on in the career you can revisit, do a landing nearby and get the Kerbin back home.

There is no "flying low" situation on the Mun (AFAIK). Its space high, space low, surface/landed. The science storage box https://wiki.kerbalspaceprogram.com/wiki/Experiment_Storage_Unit can store results: 1 per biome/situation so a strategy can be, the lander has (for example) science junior and goo; readings are taken then the results transferred, then the SJ/Goo detached and thus the vehicle is lighter so whatever remaining fuel gives more performance. You can't take 2 SJ/Goo readings in the same biome/situation and store them in the same Experiment Storage Unit. You can't take a SJ/Goo reading, store it then re-use that SJ/Goo module without a scientist resetting it - either by EVA (within 1.5m of...) or by being attached to a working Science Lab. Returning results to Kerbin earns much more science than transmitting SJ/Goo readings; also gathering 2nd/3rd/4th readings adds a bit more too, but its quite marginal. By the 4th reading, you have earned all the available science. It doesn't need to be crewed. In fact, you save a lot of weight if you can make the mission uncrewed, but you will need decent comms. This means, either a Communitron 16 & coordinate all operations on the Kerbin-facing side of the Mun; or establish a relay network around the Mun. There are a number of Mun biomes on the far side of the Mun (it is tidally locked to Kerbin) so you would need it to be crewed or comms relayed to reach them. It goes without saying, but don't forget: far side =/= dark side.

With the modular approach proven to work, its time to assemble and send more modules to Minmus. A "science & fuel" and a "fuel only" module is assembled in LKO, the 'extra' engine jettisoned, then flown to Minmus: ...where it docks with the crew module, and jettisons its engine: Forwards becomes backwards becomes forwards, its very confusing! But the idea is the Science Jr will be expended first, so its at the top. Biome hopping (SJ gone, still have a fuel module): More science and fuel on its way: Guess the biome I'm hopping to: After a few more modules, Minmus is pretty thoroughly covered for science gathering, so its time to bring Bill home. The remaining fuel got me this far, note I wanted to be within the Mun orbit to avoid a random encounter: This is the "fuel & return" module: The Kerbin orbits were inclined, eccentric and wide but I made the rendezvous and docking (nearly there): Things are heating up! Some of the science instruments are getting cooked: Its always a relief when the chutes deploy: A nice haul of science from Minmus. Also, 10x crew reports were transmitted too (they don't have a transmit/recover penalty). I tried 3 times to find "slopes" again and gave up, so I'm 2.5pts short of a full sweep. I hope it doesn't haunt me!: This trip was more about proving the technology for crewed spaceflight and safe return, than ultimate science points (the 5 science points per crew report is low compared to other experiments). But I have no chance of establishing interplanetary comms, so a crewed flight is going to be essential there. For now though, its back to the Mun and it will be a slog to extract as much science as possible before the fun of more distant worlds.

I've put "intermediate" in the title because its more involved than simply "this is how staging works...." (hopefully) Principle 1 We do staging because it doesn't make sense to be hauling 10t of sheet metal (empty fuel tanks) and using the hulking great 6t engine that lifted us off the ground. (I know.....SSTOs....) in the late stages of a flight or mission. Principle 2 We aim to reduce the weight as much as possible. It might have the side benefit of increasing simplicity, reducing part count (to under 30, in early gameplay...) etc So for smaller rockets, carrying the interstage equipment and extra engines seems counterintuitive. (This may conflict with Principle 1). Principle 3 Once we have a spaceship with separate stages, we optimise the fuel/engines in each to maximise the deltaV and produce the required TWR (and probably not much more.....because a bigger engine is a heavier engine). Being mindful that a vacuum-optimised engine isn't great at low altitudes too, etc. Principle 4 We 'set' the stages to be defined amounts each, so that each stage corresponds with a phase of the mission profile. Eg liftoff from Kerbin is typically 1000m/s dV straight up, so we use SRBs for that. Then to orbit needs a reasonable motor; then the next (which might be, eg Minmus insertion) need not be so powerful etc etc. We don't want to be half way through injecting for Minmus and needing to mess about with staging, leaving a debris fuel tank going half way there too etc. This might conflict with Principle 3. Does anyone violently disagree with the above principles? How do you resolve when they conflict? Personally I've tweaked and tweaked things on several iterations, generally in the order 1) it needs to do the job 2) 'efficient' whatever that means, ie an 18t rocket can carry a good payload; or no obvious weirdness like taking a million m/s dV to reach orbit; or having lots of dV left for later/extending the mission(s). 3) fly nice. As in, consistent, repeatable launches not relying on daredevil piloting or luck 4) low cost. If there's something that can do it for £11k when the previous did it for £12k.... But the NCD challenge has taught me - due to its limited funding and grindy nature - you need to "come to the table" with a decent design in your head, build it and fly it with no real dramas or issues straight out the blocks. So any tips, ideas or discussion is much appreciated.

I've seen it before too, on 1x speed. Going to the Tracking Station, selecting it then flying it restores time warp function, at least until it happens again. I've never gotten to the bottom of it though.

I've said it before (in other threads) but its worth mentioning again: In an ideal gravity turn, there are no* sideways forces at all! *Except for the initialisation of the turning (if it were designed to point directly upwards, as rockets are by default when built in the VAB), the gravity turn is like dropping a broom balancing on your fingertips, very gradually, from vertical to horizontal. The sideways imbalance results in the actual, very slow, rate of turn which occurs as it goes over. In theory you could turn off SAS and let it do its own thing. Indeed, people have demonstrated on YouTube this is possible. In reality, the closer you can get to this ideal, the less the sideways forces from whatever source, which need to be countered by SAS reaction wheels and/or gimballing engines. KSP doesn't help with its keyboard controls which bang in control inputs at either 0% or 100%, and some engines are very jerky with their gimbal (Thud) so its something you need to work around. But its possible that a beautifully designed rocket can be misflown and go bonkers; or a complete dog is launched in an apparently perfect ascent by an expert (or a good autopilot).

Thanks OHara, that's a good summary of how to get a grip on the concept of gravity assists, why they work and a good start to "building" your own mission plan using them. Its a bit beyond me, I've always gone direct or let the randomness of the maneouver node thing suggest something by chance; but one day I may get to grips with it all!

What do we collectively think here? The middle component is the T400 fuel tank. I am sure we could all agree attaching 8 other 1.25m 'modules' via mini docking ports is no worries - indeed you could offset the lower and upper rows. 2x6 clashes, 2x5 seems to just fit in theory.... In practice the gaps are very close, could/would it affect docking ability in space and make things much harder or impossible? (It goes without saying, anything that stick out of a module I'll place away from the docking port end and align things during docking etc) I want to get as many on as possible to a central "main part"; the previous challenge used 8x modules attached in pairs but it produced a very wide, wobbly craft:

Thanks for the checklists, I took a look a little while ago and they're useful! I am running quite a detailed tracking spreadsheet alongside my NCD attempt and it has certainly helped. In the previous Topaz and Diamond attempts, it is certainly useful to break it down into targets and know what body/biome(s) you need to visit, and what to do, to reach the target of the day. KSP certainly likes to make the calculation of the science rewards from each scenario complex to forwards predict! And the wiki page helps, but doesn't go 100% into the underlying (it would be very complicated to do so!) Anyway, my prediction vs actuals are getting better, still not exact, but good enough. And I think even in NCD, I'm not going to do a "full sweep" of any body. I am currently doing Minmus crew reports but they are worth so little compared to the effort/fuel needed! I am in two minds to track "science points/£ spend" as a metric, but if the bottom line is you need it anyway, its almost irrelevant. It would be interesting for a "speed run" or maybe an "efficiency run" (like, complete a lower level at least cost; or least trips; or least RW time playing KSP.

Is it locked at 1x speed?

We would need a pic, but a guess is that its too draggy at the top/front compared to the bottom. Like a shuttlecock, it will try to turn and as speed increases, eventually overcome whatever control (engines gimballing; reaction wheel) you have/had over it.

Which file are you editing?

Another sideways docking done: And another: Trip home. With extra fuel in the modules, we use it wisely to reduce the re-entry to a gentle one: Safely re-entered and on chutes: A nice science haul: "Electrics" upgrade done. This means we can relax a little bit on "earning" science and do some development work. So.....we will use the remaining Minmus science to gain experience in manned (Kerbal'd) flight. Bill is the first Kerbal to do a trip to another body and is excited: He hasn't noticed there is no chute or heatshield.......but I think things will work out okay, I have a plan. With the crew module, its too heavy to take much else so additional modules will be used for science and extra fuel. 2x biome remote module flown to Minmus too, and docked: That module flew terribly, doesn't have enough fuel to risk a landing, so it will be used for near & far science then jettisoned (it can still do science contracts though). A few design iterations later, and 2x biomes' is too ambitious so 1x biome at a time will be visited: Much more performance. Also the deltaV readout is inaccurate, due to fuel flow and docking etc. Anyway, with the SJ and Goo we head to Midlands, for max science return: Science Junior is used, so its pinged off the spaceship: Last of the "extra" fuel is used, so that is detached too: Just enough fuel to get Bill safely back into orbit after visiting 3 biomes and gathering useful science:

Its probably a good addition for some circumstances but KSP has always focused on manually flying something. Its part of its charm, and also part of the departure from realism. Regarding your specific example with chutes, AIUI its more/less how they work anyway - once "armed" they don't immediately deploy, but have autonomous (relatively) simple logic: at above xxxx pressure and if speed is below yyyy, semi-deploy; at zzzz altitude, fully deploy. Thus, they will work on their own. BUT the craft needs to be in "physics range". I have successfully armed chutes, then split a craft and the debris portion has deployed its chutes and survived a landing while the probe/controller part had the focus and the two remained within physics range of each other. Similarly, I've tried further distances or the other craft in physics range not being active (ie (try to) return to the space station and time progresses) and it either forbids you from leaving the game at that point; or disappears or is destroyed.

Sounds good - I nearly followed it!

Miniaturisation upgrade done. It also includes the "EVA Experiments Kit". Every little helps: Ouch! They're expensive!!! Vehicle designed, launched (flies quite well...), made it to Minmus no worries: I realised I had a bunch of excess fuel, so a redesign with 2x of each science instrument can do 2x biomes per trip: After 5 biomes of data, I have enough to do the next upgrade, so they'll need retrieving and returning. So...: Vaguely similar orbits. Note, I have gone for an eccentric one, sweeping down to below the "near space" line of 30km altitude: Getting closer and closer: Its dark but it will soon be sunny.....first try at mating: So close now..... The technique seems to be to aim for the docking port, then turn and wait for the coming-together. 0.1m/s approach didn't work at first, they didn't meet at the docking ports, swapped paint a bit, then drifted slowly away. So, another try with 0.4m/s and it worked! 2 more dockings are needed. I'll use up the remaining fuel in the one that isn't returning; note the docker-returner has 2 docking ports (for aero/weight balance, and they're only 20kg anyway). I have docked the one with least fuel first, so the last one has the most fuel, helping the home journey along. I know that you can't really rely on the dV indication in KSP any more due to the weird config and later undocking of the empty module.

Higher or lower?

1% of the population are bat-&*!% crazy. 0.1% of the population are in the top 0.1% of weath. He has ~80,000 customers.

Not so fast.......I think its possibly a brilliant idea. Why? Because the long term future people who might want to go to Mars, are similarly visionary and ultra-wealthy too. Normal people don't "get" this, how can they? What makes you dream? Why can't you achieve the dream? Is is money holding you back? What if you have money, and all that you dreamed of when you were young, you have now achieved? Do you retire? Or dream bigger? Ultimately, that route is a "commodity" provision, like wheat; or milk. There's people making millions off of that, because they are good at it and have invested millions, but at the end of the day commodities are always somewhat marginal operations.