6 ms·

This is a deliberate trade-off for performance, as described in https://www.factorio.com/blog/post/fff-176 https://www.factorio.com/blog/post/fff-176

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 ago
  It'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 ago
    I 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 ago
      There isn't any seam once the belt is fully compacted. This saves a check per full belt per tick -- this adds up.
- jtsiskin 5y ago
  Yes 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 ago
    Sure, 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
bastawhiz 5y ago
Yeah. There's no way you could build the ridiculous stuff that some folks do if each individual item on a belt was checking positions and moving individually. It's simply too much stuff.
- MaximumYComb 5y ago
  IIRC it used to behave that way and people used a lot of underground belts to compensate for this since underground belts would move as one.
  - duskwuff 5y ago
    At one point, very early on (around 2015), the game fully simulated "physics" for each item on a belt. If positioned in certain ways, inserters would place items in the center of a belt and they'd form a lane down the middle, blocking items from being placed on either side. I think they'd even stay that way through splitters. The modern game is a lot more restrictive in terms of how items can be laid out on belts. (This is a good thing. The old behavior was often unpredictable and hard to control.)
    - MaximumYComb 5y ago
      That must have been really early, I bought the game right at the start of 2016.... and now I just realised my 2111.8 hours equates to over an hour a day since then. In that time, I've been a single dad the entire time time and studied an entire undergraduate degree while working full time and still squeezed in that much Cracktorio
      - MaulingMonkey 5y ago
        Early 2016 was the initial Steam early-access release. I bought in late 2014, pre-steam. I also have a late 2013 email referencing Factorio - a RimWorld project update giving a nod to "Other interesting games you might want to check out"! Early 2013 was the initial Indiegogo campaign. While the sprites looked much different then, many of the machines and mechanics appear to have been fundamentally in place even way back then - from robots to cars to inserters to belts. https://www.youtube.com/watch?v=V1qOCAM9Syw https://www.youtube.com/watch?v=V1qOCAM9Syw

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 ago
It'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 ago
  I 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 ago
    There isn't any seam once the belt is fully compacted. This saves a check per full belt per tick -- this adds up.
jtsiskin 5y ago
Yes 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 ago
  Sure, 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

bastawhiz 5y ago

Yeah. There's no way you could build the ridiculous stuff that some folks do if each individual item on a belt was checking positions and moving individually. It's simply too much stuff.

MaximumYComb 5y ago
IIRC it used to behave that way and people used a lot of underground belts to compensate for this since underground belts would move as one.
- duskwuff 5y ago
  At one point, very early on (around 2015), the game fully simulated "physics" for each item on a belt. If positioned in certain ways, inserters would place items in the center of a belt and they'd form a lane down the middle, blocking items from being placed on either side. I think they'd even stay that way through splitters. The modern game is a lot more restrictive in terms of how items can be laid out on belts. (This is a good thing. The old behavior was often unpredictable and hard to control.)
  - MaximumYComb 5y ago
    That must have been really early, I bought the game right at the start of 2016.... and now I just realised my 2111.8 hours equates to over an hour a day since then. In that time, I've been a single dad the entire time time and studied an entire undergraduate degree while working full time and still squeezed in that much Cracktorio
    - MaulingMonkey 5y ago
      Early 2016 was the initial Steam early-access release. I bought in late 2014, pre-steam. I also have a late 2013 email referencing Factorio - a RimWorld project update giving a nod to "Other interesting games you might want to check out"! Early 2013 was the initial Indiegogo campaign. While the sprites looked much different then, many of the machines and mechanics appear to have been fundamentally in place even way back then - from robots to cars to inserters to belts. https://www.youtube.com/watch?v=V1qOCAM9Syw https://www.youtube.com/watch?v=V1qOCAM9Syw