VoidSquid

An engine like the NERV has a very high ISP, meaning a very high mileage (dV) per amount of fuel. Try building a vacuum stage for a rocket with say a Mk1 Command Pod as payload, that has a dV of no less than 8k, one build with a Terrier, one build with a NERV. You'll easily see @fulgur mentioned the rocket equation, from it it also follows that for typical KSP tanks, the maximum theoretical dV for any engine is 21.57 x ISP If you're interested in further reading: https://wiki.kerbalspaceprogram.com/wiki/Cheat_sheet

So did I for a short while until I almost exclusively started to use the Reliant in favor of the Swivel: higher thrust and less weight allows more payload/fuel, plus it's a little cheaper (savings here tough are usually more than eaten up by the need for active fins). Over time, my typical rockets evolved as 3+ -stage: 1st stage comprised of SRBs only, bring the vessel up to about 10-12 km altitude with a good vertical speed of 350-400 m/s. Reasoning: SRBs are cheap, and close to the end of their burn time have a quite high TWR, giving the vessel a good vertical speed boost. 2nd stage is typically using a Reliant (or the respective engines for other diameters) with a TWR starting around 1.2, and moves the rocket close to circularization, ideally AP 80-100 km, PE positive but below 25 km. Reasoning for using a Reliant instead of a Swivel see above. The active fins are mounted on this stage in order to provide steering for 1st and 2nd stage. Separation after stage is burned leaves the PE below 25 km in order to avoid space junk (Kessler syndrome). 3rd stage is typically using either a Terrier (or the respective engines for other diameters, see above) for vessels needing below 4k dV, e.g. to Mun or Minmus. Or a NERV or similar engine for targets needing more than 4k (e.g. Jool moons or Moho). Reasoning: in vacuum, ISP becomes the dominating parameter, see @Pecan 's detailed post above. If required, there might be additional stages as well, e.g. the final stage for landing at Tylo needs a high TWR, hence that stage typically is LfOx based with engines (depending on the payload mass) like Skipper or even Mainsail. As a rule of thumb, the dV for any given vacuum stage should be numerical between 8 and 12 times the engine's ISP for optimal efficiency with an acceptable acceleration, I usually aim for an acceleration above 2.5 m/s^2

Transfer Window Planner though "only" makes porkchop calculations for transfer between CBs orbiting a same central CB (e.g. Mun to Minmus, or Kerbin to Duna), it does not calculate Hohmann Transfers.

After leaving Duna's SOI, you're in an orbit around Sun, and you need to do a Hohmann Transfer to Kerbin. In the end, it is essentially like going from Kerbin to Mun or Minmus. Provided you have all required data, you could calculate the Hohmann Transfer, that is however a not-so-easy task, to say it mildly. So, apart from doing the math by yourself, you have two options then: Either use a tool/mod, that does the calculation for you, that tool would be MechJeb. Or you do it by try and error, fiddling around with maneuver nodes until you find an acceptable encounter.

That would assume that I'm smart enough to do do that, I'm not though (nor do I have enough time or will for this, not important enough anyway, it's just a minor inconvenience)

Didn't find one, that's why was asking. Do you know if there is a strategy that converts converts science to cash? Yepp, that worked

Well, case closed then, I reckon...

Looks very similar to the last one. But if you can play for an hour with multiple times switching between different screens before having a crash, the issue was that Razer Synapse. A crash every few hours is kind of normal, happens here too.

Hey kerbalk, If you're a bit of a perfectionist like I am and always want to have control of any vessel near any CB (excluding Sun), you can set up a relay network as per this tutorial: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Setting_up_a_CommNet_system

Hi and welcome, @ScrapIron, Wow, I'm impressed, you certainly are a very smart person (much smarter than me anyway) Guys coming to my mind immediately here are definitely @sarbian , @Jim DiGriz and the other folks developing MJ, see this thread

I've read more than once in the KSP forum that this sometimes is the cause of such access violations. Try running KSP without it.

Eeeek... another one of those ugly memory access denied errors, WinDbg says: Most common reason: driver issue. But you say your graphics driver is up to date. The error itself: SOFTWARE_NX_FAULT "NX" means "no execute" and indicates that a memory address that should not be executed has in fact tried to execute. I'm wondering though, these dlls (besides Windows itself and KSP) are mentioned in particular the crash, chances are that one of these has caused the crash: *** WARNING: Unable to verify timestamp for nvd3dumx.dll *** WARNING: Unable to verify timestamp for nvwgf2umx.dll *** WARNING: Unable to verify timestamp for poco.dll *** WARNING: Unable to verify timestamp for MessageBus.dll Are you running any additional graphics related utilities, like overlays, FPS display, anything like that? E.g. Riva Tuner, MSI Dragon Eye, Afterburner, NVIDIA 3D Vision Driver, ...?

One of my earlier landers (stock) for one Kerbal, it does the job https://imgur.com/a/bJ2H99v But if you want to go really cost efficient, follow @CBase suggestion: Such craft will probably need an ISRU unit plus required utilities (harvester, cooling, power).

Sounds like this confirmed bug to me https://bugs.kerbalspaceprogram.com/issues/23977

As per your log, you're running NavUtilities continued 0.7.2.0, the version is compatible with KSP 1.5.1 https://spacedock.info/mod/1432/NavUtilities continued I'm quite sure this mod won't be compatible with KSP 1.8.x like almost all mods having compiled dll files.

Then we've found the cause of your dV problem. You might want to check out this video

Do you wait until Mun/Minmus is in a good position for your transfer burn? For Mun, for example, your after-transfer burn-AP should be around 12GM, not more, to have an encounter. The correct moment to start the transfer burn is about when Mun is a quarter of it's orbit away from your intended encounter, then you simply burn prograde about 860 m/s dV, that should give you an encounter. If you burn way more than said 860 m/s, then you're burning at the wrong time. Again, I'm curious how much dV you've left after reaching LKO, please switch the display to vacuum dV for a proper readout.

That rocket, even if the displayed dV is vacuum dV (I don't think so) will easily reach orbit around Mun or Minmus, the staging looks ok too (tough not optimal), so it probably is the way you try to achieve your goal. Do you reach Kerbin orbit and go for Mun/Minmus after that, in a separate step? How much dV you have left after you reach low Kerbin orbit (i.e. approx 100x100km)?

Weight, fuel, engine efficiency - how far can I go? The answer to that question is the so called delta v (delta for difference, v for velocity), or short dV. Are you familiar with the terms TWR, ISP, dv?

Glad I could help

And with last paragraph, not luck either? I want my legacy parts back! If you want to get the legacy parts back, you still can do it. At your full responsibility! Before reading further, please, note the following: The legacy parts are completely not maintained. There were reports that some of the legacy parts are already broken in KSP v1.7. Due to #1 nobody is going to fix anything. Last time the legacy parts were compiled was year 2018. Sooner or later all these parts will become completely non-functional. It's not about "if", it's about "when". So, to bring back the legacy parts: Download the latest release that had them. E.g. KAS v1.1. Find folder GameData/KAS/LEGACY in the release archive and extract it. Ensure that the extracted files are located in your game at exactly same location: GameData/KAS/LEGACY. Find the KAS compatibility patch and disable it. It's located at GameData/KAS/Patches/COMP-LegacyParts.cfg. Either drop this file or rename it to non-cfg extension. Keep in mind that every KAS update will rollback these changes.

How can that be when you already have landed on Mun and Minmus? I don't think I understand your problem here.

I remember upgrading KAS and the inherit legacy part issue...: Maybe this already helps? https://github.com/ihsoft/KAS/wiki/Legacy-parts-destiny

Hmm... Nothing that immediately jumps to my eye... and I can't compare to my installation as I'm still running 1.7.3. If anyone can make sense from this, that would be @Galileo, as he's the author of SVE.

Since 1.8, afaik, the Windows log file is named now player.log The sticky post should maybe updated with this, output.log up until 1.7.3, Player.log starting with 1.8., if I'm not mistaken.