[1.0.0] Splitter Delay on Input Toggle

[DarthLunar]

1. What did you do?
   • Created a full sushi belt of alternating copper and iron. and sent it through freshly placed splitters like this:

     

     splitters.gif (9.62 MiB) Viewed 1414 times

   • Toggled the input priority of one of the splitters merging belts
   • (Toggling the input again had no effect, it's only on the first toggle)
2. What happened?
   • The first splitter split the alternating iron and copper into two belts, the top belt with 50% iron and the bottom belt with 50% copper.
   • Future splitters refused to mix these belts, despite them each being at only 50% capacity.
   • Toggling the input priority of a splitter receiving 25% of a belt from each of its inputs somehow caused a delay, making the next splitter swap the two 50% belts
3. What did you expect to happen instead?

• I expected the first splitter to split the alternating iron and copper into two belts, both with alternating iron and copper (EDIT: Sorry, I meant two belts, which would then alternate between iron and copper after each subsequent splitter. This isn't really related to the issue, I just originally expected a splitter to always move its first input item to the opposite output, instead of always moving its first input item to the second output. I can understand if this is intended, I just found the asymmetry surprising, and mildly annoying since you can't make a splitter send the copper to the top belt without changing how you put items on the original sushi belt).
• I expected toggling the input priority of a splitter to not cause a delay at all.
• If toggling the input priority of a splitter did cause a delay, I expected it to consistently do so, not to do so only on the first toggle.

This could be related to other reported issues with splitters, but all those appear to be dealing with full belts, not half belts. I continued playing with the splitters, and got seemingly random lane-swapping results depending on whether the splitters were placed with items already on the belt or not.

A blueprint of the entire setup, including how I made the sushi belt:

0eNrNWt2OszYQfZXK1/AJG2NI1D5FL3pRfUJOcBKrxCBj0q5WefeasCHpxtnMuD/qTaJgOB7OzJnx2Hknm3ZUvdXGkfU70dvODGT96zsZ9N7Idrrm3npF1kQ7dSQJMfI4/Rr6VjunLDknRJtG/UHW9Pw9Ico47bSaMS4/3mozHjf+zjW9Pd210qa9NKr1kH03+Gc6M0024VTfioS8kXVafCvO5+QBh8FwGH2BkwNx+AscvuC0nWz8lQeIlLErBvOENdqq7Tzsn/3gtxtdPzoSwC8WfG122vihdHtQg/tyntzbmiwP1INyTpv9MN1o1bE7qXr0Y613oWrqybd+yNlRJWS+OnvwOq/tTNq30ik/57Ybp2ChWZaQY9dM49KlrZIXi27BEKJKLK9yVI0ej6lqPRNWb9O+a1WA+2zhLcx9CfQhe4FTLTjOSjP0nXXpRrVfc5xdOL7zJgsgrxDIOQqZZgjo7Dn05FLjbNfWG3WQJ93Z6amttttRu9qPNQvUTtvB1Q+54aStG2V7lx4ud6TqpOybO/jAm/LElFucnGLnMuWxl1a6aTLy42X4Y0Jl5KZVdaOH6Zusd7Id1G3YKtnUB2mayTLnKVkC987iy/X51jlE6Ty/mV/6IgM6feytUuY+WenG33yJ3hDjFM44Xf2fGOefGP/pK8b/SmeI8E8++fuMZ88YZ48lJ8D1tWRkD0TP2cw/vu36Xtkli83ptvaVr7N+wil5q10w/dIc4XRxdToFKZjHQGPjKUJQAP9mQXcVIHeVC0sAjgSCI46jv0RAFzjoKsbqB8/yEPQqxmpQRWGIikIZihCGSZ05DpohoDMcIRjtUxw0j7GaQiKEFTFWw7hGqLHC8YEQ4wqHjNCiwCEjpFiikHOEEjkOGSFEXPbIETrEraFzhAxxa+gcoUJc6sgxIsQhwzWIBC4B1Tt7stQK4cGFh/TaCg8MSm88AzDAEKsXDlcbTmwcsjDmGEvhGsOlMs4Blgp4VHG4sHB1gsN1hSttHF7akIsIXgG4pdnr7sjK39OdHg7Bzsjq/SHYGnG4DilO4QW8/lFcLSngikSungt4/aO4ml3AtUlx4izg9Y/i1kYFXKYUJ6dCIDf9svCeX1EiNm6nDPp6p/Ymx9F4wL3t/PfLjj7U0F933c2zqVYRWwegGigyVA8PKC2CRjTD/8Eux+ttw+Amh2ARDTgoskUegUzD0S04KhbZ61h8HveiiNg3gAWjiNg2gCGXEcigDRpRRbTfT3KUWEXsEjzBKrMIrCfRVdKIdwT5pWTo7gakrTJH9wwwezkaF2ZvgWhFAEm4FOhOBGZniWhEIHZW6D4EZucK3TaAcKsM3TXAcO+Oy53c/pZqMygbXuCXXwu/YuAT5FtZjzw/Ds6fw1+levEqHP4q1b/xKjGH8eyfPIv/dI4FP43/nsz/4Vjf/eUjIa30seqv/fyh3R9+Udo2Rg2DHzz5uecArSgv+aoUJc1EIc7nPwHYDU7E

[boskid]

I see no issues here. Some related topic that may interest you: 87190

[DarthLunar]

Sorry, I may have overcomplicated my example to make the effect more obvious and to show that this delay can matter, since it can screw up later logistics.

Here is the same issue, with just a plain old belt of iron plates:

splitters_2.gif (11.65 MiB) Viewed 1391 times

This also demonstrates that this delay only occurs on the first toggle, not subsequent toggles. Even if the flow of iron is stopped completely, and then later restarted, this delay does not happen again unless the splitter is picked up and then replaced.

On further investigation, this appears to be because the splitter outputs 2 more iron plates to the top, even though there's nowhere for them to go.
Toggling the input priority of splitters causing them to hold more items in one of their outputs seems unintended, or at least very unintuitive.

[DarthLunar]

Not sure which bug report this is a duplicate of, since the linked thread has nothing to do with input priority, but I guess this bug report lives in Duplicates now.

One final update: Turns out this isn't necessarily caused by the first toggle, but by any splitter with an input priority set. For example:

splitters_3.gif (12.45 MiB) Viewed 1369 times

The top three belts make sense, the bottom one is delayed because those splitters are each putting 8 iron plates in their bottom outputs, instead of only 6 like every other splitter.


Always setting the output priority on splitters when they have only one output seems like a workaround that should usually avoid this. I guess that's good practice anyway to prevent resources from sitting on dead-end belts. I'll submit another bug report if I come up with any possible exploit using this, but I doubt there's any practical use for cramming 8 items on one output of a splitter, since 8 items fit on a belt already.

[boskid]

Looking at the code, this is intended behavior due to some corner cases where splitter would fail to produce compressed output belt when it is expected to. Basically, one check is a little different on the priority input and this is why there is a delay. Nothing interesting here.