[1.1.56] stark belt priority overflow issue

[nommynap]

I made an account because this bug driving me mad sorry if i stumble a rule I read through the other bugs and didn't see it

red belt losing priority and overflowing system if I put the input on the right hand side of a feeding belt to the koverex cycler.
the left stack of kovorex is the same as the right the only difference is the 238 input belt side

video and string of general troublemaker below

as a note due to the size it can takes a while to overflow which is why it took so long to diagnose.

[disentius]

Not a Bug.
If you do not want items U238 to go on that side of the belt, you need to set a splitter filter to U235 (left side in picture). Priority means that it will output to the prioritized side only if there is room.

[boskid]

I see no bugs here, its just a design which is not robust.

[nommynap]

sorry for not cropping the issue with priority is the feeder belt to the entire system. it is feeding a full belt and inserting onto an allready full belt taking priority from that belt. the area that you are showing is working as expected yes.

in the example string there are two exact copys of the rows the only difference is one is fed from the left the other to the right on the 238 main feeder. only the right one will take over priority and insert to a full belt.

i cropped where its happening below.

[nommynap]

here is a cropped video,

[Loewchen]

it is feeding a full belt and inserting onto an allready full belt taking priority from that belt.

This is not a bug either, the priority depends on the update order.

[nommynap]

belts can force items onto an occupied belt, overriding an already full belt?

its also only when on the right lane of the feeder, the other stack using the left lane of the feeder belt of koverex cyclers next to it on the left side of the string instead has no such problem

[MEOWMI]

That's very peculiar. I have a lot of builds which rely on this behavior working properly, and they do work. It's pretty standard behavior that belts can't sideload onto a full belt. The tail of the belt will always have priority. (It's literally the reason why many "1 splitter lance balancers" don't work: they rely on sideloading, which won't happen if the belt is under compression.)

Try removing the belt and replacing it, maybe even both of the belts there that should fix it. Don't know why the items are allowed to overlap, as they clearly are, items never overlap like that on belts, it's as if the belts there aren't connected except they are. Anyway try the fix.

[malcolmputer]

Yeah, I can see the weirdness going on in the screenshot/video, it looks like the full belt is being "held back" by the tee-ing in belt? If so that would be a bug IMO.

You shouldn't be able to tee into a belt like that and it hold back the main belt instead having priority on the input.

Loewchen: I understand you saying it's a tick quark between the bottom feed in and the top feed in having priority, but it wouldn't make sense to hold up a full belt to insert from a side feed like that would it? That would fundamentally change how belt physics works.

[nommynap]

i have rebuilt it multiple times, even have the "working" fix in the column next to it in the string, made sure it was thoroughly reproducible first. drove me mad for a bit

[Silari]

Yeah, I can see the weirdness going on in the screenshot/video, it looks like the full belt is being "held back" by the tee-ing in belt? If so that would be a bug IMO.

You shouldn't be able to tee into a belt like that and it hold back the main belt instead having priority on the input.

Loewchen: I understand you saying it's a tick quark between the bottom feed in and the top feed in having priority, but it wouldn't make sense to hold up a full belt to insert from a side feed like that would it? That would fundamentally change how belt physics works.

There's already been dev posts on the subject, here's one: viewtopic.php?p=380043#p380043 There's no good way to enforce update order because things like belt loops can exist, so sometimes a sideloaded belt gets priority because it happens to be first.

[malcolmputer]

If that's the case then this should be moved to won't fix, but at a minimum it *is* a bug

[Loewchen]

I'll close this now. If you want to discuss this further open a Gameplay Help topic.