Sideloaded belts do not always pulse items to circ. network

[dewiniaid]

If a belt is being sideloaded -- and is configured to output its contents to the circuit network using "Pulse", it is possible that not all items will be output.

It looks like that the issue occurs when items are 'nudged' in order to fit an item being sideloaded.

Setup:

• The two wired belt segments in the screenshots are wired to "Read belt contents; pulse".
• The adjacent combinators are simple counters (Input: Gears * K > Output: Gear, wired to themselves).
• The lights show the current value of each counter.
• "K" comes from the constant combinator; enabling this combinator serves to start the test case. Disabling it resets everything
• The upper belt/light/combinator section works as expected and counts 5 gears all the time.
• The lower belt/light/combinator section consistently counts 4 gears in this particular case.

Before running:

Before

bug-before.jpg (155.97 KiB) Viewed 1963 times

After running:

After

bug-after.jpg (148.41 KiB) Viewed 1963 times

Save to Reproduce:

Sideloading Circuit Bug Repro.zip

Save to reproduce. Requires the "Creative Mode" mod (used for quickly establishing power while making the standalone test case.)

(3.8 MiB) Downloaded 68 times

Required Mods:

• "Creative Mode", used solely for the purpose of building this as an isolated test case (namely the power source)
• "Picker Extended" was also enabled, but should not be required.

Some notes:

• If all of the gears are on the top lane of the belt, the issue does not occur. Likewise, if all the gears are on the bottom lane of the belt, the issue does not occur.
• That said, I don't think the mix of the belt lanes itself is the issue. The save that inspired me to condense this down to a simple test case had a single lane being input from two different directions at once. (The original goal was a belt-based alternator that'd force a 50/50 split of items)
• BenjaminK on IRC says the he's "never made a bug report, and i feel like i made a contribution!", so here's a cursory mention by his request. (To be fair, the lights were his idea...)

[impetus maximus]

just tested this and it looks like you are correct about them slipping by.

side.count.png (59.19 KiB) Viewed 1951 times

*numbers shown thanks to nixie tube mod

[Rseding91]

Thanks for the report however this is working correctly. It even says it in the tooltip: http://i.imgur.com/jwPEGIs.jpg

[impetus maximus]

DOH!

[dewiniaid]

Thanks for the report however this is working correctly. It even says it in the tooltip: http://i.imgur.com/jwPEGIs.jpg

I respectfully disagree, for two reasons:

1. It's not intuitive that another belt counts as "an external entity"

2. It still counts some (but not all!) of the items, which is inconsistent and feels buggy. It should count either none or all of the items in this case.

The messaging as I interpret it as a player (which may not be the intent) is "The belt won't pulse if an inserter puts something on it/a miner outputs to it/etc/an overzealous player hits "Z" a bunch.

It's worth noting that the original intent here was to have two belts of different items mix at a 1-1 ratio using some simple circuitry by having one of two item types subtract from the counter rather than add and then conditionally blocking the side belts based on whether the count was <= 0 vs >= 0 -- and it had the annoying feature of working when tested manually by dropping individual items on the belts one at a time but then promptly inexplicably failing under load. I suppose that it might be worked around by moving the wiring back one tile though...

And it still really feels like it has something to do with the sideloading-nudges-items-to-make-a-new-item fit mechanic of belt physics...

[grumd]

Hello, I wanted to bump this thread instead of creating a new one.
OP had good points in the last comment and you guys should address those!

I think this is a bug. Current behaviour is very inconsistent and it's not user-friendly.

See this screenshot:



I don't really see how a tooltip saying "belt will not send correct signals" makes such inconsistent behaviour acceptable. At the very least the belt scanner should ignore all sideloaded items, instead of only ignoring some of them (in particular it currently ignores the ones that were pushed when merging lanes).

You wouldn't just add a tooltip for all random bugs saying "it doesn't always work, so deal with it", and call it a day, would you?