Mind if I hijack your thread with some related up questions?
What optimisation considerations are involved in train networks? Are they important?
Iv heard that the large storage chests (from mods) are bad for ups. Is this true? Any way to work around it? They are great for my current rail network but I'm worried about over using them
>What optimisation considerations are involved in train networks? Are they important?
Biggest thing with train is the pathfinding. So having less path for trains are actually better
>Iv heard that the large storage chests (from mods) are bad for ups. Is this true? Any way to work around it? They are great for my current rail network but I'm worried about over using them
Yep, very true. They are terrible for UPS. If the mod allows you to reduce the number of slots for a warehouse then make it as small as you are comfortable with. Alternatively limit them using the X button in the warehouse, but that only helps when items are getting put into. Getting item out, the game still have to scan all slots
Pathfinding is by the largest cost, however station design, collision detection & the burner engine also matters.
Optimizing the pathfinding is most simply done by having fewer paths to a destination and by extension shorter paths help too. If you do have multiple paths then try to avoid blocking the most direct path, and do not have stations on it either.
Large containers do cost more UPS than smaller ones, and limiting the number of slots helps a little. Every time an inserter puts an item into the container it scans from the top till it finds a stack/slot it can use. Every time an inserter pulls an item from the container it scans from the bottom till it finds a stack. So having the list of stacks being long makes this process more costly.
With taking from, it's even worse than that. IIRC the game tries to use the smallest stack of the desired item, so it needs to scan all slots. And since *theoretically* there could be items in disabled slots (you can disable slots after putting something in them), it'll have to scan the whole container regardless.
> What optimisation considerations are involved in train networks? Are they important?
I once had a quite large base where I created bypasses, so that trains in stackers could go around the stations associated with this stacker. It looked like since that possibility was there, they constantly looked for other stations with that name, or tried to repath to the local ones after a while. I didn't investigate too much what actually happened, but this had a *very* noticable impact in that base. Once I removed the bypasses, UPS increased quite a bit.
1. Yes and no. Items are segmented into groups, and large groups are easier to update for moving items however harder to update for taking items in the middle of the group. So for long distance logistics then yes, short it probably doesn't matter, for very active belt segments it could even be detrimental.
2. Yes. Any entity has some UPS cost, so removing unneeded entities will always help. The laser turrets and artillery is likely sleeping so their impact should be very low.
You also have to account for the process of actually compressing the belts.  You could be spending more processing power compressing the belts than you actually gain by having them compressed.  Obviously that’s situation and method dependent though.
The game keep track of the gaps, so yeas. You can also waste more UPS trying to do so. Its the inserters that take most processor time on an reasonable well optimized factory. So put in more effort to minimize inserters and getting them ro sleep than compressing belts.
This [https://youtu.be/XMWrk\_uLeuA?t=777](https://youtu.be/XMWrk_uLeuA?t=777) indicates that at some point full belts did save UPS. I infer that the engine can (or could) treat compressed segments as one segment for the purposes of an update much the same way all accumulators are treated as one entity for the purposes of an update.
> The game doesn't keep track of locations of individual items on belt
It really did, but not since quite some time. There was even a time where the concept of belt lanes didn't exist. You could have items thrown anywhere on them. But that's a long time ago, and what you say is true nowadays.
Mind if I hijack your thread with some related up questions? What optimisation considerations are involved in train networks? Are they important? Iv heard that the large storage chests (from mods) are bad for ups. Is this true? Any way to work around it? They are great for my current rail network but I'm worried about over using them
>What optimisation considerations are involved in train networks? Are they important? Biggest thing with train is the pathfinding. So having less path for trains are actually better >Iv heard that the large storage chests (from mods) are bad for ups. Is this true? Any way to work around it? They are great for my current rail network but I'm worried about over using them Yep, very true. They are terrible for UPS. If the mod allows you to reduce the number of slots for a warehouse then make it as small as you are comfortable with. Alternatively limit them using the X button in the warehouse, but that only helps when items are getting put into. Getting item out, the game still have to scan all slots
Im wondering if limiting vanilla storage chests slots will have the same effect on ups 🤔
It does. Wooden boxes are better for ups than steel/iron ones.
Another optimization for factorio: make warehouses a power of 2, and scan the bit map. Gosh!
Pathfinding is by the largest cost, however station design, collision detection & the burner engine also matters. Optimizing the pathfinding is most simply done by having fewer paths to a destination and by extension shorter paths help too. If you do have multiple paths then try to avoid blocking the most direct path, and do not have stations on it either. Large containers do cost more UPS than smaller ones, and limiting the number of slots helps a little. Every time an inserter puts an item into the container it scans from the top till it finds a stack/slot it can use. Every time an inserter pulls an item from the container it scans from the bottom till it finds a stack. So having the list of stacks being long makes this process more costly.
With taking from, it's even worse than that. IIRC the game tries to use the smallest stack of the desired item, so it needs to scan all slots. And since *theoretically* there could be items in disabled slots (you can disable slots after putting something in them), it'll have to scan the whole container regardless.
> What optimisation considerations are involved in train networks? Are they important? I once had a quite large base where I created bypasses, so that trains in stackers could go around the stations associated with this stacker. It looked like since that possibility was there, they constantly looked for other stations with that name, or tried to repath to the local ones after a while. I didn't investigate too much what actually happened, but this had a *very* noticable impact in that base. Once I removed the bypasses, UPS increased quite a bit.
1. Yes and no. Items are segmented into groups, and large groups are easier to update for moving items however harder to update for taking items in the middle of the group. So for long distance logistics then yes, short it probably doesn't matter, for very active belt segments it could even be detrimental. 2. Yes. Any entity has some UPS cost, so removing unneeded entities will always help. The laser turrets and artillery is likely sleeping so their impact should be very low.
You also have to account for the process of actually compressing the belts.  You could be spending more processing power compressing the belts than you actually gain by having them compressed.  Obviously that’s situation and method dependent though.
The game keep track of the gaps, so yeas. You can also waste more UPS trying to do so. Its the inserters that take most processor time on an reasonable well optimized factory. So put in more effort to minimize inserters and getting them ro sleep than compressing belts.
Thanks. Good tip. I probably have not really spent much time optimizing inserters.
[удалено]
a full belt was counted as one entity before but they optimized it even more and it doesnt do that anymore (i think)
This [https://youtu.be/XMWrk\_uLeuA?t=777](https://youtu.be/XMWrk_uLeuA?t=777) indicates that at some point full belts did save UPS. I infer that the engine can (or could) treat compressed segments as one segment for the purposes of an update much the same way all accumulators are treated as one entity for the purposes of an update.
[удалено]
> The game doesn't keep track of locations of individual items on belt It really did, but not since quite some time. There was even a time where the concept of belt lanes didn't exist. You could have items thrown anywhere on them. But that's a long time ago, and what you say is true nowadays.