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).
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.
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
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.
It's not a bug. It's a game mechanic. If it was a bug Wube would have had it fixed within 24 hours and pushed out a new release. They are an admirable exemplar to inspire all of us.
The fact that they chose not to fix it does not mean it’s not a bug. It’s obvious to even a first grader that this is not how items on a circular belt should behave.
All full belts stop moving if there is nothing removing content in the Factorio universe. It's obvious to a pre-schooler that full belt that is circular stops moving too.
It's a game. It's not reality. In reality belts need to be powered. Also, in reality, you do not shoot aliens or drive large mechanical spiders. The fact that they chose to implement a game mechanic means it's a game mechanic, not a bug.
If author is here, I would showcase this behaviour with a mixed material circuit gif, because it is not obvious at all to the spectator that the impression of stillness is due to the belt being still and not to the refresh frequency moving items exactly to the former item position.
I have accepted this is how belts work and it is intentional for some reason, but on my first build I struggled with this.
My concept was that all of the research would be centralized and wrapped with a single belt that continuously loops with all of the various research types. This kind of works, but everything gets backed up and then no longer rotates, which limits access.
A cycle of belt items never moving because each item is blocked by another item (whether moving or not), reminds me of a cycle of reference-counted objects never being freed because each object is referenced by another object.
Factorio is driving me to upgrade my 2015 i7-5820K based computer. I've been playing with 2 sets of mods, "Bob's" and "Angel's" which increase the complexity of Factorio by at least 1 order of magnitude.
To run a base large enough to produce everything I want has dropped the speed from 60 updates+frames per second to about 40, with each addition further slowing the whole thing down.
It would be an interesting exercise to see how much complexity one could add to a Factorio map before the updates/sec start to drop. I'm hoping that a new AMD chip will be able to handle a much, much larger base/map before slowing down again. EDIT: To actually finish my thought here: You could test different CPU/RAM configurations with a series of maps of increasing complexity.
I seem to remember reading somewhere on the forums or the subreddit that for Factorio, memory speed is a lot more important than CPU/GPU performance (in terms of the UPS gains you can achieve by improving either of them)
Readit News
It's a game. It's not reality. In reality belts need to be powered. Also, in reality, you do not shoot aliens or drive large mechanical spiders. The fact that they chose to implement a game mechanic means it's a game mechanic, not a bug.
Also, as pointed out, that setup can be made more reliable and not-glitch-using by making the bottom left corner of the loop a slower belt.
Oh and if you're hitting 100% you're using too little nuclear power or building not enough nuclear bombs ;)
My concept was that all of the research would be centralized and wrapped with a single belt that continuously loops with all of the various research types. This kind of works, but everything gets backed up and then no longer rotates, which limits access.
To run a base large enough to produce everything I want has dropped the speed from 60 updates+frames per second to about 40, with each addition further slowing the whole thing down.
It would be an interesting exercise to see how much complexity one could add to a Factorio map before the updates/sec start to drop. I'm hoping that a new AMD chip will be able to handle a much, much larger base/map before slowing down again. EDIT: To actually finish my thought here: You could test different CPU/RAM configurations with a series of maps of increasing complexity.
I have to upgrade my computer to load the map if any other applications are open (something is also messed up with my swap, it just grinds to a halt)