I've only used SCANSat once, in a stock game to try to wring a Kerbin height map out of it back when Kopernicus wouldn't permit using a BUILTIN map more than once. Maybe it's time to drag SCANSat out of the closet and see what's happening. There might be a problem with one of the stock height maps.

That's in the HomeWorldSetting.cfg file in the 'root' of the AlienSpacePrograms folder itself. There are also toggle switches for Realistic Atmospheres / Stock Atmospheres for Eve and Jool, but the atmospheres of Duna, Laythe, (Ker)Bin and The Sun were replaced with OhioBob's Realistic Atmospheres configurations. Kerbin shouldn't make any difference to flight, but Duna's ceiling was raised to 70 km and Laythe's to 60 km.
The option list for home world choice also includes Kerbin. In my fork I keep Kerbin renamed to Bin for consistency with visual mods, but the original version names it Kerbin when starting from there.

@Northern Cross and @Acetylcholine, I have an experimental version you can grab from my forked repository. Just download the current master as a Zip file and see what happens. I haven't done a release yet, and even so this is GregroxMun's project.
The current edition of Kopernicus is supposed to do away with celestial body index numbers in favour of an internal GUID of sorts, allowing ships to stay in the orbits of the intended bodies even after, say, changing the home world setting. I have yet to test this. But I can at least say that the current master can load on the current Kopernicus.
I'll return after some short tests.
[Update testing from Minmus] Going through each story contract, starting from the usual four, followed by escape, rendezvous and finishing with crew transfer, my next story mission was to orbit Bin. This may have had something to do with my Minmus Escape contract also doing a Kerbin Escape / "fly-by." But this appears to be the logical progression of a space-faring species originating from Minmus. I could test starting from Laythe, but I think it would choose Jool as the next story destination based on my prior experience.
Also, testing from Minmus and Duna I found the Transfer Window Planner add-on picked the correct body names and had transfer plots that 'looked right' compared to the stock counterparts. I think this is a result of TriggerAu testing it against Galileo's Planet Pack and others, to make sure it would work for non-stock systems.
So the solution seems to be to get Kopernicus 1.3.1-3 and a copy of this forked repository. Story contracts might still jump past Bin if you accomplish those tasks ahead of the story.
[Update regarding Laythe to Vall Transfer Window Planner] I'm getting the same result with Kerbin set as the home world. I'm also getting the gray screen problem doing a plot from Laythe to Vall in my stock game, so this might be an actual problem with Transfer Window Planner. I'll re-verify, then take it to that repository's issues list.

I've experienced this with messed-up craft files in the save, rather than in the persistent.sfs file itself.
Try copying your craft from your save to a safe place. Copy the contents of [KSP]\saves\[your-save] somewhere, then erase the contents of [KSP]\saves\[your-save]\ships\SPH\ but keep the folder itself. Then replace your craft files one at a time; copy one craft, enter the SPH, exit and copy another, and so on until you hit the craft that causes the SPH to not load any craft, then remove that one. Or if you know what craft is causing the problem, copy the rest back and skip that one.

Yes driving a rover on Minmus can be frustrating due to the lack of traction, but I wouldn't count it out entirely.
I find that heavier craft and better wheels seem to help a lot. The tiny S2 wheels on this example wouldn't do for a Minmus rover, and neither would the brown dune buggy M1 wheels. A larger, 2.5m craft with the TR-L2 wheels seems to do much better for me, along with some patience.
For RoveMate-sized rovers, I had much better success with a bunch of monoprop tanks, some RCS blocks, and a pair of O-10 engines for landing it than I ever had with wheels.

That's up to @StarCrusher96 and the other folks who maintain this planet and star pack. Though it's pretty easy to add support.
You'd need only modify the resources config for each world that's supposed have hydrocarbons in the air. Check out the existing settings for Eve, Titan, Tekto, Catullus and others in the GitHub repository for inspiration. If StarCrusher or Jade want to do a pull request for additions, I'll merge it.
Note that these engines are more oxidizer hogs than fuel hogs, and the math suggests you don't need a very high percentage of vapour to make the engines work. The intakes / harvesters will work appropriately with respect to the percentages in the atmosphere.

I was following the Reddit challenge after seeing Matt Lowne do it. Which challenge came first, then.
Anyway, here was a response to the Reddit edition:
I believe this qualifies for the base challenge, plus:
Old School: No nukes or ions, especially since a single LV-N exceeds the launch capacity by one tonne by itself.
Consistency, Good Sir: Same launch vehicle used, re-used, and serviced on the runway for good measure.
Mods: EVA Transfer used as the only part mod, though I could have used the Klaw on that tanker. Ferram Aerospace used for the launcher, though the craft itself is Stock. Duna Restoration Project used just for a better looking Duna.

Twenty-five Spark engines (1, 8, 8 x 2 symmetry) strapped to an orange tank plus five tonnes of logic and ISRU, and I could get to low Dres orbit. Just had under 4 km/s. Couldn't land though; was 50 m/s too short.
With better planning I could have refueled on Minmus and set up an ejection toward Dres from Minmus, burning only about 300 m/s back toward Kerbin and ejecting from there. A normal ejection from 86 km LKO cost just over 1500 m/s. Starting from Minmus and dipping down at the right time, I might save 400 m/s or so, which would have allowed me to land there.
Using small engines you'd need the modded Spark from Eve Optimized Engines. Even then I think TWR is too low.

In case @Snark didn't get notifications of a pull request or was monitoring a Suggestions thread, that Suggestions thread prompted me to update Jool Biomes for Kopernicus 1.3.1-3.
Notably, I added localization support. Not doing that would cause KerbNet to not display biome names, and science reports would read as coming from "a Great Green Spot of a Jool." Adding displayName values and getting the grammar right fixes the science reports and KerbNet.
This is a pre-release. I'll leave it to Snark to accept the changes or not for an official release.
If I were better with Gimp I'd change the biome colour map to look more Jool-like. The biome map didn't previously matter until KerbNet came along with its coloured biome maps.

I saw this thread, remembered Snark's project, and thought, why not bring it up to date.
https://github.com/gordonfpanam/JoolBiomes/releases
I left a pull request, but please try it out in the meantime.
If you also have Stock Visual Enhancements, the Great Green Spot won't line up with the clouds in that band unless you also modify the rotation rate of that cloud texture. Edit SVE_Clouds.cfg:
OBJECT
{
name = Jool-Bands2
body = Jool
speed = 0,-1000,0
altitude = 10
offset = 178,0,-2
Hm, I remember setting the speed to 0,0,0 in the EVE Clouds editor. It must use -1000 to represent zero as well.

KSC both clipped into and floating above terrain
I'm working on updating GregroxMun's Alien Space Programs for Kopernicus 1.3.1-3, supporting localization, non-index-numbered worlds, and so on, making sure the configurations are up to date.
I'm stuck on his Restored Duna version. "Restored Duna" uses the Duna textures from KSP versions prior to 0.21. For some reason, the KSC will both clip into the terrain and float above the terrain depending on the original underlying terrain map. The screen shots here are on the flattest place I could find close to the original non-Restored Duna version.
The bottom one is directly west of the research lab, and the KSC hovers roughly one metre above the terrain. The top one is just encroaching on the runway.
The entire configuration is available from my fork of the project. Note that my fork moves the Restored Duna KSC three degrees south to use flatter terrain. The relevant bit is here:
So do I need to flatten out the land underneath the KSC by editing the underlying height map image, or is there a way to flatten the underlying terrain directly? I thought the MapDecal configuration raised the surrounding terrain up and flattened it out.

If you can match Ike's orbit precisely, you can place relays along the orbit. I time-warped this for a couple of years and found it stable enough to work.
You don't need to do this though, since relay antennas don't need to point in a specific direction. Simpler to have this trio of relays inside or outside Ike's orbit.
If you're curious though, get a relay launcher of some kind in low Duna orbit, target Ike and match its inclination, then study Ike's path for a bit. Find its AP and PE in map view. As you place each relay, use the target markers to find the right spot for each one. I'm not exactly sure because Ike's orbit isn't a perfect circle, but maybe if the speed in Target mode is zero when Ike is targeted, it should be set.