Jump to content


Parts Hero
  • Posts

  • Joined

  • Last visited

Everything posted by RoverDude

  1. 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.
  2. 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.
  3. Close. It will be split across mods that explicitly need the resources. So Karbonite in Karbonite, the MKS chain in MKS, etc.
  4. 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?
  5. 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.
  6. @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.
  7. 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).
  8. To add - PL does not support extraction other than as part of a reaction chain (and it is something that will probably be deprecated since WOLF does it all so much better). If you want output directly from production, WOLF Hoppers are the way to go. For your situation, having the Ore->LFO converter in MKS land would pull Ore from Planetary Storage and generate the LFO locally.
  9. based off of the 'Ultra Safe' Nuclear Thermal propulsion system because I found the name hilarious
  10. Working on a bunch of new bimodal nuclear thermal rockets to work alongside the Orion, from 5m down to 0.625m, with a couple of truss variants along the way for the middle sizes.
  11. Ship up what you need. And much like reality, it's going to be more expensive to build something in orbit from scratch with zero supporting infrastructure. I'd start with at least matkit production. The other resources are there primarily as cost sinks. Re the storage, shipyard construction is big. So I'd expect storage capacity to be commensurate. At this time there's no partial-assembly option, though we've talked about an option to facilitate stockpiling.
  12. Ok - tbh I would nab the pre-release due to the level of goodness in it We've been working on a CI build (bleeding edge downloads) and some last part textures before it goes to showtime.
  13. Are you on the pre-release or no? Reason I am asking is that I've been doing complete base assembly in the prerelease without issue...
  14. Not about licensing, more about bypassing a perfectly functional system and dumping in support headaches. Easy enough to sort, and would prefer to sort it separately from CRP (whether via discussion, or failing that, incompatibility settings and/or defensive modding). In any case since there seems to be no disagreement at least as far as splitting out definitions go, I'll be pulling those out in a future CRP release after labor day - that gives folks plenty of time to update what they will, unless one of you needs more time. I'll be switching my pre-releases over to give it a whirl in the interim.
  15. All depends on the 'why'. Resources are not a balance lever in isolation, and do not exist in a vacuum. It's about how the resources are used. There are a few different ways to approach it, but it all depends on the why.
  16. Addition is by design in the stock system. And there's a series of overrides noted above. If you want to override the CRP defaults, go for it - fully 100% supported out of the box by entering planetary overrides. Once CRP has no overrides, you can even make your own globals for your mod to whatever defaults your mod desires. If you and another mod share a resource, it's going to take the most optimistic view. If you disagree with that, then have a conversation and get to a compromise. With distribution removed from CRP, there is absolutely no reason for a mod to explicitly remove or reduce resources set by another mod. This goes double if your mod does not actually even use the resources in question.
  17. Then the right way to solve that is to put updated planetary distributions in it. Problem solved. That's exactly how everything is designed to work. The wrong approach is to wipe out planetary/biome configs of other mods. Also - people are getting RR as part of JNSQ, so I get support questions because people are surprised when MKS suddenly does not work correctly.
  18. That becomes an inter-mod discussion, with the right answer not being 'I will just overwrite your stuff'. There's a really wide gap between 'here is the crafted resource list for the planet pack I make, and I have my own baselines and defaults' - which is perfectly fine and using the system as intended - and 'I am going to explicitly strip everything out'. It's actually a losing battle to do the latter, because of how stock works (you're kinda fighting against the system). Especially when there are already tons of built in levers and options to do it in a more neighbor-friendly way.
  19. I'm really not asking to unite, I'm asking (nicely) for the USI suite not to be messed with. The starting point and the question at hand is whether we're good with moving resource distribution out of CRP. Because the other option is defensive coding, or to flat out make Rational Resources have explicit incompatibility with CRP, which is likely not a path we want to go down.
  20. Sure, the problem there though is that right now they are doing that by explicitly overwriting CRP, which is a big no-no. So the proposed solution is to remove resource distribution from CRP and let mods handle their own, so if someone had RR as a baseline they could do whatever they want (even if it's a bit odd messing with resources you don't even use). So there would really be no need for the stomping. And if someone installed USI, we'd have our own resource set (same with NF, etc.) as the bits are meant to layer on top of each other. Ideally we can land in a place where people are not explicitly breaking other mods, or where we have to do defensive coding. To add - in the event of planet packs, the correct approach would be to set up whatever relevant planet resources you want/don't want - but again, that really seems the realm of the consuming mod. So if planet pack Z included resource converters for, say, Ore - then it would be logical for them to craft how they want ore distributed in their planets. That's built into the resource system and using it as intended. If they decided to eliminate Substrate (used mostly by USI mods) from their planet, but did not do anything with said resource, that would be kinda weird, but their call, their mod. But if they decided to explicitly override other mod's values - then that's not cool, especially when they end up breaking things.
  21. The point I am making is that interop is a separate topic from resources, and probably more of a topic for the MKS/KSPIE threads The goal here at the moment is to mitigate CRP being stomped on and encourage folks to just leverage the stock behavior for conflict resolution, and let mod handle their own resource distribution vs. having CRP do it - which should also eliminate the need for Rational Resources to stomp over it and do their own baselines.
  • Create New...