We started a playthrough with your dangerous mod and the mods suggested there, so we were also using this peppermint mining mod. Played around with the peppermint marker, grinded our way to bots and somehow it is very very inefficient. E.g. it takes 5 minutes for peppermint to assign one job to bots. We made sure power is sufficient and everything, but I felt something is off. We looked at the code and these are our findings:
1) Junk coordinates
Peppermint basically runs once every 61 ticks. One run takes a coordinate from global.peppermint and if there is ore and other conditions succeed, it will mark it to mine for bots. If this coordinate is not useful, it stops and does nothing. After the next 61 ticks the next entry is checked.
Now the root of the problem is that global.peppermint got full of junk coordinates, which have already been mined away in the past. So keeping this garbage collected is important. There seems to be a line to keep it tidy (control.lua:390), but this is never executed. The picker always returns the coordinate (control.lua:378). You even have a fitting comment on the next line: "Why is ore invalid? Check if it's been depleted or replaced." - That's really what should happen there now and remove the coordinate from global.peppermint.
We did a hacky workaround and run a little garbage collector on every 601 ticks:
function peppermint.gc()
for forcename, surface in pairs(global.peppermint) do
for surfacename, minty in pairs(surface) do
for key, ore in pairs(minty) do
if not (ore.valid and peppermint.is_tasty(ore, forcename)) then
minty[key] = nil
end
end
end
end
end
script.on_nth_tick(601, peppermint.gc)
But this is not a good solution. Better would be to do a clean check in the picker and decide to remove the coordinates from global.peppermint.
2) Efficiency
Looking through the code I realized that the bigger you mine with peppermint, the more inefficient it gets. We right now have only 2 outposts with around 200 bots in total.
The problem here is the way it assign those jobs - it is very serialized. Currently it takes one coordinate from global.peppermint per run. So for peppermint to come back to this coordinate is to take a full loop of all those coordinates. So the bigger global.peppermint is marked, the more inefficient are the jobs to mine, because it takes too much time to go through all the coordinates in global.peppermint.
The way you intend it to work is your decision. I just wanted to point out, that this mod is more and more inefficient the more ores on different places are marked, because handling those coordinates is serialized. One loop = amount coordinates * 61 ticks.
I first thought maybe try to assign a job per logistic network in one run. The problem is though if you have a big base with one big logistic network, this won't help. Peppermint mining probably needs to try to handle coordinates in chunks. Do you have access to chunk coordinates? So that one job per chunk per 61 ticks are assigned. Gives room for parallelisation with bigger marked lists without impacting performance too much.
Once every 61 tick is also maybe too conservative, you might want to do mining more often.
3) Visibility
Have a way to show which coordinates are marked for mine with peppermint. E.g. by toggle or if you have the peppermint tool in hand. As a first iteration would also be fine if it was a debug toggle, if this is something mods can do.
