Factorio Forums

I want to know whether the items on a belt are moving or stationary. This would probably be a property of a LuaTransportLine.

The use case for this request is for the Belt Overflow mod, or possibly for a mod that highlights belts that aren't flowing.

Another year, another bump. I'm taking another crack at rewriting this mod and detecting stalled belts is still a significant amount of lua logic.

We'd also like this for Factorio Access: we used to try via heuristics but had to throw them out because it turns out that lying heuristics are worse than no heuristics at all (people including myself never realize they're lying...). It'd be great if we could announce this accurately.

This has smell of a "wont implement" because it asks for a piece of data that is simply not present.

First issue is that LuaTransportLine tries to hide internals of transport belt connectables, specifically it tries to hide inner transport lines can span multiple entities. Because of this, a single LuaTransportLine is only given a range of positions of the inner transport line that it is supposed to present to the lua at any given point in time. That means it could happen that the inner transport line has one item moving somewhere in the front but there are absolutely no items on belt pieces behind so any type of logic here would need to try to account for presence of items in various parts of the belt. Same issue happens when belt is backed up at the front: it may happen front of the transport line is not moving because it is full however there is a gap on the transport line that is shrinking causing items in the back of the line to be moving, again definition of "moving/stalled" is fuzzy. Different example would be if there would be some belt defined with a crazy speed (more than 1 tile per tick) in which case it could happen there would be a belt piece B which could be told to be stalled due to being empty even if there is an item a little to its back, however after the update the item would be already past the belt piece B causing it to again be considered stalled.

Second issue is that in certain cases it is simply not possible to decide if an item is moving without doing the update itself. If there is a backed up line feeding another backed up line, then state of the line in the back would be dependant on the state of the line in the front. More than that, if the line in front is feeding a splitter then knowing if the front line is moving would be trying to predict if the splitter will take the item from a specific input in the next update, which means you would need to know if the splitter during its update will have an empty space on either of its outputs, which basically cascades down the line.

Given that this request has not well defined rules it is not going to be implemented.

There is one piece of data that is available under the hood but in many cases it could be misleading as it refers to the inner transport line in its merged state: transport lines have "active" state in which case they get the update. Issue is that even if a line is active, the LuaTransportLine could be pointing at the range of positions on that transport line that has no items and as such is not moving, so that state would be misleading. It could be that the LuaTransportLine would be pointing at the backed up front part of the inner transport line which is not moving but the line behind is moving again being misleading because the LuaTransportLine would be showing a lot of items, saying line is active but none of those items are moving. Yet another confusing part is that it may happen that a line way ahead in the front was just made active by an inserter taking item from it, and the active state will propagate backward but not earlier than during the transport lines update so a line would tell you its not active even when the items are going to move soon. You can tell if the line is "active" by using the show-transport-lines, not active ones are white and active ones are blue.

In 2.0 there will be one addition to LuaTransportLine that may make any of the mod-side heuristic easier to implement because it will give ability to get exact positions of item stack on a line with some unique identifiers attached to each of the stacks (regardless if item has data or is a simple item), but that is a different interface so i am not considering it as fulfilling the request from this topic. It is simply not possible to easily tell if a section of a transport line is moving or not without doing the full update. Just because you see the movement by comparing two render frames does not mean that game state at one of those render frames is enough to tell if item will change position in the next render frame.

In our case seeing the past is fine, we don't need to predict the future. That's sort of a "sounds good", not a please implement. Knowing that a belt segment is less than full or that it is full but not making progress are the two pieces of info we need. So e.g. for our use case we don't care about empty belts moving because they're empty, they're inherently moving from a simplified model.

If I understand what you're saying then the 2.0 interface will let us know specifically that a belt full of the same item has changed to a different set of the same item? E.g. we'll be able to tell if a completely occupied lane of iron plates is moving because some sort of id is going to be changing? If so then this is (for our specific purposes) the same thing because we just compare current ids to ids of last tick. Leaving out mod specific complexities here that'd just be like 20 lines. Sadly we will have to predict where people will look next, but that's not your problem heh.

It sounds like the active flag will be partially helpful. I'll still need to check belt contents manually, but I won't have to check as many of them.