DStaal

My take on these: DecayingRTG - harder than stock, more realistic. I skip this one, but yes for easy play no need to install. XenonHallThrusters - Not really easier/harder here; it's a bit more complex without as you'll have another fuel to think about, but each engine will be more distinct. OrbitalLFOEngines - As Nertea said, just switches the Monoprop engines to stock. Personally, I think that would make the game harder as I like the monoprop engines for low-orbit ships that also use monoprop for RCS...

I know a lot of part creators use Blender as well. Either way, the main point is that it needs to end up in Unity: https://forum.kerbalspaceprogram.com/index.php?/topic/23478-tutorial-getting-started-with-unity-back-from-the-dead/

Still not actually more complicated - just more tedious. (Not really arguing with the conclusion, just pointing out that translating the same logic system to different language - even if that language is blocks - doesn't change the logic system. You could make it more/less complicated by also changing the logic system or changing the level of abstraction, but just about all programming uses the same types of logic at this level.)

MM patches are a better solution than changing the config file - it allows you to update the source of the parts and keep your changes intact in a separate file. Mass is just another line in the config file. I believe it's either 'Mass' or 'mass'. (Case matters.)

Probes Plus:

Honestly, those are equally complicated - they have the exact same number of comparisons, entities, and results. The first is just more verbose.

I mean I think it'd be a good DLC for KSP2, but shouldn't be in the base game.

I think RSS would make a great DLC (in conjunction with NASA?), but I don't think it should be in the base game.

There actually was a mod for that as well, though I think it never was fully completed... If they build in something like Kopernicus's capabilities it should be possible to do something in KSP2 towards that.

For most parts it's auto-calculated. However, it can be added as an override in the .cfg file. Example: MODULE { name = ModuleKISItem volumeOverride = 45 } So you could look for that in the config file, or write an MM patch to add that.

A lot of us have been there, done that on running this game on low-end computers - I ran it for quite a while on a 2011 i3, and on a 2008 Xenon. (It was faster on the Xenon, but that machine also had an SSD.) The one nice thing about KSP on potato machines is that it's all about what you find acceptable - KSP will slow down if it starts getting load, but it'll never stop and say 'I don't have the CPU, sorry' - it just keeps running as fast as it can.

The one worry with USI-LS on a potato machine is that habitation means you need bigger ships. Bigger ships is more parts, and high part counts is what slows down KSP. I don't think the mod itself will be to much for you machine, but you'll be more likely to have ships that push your part count limits. The 'Planetary Warehouse' and 'Local Warehouse' options in SSPX is actually support for MKS's warehouse options, and not directly part of SSPX. Removing it from those parts in particular is easy - remove the patch files. But you'll still have the warehouse options on other parts that support MKS - including the MKS parts.

MiniAVC just checks the current folder for a .version file, and pops up a warning if that mod is out of date. KSP-AVC suppresses any MiniAVC installs you have, checks every folder for a .version file, and gives you a list of what's up to date and what isn't. MiniAVC is for modders to include with their mods so their users get updates. Users shouldn't ever install it on their own. KSP-AVC is the full-featured user interface, and is the stand-alone mod to install if you're a user and don't like all the individual popups.

I'm trying to find the best quote on it - but basically they're fully aware of how important mods are, and have been building in modding support from the start. I don't think it's been explicitly stated that it will be more modable - but mods are definitely part of the base design, instead of a lucky afterthought in KSP1.

Probably not the best example - I read a full review of that game yesterday, and it sounded like the reviewer spent several hours in the game and *still* didn't know what the game is about. (The reviewer's opinion: Brilliant in places, but Hideo Kojima needs an editor.)

I'd recommend at least learning how to install mods manually, even if you do use CKAN - not all mods are on CKAN, and CKAN isn't always perfect. It can mess up mod installs, or think mods are compatible/incompatible with your version of KSP when they aren't, etc. On that front, I'd also recommend KSP-AVC and MADLAD - together they'll make sure you have the most current versions of your mods, and that they're installed/working correctly. Both are fairly lightweight and are basically done with everything they're doing by the time the loading screen is finished. Oh, and you asked about MKS Lite: MKS Lite as a separate mod was a very short-lived thing, as it was essentially all the MKS tools with a slightly different config file. You can recreate it by changing the preference settings in MKS to disable machinery, IIRC. (Regardless - all the changes that were MKS Lite can be set using the preference settings in MKS, even if I can't recall for certain exactly what those changes are.)

I think MKS or Pathfinder would likely actually help performance somewhat - both allow for disconnected bases, and KSP *can* multi-thread multiple ships. There will be a bit of overhead for their respective logistics systems, but not huge amounts. What I would stay away from (unfortunately) in conjunction with either is Kopernicus. Unless they've fixed something recently, it plus either of the above slows things to a crawl, even on decent systems.

Well, the latest version of MacOS doesn't come with Perl anyways...

Note that that script still doesn't appear to work on Mac - it just created an empty folder called 'Space' when I ran it. (I'm thinking I created a Perl version for you at one point - was that some other mod?)

Texture appears to be in the same place. I haven't tested the mod yet, but could it be the texture no longer loads in KSP 1.8? They did drop support for some DDS files.

I suspect some of them are likely people like me - they see an odd (or suspicious) looking mod, and they download it to check what it actually is.

At this point I'll just point to his user page... https://spacedock.info/profile/ilyahiden There's a comment in the 'Build Graphics' mod that shows he isn't getting it at all - he's asking for the mods to fix whatever issues there are instead of deleting the mod. The issue of course is that the 'mods' aren't single mods and aren't his.

I dislike the idea of changing stock behavior when it's not the actual goal of the mod - it's always possible that they could put a fix in 1.8.2 (or some future version) and the fix would then break the override. So for me, I lean heavily towards the first two. Of the two, #2 is likely less annoying in use, though I wouldn't mind #1.

Take a look at: (Though I think we're starting to get a bit off-topic here.)

I'll add for the request for more monoprop engines. I use the ones from Near Future all the time. As for reasons why to want such engines: For me, it's a bit of design simplification, and a bit of headcannon. The headcannon is that I tend to treat LFO engines as 'limited starts' - I don't actually play with anything limiting it, but if a ship is going to need to do a large amount of arbitrary burns, I'll avoid LFO. The design simplification angle is easier to explain: I often design ships with 'orbital' stages which mainly perform a redezvous to some other ship/station and then deorbit again. Such a ship needs only a small amount of dV, but it absolutely must have RCS. If the main engine is LFO, that means two sets of tanks - one for the main engine, one for the RCS thrusters. While a monoprop main engine means the two systems can share a tank, saving design complexity, part count, and mass.