[0.18.36] Inconsistent splitter behaviours on full flow

Things that has been reported already before.
Post Reply
foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

[0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

In a full flow situation -- full inputs, full drain -- splitters can exhibit inconsistent behaviour. I encountered it when attempting to create a belt-driven sushi setup, as here:

Image

The splitters of interest are the ones in the 8:8 balancer, whose intended purpose was to output eight evenly mixed belts. Mathematically, this should work; all eight (seven loaded, one empty) input belts have an equal number of paths to the eight output belts and there are no throughput bottlenecks inside the balancer itself.

However, as shown in the screenshot, the fully loaded splitters are not mixing the provided belts. Instead, some of them are swapping them (e.g. the first splitter for red and green sciences, which produces one belt of red and one belt of green instead of two belts of one-half each) and some are simply passing material straight through, such as the first splitter on military and chemical, or the first splitter on purple and yellow. Similar behaviour is visible elsewhere.

This is not consistent with the purpose of a splitter. Worse, it's inconsistent in different ways, since sometimes the belts are switched and sometimes not. And, further, there's at least one other state I have observed, though do not currently have a screenshot of, which is that one lane will get swapped. This gets the 2-belts-of-half-and-half but isn't really what's desired either.

I don't know what makes any given one of these states occur over the other two; I suspect timing issues of some sort involving which feed hits them when.

Rseding91
Factorio Staff
Factorio Staff
Posts: 13171
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by Rseding91 »

Thanks for the report however I doubt there's anything wrong here or someone else would be having issues and or one of the *many* tests we have would be failing. I'll just wait for someone else to come through and explain what assumptions you've gotten wrong about how splitters work.
If you want to get ahold of me I'm almost always on Discord.

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

Rseding91 wrote:
Mon Jul 27, 2020 4:28 am
Thanks for the report however I doubt there's anything wrong here or someone else would be having issues and or one of the *many* tests we have would be failing. I'll just wait for someone else to come through and explain what assumptions you've gotten wrong about how splitters work.
The idea behind a splitter is that it takes two belts of inputs and then outputs two belts of output, each of which can be supplied by both input belts. You would expect that each output belt will contain equal amounts of both input belts-- which is true in most circumstances.

If there is spacing in the input belts -- for example, if you provide two belts of 50% concentration -- you will get two properly mixed belts back out of the splitter (both at 50% concentration). Similarly, if one of the output belts is not full flow, it will back up, and then the other belt will now start drawing evenly from both inputs. And if your materials are all the same kind of material, of course, you can't tell the difference.

The reason this specific case exposes the odd behaviour is because it is a situation wherein the splitters are a. provided with fully compressed belts of input and b. have no outflow backups and c. are supplied with different materials. Other people have encountered it in the past as well, if I recall correctly (example: viewtopic.php?t=68797).

I'm not making any assumptions about how splitters work -- I am reporting observed behaviour. What I am making assumptions about is how splitters are intended to work, based off how the work when the specific conditions required to get these weird flows are not met. For example, with space on the belts, they behave much differently (and as expected):

Image

In this layout, the input belts are decompressed to a quarter of their nominal throughput before being run through a series of mergers, resulting in two belts with even 1/8th mixtures of the original seven feeds (plus 1/8th empty space). At each step you can see the very neat ordering of the bottles. This is the usual and desired behaviour. However if there is no space on the input belts this undergoes a phase change. What's worse, which way that phase change breaks is unpredictable and very non-obvious.

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

Follow-up:

I was able to trigger these behaviors even with uncompressed belts. The key appears to be input synchronicity, which full inputs guarantee but can happen in other scenarios.

I was also able to document the lane-unzipping behaviour, seen here:

Image

I don't think 'chose between one of three possible output states, none of which is the naive expectation, depending on precise item timing' is a desirable behaviour :(

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 2227
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by boskid »

Duplicate 80681

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

boskid wrote:
Mon Jul 27, 2020 7:22 am
Duplicate 80681
Duplicate it might be, but uh, I decided to build something simpler to highlight things:

Image
Image
Image
Image

I can get multiple different behaviours by deconstructing & replacing a belt tile on each output belt, and the same if I do it on the input side. Even if there's technical reasons as to why the splitter is not actually putting the items on both belts, as it would should only one input be provided, this multi-modal state is undocumented, unreliable, unpredictable, and generally weird.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 2227
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by boskid »

Still not a bug. Splitters have their internal state that chooses from which input lane next item will be taken from (in case of a tie in same tick) and to which output belt they will be put (obvious fact since if you feed splitter a full belt it will give you 2 half belts at output alternating, and splitter state has to be save-load stable at any given tick). If you have 2 input and 2 output belts, you may end up in a state where next item will be taken from left input belt and will be output to the left output belt, or when item will be taken from the left input belt and output to the right output belt. Lanes are independent so you have 2*2=4 different outcomes.

-- edit:
If you want to mix items, do not use splitters with 2 input and 2 output belts at the same time. 2:1 or 1:2 only.
87190.png
87190.png (212.23 KiB) Viewed 2810 times

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

boskid wrote:
Mon Jul 27, 2020 7:46 am
Still not a bug. Splitters have their internal state that chooses from which input lane next item will be taken from (in case of a tie in same tick) and to which output belt they will be put (obvious fact since if you feed splitter a full belt it will give you 2 half belts at output alternating, and splitter state has to be save-load stable at any given tick). If you have 2 input and 2 output belts, you may end up in a state where next item will be taken from left input belt and will be output to the left output belt, or when item will be taken from the left input belt and output to the right output belt. Lanes are independent so you have 2*2=4 different outcomes.
Right, but the fact that you can actually get into those four states, effectively at random, is not really great from a consistency point of view, no? Like if it could lock itself into just one of the patterns, that'd be a superior choice to current, especially if it were the lane version.

Moreover, the splitters do behave correctly when forced to output to just one belt:

Image

So it's specific to the two-belts-in-two-belts-out problem. If you say there's technical reasons as to why a splitter can't work on two belts out the way it would with one, I'm happy to take your word, but that it works unexpectedly and unpredictably so is a sharp edge that cuts out some interesting design possibilities. I don't like having to work around a game engine instead of with it.

IOW: It might be WAI, but I think there's issues that warrant revisiting that. Having to build most of a 4:4 balancer just to mix two belts is deeply silly.

EDIT:

I'm not sure why a splitter can't store, in it's internal state, the full setup of which belt it last put an item onto for each input, and use the alternate one if it's not full, the original if it is, and neither if their both jammed, but I'm sure there's something or you'd have done that already.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 2227
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by boskid »

Splitter ignores item type (only check is when filtering) and has no extra internal buffer. What you want would be for each input lane to remember to which output item should be moved. Lets say items were going alternating: 1 from left input, then 10 ticks of no items, then 1 from right input, repeat. This input pattern could result in an output pattern where 2 items are output from left output, and next 2 items are output from right output, so lanes would not be properly alternating. In case of 2 full inputs and 2 outputs, it could be that state for both input would say "output to left", first item is moved and then for second input, logic would say "i still want to output to left" but output is full. What should splitter do? hold the item for later? (there is no buffer) at the same time creating gap on right lane (violates full throughput) or should stall right input until left output can take that item? what if left output lane stops, should splitter get stuck even when right output is still empty? After what amount of ticks splitter should decide "i give up, just output to the right"?

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

boskid wrote:
Mon Jul 27, 2020 8:13 am
Splitter ignores item type (only check is when filtering) and has no extra internal buffer. What you want would be for each input lane to remember to which output item should be moved. Lets say items were going alternating: 1 from left input, then 10 ticks of no items, then 1 from right input, repeat. This input pattern could result in an output pattern where 2 items are output from left output, and next 2 items are output from right output, so lanes would not be properly alternating. In case of 2 full inputs and 2 outputs, it could be that state for both input would say "output to left", first item is moved and then for second input, logic would say "i still want to output to left" but output is full. What should splitter do? hold the item for later? (there is no buffer) at the same time creating gap on right lane (violates full throughput) or should stall right input until left output can take that item? what if left output lane stops, should splitter get stuck even when right output is still empty? After what amount of ticks splitter should decide "i give up, just output to the right"?

If I understand you alright, the scenario you're describing does alternate the outputs? It just does so in chunks of two per lane, and I don't see a ready way where that would go beyond to chunks of 3+. That makes it an improvement over current, where in these scenarios the output isn't alternating at all.

I think I said that should the desired target lane be full, it should fall back to the other possible lane and try to output there, and then if it can't do either that means the outputs are jammed, whereupon you hold it 'til something clears.

So, going through the scenarios:

Scenario 1: Belt A has an item in a lane every X ticks, Belt B has an item in the same lane every X ticks. Belt A arrives, outputs left; Belt B arrives, and also outputs left; then both output right, etc. In this scenario, the matching output lanes are now composed of 50% of each belt. That is the desired behaviour. However, items don't alternate between the two output belts individually, but in clumps of two. That is undesired, but averages out pretty quickly; even yellow belts push fifteen items a second. Maybe I'll think of something more clever to fix that last point overnight rather than just averaging it out :) But I think this is in fact better behaviour than we've got now even without further improvement.

Scenario 2: Belt A & Belt B are both full, proceeding onto empty belts. Loop, void chest, whatever. We'll say belt A gets processed first. It will attempt to go left-right-left-right, and succeed. Belt B will also attempt to go to the left at first, and fail, because belt A is already there. So, instead, it goes to the right. which works, and then left-right-left. This gives you equal distribution between the two output belts and again exact mixing of the items in each lane, as well as full throughput. All of this is desired.

Scenario 3: Belt A & Belt B are both full, proceeding onto 1 belt (the other being jammed, filtered, whatever): Current behaviour is correct and, in the one-output-belt case, I don't think what I suggest will cause a change in behaviour.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 2227
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by boskid »

Even if splitters would be implemented to trace next output separately for each input so the splitter would produce something like this:

Code: Select all

AAAA |> ABAB
BBBB |> BABA
It would be useless for your contraption since second "mixer" when given alternating input would "unmix" items on its output:

Code: Select all

ABAB |> ADAD
CDCD |> CBCB

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

boskid wrote:
Tue Jul 28, 2020 2:17 pm
Even if splitters would be implemented to trace next output separately for each input so the splitter would produce something like this:

Code: Select all

AAAA |> ABAB
BBBB |> BABA
It would be useless for your contraption since second "mixer" when given alternating input would "unmix" items on its output:

Code: Select all

ABAB |> ADAD
CDCD |> CBCB
That's true, but it's inherent to a strict-sequence approach; you'd always be able to feed it a matching pattern of inputs to get ordered output. One way around that would be a pseudo-random coinflip, but I suspect that would involve way more processing for a very common entity than you'd want.

However -- my contraption being set aside here--, I think there are still advantages. First, it means that from a UX perspective, one level of splitters should be have exactly as the naive expectation of them would be, without major changes between one-belt output and two-belt output. That's something worth pursuing, I think. Secondly, in the case of ganged splitters, it at least means you get more predictable outputs for given inputs, which is also good. And thirdly, the ability to use splitters to *unmix* a belt might lead to some interesting new designs not currently possible.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 2227
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by boskid »

pseudo-random approach is not going to be implemented because of added performance penalty to compute value every time and due to extra logic that would have to check if there are 2 items that arrived at the same time to decide if this extra logic should run. It would also not be reliable to run since it would be only able to run if 2 input items arrive at the same tick. In case of items that are arriving in alternating ticks (with ticks of silence of course) due to full throughput rule this whole logic would be bypassed.

This idea is not going to be implemented.

foamy
Filter Inserter
Filter Inserter
Posts: 432
Joined: Mon Aug 26, 2019 4:14 am
Contact:

Re: [0.18.36] Inconsistent splitter behaviours on full flow

Post by foamy »

boskid wrote:
Wed Jul 29, 2020 8:42 pm
pseudo-random approach is not going to be implemented because of added performance penalty to compute value every time and due to extra logic that would have to check if there are 2 items that arrived at the same time to decide if this extra logic should run. It would also not be reliable to run since it would be only able to run if 2 input items arrive at the same tick. In case of items that are arriving in alternating ticks (with ticks of silence of course) due to full throughput rule this whole logic would be bypassed.

This idea is not going to be implemented.
Uh, that's what I said: Pseudo-random would take way too much processing. I wasn't suggesting it, just saying it's the only way you could avoid the pitfalls of a round-robin or alternating output. What I then went on to say is that the case where strict alternation is used is still better than the current results in that it will:

1. Make output behave more uniformly between one- and two-belt cases;
2. Be more consistent with the naive expectation of how splitters would operate, improving UX;
3. The ability to use a splitter to unmix an alternating feed opens up design space;
4. Probably reduce the microlevel timing issues that result in four possible output states with unpredictable materials on given belts, as exists RN.

All of these I think are desirable and should only require an extra half-byte per splitter (a bit per lane) to track that lane's current desired output lane. As splitters already necessarily have to be able to check for blockages (and redirect if so) and so on the additional logic to specify 'try this lane first' from that one bit I wouldn't expect to be particularly heavyweight in relation to everything else going on.

Post Reply

Return to “Duplicates”