swjr-swis

Rightclick the ore tank - Jettison ore.

I don't know. I just felt like someone should actually answer the question.

My guess would be.... roughly 15 N 120 E, almost exactly at the other side of Kerbin from the KSC.

The Rocketeer? I think a couple others too, but seems the most fitting here. Autostruts definitely help. Be mindful of how you use them though, and try to take advantage of part symmetries whenever possible - parts attached in symmetry will generate autostruts in symmetry too. Symmetry at both start and endpoints of autostruts create lattices... which can add to structural strength exponentially.

Not really needed: when you load your plane on the runway, just open the stock debug menu (Alt-F12), Console, and enter "/waypoint Kerbin 73.0 -80.0 NorthIceShelf" to create a waypoint at the closest edge of the Northern Ice Shelf (which is what I think OP means with 'North Pole', considering their own entry). Or use 90.0 -74.25 if you want it to be the actual NP due exactly north from the end of the KSC Runway. Then rightclick it to 'Activate navigation', and you're all set to go. See screenshot:

My bad: the wording just didn't make sense to me. 1.4.0 doesn't fit with the category 'or earlier', as far as I'm concerned. I realize now though you must be referring to MH being delayed to the next patch. I guess that shows how much I don't play MH. Or '1.4.0 or later' (*) for that matter. (*: 'or later' currently being limited to 1.4.1 - 1.4.5, but not necessarily excluding 1.5 'or later'. The significance of 'or later' may be extended to include other major or minor revisions, until such time as a version is released deemed worthy of succeeding 1.3.1. No kerbals, version numbers, compound phrases, or qualifiers were harmed in the typing of this disclaimer. Some kerbals may be harmed as soon as this disclaimer is done and we all can go back to launching rockets.)

Are you really though? You are preemptively excluding people that still stick with 1.3.1 (or earlier versions) for any number of reasons. It's like claiming you're wondering how many people use 20 inch rims on their cars by starting all 10 possible answers choices with "I drive a Ford 150 and ...." Edit: it seems I missed the 'or earlier' in the first options. I'm pretty sure I'm not dyslexic. Risgedard.

Assuming a pure stock game: place an Mk1 pod. Attach an Mk16 parachute on top, a 1.25m service bay below, and a 1.25m heatshield under the bay. Drain the pod monoprop. Then using the offset gizmo in absolute mode, shift the service bay one 'tick' up, leaving no gap between the edge of the pod and the service bay. The bottom of the pod ends up inside the service bay, becoming the new curved ceiling of it. It makes no difference for drag calculations, but the CoM is moved down, which is the most important consideration here. That combination is very stable in retrograde reentry. Even when plunging in at >3100 m/s from near the Mun to a Pe of 15km, with SAS off and tumbling around, it will still orientate itself retrograde before heat causes damage, and it will slow down enough for chute deployment well before reaching the surface (assuming proper chute settings). Video inside the spoiler of how to build it and how it points itself retrograde even when reentering the atmosphere tumbling: If it doesn't work for you like that, something in your game is no longer stock.

Does the RW money involved in getting that engine count as a drawback?

I should've worded that differently. Just backing up your statement, really.

Really? Simpler than giving the rocket a small nudge (or a tilt) at the start and letting the balance of thrust, gravity and aerodynamic forces do the steering for you? As opposed to going straight up and then having to fight to switch to horizontal, as literally every one of those forces is at that point working against the direction you now want to turn to?

Oh I've modded KSP before, including KER and MJ; had games with close to 200 mods, customized KER displays etc. I just stopped at one point and haven't yet felt the need to do it again. Stop already. This stopped being a 'smart' ascent profile years ago. It only compounds the problems and confuses new players.

I'm not sure we're looking at the same screenshot. In the screenshot linked in the OP, the KER readout at the bottom says EC = 350, which indicates three Z-100 batteries have been added, probably in the same 3-way symmetry used in the rest of the craft. The one on the hatch may get in the way of EVA, although that may not be part of the mission plan. I hadn't considered KER also showing the biome - I don't use it. The only stock ways to keep track of the biome you're flying in/over are KerbNet (he has no probe core for that), rapid-fire running/cancelling of one of the science instruments (gets tedious very fast), or the surface scanner PAW (add the part, pin the PAW, done). It's a pretty handy functionality of that part that many people seem to be unaware of. In any case, it looks like @zyco187 is playing career, from the looks of it still stuck in tier 4 tech or lower, so the surface scanner (T7) is likely not available yet and so irrelevant in this discussion. Taking another look at the OP and the screenshot, I don't see any mention of wanting to land on the Mun (other than the oddly overcalculated dV numbers), and the craft is called 'munar flyby'. If a flyby is really all you wish to achieve, this craft can go a LOT smaller still - you can stop counting at just the intercept, with a tiny amount extra to correct your Pe when on your way back to Kerbin. That last stage needs only a single FL-T200 tank to be able to get a Mun intercept from LKO and get back to Kerbin, at a total of around 3.1 t. Which means the lifter stage can be a lot smaller too: See the full album on imgur for additional commentary about craft design and flight profile.

One of several dV maps of back then confirms this:

Which in turn is not really so odd, considering it's the Steam forums we're talking about...

Before you try to edit that file manually, you might want to try one of the backup files that the game makes. You don't specify what version of the game you use, but this has been part of the game since 1.1.0, so you probably have them too. First, make a backup of your current persistent.sfs (maybe add a date or something to the name so you can identify it later). In the directory <KSPinstalldir>\saves\<yoursavename>\backup, you'll find 5 backup files of previous moments in your save. Test those to see if they will fix the issue, by copying them into the main save directory and renaming to persistent.sfs.

Downloading a game through Steam is a two-step process: it downloads the files in a temporary location initially, then moves them (either a direct copy or though an install script) to the game's install directory. If cleaning up the game's install dir has not helped so far, you may want to check the temporary download location for stray files that mess up the process. It may indeed be that Steam is messing up, either because the repository is badly configured somehow (this is within Squad's control, they could fix this), or the specific download server you are connecting to is having a bad day (Squad can't directly do anything about this, they'd have to contact Steam). From the Steam client menu, look in Settings/Downloads which 'Download Region' you have - they will need this info. While in that screen, try the 'Clear Download Cache' button - it should clean up the temporary download location so there's no stray files left to mess up anything. Apparently no longer valid information, Steam does something slightly different now: Default location for this temporary download on Windows would be "C:\Program Files (x86)\Steam\SteamApps\content". This folder should normally be empty, unless you are in the middle of downloading a game (or updating one). When downloading or updating KSP, a folder is created in here called "app_220200\depot_220201", which will fill up with the entire contents of the KSP base dir (when downloading fresh) or just the files it needs to update. As soon as the download ends, it moves the whole bunch to the KSP base dir location and wipes it from here. So if you see any folders or files in that 'content' folder when you're not downloading or updating, it's an error - delete all of it, restart Steam, and try again. Edit: I just tried redownloading 1.3.1 fresh. It does something I have not seen happen before: it downloads something that is too small to be the full game (only 740MB), then immediately downloads an update (879.8MB), then another (981.6MB). Also, it downloads this into "C:\Program Files (x86)\Steam\SteamApps\downloading\220200" instead of the location I mentioned above. At the end of the download process, the KSP base dir is 2161 files, 335 folders, 3.30GB in size. It starts up fine and works as expected. My 'Download Region' is Netherlands, so if yours keeps giving you trouble, see if changing it to the same helps. That would indicate that your download region server is the root cause of the problem.

I get a feeling you are confusing the batteries (which are there, several of them) for a surface scanner (which I can't see, not even after extreme zooming). To @zyco187 Assuming the scanner is there: keep the surface scanner! It's not as useless in space as some people might think. If you rightclick it and pin its PAW window, it will show you 'live' what biome you are flying over, which in turn allows much more precise timing to capture extra science from orbit. Even in a perfect equatorial Mun orbit, you will pass over a good number of different biomes, so the benefit in science points will easily be worth taking it with you. I'm more puzzled at why you decided to surface-attach so many fragile and draggy things on the outside of the pod, when you have a service bay right there to protect and shield them. All that stuff should be in the bay - that's what it is for. Personally I'd stuff it all in the service bay, move the bay up above the heatshield, and land both pod and bay on the return. Even if you decide to save only the pod, condemning all the stuff in the bay to a fiery death, you can still move all data into the pod before separation, and the pod's internal EC and antenna are quite enough to work through reentry until recovery. So there's no need to suffer all that extra drag or risk losing them to heating through the initial ascent. Move it all into the bay.

Any message showing an '#autoLOC_<number>' string is an indication that KSP is unable to find/load a localization string. When the rest of the game is running, it could indicate a missed string by Squad, which they would need to correct. If it goes with a complete failure of the game, as seems to happen in this case, it is more indicative of one or more of the following files missing: <KSPbasedir>/GameData/Squad/Localization/dictionary.cfg <KSPbasedir>/buildID.txt <KSPbasedir>/buildID64.txt Along with the above ones, you will very likely find a good number of other files missing as well. Any of those files not downloading when clearing the KSP basedir and redownloading through Steam may be a reappearance of a problem that has happened a few times before, where Steam would refuse to offer the complete/correct repository of files for a certain game version. A similar issue has plagued the 1.0.5 repository for a long time now and was never resolved - which makes it impossible for regular Steam players to download a viable copy of 1.0.5 anymore. I really hope this is not now also the case for the 1.3.1 repository. I doubt this is in play here: if memory serves, there's a forced message/notification when Defender blocks/removes a file. Also, OP is referring to version 1.3.1, which is still very popular, and lots of people on Windows run Defender... I would expect a LOT more reports about this if it had suddenly decided to cripple 1.3.1 enough to prevent it from loading. Even so, it would be easily checked by looking into Defender's event log, either in Defender's main window (under History?) or through Windows' own Event Viewer (Applications, Microsoft, Windows, Windows Defender, Operation).

I'm not sure what went wrong for you, or if they removed that functionality from CKAN (which seems very unlikely), but here's a screenshot I found from an old CKAN install: This one was obviously from a point in time when I had just one CKAN-modded instance per KSP version, but it worked the same with multiple installs of the same version. All installs I added to CKAN started as copies of a clean Steam stock folder. CKAN was then pointed to them (the 'Add new' button asks for a specific path to the KSP base dir), which then allows you to select which KSP install to work with from this dialog or from the CKAN main menu. From that point all modding for these installs was done through CKAN, which updated and maintained the mods for each of them side by side for a good while.

It's been a while for me, but when I last modded KSP I had 5 installs of the same version with different mod sets, all but one handled by a single CKAN instance. If nothing major has changed since then, you just need to tell it that you have multiple installs and provide the paths for each in the settings - this works across different versions of KSP too. With a bit of OS filesystem trickery, you can even use the same single download folder so CKAN doesn't redownload the same mods over and over (hint: mklink /d <pathtonewKSPinstance>\CKAN\download <pathtomainCKANdownloadfolder>).

I notice a distinct absence of comments from some frequent KSP Weekly participants. Might be about as much of a compliment as you can expect, @SQUAD... I'd take it and run.

The second option needs rewording, or it doesn't make sense: it should probably be 'bought the game and skipped the demo entirely". Why would I need to try a limited demo when I already had the full game?

Like @bewing said, they're just plain text files - they just end with the extension '.craft'. Any text editor you have installed can edit them. Make a backup copy of the file you want to edit so you can get back to the original, and you can experiment without worry. Do me a favour though: please, please change your folder view settings to show the file extensions. I don't know who at Microsoft decided it was a good idea to make that an option, let alone turn it off by default, but I sincerely hope that the closest those persons get to UI programming in their next seven lives is by cleaning out pig sties.

This only happens with bays and fairings, which is not the case here. No other parts will 'occlude' anything, as the game code treats any other part clipping as if the parts are fully exposed to space.