RoverDude

All of us curate it That sounds.... really bad?

1. Everything a mod needs comes with it. No need ever for an extra download, except in the case of one dependency getting out of sync. 2. Use KSP AVC and you will know if something is out of sync. Easy peasy. If you don't want to use KSP AVC you abdicate all rights to complain. 3. The catalog links are automatically pointed to the latest release. And if the page itself is out of whack, you can do a PR if you are so inclined to fix the HTML.

I've passed it on

If you need help I can toss a PR as I found out what caused this

@Wyzard - short answer, yes. Stock now has some options that I had to override before, so log a github issue to remind me

@linuxgurugamer - Probably getting out of the realm of this thread tbh as this is the CRP thread, and you're asking a plugin question. Best bet is to look at one of the (many) samples out there, including stock itself, and if you get specific questions/snags, hit up the addon development subforum.

It depends. Anything from BaseConverter on down will implement catch-up and do what you want. So either extend your own converter or just use ModuleResourceConverter if you want inputs that turn into outputs.

To answer... yes, this directly conflicts. Or to put it another way... if you're using MKS, you should not also use this mod as you're going to get a bucket of weirdness.

You're using the old ModuleGenerator there - so yeah, that's just how it works. Also... it does not do any kind of catch-up mechanic so bear that in mind. While it's fine for RTGs, it's not a very good tool for what I think you're trying to do there. We won't even get into the whole conservation of mass issue

Don't understand the question - can you provide a screenshot?

No worries, all good

Not sure tbh, best bet is to look at the .version file in GitHub and that will tell you what version of KSP it was compiled for.

Thanks, @Wyzard If you do want to get punchy, ping me off-forum and we can discuss what would need to happen to do an across the board update.

@Nhawks17 - same answer I gave elsewhere. To expand these post-launch you do so with an EVA Kerbal.

They are expanded on EVA only.

@Domfluff - then for that situation, the best thing would be a module manager patch that adds the boil-off/cooling constraints.

To be fair, the whole boil off/cooling thing is irrelevant as that's not a stock behavior. I'm fine making sure the volumes and compression are matched (a lot of this I expect is tied to Xenon never getting its proper balance pass in stock) - i.e. if a tank contains 1000L of LFO, it would contain 5000L of most CRP resources, or more if Nertea is using a specific volume multiplier. But the tank wet/dry ratios are ones I would like to keep consistent unless there's some compelling thing I am missing.

For GC, you just have the DIY Kit. The rest of the parts are covered by MKS functionality. No idea - let us know

@Wyzard - best bet (and to minimize disruption) is to keep the volumes the same since for almost all resources, that's going to be correct (1L for CRP stuff, 5L for LFO, etc.). In the case of the pressurized tanks I have no problemo making the ratios consistent with NF, just use the volume already established for that tank. If a specfic tank appears to be REALLY off, let's discuss. Since messing with these is like pulling that loose yarn on a Christmas sweater.

use a claw.

It's kinda an overlap, but the mechanic would be in life support. Also, if I were to (hypothetically) add in aging/death, it would be an optional setting and turned off by default.

The biggie is that with TAC-LS, all of the habitation parts are just aesthetic. And yep, the patch is community maintained. One of the main drivers in USI-LS is that life support was/is a core dependency, and there were a few KSP versions where a lack of TAC-LS updates tied my hands on my own releases, so it made sense to do my own, and also extend it in new ways (habitation, etc.)

Not sure, but in any download you can look at the version file to see what KSP version it works with.

tbh, this would be a USI-Core discussion vs a CRP discussion. That being said - within a kontainer the quantities should be consistent based on volume for that kontainer (the 5:1 is because stock LF/O is stored in 5 liter units). So that bit is correct. But I would not mess with the other resources since in some cases, I trade off durability for capacity, etc. unless there is a volume discrepancy between resources in the same tank.

No. EL was dropped because as noted, the EL chain is simply not realistic, and replacing with an MKS resource chain caused too many support issues. Got tired of waiting (literally) years to see what the EL 'detailed' mode was going to be, even offered up to redo the entire MKS chain to whatever Taniwha wanted... never happened. So I found a more cooperative and collaborative modder to work with, problem solved. As noted - NOTHING stops you from using EL. EL parts work, the EL resource chain works. But I see no point in expending my efforts on integration work on a mod for whom integration ends up causing support issues, when I can expend that same effort working with someone genuinely interested in collaborating. Use EL, rock on, all of its bits work. But the officially supported construction mod for MKS is and will always be Ground Construction, since there's pretty much zero impedence mismatch there. Bingo. I left bits there, but will in no way be expanding or updating EL support. EL works out of the box as is. If folks want to do PR's for a compatibility patch, rock on. But as noted, it is not something I would focus on, nor do I have any intention of maintaining the old parts (to be honest, the models should have been dropped a while ago and likely will be dropped eventually).