Jump to content

RoverDude

Parts Hero
  • Posts

    9,056
  • Joined

  • Last visited

Everything posted by RoverDude

  1. Agreed. In retrospect I think we were doing it for convenience, but that can be solved with an extras folder for those who need a starting point. It will also clean up resource scanners if you only subscribe to a subset of mods.
  2. That's a consumer issue not a CRP issue. Same as the fact that from an USI standpoint, KSPIE reactors are super overpowered yet I do not ask you to change them If you have an MKS request we can handle it there, but as it stands, USI would continue to have Munar water. And unless I am missing something, it's what CRP has today as a default, though no reason why KSPIE could not override that at the planetary level - but if both MKS and KSPIE were in the same save, the more optimistic view would take precedence as that's how stock works (and it's a fair assumption that folks playing with MKS expect a certain resource distribution for stock planets).
  3. The point being you would not have to account for MKS at all. You would have no water on the mun, but I'd include mun water in the USI configs, so it's only there if MKS is installed (or some other mod that adds mun water configs). Beyond that, as to what a part pack does or does not do is really up to the individual modder and a topic more for the MKS threads than this one.
  4. You can always mess with the configs
  5. Yep this would only affect mods that depend on harvesters as part of their pack. Or ones that modify the stock harvesters for their mod. Which is really where the control should be. To add - at first blush, a good approach would be a grace period where mods can introduce into their own mods their own resource distribution schemes. Then I'd just move the distribution schemes in CRP to an Extras folder so mod makers can either borrow those, or use them as a starting point. That should have the least total impact. Ideally, Rational Resources follows along and removes the CRP overrides it has. Otherwise, there will be a bit more work to do.
  6. Time to resurrect the CRP thread, and a heads up for folks who bundle this. Fist a bit of background (that I assume most folks know, but covering it just in case). the stock resource system was specifically designed to prevent mod collisions, since the intent was for individual mods to have great control over resource placement and distribution. The reason for this is that the resources themselves do nothing - they are not a balance lever. Balance levers are up to the parts that utilize the resources. this is a pretty important point. So when the stock system looks at abundance, it goes off of two golden rules: First. Biome settings override planet settings which override global settings. You can see how this works in the small with 'Ore' in the stock config: GLOBAL_RESOURCE { ResourceName = Ore ResourceType = 0 Distribution { PresenceChance = 100 MinAbundance = 1 MaxAbundance = 15 Variance = 50 Dispersal = 3 } } PLANETARY_RESOURCE { ResourceName = Ore ResourceType = 0 PlanetName = Sun Distribution { PresenceChance = 0 MinAbundance = 0 MaxAbundance = 0 Variance = 0 Dispersal = 0 } } PLANETARY_RESOURCE { ResourceName = Ore ResourceType = 0 PlanetName = Jool Distribution { PresenceChance = 0 MinAbundance = 0 MaxAbundance = 0 Variance = 0 Dispersal = 0 } } What this means is that if someone were to enter a planetary resource node for their own custom planet, they could set it to however they want. They could even only allow Ore in certain biomes, or specifically exclude ore from certain biomes (like allowing no mining for Ore at the KSC, etc). The second point - and this is super important - is that when the stock resource system sees conflict, it will always take the most optimistic route. But this is in line with the point above. So you could., with the presence of a config file and no use of Module Manager, turn off Ore for Kerbin just by adding a PLANETARY_RESOURCE node for Kerbin with all zeros. Or turn off a biome the same way. Let's say Modder A created a water resource and had it everywhere on all planets by default. And modder B wanted to explicitly exclude it from the Mun. Stock supports this out of the box, and in that situation a planetary explicit override would go over the global override. Now, if modder C wanted water in one biome, they could do a Biome setting which in turn overrides the planetary setting of modder B. Finally, if modder D wanted to make the mun a water world, their planetary setting would override modder B (since theirs is more optimistic than B's settings of zero), but would not override modder C (since it's a biome setting not a planet one). And of course all of these are subject to being affected by the global difficulty settings, even for modded resources. The goal when I designed all of this for stock was peace and harmony. Unfortunately, we seem to not have peace and harmony because the golden rule of CRP is being broken - which is 'DO NOT USE MODULE MANAGER TO BREAK CRP!'. In this case, by Rational Resources. And while I get the reasoning, in my opinion it is solving their concern the wrong way, and without consideration to other modders. There are two parts to why this is going down. First - resources are being explicitly overridden. As I've said before, the balance and difficulty levers are functions of mods that utilize the resources, not the resources themselves. And it's really up to the mod designer who built the parts for their mod that should have control over that. Having assumptions rolled over outside of things like stock difficulty settings is problematic, especially when it results in having to do defensive coding to get around. If you want your planet pack to be a blank slate, rock on. But respect that stock (not CRP) was designed for harmonious resource interaction, and folks are likely going to add their own configs to sort this out. Use of module manager to break that is not being a good neighbor. Second - and this is the punchline - IMO the root cause is that CRP does two things. It standardizes resources (which is a good thing!), but it also sets resource distribution (which can, as seen, be a contentious thing). So one thing I am considering strongly, is breaking apart the planetary resource configs from CRP, and leaving it to the consuming mods to handle how they feel resources should be distributed, taking into account the overall nature of stock resource conflict resolution. So if KSPIE wants no water on the moon, and MKS wants water on the moon, and Near Future does not care, you'd land with moon water on an MKS+NF install, but no moon water on a KSPIE+NF install, and water on the moon if you installed all three. Which I think is a pretty reasonable compromise. If there are balance concerns between KSPIE and MKS in this example, then the best way of solving this is discussion. But that discussion is now a mod interop question, not a CRP one. Same rules apply to planet packs. If a planet pack designer wants their planets to have certain distributions, that's fine - as long as they respect that another modder may change those to suit their mods. As noted at the start of all of this - the resources themselves are not a balance lever, it's up to the consuming mod to balance in respect to their mod as they see fit. And a conversation is infinitely preferable than overriding other mods in a vacuum. Tagging @FreeThinker and @Nertea since the three of us curate the harvestables. Tagging @JadeOfMaar since this should solve the need to Module Manager out CRP stuff in Rational Resources (and for stock ore, a planetary override and/or difficulty settings will give you plenty of control), at which point I'd really like that removed to circumvent having to do a bunch of defensive coding. Will leave this up for a bit to solicit feedback, before doing the update.
  7. Localizations are done by the community, and bundled when submitted with the mods.
  8. Thanks! I know it's a pain, but it helps us see if there's a conflict somewhere, and it's appreciated. If everything still works, then it's something in the save and we can try clearing out all of the USI-LS persistence data and see if that fixes it.
  9. Next, do a clean save with just the latest USI-LS release (and other bundled requirementss) in it. Something is conflicting along the way, need to see what it is.
  10. Does this occur on a fresh save? Was USI-LS added to a new or an existing save?
  11. Always start with KSP version and USI-LS version. A screenshot of your GameData folder would not hurt either.
  12. I do not know what wedge experiments you are referring to?
  13. Yeah, if you have no EC then yep that will do it.
  14. Do you have EC in the ship now as well? If you have supplies, hab, and EC generation, try to go back to the KSC scene, then back to your ship and force a reload. If that still fails, send a ship with a claw and use crew transfer to get her home.
  15. Use the local logistics you have with MKS to transfer the supplies from the probe to Val's ship. That should do the trick - if not let me know.
  16. EVA? In a craft? need more details please
  17. Nope, IMO one of the balancing factors of this drive is sorting how to handle the whole circularization bit
  18. That's by design. It's like a 3d-printer. Just because I have a shipping container next to my desktop 3d printer does not mean I can make something larger than the print bed.
  19. Already living the dream
  20. Full disclosure... I spent a lot of the time building that just sitting there and watching the animation on a loop
  21. We'll be giving the whole tree a once-over - the early bits are mostly there to support electric rover routes and MKS support
  22. True background processing is a save killer. Stock's compromise is to do a catch-up in (roughly) four hour chunks while vessels are in focus, and MKS leverages stock. WOLF solves this by removing the temporal element (and tbh, WOLF was one of the thoughts I had when I built stock, but it's limitations are why it could not be stock - that is, it is completely decoupled from stock systems that manage things like batteries and (especially) solar panels). for WOLF see the wiki and experiment. For greenhouses, if you are using USI-LS, it works the same way as stock, so the two dovetail really well. USI-LS is just an extension of the stock base converter classes WOLF has like... zero perf impact. That was the other problem we solved with it. It's super performance and safe file friendly, and you can do massive infrastructure expansion with essentially zero impact. But it comes with it's own set of design constraints (which are totally worth it IMO - MKS and WOLF are like peanut butter and jelly... or jelly and peanut butter!).
  23. No more science crate, but there are new storage bits that work with the stock inventory system.
×
×
  • Create New...