Factorio's Belt Bug(pubby.games)
pubby.games
Factorio's Belt Bug
http://pubby.games/factorio.html
65 comments
It's good on desktop, but when I initially looked at this article on my iPhone, the photos were much too small.
I sometimes think that the rise of mobile, and subsequent need for responsive design, is what truly killed the ideal of an internet driven by readable markup and only the most basic stylesheets.
I sometimes think that the rise of mobile, and subsequent need for responsive design, is what truly killed the ideal of an internet driven by readable markup and only the most basic stylesheets.
The images are actually a bit small on desktop as well. It could definitely use a few tweaks but I still like the idea. I think a bit of minimum padding so that text doesn't touch the edge of the screen and some logic for sizing images would make this a great style.
Hello my name is John and I am a Factorio addict. I have so far managed to go two days without playing Factorio. But I fear that my resolve is slipping away. I dream of belts and factory layouts in my sleep. Of killing biters with long range artillery while laughing like a crazy person. Of witnessing yet again the launch of a mighty rocket as it race to the heavens. My name is John and I am a Factorio addict.
Is the "Merges" section true? In factorio, since belts have two lanes, a T-intersection merge like the one pictured doesn't zipper; instead, the left belt feeds onto the left lane of the central belt and the right belt feeds onto the right lane. If the central belt already contains an object, that object has "right of way" over merging objects.
Any article referencing Factorio should warn how insanely addictive it is.
Yep :) I have played Factorio more than any other game. By far.
[deleted]
This is a deliberate trade-off for performance, as described in https://www.factorio.com/blog/post/fff-176
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.
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.
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.
There isn't any seam once the belt is fully compacted. This saves a check per full belt per tick -- this adds up.
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
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.
"yourself" detection is anything but simple
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.
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.
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.)
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.)
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
I've been a single dad the entire time ... and still squeezed in that much Cracktorio
First of all, I applaud you for squeezing that much into your life. I honestly think that's awesome.
re single Dad and Cracktorio: my wife calls it Divorcio. So I see how those go together. :)
First of all, I applaud you for squeezing that much into your life. I honestly think that's awesome.
re single Dad and Cracktorio: my wife calls it Divorcio. So I see how those go together. :)
Wow. And I thought my 800+ hours was a lot :)
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
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
I decided to check when I did. Apparently 2014-09-09.
Well worth it to get my name into the game. https://i.imgur.com/RftBXWG.png
Well worth it to get my name into the game. https://i.imgur.com/RftBXWG.png
One of the very few games I bought somewhere else that gave me a free steam key when it moved to steam. Still gives me warm fuzzies a half decade later. Can't say the same about satisfactory.
I also remember if you had 1 belt side loading onto another belt, and the item frequency lined up just right, items on the main belt could catch those on coming in from the side belt and push them along. This resulted in items hanging off of the side of the belt, still making their way through the factory.
this is like coinduction
As with all bugs and edgecases this of course eventually became useful for some setups: https://www.reddit.com/r/factorio/comments/9bs4sx/my_new_kov...
From the description, it takes advantage of belts being a little weird, but if it actually hits 100% that setup locks up.
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.
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.
I'm running several similar setups without any hiccups. It's a three year old post, possibly the behavior has been slightly adapted.
Oh and if you're hitting 100% you're using too little nuclear power or building not enough nuclear bombs ;)
Oh and if you're hitting 100% you're using too little nuclear power or building not enough nuclear bombs ;)
I... don't quite see how it's a bug, honestly: if the belt is full, you should not be able to place another iron plate on it. And indeed, you can't. What's the bug?
The problem isn't that you can't put more stuff on it, it's that the contents aren't moving. When the contents of the belt are perfectly homogeneous, this is less of an issue, but if you had a belt full of mixed materials with grabbers configured to pickup only certain materials, those grabbers may never have the opportunity to pick up their configured target because the belt contents don't move once it's full.
Looped belts are never the best way to do something in factorio anyway. This would only affect people very new to the game, and might give them a hint that there’s a better way.
It's also a playstyle, though. People make these 'sushi belts' for fun with different items on them.
A somewhat valid use-case is for inserting science packs into labs.
A somewhat valid use-case is for inserting science packs into labs.
> A somewhat valid use-case is for inserting science packs into labs.
There are seven kinds of science packs in the vanilla game, so without sushi belts, you need four belts to bring all of them to the labs. That can take a lot of space, making it harder to for instance use beacons (which like compact designs since their effect range is limited).
There are seven kinds of science packs in the vanilla game, so without sushi belts, you need four belts to bring all of them to the labs. That can take a lot of space, making it harder to for instance use beacons (which like compact designs since their effect range is limited).
you just need to bring those belts to the first LAB. Rest of them can get science by stealing using inserters
What would happen in the real world? If fully compact means full of material, then would corners have more material that would spill over after the turn? Or would this cause so much friction that materials would stop moving?
I think we need a mythbusters style investigation on this.
I think we need a mythbusters style investigation on this.
In the real world, the items aren't moving, it's the belt that's moving. So the belt just keeps spinning even if it's completely filled with items.
The cause of this bug is the fact that items move while the belt is static (despite the animation) and their moving requires a free spot in front of them. Once the belt is full, there's no empty spot for items to move into and the items stand still. The loop is stuck.
The cause of this bug is the fact that items move while the belt is static (despite the animation) and their moving requires a free spot in front of them. Once the belt is full, there's no empty spot for items to move into and the items stand still. The loop is stuck.
Either that, or the belt is actually a bunch of locally controlled tiny sections. In which case it makes perfect sense that it stops.
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.
[deleted]
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.
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.
It’s a textbook bug, it’s an unhandled edgecase.
The designer didn’t sit down and go “and logically when a circular belt is full, the items should stop moving while the belts keep moving”.
The fact that it was decided to not handle this edgecase does not mean it stops being a bug, no matter how much you love the game or how strongly you want your mantra of “factorial has no bugs” to be true.
Of cause factorial has bugs, lots of them. Just look at the thousands of fixes. This is one of them, and it’s a bug that has been there from the start and will likely never get fixed, but it’s still a bug.
The designer didn’t sit down and go “and logically when a circular belt is full, the items should stop moving while the belts keep moving”.
The fact that it was decided to not handle this edgecase does not mean it stops being a bug, no matter how much you love the game or how strongly you want your mantra of “factorial has no bugs” to be true.
Of cause factorial has bugs, lots of them. Just look at the thousands of fixes. This is one of them, and it’s a bug that has been there from the start and will likely never get fixed, but it’s still a bug.
The way items “should” behave is up to the designer/developer. It is not a bug if it’s an intentional design decision.
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.
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.
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 bet you just nerd-sniped them into their next FFF post.
This is almost certainly a side effect from their belt optimization from years (?) ago? Strangely I do sushi belt science sometimes and I’ve never noticed this bug, I’d wager the splitters and circuit network stuff changes the behavior enough to avoid the problem.
This is almost certainly a side effect from their belt optimization from years (?) ago? Strangely I do sushi belt science sometimes and I’ve never noticed this bug, I’d wager the splitters and circuit network stuff changes the behavior enough to avoid the problem.
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.
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)
Yes the simulation basically reads and writes all RAM each tic. So if your RAM is slow upgrading that gets you the biggest performance increase.
Yeah my K2 + SE run now allocates ~98% of all my available RAM.
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)
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)
So, for having a problem with this bug I need not only circular belts, but also letting them fill-up with mixed materials?
Well, I for one don't care about it. If you are letting belts fill-up with mixed materials you already have enough problems that you won't even notice this. And circular belts just aren't useful.
Well, I for one don't care about it. If you are letting belts fill-up with mixed materials you already have enough problems that you won't even notice this. And circular belts just aren't useful.
Circular belts are useful as fast buffers.
Ok, they work. But chests with inserters react faster after empty and store more items per structure applied or space.
tbf, I’m a total noob at factorio. I loved it and played it quite a lot but Satisfactory definitely stole my attention when it comes to factory building.
Here comes 1.1.42. I'd expect it cob Monday, even Wube would get the weekend
this is madness, a transform parenting system would have done this.
https://pubby.games/style.css