RoverDude
-
Posts
9,072 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by RoverDude
-
-
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.
-
53 minutes ago, Spaceman.Spiff said:
Is that a little Stirling/RTG-based NTR at the end there?
based off of the 'Ultra Safe' Nuclear Thermal propulsion system because I found the name hilarious
-
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.
-
1 hour ago, OldSedan said:
Is there any way to use the new konstructor without having all the materials immediately available? Especially with WOLF infrastructure to deliver a steady supply of matkits it seems silly to have to build a million units’ worth of storage to construct a moderately sized ship.
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.
-
2 hours ago, FrontLineFodder said:
The bleeding edge page on the MKS wiki says to look for the construction function in the original docking ports. Is this a 1.12 function or in the next USI update?
USI Update
-
5 hours ago, snakeru said:
No, I'm a regular user:
I just had a clean install, then added MKS (and eventually also AutoLoadGame and KSP_PartVolume).
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.
-
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...
-
3 minutes ago, Nertea said:
@RoverDude I do disagree that no mod should ever edit another mod's stuff. Lots of mods do that, it's up to the author of the 'editing' patch to be clear that they are the support resource for the supported combination. If RR wants to screw with somebody else's resource distributions via MM, whatever. It's just now RR's problem. I realize how it changes the support model but fundamentally you can't make a license that says 'don't MM my stuff', you just need to spend the time setting up the process (canned reply, etc) for when the conflict inevitably comes up.
@FreeThinker The point here is to get this argument out of CRP. If two mods have different ideas of balance right now it becomes everyone's problem, rather than a discussion between say, the RR and MKS authors. Better to have the community thing stable and fairly immutable than go through this every time an author wants to tune a distribution slightly.
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.
-
54 minutes ago, FreeThinker said:
Alright, lets try to think out of the box here. Lets say your the author of Ration Resources and wanted to reduce the distribution of ore globally by 95%, how would you try to realize this rationally?
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.
-
2 minutes ago, FreeThinker said:
There reason this happens is that the CRP has a serious shortcomming which is that you can only add (positive), not reduce by an absolue value or multiply or divide with rational number. One of of the first steps Ration Resource is to remove all resource because There is no other way to achieve it globally.
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.
-
1 minute ago, FreeThinker said:
Yes but there is also some merit in the reasoning that people download Rational Resources precisely because they agree the stock atomistic resource distribution solution is unbalanced/boring and they want a more holistic high entropy distribution for resources.
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.
-
1 minute ago, FreeThinker said:
Well you can remove all resource distribution out of CRP but it won't change rational main aim to create entropy, the only possible solution I see is that a compromise could be made, in the case of water, certain polar biomes might add water.
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.
-
1 minute ago, FreeThinker said:
No it wil not solve anything because your proposed solution is Atomistic while Rational Resources is Hollistic, they cannot be united.
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.
-
Just now, FreeThinker said:
Well Rational Resources as I understand it, takes a more hollistic view on resources as resources are not only give meaning as a positive presence but also by their absence as this creates entropy which makes a game more intresting.
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.
-
1 minute ago, FreeThinker said:
Well this is something I can fix, and you don't even have to ask.
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.
-
1 minute ago, Nertea said:
Yes I would prefer this also. Because fundamentally overlapping resource distributions don't conflict, they don't need to be defined in a community deconfliction pack.
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 minutes ago, FreeThinker said:
Yes, but the mere fact that MKS adds water to the surface of the Mun, causes it to be convertable into Hydrogen upsetting the balance and realism. A solution would be if MKS uses something different than Water for its processes.
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).
-
10 minutes ago, FreeThinker said:
Well I think in general, there should no Water on the Mun (which is a game representation of the Earth Moon) but I'm willing to compromize by not removing Water from the Mun surface when MKS is installed, but in exchange MKS should not allow that water to be converted into LiquidFuel or any other resource that can be used for propulsion, as this upsets KSPIE balance.
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.
-
Just now, NateTheGreat said:
I wan't one that can go 1000 time the speed of light
You can always mess with the configs
-
2 minutes ago, zer0Kerbal said:
Interesting. Am pondering how this would affect players like myself who use mods like SimpleConstruction!, which uses CRP for [metals] and {rocketparts].
Ore is also used, but that is stock (of course) and stock controls the distribution.
The change wouldn't affect (directly)...
sounds good then.
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.
-
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.
-
On 6/24/2021 at 10:20 AM, DeDMC said:
hello. Is there a translation into Russian? if there is, where can I get it?
Localizations are done by the community, and bundled when submitted with the mods.
-
1 hour ago, JB5 said:
Clean save with just LS worked fine. I'm going to do a one-by-one addition of all mods till it stops working. Ill report back what I find.
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.
-
7 hours ago, JB5 said:
So new save changes nothing. Tried it on Sandbox and Career. Blank screen in Space Center view. With and without a command pod or something similar in the VAB I can't get the screen to pop up.
Also, the error is still spamming in the console.
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.
We've been working on a CI build (bleeding edge downloads) and some last part textures before it goes to showtime.
[1.x+] Community Resource Pack
in KSP1 Mod Releases
Posted · Edited by RoverDude
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:
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).