Bug: Conveyors don't always distribute reagents optimally

It’s possible to double-up on machines with a cycle-time of two in order to maintain throughput. However, attempting to do something similar with units that take three cycles to run isn’t currently handled optimally.

(Apologies for the oversized screen-shot; Big Pharma looks great in 4K! I’ve had to convert it to 256-colour to come under the board’s attachment size limit…)

You can see in the top-left two condensers being used in parallel. This works great! On the exit-side of these condensers, however, are three UV devices, which have a cycle-time of three.

What I was hoping would happen with this layout is that the intermediate stage between the condensers and the UV units would act like an efficient bus, distributing the reagents from both condenser sources equally across all three UV inputs. However, what currently happens is that only the two outer UV units are used; the third central UV unit is not used at all.

This results in a corresponding drop in efficiency that can’t be avoided without building an extra fourth UV unit and explicitly allocating each UV unit to one condenser or the other.

Looking closely at the chevrons on the conveyor belt at the input to the central UV unit, it appears that while the path into the UV unit is pointed in the correct direction, the other two paths (across the top of the ‘T’) are both pointing outwards, which is the wrong direction.

I’m hopeful that a tweak to the existing pathing algorithms could alleviate this problem…?

As an aside, I’ll also mention that I couldn’t place a 4-way conveyor belt, which meant I couldn’t place the input to the central UV unit directly across from the output from the top condenser. I’ve seen that you plan to introduce over/under conveyor belts (which is awesome!); have you considered allowing the conveyor belts to be toggled between over/under (no interaction between paths) and 4-way (redistribution permitted)?

Thank you for a remarkably polished and beautiful beta. :slight_smile:


For anyone else who’s been following this issue, this is now reportedly fixed in development: