panarchist

NFE doesn't work with Kerbalism, and the reactor mechanics are different. Ditto for System Heat. The rest of NF works fine with both Kerbalism and USI.

As RoverDude says, ask on that thread. It's unlikely, as Kerbalism changes a lot of the stock mechanics - but Kerbalism is very configurable through configuration files, so it might be possible to have most of the functionality of both mods. Expect to have to do a lot of work and testing on your own, and expect to have issues. In general, you can pick one of USI, Nertea's NF, or Kerbalism; or pick two and get partial functionality with some effort. (but never full functionality) I can tell you that several people have tried to make Kerbalism compatible with the USI mods, and no one has fully succeeded yet. Now that KSP 1.x dev is wrapped up, maybe there's a potential for that in the future if someone on the Kerbalism side is amenable to making play nicer with the other major plugin mods.

1. There's at least 2 modders out there who deliberately push back updates each time someone asks about them. Some of these folks have been coding KSP mods for 7+ years, and every time someone asks about an update, there's a chance they'll decide that's the last straw and take their toys and go home. There are several posts on the forum asking people not to ask when a mod will be updated, and it's been a contentious issue over the years that a lot of people feel very strongly about. When people ask, even once, it makes a number of us think that the poster didn't read any of the forum stickies or review the most recent pages. (not saying that's you, but it's the impression that long-time forum folks take away, whether warranted or not) 2. If you don't want to wait, there are several threads in the mod development section of the forum that can bring you to speed very quickly on the KSP specifics, including where to download the files you need, and links to an extensive API reference. If you're experienced with C++, there won't be any surprises. 3. I don't know, but you can always do the Patreon and immediately cancel if you want to do a single payment.

You can tell CKAN to allow older versions, and that will allow the install - instructions in the CKAN manual. You'll need to be cautious with that, as it's an overall setting, but it will allow you to install Scansat via CKAN on 12.x without having to wait for an update. Scansat is currently working for me under 12.1.2, in a 85+ mod install (non-CKAN), so you shouldn't see any issues with that mod.

Everything going forward is bugfixes, no new functionality. They're going to have to work REALLY hard to break anything now. Also, I should say thanks so much for APP! This has been the #1 app for me to install for the last 6 versions of KSP, and even in a "mostly stock" game, this and Universal Storage II are my "have to have" mods. For building aircraft in KSP, I consider APP to be not optional.

redacted - no longer relevant.

Not definitely - did you try JNSQ *without* Kronometer? The Kronometer config file is in JNSQ, so if the problem is Kronometer, it would also only happen with JNSQ installed.

QA isn't responsible for the bug tracker, or referring people to the bug tracker. That's Support's job. QA is only as good as their test plan. QA typically doesn't write the test plan, just executes it. The original QA team under Ted had a test plan that covered a large percentage of the common and uncommon scenarios. They were also unpaid volunteers. (I was one) Ted left shortly before the Take Two acquisition, and after that, a professional QA team was hired. I don't know what they typically test, but they're always working under a deadline, and have to test fixes to existing bugs as well as new features while also doing all the normal "smoke testing" associated with a release. It wasn't a large team, and no matter how good a job they do, people always complain. It's fair to criticize how Squad and Private Division have managed the bug process, and communication to the player base - I also think it left a lot to be desired, though Squad has never had a large team and I can't imagine working under their circumstances with being acquired, having most of the original team leave over an 18 month period, and having a large chunk of resources allocated to the KSP sequel. This team isn't perfect, but they've always put out a playable product, and most of the bugs / deficiencies have been addressed by mods. That all said, the complaints about docking port behavior are valid - pushing something that fundamental that close to the planned end of development seems... unwise.

And that right there is the difference between coders who mod and coders who mod and do actual Enterprise-level coding professionally (with the attendant tools). Speaking as someone who has only ever dabbled in coding but supports coders and/or translates requirements between Engineering and Customer Service, I'd love to see your setup.

The version of Kronometer which ships with JNSQ has issues - there's a fix detailed in that thread. As for what it does, it allows different day lengths than 6 hours or 24 hours (JNSQ has a 12 hour day) and does the time and date handling for displaying it. Either Precise Maneuver can't handle dynamic day lengths / year lengths, or Kronometer's issues under JNSQ may be causing it. I'm using it successfully with the patched Kronometer on my own custom 2.7x scale game, with no problems so far, so I suspect it's the latter. https://github.com/Kopernicus/Kronometer/issues/17

Yep, exactly - wheels have been broken on those for several versions, IIRC.

The answer to the OP question is - today!

Also, one of my favorites, the extra that makes RTGs have radioactive decay over time. (in NFE)

For me it was 0.23-0.24. I started with 0.17, 0.18 introduced docking and made things A LOT more fun. By 0.23 the modding community had released most of the "must have" mods everyone takes for granted now. I was playing on Mac back then, and it was totally awesome.

That's true for any reasonable amount of ΔV - once you start using the truly insane propulsion types, like NSWR or Orion, then you can burn a little longer to go wherever you want whenever you want.

There's a patched version which does work with 1.12, referenced here

Magicore does that for me as well - locks it up on start. It's definitely a mod conflict, but I haven't isolated which one. I'll see if I can try testing it tonight or tomorrow and narrow it down or at least get you a full set of logs and a Gamedata screenshot. My original mod list was as lengthy as Sesshaku's, but the last time I was trying to figure it out, I'd whittled it down to 20-ish mods.

Ok, that one sounds pretty awesome. At some point in the near future, I'm going to try my hand at writing a dll / mod for the temperature management side of ECLSS. I'd rather use SH than the stock heat mechanic, and this sounds like it would enable that.

I don't know where you'd get that idea - it was updated through 1.10 and there wasn't anything in 1.11 to break it - it's definitely not dead.

Not unless someone rewrites the code. I looked in FF's utilities folder in Nereid's Github, and the Kerbin day and year are hard-coded. Basically, it works correctly if you're on 6 hour or 24 hour day (Kerbin or RSS), but it doesn't work for JNSQ or any other system using a non-6/24 day or a non-standard year.

I think I was mistaken - I was remembering the Kronometer fix, not FF. I'm actually surprised FF is doing any kind of date/time calculation to begin with.

Brigadier has it right - if you're using the version of Kronometer that is included in JNSQ, then days will not be correct - there's a patch in the most recent pages of that thread which fixes it.

This presumes you have the additional 4-12GB of hard drive space for each instance you create. At a bare minimum, you should copy the C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\Saves folder to another location. You can then alternate between the 1.11.2 and 1.12.x versions if you don't have the space to maintain separate instances. IF YOU DO THIS, then in addition to backing up the save game folder, you should create a separate save called "1.11.Edit" or something like that and then edit KK assets in that save game. A benefit to doing it this way is not needing to copy the KerbalKonstructs folder from one instance's GameData to another. Whichever approach you use, be sure to back up your Save game folder first, and the entire KSP directory if possible, so you have a baseline to return to. KSP will run just fine launching the KSP.exe file from a copied directory.

Redacted

If you want to *use* it, yes. If you want to create bases, no - use KSP 1.11.2 instead.