[0.18.18] Consumption graph inaccurate with modded lab.

[triggerman602]

When using the lab from the Big Lab (https://mods.factorio.com/mod/BigLab) mod with lots of beacons, productivity modules, and loaders, the consumption graph shows all science except for the slowest one being consumed at half the rate of the slowest one when bottlenecked. I've attached a save file with this being demonstrated.

[Rseding91]

Thanks for the report. I know what causes this but I don't have any fix for it. The actual amount of science packs being consumed is correct, just not all of them being consumed are being reported as consumed. Example:

* Lab consumes 90% of the durability of 1 science pack
* Loader transfers 90% of the science pack durability it has to the lab science pack
* Lab consumes 90% of the durability of 1 science pack
* Loader transfers the remaining 10% of the science pack it has, reduces the count by 1, and transfers 80% of the next science pack it's holding

From the loaders perspective nothing is being consumed - it's purely transferring items from itself into the lab. From the labs perspective nothing is being consumed - it's just taking 90% durability off 1 item each time it works.

And so you don't get the numbers reported as consumed most of the time.

The transfer logic is correct.
The lab logic is correct.
Together they're incorrect.

And I have no solution to that

[robot256]

Saw this thread because it was referenced in viewtopic.php?f=47&t=101875

One solution is for science pack consumption to be recorded as a fractional value. But that would be way more compute intensive and still have corner cases.

Another solution is to change loaders so that they behave like inserters, only moving whole items. Really, I think this is the unexpected behavior here--even though I know this is how ammunition is treated when moving stacks by hand, it did not occur to me that a loader could move and merge partial items.

[Adrenalex]

I just posted a report from 1.1.56 that was very similar to this. However, I'd like to add something which I think might be relevant.

I don't actually think the consumption is correct. I've been playing Krastorio 2 and have been having some lab issues.

I have a base where I'm producing 2k of every science tech card. One of them I was reworking and so it was drained from the science labs. I have not been able to refill the labs with that tech card since. I'm now producing more of that tech card than any other I've let it completely buffed with continuation production and everything else over night.

I can not refill it. The tech cards disappear faster than all the other tech cards by far. As soon as the belt no longer has one of the tech cards feeding it the machine mows through it and the other ones don't really change.

Watching the machine, sometimes the durability of one of the cards doesn't even change. I guess I can use inserters?

[MEOWMI]

To chime in some:

If two items combine into just one, then at least one full item's worth of durability has been used up across both items combined, as otherwise they couldn't combine into just one item (they must be at 50% or lower on average, meaning at least 50% durability has been used on each item on average, 2*50% = 100% = one item).

This means, that it would be numerically correct to trigger a consumption event when they are combined.

I believe this works just as well if it's smaller partials. (E.g. 30% + 30%, count it as a consumption and merge to 60%, and once 60% is used up it counts as another consumption, it just means that the remaining 40% was consumed somewhere else prior to it so the logic still seems to add up.)

If the two items combine with a combined durability of >100%, then two items still persist, no consumption is recorded. It just means you will eventually trigger two consumptions earlier down the line.

[posila]

If two items combine into just one, then at least one full item's worth of durability has been used up across both items combined, as otherwise they couldn't combine into just one item (they must be at 50% or lower on average, meaning at least 50% durability has been used on each item on average, 2*50% = 100% = one item).

Your logic is correct, the problem is that item transfer code is completely oblivious to any context under which the transfer is happening, so for example it has no way of knowing to which force the consumption should be attributed to. And providing this context to everywhere it would be needed would require major changes in the code that would also probably have some negative performance impact. Therefore Rsading said "I know what causes this but I don't have any fix for it"

EDIT: And actually even if it had this context, it would still not be 100% correct, because the one who is merging the two 30% items might not have been the one who consumed 70% out of them, so the consumption would be attributed to the wron force.

[Silari]

EDIT: And actually even if it had this context, it would still not be 100% correct, because the one who is merging the two 30% items might not have been the one who consumed 70% out of them, so the consumption would be attributed to the wron force.

Is there a reason why the labs themselves can't just report their partial consumption each tick, or does the consumption stats not support anything but integers?

[Rseding91]

EDIT: And actually even if it had this context, it would still not be 100% correct, because the one who is merging the two 30% items might not have been the one who consumed 70% out of them, so the consumption would be attributed to the wron force.

Is there a reason why the labs themselves can't just report their partial consumption each tick, or does the consumption stats not support anything but integers?

Consumption/production only supports integers.

[mrvn]

The lab could have an internal counter for the fraction consumed and report consumption whenever the internal counter reaches a full pack.

[FuryoftheStars]

The lab could have an internal counter for the fraction consumed and report consumption whenever the internal counter reaches a full pack.

If a lab is mined, though, any partial unreported amount would be lost. I know, it wouldn't be common and should be a trivial amount. Still, worth mentioning.


I like this idea the best:

Another solution is to change loaders so that they behave like inserters, only moving whole items.

[mrvn]

The lab could have an internal counter for the fraction consumed and report consumption whenever the internal counter reaches a full pack.

If a lab is mined, though, any partial unreported amount would be lost. I know, it wouldn't be common and should be a trivial amount. Still, worth mentioning.

The counter doesn't have to be per lab. A static counter used by all labs in common works even better. If 10 labs each use 10% of a science pack you would get a consumption of 1 science pack. Also means the state of the lab doesn't grow, only increases the game state by 7 (num science packs with mods) counters in total.

[Wiwiweb]

Just to clarify since I link to this thread often anytime someone wonders about their consumption graphs:
This is an issue with loaders connected to any lab, even vanilla labs. The thread title should be "Consumption graph inaccurate with loaders feeding into lab."

[Zaflis]

Thanks for the report. I know what causes this but I don't have any fix for it. The actual amount of science packs being consumed is correct, just not all of them being consumed are being reported as consumed. Example:

* Lab consumes 90% of the durability of 1 science pack
* Loader transfers 90% of the science pack durability it has to the lab science pack
* Lab consumes 90% of the durability of 1 science pack
* Loader transfers the remaining 10% of the science pack it has, reduces the count by 1, and transfers 80% of the next science pack it's holding

From the loaders perspective nothing is being consumed - it's purely transferring items from itself into the lab. From the labs perspective nothing is being consumed - it's just taking 90% durability off 1 item each time it works.

And so you don't get the numbers reported as consumed most of the time.

The transfer logic is correct.
The lab logic is correct.
Together they're incorrect.

And I have no solution to that

What if moving science packs from labs would always keep at least 100% (or at least 50%?) durability of work inside it? So stack inserter moves 12 red science in it, then other one removes 11 out. It would also give more continuous lab production on daisy chained setups. It's not an issue even if inserter's hand size is just 1, it will just take 2 or 3 insertions before the first chained insertion happens. As the hand size increases it just gets better, and this doesn't really limit how many labs you can daisy chain together.

As a more general inserter rule it would also help steam boiler setups that chain coal, although i haven't tested its current state. Other potential uses are gun turrets that also have ammo durability on item.

Edit: I misunderstood the problem as i re-read it... and i still don't really understand. Loader transferring something out of a lab is not "consumption".

[mrvn]

That would also remove the loss of science packs due to transferring packs with partial durability. Apparently when you daisy chain labs you get less science than when you feed them individually. As for steam boilers don't they consume the fuel when they use the first joule of energy and then keep an internal counter of how much energy is left? I've never seen an inserter take out a partially used coal out of a boiler. Don't think that is even possible.


The problem is this: A science lab reduces the health of the science packs as it researches. When the health of a science pack reaches 0 the science pack is removed and a consumption of 1 science pack is reported by the lab.

Now loader seem to take science packs out of the lab and merge their health. So if the loader takes out a science pack with 40% health out of the lab and then shortly after it takes another science pack with 40% health out of the lab then it will merge that into a single science pack with 80% health. 2 mostly used science packs become one little used science pack.

So the loader reduces the item count of science packs but does not report a consumption. When the science pack is eventually consumed by a lab only one consumption event is reported even though initially it was 2 science packs.

The loader doesn't really consume anything since 2* 40% == 80% is no consumption. But if you look at it another way what the loader does is take 2 40% science packs and make one 80% and one 0% science pack and then it "consumes" the 0% science pack. The consumption graph works on items and the loader destroys an item.

I don't get why the loader doesn't just report the consumption to the force the loader belongs to. Maybe that's the wrong force but then one force is stealing science packs from another and the production/consumption graph for that force will be off anyway. Can a loader even take items out of a science lab of another force? Does that happen in games?

[SilberSeele]

I can think of two fixes; both kinda annoying.

1) rework labs to always instantly consume 1 each of the needed science packs; meaning you'll add bars for each pack below the lab's inventory showing the current consumption of each pack. The current lab inventory will remain has an inventory to grab -1 item if a bar reaches 0. This should keep the lab consumption logic completely as it is while fixing this glitch. This is also somewhat in line with the machine inventories revealed in 2.0. But needs a slight visual rework of the labs UI. Alternatively add a second inventory below, which inserters cannot grab out of, and instead use this with the same logic as above.

2) add a hidden variant of insertes to fix this. Should be quite cheap. If placed from hand; evaluate the backside of each placed inserter: if lab -> change into variant inserter.
if placed from bluepring; you can evaulate all inserters once when creating the BP. The variant used will be hidden from the user.

[Zaflis]

Why are we even talking about loaders? What items are in the input slot and what % they have have nothing to do with consumption graph. Each lab needs an internal variable for each science type that is increased by per-tick progress normally + productivity. When that internal variable reaches 100% => increase that item consumption by 1. If the input slots don't contain input items with enough durability then progress cannot increase.