A bug! The correct behavior, as handled by the first algorithm, is to only move one or the other not both. What happens when two or three belt merge together, as in the case below?Īs defined, the second algorithm will move both items onto the merged belt at once because it can't prove either to be immobile. If you try this algorithm out on a circular belt, you'll notice it completes without marking a single "X"! But this is correct: all items in the belt will move around it, as none were proven to be immobile.īefore giving the pseudocode, there's something that needs to be addressed. Then, all items without a red "X" can be moved forwards. This new algorithm also runs until it reaches a fixed point. Once we mark a red "X", the item before it can be marked as well. Likewise, if an item is blocked by another immobile item, it can't move either. Below, we'll mark such items with a red "X" to show they can't move. So how do we do this? Well, if an item is at the end of a belt, it's safe to say that item can't move. The algorithm above tries to prove which items can move, pessimistically assuming that any item it can't prove, won't move.īut what if we do the opposite? Consider an algorithm that optimistically assumes all items move, then proves which items can't.
#FACTORIO SPLITTER FREE#
But when the items are packed tightly into a circle, there is no free space and so the whole belt jams up. We'll have to tag each item that moves and exclude it from future iterations.Īnd here's the algorithm running to completion, visualized:įor an item to move under this algorithm, it must have a free space to move onto. Otherwise, items will teleport all over the place at inconsistent speeds. Lastly, it's important that when an item moves, it won't move again until the algorithm completes. The algorithm stops when no items can be moved anymore. There are different orders one can iterate - some more efficient than others - but for the sake of correctness, all that matters is eventually reaching a fixed point. For example, item "A" below can't move until item "B" has moved, and this may take several iterations. If the tile in front of an item isn't empty, we can't move the item there yet but it may be possible to move the item at a different iteration. As we find such items, we'll move them forwards on the belt and continue our iteration. To update, we'll repeatedly iterate over every item on the belt, looking for items that have an empty tile in front of them. Imagine a simplified version of Factorio in which belts are single-lane and can hold only one item per tile: I don't have access to Factorio's source code, but I reckon I can give a good explanation of why this happens.
#FACTORIO SPLITTER FULL#
But as soon as the belt reaches full capacity, it stops. At first, items placed on the belt appear to work normally, circulating around like the luggage return at an airport. The issue occurs when belts are arranged in a loop.
#FACTORIO SPLITTER CODE#
The code that implements these belts is marvel of optimization, but unfortunately they can't handle every construct. Factorio is a factory-building game involving lots (and I mean, LOTS) of conveyor belts.
0 kommentar(er)
