Stock chip creates multiple requests for "long" production time items
zaped212 opened this issue ยท 3 comments
I was working on trying to use a stock chip to try and "always" have x of a specific item available at a given time to increase the efficiency of my automated crafting machines.
This would be very handy for items that are frequently used but take a while to produce.
One thing I am noticing though, for the items that take a long time to produce, multiple requests are made to re-stock the item.
I have built a machine that is capable of building solar panels from absolute scratch or any intermediate items currently in stock. Creating 8 solar panels currently takes 70 seconds from scratch, but when i started adding intermediate stock, i was able to get the production down to 40 seconds.
When building more items that have alot more crafting steps this time could greatly increase, example HV solar panel, at the current rate my system runs ( 40s/8 panels ) it would produce the necessary 512 solar panels in 42 minutes. So some of these recipies could take a relatively long time to complete.
From observation of the system:
It looks like the stock chip will periodically check its inventory and make a request for all missing items.
For items that take a long time to produce, it can check the stock multiple times. Resulting in more items than expected.
It would probably work well to track outstanding requests,
Such that:
Count of available items = C
Count of requested items = R
Expected count = E
Missing Items = M
So the broadcasting chip would use C, but when calculating the missing items you take into account the number of requested items.
For restocking any missing items:
M = E - ( C + R )
For restocking when empty:
If C is 0, then M = E - R.
On each request R is incremented. Then every time that an item is added, R is decreased, and C is incremented, essentially not changing the sum of C + R.
Confirmed bug. You are describing how the system is suppose to work. I Have a solution to this in mind.
Just to update, this will be inherently a non-issue for the pipe network rewrite I am planning.