RizzoTheRat

I must admit I hadn't thought about that as well as I should have done, I was thinking in terms of extra weight needing extra fuel, and the extra fuel needing extra fuel etc. But you're right about the rocket equation and I hadn't thought about the drag difference. I scaled up my SSTO to put 42 tonnes in to a 100km orbit last night and it worked out a bit under 800 credits per tonne. That's with 6 vectors, I guess I could squeeze a 7th on the engine plate but after that I'd need to increase diameter which will mean more drag. I could probably get the current design a bit cheaper if I used parachutes rather than saving about 600m/s for deorbit and landing, but where's the fun in that? A 2 stage recoverable system should be cheaper still but that means messing about with mods that tweak save files so you can fly them both.

Not a book but this covers all the maths you need for KSP http://www.braeunig.us/space/orbmech.htm

In KOS you can create a new orbit object by giving it a bunch of parameters and can then access the other parameters that KSP has calculated about that orbit https://ksp-kos.github.io/KOS/structures/orbits/orbit.html If you can do something similar in kRPC can you create a new orbit object for each timestep and let KSP do the difficult bits?

I think if it was just related to speed then it would be Fibonacci, but as gravity reduces with distance it probably complicates it. I use KOS rather than kPRC, interested in similar stuff but not sure what information you get in kPRC compared to what I get in KSP. It's an interesting idea I might have to have a play with at some point, but I think it's going to need a numerical solution in small time steps rather being able to work out the formula for it with my level of maths. It gets embarrassing when I have to ask my wife (maths teacher) for help with the game However I think the biggest problem would be the change of SOI. I'm about to send a relatively heavy and low thrust vessel off to the Mun and plan to knock up some code to break it down in to several smaller burns, and knock off the period from the planned time of the ejection burn. For calculating ejection angles and excess velocity I find @OhioBob's website very useful http://www.braeunig.us/space/orbmech.htm

50 tonnes payload to LKO? That's a pretty big ask at your tech level even without trying to keep the costs down. Assuming a significant proportion of the payload mass is fuel for the follow-on mission, you might find it's cheaper to do 2 x 25 tonne launches, one with the ship and the second one with the fuel. Your biggest cost saving would be to try and reduce the weight of the payload. A 3 crew capsule and an empty hitchhiker should give you plenty of habitation to make it to Minmus, and you should only need a few minipacks of supplies. No need for recyclers and other heavy USI bits if you're only planning a single landing. Another option is multiple launches again, one for the lander/re-entry capsule and one for a module that stays in Minmus orbit with extra habitation and life support. I'm currently putting an 18 tonne payload in to LKO for about 15000 kredits (830 kredits per tonne, slightly more expensive per tonne than your launcher!) with a reusable VTOL SSTO, but using the higher tech level Vector engines as I find Mainsails and Twin Boars tend to overheat on re-entry. The trouble with VTOL SSTO's is they don't scale all that well and launch cost per tonne tends to increase with heavier loads, so I'm launching stuff in smaller modules and docking it together in orbit. HTOL SSTO's will generally be cheaper again, but are more of a design challenge and can struggle with odd shaped payloads. Not sure which engines you have available at your tech level but I'd guess it would be a major challenge to get something that big in to orbit that early in the game.

My early game Mun landers go for a single landing, with the pilot taking the science from the experiments so no need to bring them back to Kerbin. So usually something like: Re-entry stage - Single seat capsule with a parachute. No need for a heatshield to re-enter kerbin from the Mun, just set a Pe of about 30-40km and you'll be fine. Return stage - Decoupler below the above with a fuel tank and engine with enough dV to launch from the mun and return to Kerbin (about 800-900m/s I think). I usually use the Terrier engine here. I usually put the science on this stage just keep the craft symmetrical. You also need a battery or solar panel on this stage or the one above. Dump this stage just before re-entry. Transfer and landing stage - 3 tanks on radial couplers with fuel pipes if you have them (or transfer fuel manually if you don't), aerodynamic nose cones for launch if you've not got faring's yet, and landing legs on the tanks. This gives a nice wide stance for landing on slopes, and lets you jettison the weight when you launch from the Mun. Needs enough dV to get from low Kerbin Orbit to landing on the Mun. Something like this (I'm also using KOS and life support so ignore the extra window and a couple of extra components). Then you just need a rocket big enough to put the whole lot in to low kerbin orbit.

If it's Real Solar System you mean, its available for 1.7 https://github.com/KSP-RO/RealSolarSystem/releases/tag/v16.3

Am I right in thinking this issue is if there is a probe core and a Kerbal in a capsule? So a core on it's own or a core and an empty capsule should work ok? That seems to be the behaviour I'm seeing in a fresh install of 1.7.3 with RemoteTech, but in my main 1.7.2 game, with several other mods, the pistons work with a manned capsule, but not with a remote guidance unit and no capsule, which is confusing.

This afternoon I have installed 1.7.3 and restarted it over and over again installing a new mod every time to try and find out which one causes hydraulic rams to stop working when I put a probe core on the vessel. However I then found RemoteTech hadn't installed properly, so maybe OI had the wrong version. Reinstalled from scratch suing CKAN for the mods and now I seem to be missing loads of parts (eg only one capsule in sandbox mode!) AARGH Seems it'a known issue with RemoteTech now I've managed to isolate it and work out which mod threat to search on

For my early game landers I eva to get the science from the experiments and then only land the capsule. A 30-40km pe from the mun or minus is fine without a heat shield. This keeps the weight, and therefore the fuel requirement, down a lot.

I always do a time stamped save (yymmdd_hhmm) at the start of every ksp session. It's saved my bacon more than once

KER will show info like orbital period and ap/pe altitudes so I'd say well worth having.

Well KSP does use simplified physics, but someone's bound to have written a mod that incudes the heat death of the universe

Once you're within a couple of km (I think) of the target ship, right click on the docking port on the target ship and you can select that docking port as the target rather than the ships centre of mass. Similarly with "control from here" on the docking port on your own ship. That's why you want to use the navball to show the directions you're facing and moving in relation to the target, so you're only eyeballing the up/down and left/right offset in 2 dimensions. I believe some of the docking aid mods mentioned will give you that kind of info numerically. Or you could have a play with Kerbal Operating System and calculate and display the numbers yourself...and then take it a step further and write your own code to dock 2 ships. Getting that working was one of the most satisfying things I've done in KSP so far.

Good point, that's the step I missed out and that's the bit that really made a difference for me.

How about doing a calculation on paper and then setting up the same manoeuvre in ksp to show it? Eg orbital period for given Pe/Ap, or take that a step further and calculate the phase angle for a hohmann transfer?

Set the target ships port as the target and control from your docking port. Rotate the camera so that rcs pushes you in sensible directions compared to your view. Fly on the navball not just visually. Locking SAS to target will keep the target indicator centred on the ball, but i prefer to get it all pointing in roughly the right direction first if it's a heavy craft and slow to rotate. Then nudge the prograde vector on to the target marker, but be prepared to move it a bit vertically/sideways to get yourself square on to the port. It's a challenge to begin with but it gets easier with practice. For new aligning the camera properly made a huge difference.

Whenever I've dabbled in programming (I am not a programmer) the biggest issue has been needing a purpose. I'm reasonably competent in VBA and KOS as I have things I want to with them, but when I had a play with python I found it hard to keep interested as I didn't have a purpose. Hence I'd say learn python as you have an immediate application for it. However there is a KSP mod called KRPC that lets you program your ships in C++....

I'll be honest, I'm not actually sure what the difference are, and looking at 5thHorsemans post I'm not entirely convinced I'd see much difference. I've been using RemoteTech and KER for years so haven't really noticed changes in the commnet or dV displays. I did try out an EVA parachute for the hell of it but only the once. In my current game I'm starting to use some of the robotic parts from the Breaking Ground DLC (probably out of scope of you're question anyway), but had previously done similar stuff with Firespitter anyway. There was one release that got wheels and landing gear working a lot better than previous versions which was something I noticed, but I can't remember which version that was. I'm on 1.7 at the moment but I can see being able to edit action groups in 1.8 could be useful.

Too much usually My early game (career) mun/minmus landers tend to be a similar design so I have a pretty good idea what I need to use to get there, but the return tends to be less than a tank of fuel so I usually have too much. Where I do try and make a bit of effort to get the fuel right is on launch, where I like to drop a stage shortly before achieving orbit limit the amount of orbital debris (I know it doesn't really matter but it does to me), however I've now got my reusable SSTO working so hopefully won't need to dump stages any more.

I built a new machine last year and had the same dilemma, in the end I went for the i5 (8600k) as gaming is the most demanding use it gets, so I'm not convinced the extra cores would be worthwhile. I've not tried overclocking it yet but I'm starting to hit framerate limits when physics warping in KSP so it may be time to look in to it, I deliberately over specced the cooler though to be able to handle it I'd initially started looking at Ryzen 5 with a GTX1060 but then it seems silly not to spend the extra €20-€30 here or there and the next though you know I'd nearly doubled my budget and bought a 8600k, GTX1080, bigger monitor, etc It's a slippery slope and the pcpartpicker website is just dangerous.

Ever reach the point where what you've got works fine, but it's not quite perfect? And you know it's going to take a chunk of work to make it perfect, and probably break what you've already got in the process, but you're so close you really want it to be perfect? Well that's where I am this evening. So close, yet that last little bit eludes me. Currently I have to set the target location 35m east of where I want to land for it to work as my cos landing script over cooks the pitch down and doubles back on it's self a bit. ETA: Fixed it for that approach, but try a lower dV retro burn for further back changes the flight profile enough to make it land short again. Needs about 500dV from an 80km orbit to landed. I can land it within the hexagon around the pad every time, which claims to be 98% fund recovery, but in practice seems to be giving me 100%. This test vehicle put an 18 tonne payload in to a 80km orbit for a total cost of 14844 Kredits which should make my space programme a bit cheaper.

I'm glad I bought mine from the KSP store rather than Steam as it means I don't know how many hours I've put in I tend to get bored occasionally and not play for a few months, but then it sucks me back in. In my last sabbatical I bought a Rift and have to say that Superhot VR is probably the best game I've ever played...but it's so short...so now I'm back in KSP again... Actually I say bored, sometimes it's the other way around, it get so daunting with all the things I want to do in KSP that I end up not doing any of them. Currently I think I've probably got 2 or 3 weeks worth of work just build and test the stuff for my next mission.

Ben Rich's "Skunk Works"? Great book.

Playing with a KOS script to land my New Glenn-ish SSTO. The wings make for an interesting approach, with a kind of vertical S to kill the horizontal velocity and steepen the landing angle. I'm using trajectories to do a deorbit burn that should land it about on top of the KSC, then I'm pitching the "nose" up at 1400m/s (this seems to be the point where the temperatures start to drop) which extends the glide by a couple of kilometers, and drops the horizontal speed a fair bit without needing the engiines, allowing me to then pitch it down and kill most of the horizontal velocity before for the braking phase. With no parachutes it's got a ground speed of 25m/s and vertical speed of 230 when the engines cut in. Currently using about 200m/s for the deorbit burn and under 400 for the landing. I can probably tune that down a bit though as I could to a a lesser deorbit burn from further away and I'm currently spending several seconds gently easing down at about 6m/s, although the latter is useful to allow the RCS to kill off any remaining horizontal velocity. Also need to sort out the guidance a bit in the final phase, it's all pretty rough with just pitching up or down 10 degrees at the moment, and my sideways correction isn't working properly. If I can figure out the pitch down properly I should be able to reliably put it down on the pad every time, plus I need to set up the script to automatically sort out the fins, it seems KSP can't cope with using fins backwards so I'm disabling them for the ascent and re-enabling for the descent.