Decrease output of miners on infinite ores

[FuryoftheStars]

TL;DR

Decrease the output of miners placed on an infinite ore source to output no faster than a miner on non-infinite ores.

What ?

A while back, a change was made for miners sitting on infinite ores:

Version 0.17.65

Fixed that infinite item based resources with yield of more then 100% didn't actually mine more. So yield of 260% for example means that it mines 2 resources and 60% probability of 1 extra.

I'm asking for this change to be "undone" so that miners will operate the same on infinite ores as they do on non-infinite ores.
(I would've asked for this sooner, but I took a break from the game just before this change, only recently coming back and noticing it.)

Alternatively, add some kind of boolean flag to ores (or miners themselves) that defaults to current behavior, but can be changed to force mining of that ore's tiles to a max of 1 ore per cycle.

Why ?

Under the existing system, with infinite ores, it only takes a couple of miners to completely fill belts. With a (internal) max value of 100 for an infinite ore, the starting area can see values ranging from a few hundred to thousands of % per tile, even with the richness multiplier set for 100%. This means I only need to build a couple miners and they'll easily saturate my resource input needs (and as such I'll produce less pollution).

I can't speak for everyone, but for me this is not why I used infinite ore mods. To me, the point was to allow them to mine infinitely (essentially, I want my outposts to have infinite life ), but at the normal rate (so you'd still have to place a lot and create a lot of pollution for a higher throughput), and the higher % resource tiles just meant they'd last at the normal throughput rate longer before starting to output less (personally, I like the ones that allow depletion, like this one: https://mods.factorio.com/mod/infinite- ... -depletion).

I realize ores in vanilla are not infinite, so this is a mod use case only issue and as such has a low chance of being looked into, but there's no harm in asking, right?

[mrvn]

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]

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.

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.

How to modify that value in an already started game i dont know though.

[FuryoftheStars]

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.

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.

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 1263 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.

[FuryoftheStars]

Edited the main post to add into the alt idea of a bool flag on the ores to potentially be on the miners themselves. This could have the benefit of allowing some miners work 1 ore at a time, while other (mod) miners could output large quantities at a time.