Simple Priority Merger issues
@Andre Aquila <Aquila Industrial> There are some issues with the Simple Priority Merger.
1. The hole being used for output is an input hole. The whole with the silver on top is where output should leave the merger. The hole opposite the current output hole.
2. It takes items from unprioritized input when it shouldn't sometimes. I think this may be a threading issues, like the order in which belts/mergers do factory tick. I tested this with 2 containers feeding the priority merger, outputting into a third container. I found that I was often able to trigger this incorrect behavior by opening the inventory of any of the containers. I think this may re-order when things get factory tick, leading to issue. Maybe we could look a little further down the correct input belt in case that hasn't had latest tick?
4 Replies
I typed a story when creating this post, now I cannot see that... fml
There are some issues with the Simple Priority Merger.
1. The hole being used for output is an input hole. The whole with the silver on top is where output should leave the merger. The hole opposite the current output hole.
2. It takes items from unprioritized input when it shouldn't sometimes. I think this may be a threading issues, like the order in which belts/mergers do factory tick. I tested this with 2 containers feeding the priority merger, outputting into a third container. I found that I was often able to trigger this incorrect behavior by opening the inventory of any of the containers. I think this may re-order when things get factory tick, leading to issue. Maybe we could look a little further down the correct input belt in case that hasn't had latest tick?
Hmm, good to know elcheapogary! I have to change the mesh position asap...
The item 2 is a bit harder, i still trying to find out why it does it. Maybe it reads as the coming item as an empty item for a tick and if we slow it down a bit this tick it will work correctly.
Make a way to wait a little more for getting the second/third priority
Im using the function factory collect input, but maybe using another loop way will be better
Hi Andre, I saw the mesh update, looking much better, thanks. I was thinking about the second issue. I can't really see the screenshot nicely, but... Are you getting an input item and copying it into an inventory in response to the Factory_Tick event? If so, I think that may explain it. I think Factory_Tick can happen more frequently than Factory_GrabOutput - maybe even very, very soon after a previous Factory_Tick. Maybe interacting with other buildables connected to the belts causes Factory_Tick event on other buildables connected to the belt. At output 60 items/minute, there should be ~1000ms between Factory_GrabOutput events. Also, ~1000ms before we can get another item from the input belt. Consider this sequence: Factory_Tick - we move item from input into inventory, 200ms pass, Factory_GrabOutput - item is moved from inventory to output, 100ms pass, Factory_Tick again, caused by some user interaction. Inventory is empty, so we try fill it from input. At this point, it is still 700ms until we can get another item from the priority input. We try, get nothing, so move an item from second input into inventory. Next Factory_GrabOutput will take that item from inventory that arrived via secondary input. Maybe, instead, we just forward the Factory_GrabOutput event to the most prioritized input, stopping when one returns true. That way we are sure we are taking from input at the same rate as we are outputting. Don't even need Factory_Tick.
Like I say, I couldn't really make out what your screenshot says, and maybe I'm barking up the wrong tree. If so, I apologize. Just trying to imagine what the cause may be. In my head, this made sense. I hope it makes some sense to you too.