mrvn wrote: Wed Nov 10, 2021 10:07 am
So why not just fix the mod to not set 260% for the resource? If the mod uses just 100% you get what you asked for.
UkcsAlias wrote: Wed Nov 10, 2021 10:52 am
The mod you specified as far as i know allows you to set the upper and lower boundary. And over time even causes depletion (although for my preference far too slow to realy influence the balance compared to a mod without depletion, hence i moved back to a mod with static value). Before starting a game, you might want to look in the mod settings first.
Not that simple.
UkcsAlias wrote: Wed Nov 10, 2021 10:52 am
Personaly, i think any value above 100% is normaly already too powerful in those mods. Even at 100% you generate such large value of resources it generaly causes a lot of your factory to become idle quite early. And buffering of resources doesnt become required.
As it's currently being used in game, absolutely, which is why I'm making this suggestion. Pre-0.17.65, this was not the case.
-----------------------------------------------
Here, let me go over how infinite ores (and this mod) actually work.
This is the code for the mod in its entirety (data.lua file):
Code: Select all
for k, v in pairs(data.raw.resource) do
if not v.infinite then
v.infinite = true
v.minimum = 15
v.normal = 100
end
end
That's it. Only other files in there are the thumbnail and info.json files.
The .normal value is used as such: [spawned ore tile quantity] / [.normal value] * 100% = [tile percentage]
At a value of 100, this will straight convert all tiles from x quantity to x%. A value of 50 converts from x quantity to (2*x)%, while 300 would convert x to (x/3)%.
This also affects the depletion rate, though, at a factor of: 100 / [.normal value] = [depletion rate]. At a value of 100, for every 1 primary mining cycle (the bonus mining cycles miners get from research doesn't count towards this) that yields ore, the percentage of the tile is reduced by 1 (the actual quantity of the ore yield doesn't affect this so long as it's > 1, so yielding 20 ore from a 2000% tile still only decreases the tile percentage by 1, while a yield of 0 ore (from a tile <100%) will not cause depletion). A value of 50 will deplete the tile by 2% each cycle (that yields ore > 1), while a value of 300 requires 3 ore yielding cycles before it will deplete by 1%.
The .minimum value is more straight forward. It's the lowest percentage the tile can deplete to.
Here's a screenshot with different .normal values compared to vanilla (used the map exchange string to ensure identical map):

- Non-infinite vs infinite ore.jpg (2.62 MiB) Viewed 1421 times
The mod itself is not actually controlling the amount of resources that spawn there. These are controlled by the game's internal systems, like the richness multiplier, on map generation.
Prior to 0.17.65, miner layouts on an infinite ore field would still yield roughly the same throughput of ores as in a non-infinite ore game to start, then after a while the throughput would start to decrease to the minimum. From 100000% to 100%, each mining cycle would still produce 1 ore as in vanilla. Once it's under 100%, then you started having the chance of not getting any ore on a cycle (90% yield has a 90% chance of giving you ore).
After 0.17.65, these same miner fields will yield many times more ore (not only are the primary mining cycles affected, but the bonus ones are too!) for the same period of time (assuming you could move all the ore out fast enough) before running down to the same depleted levels. However, as you can't really move the ore fast enough, you instead end up in a situation where most of the miners will be shutdown, reducing power consumption and produced pollution (both directly and indirectly). So this is now means infinite ores get 3 bonuses: fields overall will yield exponentially more ores before depleting, they'll produce significantly less pollution,
and you never run out.
The pre-0.17.65 behavior is what I liked: miner output would still be the same at start, then would run to low output levels, and would still have the same power requirements and pollution risk. The only way to achieve this now would be through control.lua, mapping out all ore tiles, and for tiles whose quantity is > 100, store their initial quantities off somewhere (-100), then set them to 100. Then every second or so (depending on how perfectly you want to mimic the pre-0.17.65 behavior), check all relevant ore tiles, setting them back to 100 quantity, decrement the stored initial value by the difference, and continue to do this until the stored value reaches 0. Then you can remove that tile from the checks let it deplete to the minimum. Can you imagine the performance cost of that?
I get, though, that the pre-0.17.65 behavior may not have been as intuitive (because yeah, I can see someone expecting a 200% yield tile to yield 2 ore per mining cycle), which is why I also threw in to the suggestion the alternative of adding a boolean flag to ores that would default to current behavior, but could be changed so that they'll only yield 1 ore per cycle. I should probably edit that post to make that more prominent.