RoverDude

That's still just a matter of proper cooling and config value settings (and how much bleedthrough you want). Most of the MKS stuff, for example, is due a revamp - basically relying more on core heat and removing most of the bleedthrough for reactors for example.

Stock thermal is not janky - just folks were not reading the instructions - killed it to mitigate support questions.

tbh, the next release is pretty much the pre-release minus a few Nuclear Rockets bits, maybe an extra part or two - nothing save breaking, and definitely worth it

Possibly. But low on the list. Higher on the list if someone does a PR.

Item 1 - Stock bug. KSP Recall fixes this. Item 2 - use the pre-release, it has our own orbital shipyard and construction code

Transport credit bottlenecks are not too surprising - consider that you're building the infrastructure for in-orbit refueling and effectively infinite fuel. It's worth it though.

About halfway through the engines...

Plan would be to move asteroids out as well. Asteroids are additive by nature, but to your point there's no conflict resolution. Should not be necessary to be stompy tho. Feel free to ping me off-thread if you want to discuss potential conflicts.

Close. It will be split across mods that explicitly need the resources. So Karbonite in Karbonite, the MKS chain in MKS, etc.

Pretty easy - put the stuff in GameData in the download inside of your GameData folder in KSP. If you mess with that, it will not work. KSP version?

Given that it's only config files, it's compatibility version has been set to 1.99 for a while So no need for a new release.

hrm... ok that's a new one then.

@Kielm - KSP 1.12.1 correct?

@JadeOfMaar - thank you in advance for the discussion, it's appreciate (even if we don't fundamentally agree). We're fundamentally in this pickle because CRP made assumptions about distribution - which we are going to correct. So to be clear, after labor day, CRP is going to be released with zero distributions in the box. this is already done in development and is under test. At that time. it's going to be up to the mod authors (both planet pack and parts mods) to cast their appropriate visions, understanding those are probably going to conflict. In that world, as noted before, there's no need to remove resources... as there are none. Anyone who uses CRP is opting in for the configs. Distributions are up to the mods. The only reason distributions were included originally was to provide a fallback. But since these fallbacks are causing some strong disagreement, it's easy enough to solve this problem. In that world, RR becomes a bespoke resource distribution pack and some nice defaults for planet pack makers - which is great. It's exactly what I had hoped would happen when I built the stock resource system. And if, say, KSPIE likes those settings, then @FreeThinker is free to bundle them, take a dependency, or use them as a starting point. By all means, rock on. It also means I'll have my own more bespoke settings for MKS, Karbonite, etc. now that they are USI specific and not generalized for global use. It also means we're not going to have cluttered resource windows. The soon-to-be-removed distributions in CRP were consensus, but also meant there were a lot of things players never used. This sorts that (unless you're using a few different mods all with different resource chains - but then that's what you opted into). This, as @Nertea noted before, is a good thing. We should also chat about a misconception of 'additive'. It does not mean just 'adding more stuff', but rather leveraging the priority system built in. It's a smart system of defaults to encourage a bit of harmony. Ideally, those can be leveraged. If a resource pack made assumptions, say, about water on the mun, then that comes with the reality that some other mod may disagree, and the system is going to try to reconcile those. So who's in the right here? In my opinion, it's the player. They have a reasonable expectation that when they install mods, they are going to work. Especially in a case where CRP has no distributions - at that point, they are explicitly subscribing to a resource set by installing a mod. Breaking that, in my opinion, will always be wrong. I may disagree with Kerb4lZer0420's 'infinite fuel and money' mod, but it's not my place to actively work against it. If they decide that giant piles of free-standing exotic matter are the resource they want to use for it - I may talk to them and suggest something else if it causes some weird balance issues. But if they are insistent, then I shrug and move on. Not my mod, and apparently players dig it enough to download and install it and seem happy with it. I will always say it's wrong to remove a resource through offensive coding. Especially since without CRP having distributions, mods would either be targeted without context (bad), or by name (infinitely worse). I think time will tell where we all land. For now, as noted, CRP distributions will be removed, and I am going to request to please not explicitly target it as there would be no reason to. The rest, we'll see how things shake out.

Appreciated. More comments to follow - I think there's a path that should work for everyone and keep us from colliding. There are two major problems, and you have provided a prime example of bypassing and breaking a system in your own example. First - RR is bundled in JNSQ, which completely breaks Karbonite. Second - it bypasses how stock resources work, which is an additive system, and ideally we leverage the systems that exist. Someone may want to opt into both the RR resource distribution while being able to add other stuff (i.e. Karbonite, or other similar mods), and it would be a losing battle to try to find every mod and every 'handwavium' resource. As it stands, Karbonite cannot be used in a JNSQ save because you explicitly remove it via RR - and people opted into installing Karbonite. This is not unlike walking onto a playground and stabbing the soccer ball just because you personally do not like playing soccer. Since you're explicitly modifying CRP to make it non-compatible, the logical (but not very fun) answer would be to mark CRP as incompatible with RR. And while this would solve the problem, it would not be neighborly (hence the discussion and request at hand). A more appropriate way of handling this would be to: Remove assumptions of resources from CRP (which is happening), Remove the Module Manager overrides to CRP from RR (since CRP would not be the host of these anyway). Add in your own set of additive planetary overrides in RR to put in a resource distribution you feel makes sense (emphasize on additive). Mods would then add in whatever they feel is appropriate. Global config nodes to handle third party planet packs, or planetary/biome ones for additive resources specific to their mods (like Karbonite). End result is that players get exactly what they want given the specific mods they have opted into, and no need for defensive modding - and we're leveraging resources exactly as intended when I built it (since modder interop was a huge design factor). See above. Because (a) it explicitly impacts CRP, (b) is bundled with a popular planet pack, leading to confusion, and (c) flat out breaks some of my mods, then our choice is either compromise (and by removing it from CRP, I can then ask very nicely to not override the various USI configs), or force defensive modding to land us in pretty much the same place. Regarding ISRU - Resources do not exist in a vacuum. In a world where the only configs for the Karbonite resource exist in the Karbonite mod, RR has really no reason to mess with those, as it is not a consumer of that resource, and the stock system is extremely good at merging together multiple conflicting resource configs on it's own. There's an argument for Ore as that's stock. But I do not think there's an argument for something like Karbonite (in a post-CRP-distribution world) since that would be explicitly overriding something someone else opted in, and may not have bargained for when they got JNSQ (especially if they know how stock resources work, and assume everyone acts in good faith). I really don't have a bone to pick with Ore to be honest. Though in my opinion the best way to handle it would be via planetary/biome overrides or worst case (and not sure if this is what you do for ore or not) override the stock general distribution. That would leave planetary/biome overrides open for other modders to use as they see fit without conflict. So in closing, what I would respectfully ask is that you remove explicitly eliminating resources based on the presence of CRP, since it will no longer have any distributions. And I'd ask that you not override any USI mods please. Whether other modders have a similar request or not is really their call, but it at least moves the conversation to the appropriate place (and to be honest, is an improvement for CRP since in a USI save vs., say, a KSPIE save, you clean up a bunch of resources that your installed mods don't even use - which in itself is a nice side effect).