RoverDude

Got it. Answer is absolutely no idea.

I have no idea what the JPLRepo fix is?

Unintended consequences of having them be the same part. Holding off any changes until we do an upcoming Konstruction revamp.

Pretty stable, better than the last pre. Fully ready is always relative

So would I No idea, ask in the Kerbalism thread if anyone has done it.

Not us. Either the host mod, Or a separate mod by the community.

37.5% less bees. But I have to fix a bunch of wheels....

We're looking at a tech tree revamp Konstruction has orbital out of the box and I'm testing a new balance pass currently.

In the short term, KSP Recall sorts it as it fixes Firespitter. In the long term, we've been looking at a rewrite of that code.

Do some Module Manager magic and prune what you don't want.

Thanks - yep, I have to do a bunch of wheel config updates.

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.