4 ms·
Sweet article but I'm pretty sure the optimization there is independent of the circular belt bug. Presumably one could implement a similar optimization for both
by pubby 5y ago
Sweet article but I'm pretty sure the optimization there is independent of the circular belt bug. Presumably one could implement a similar optimization for both algorithms (it just might be hairier for the second one).
- freeone3000 5y agoIt's actually the result of this optimization -- since compacted items don't shift, a fully compacted belt will not move, even if the full compaction is in a circle.
- pubby 5y agoI still confused about your point. The segment optimization reduces the number of nodes being iterated over, but doesn't change much else. A fully compacted belt can move in Factorio, but only when Factorio knows it can output into an open belt. You can have a whole chain of fully compacted belts move, so long as the last segment has an opening. This is handled just like the first algorithm in OP - moving one segment per iteration like a big caterpillar walking. A loop is just a segment that outputs into its own input - it has a seam. Factorio can't move the belt because it doesn't see an open space. But one could still use the second algorithm, marking segments as immobile rather than tiles. This allows the loop to work without jamming, even with the optimization.
- freeone3000 5y agoThere isn't any seam once the belt is fully compacted. This saves a check per full belt per tick -- this adds up.
- jtsiskin 5y agoYes but the real solution is way simpler - when removing a gap, if there is no next gap, check to see if you’re merging with yourself. If you are, keep spinning
- pubby 5y agoSure, but that only works for the most trivial cases. The belt graph can be quite complicated, with loops comprising several segments. For cases like that you'd have to do cycle detection, which is totally not better than the 2nd algorithm.
- avereveard 5y ago"yourself" detection is anything but simple