Understood. I have reworked the mod around the one-connectable-per-tile invariant for now (and tested/released for 2.1); if this API is ever implemented, I will restore the original functionality.

Btw, in case it would make the API request more palatable: the mod would be equally well served if the ...

TL;DR:
In 2.1's transport-belt-connectable collision mask validation, please allow a linked-belt prototype to waive only the "must collide with itself" half of the check, for example by honouring the existing not_colliding_with_itself flag, while keeping the pairwise "must collide with every other ...

2.0 gave all the tools needed to solve belt balancing without any per-item Lua work.

Better Belt Balancer is now GA, with performance on-par with vanilla hand-built belt balancers.

Oh also the linked container + loaders approach breaks down pretty badly if you have multiple kinds of items coming down the pipe, but that's another limitation that is probably fine™ in real world use.

Tell my why that wouldn't work.


Taking another crack at this; I did some experiments with linked containers and loaders.

https://i.imgur.com/24yva3s.png

It works pretty well in the supply-shortage case -- with 500 input items I saw a range of ~8 item variance from the most favored output to ...

I agree that it sounds nontrivial to implement this trigger if the belt update code is multithreaded. Would be cool if it ended up making the cut though!

As for why not do it with loaders and chests; I'm trying to make a drop-in replacement for the existing mod, which does transparent flow-through ...

I'm working on creating a more performant version of the belt balancer mod .

The current version works by iterating over all balancers in the world every few ticks and processing them one by one.

There is a lot of room to optimize this (the low-hanging fruit improved performance 20%), but to get ...