[HN Gopher] Factorio's Belt Bug
___________________________________________________________________
Factorio's Belt Bug
Author : pubby
Score : 175 points
Date : 2021-10-02 02:12 UTC (20 hours ago)
(HTM) web link (pubby.games)
(TXT) w3m dump (pubby.games)
| lullibrulli2 wrote:
| 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...
| Dylan16807 wrote:
| 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.
| lullibrulli2 wrote:
| 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 ;)
| [deleted]
| etempleton wrote:
| 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.
| freeone3000 wrote:
| This is a deliberate trade-off for performance, as described in
| https://www.factorio.com/blog/post/fff-176
| pubby wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There isn't any seam once the belt is fully compacted.
| This saves a check per full belt per tick -- this adds
| up.
| jtsiskin wrote:
| 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
| avereveard wrote:
| "yourself" detection is anything but simple
| pubby wrote:
| 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.
| bastawhiz wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| martincmartin wrote:
| _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. :)
| MaulingMonkey wrote:
| 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
| idiotsecant wrote:
| 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.
| Akronymus wrote:
| 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
| Macha wrote:
| Nice. Probably the most commented on name in the game, I
| don't remember most of them but have seen this one
| referenced in reddit threads etc.
| Akronymus wrote:
| I think the "is on fire" is more commented upon. (which
| is the one that inspired me to choose the bees)
| Laremere wrote:
| 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.
| kevincox wrote:
| Tangential: I love the stylesheet. A whole 4 lines to make a very
| readable website.
|
| https://pubby.games/style.css
| Wowfunhappy wrote:
| 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.
| kevincox wrote:
| 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.
| pyrale wrote:
| 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.
| francoisdevlin wrote:
| Here comes 1.1.42. I'd expect it cob Monday, even Wube would get
| the weekend
| tullianus wrote:
| 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.
| [deleted]
| onlyforthiss wrote:
| this is madness, a transform parenting system would have done
| this.
| Evansbee wrote:
| 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.
| bregma wrote:
| 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.
| tomtimtall wrote:
| 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.
| MattRix wrote:
| The way items "should" behave is up to the
| designer/developer. It is not a bug if it's an intentional
| design decision.
| tz18 wrote:
| this is like coinduction
| nyanpasu64 wrote:
| 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.
| Joker_vD wrote:
| 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?
| ericpruitt wrote:
| 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.
| bspammer wrote:
| 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.
| flemhans wrote:
| 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.
| cesarb wrote:
| > 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).
| krzyk wrote:
| you just need to bring those belts to the first LAB. Rest
| of them can get science by stealing using inserters
| aenis wrote:
| Any article referencing Factorio should warn how insanely
| addictive it is.
| bloopernova wrote:
| 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.
| X6S1x6Okd1st wrote:
| 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)
| 130e13a wrote:
| 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)
| bombcar wrote:
| 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.
| fimdomeio wrote:
| 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.
| VortexDream wrote:
| 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.
| Linosaurus wrote:
| Either that, or the belt is actually a bunch of locally
| controlled tiny sections. In which case it makes perfect
| sense that it stops.
| marcosdumay wrote:
| 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.
| pjerem wrote:
| Circular belts are useful as fast buffers.
| marcosdumay wrote:
| Ok, they work. But chests with inserters react faster after
| empty and store more items per structure applied or space.
| philipov wrote:
| What a coincidence. I just spent all day playing Factorio.
| alexktz wrote:
| It's Saturday... What day do you think it is?
| nacs wrote:
| They probably believe it's still September.
| dkersten wrote:
| Of last year
___________________________________________________________________
(page generated 2021-10-02 23:02 UTC)