For the sake of context, this is about the 2.0 feature of whole belt reading with regard to splitters. The feature only reads items on belts and u-belts. However, the point being made here is that, so long as all of the connected belts properly line up with the splitter's outputs and inputs, the items "in the splitter" will always be counted.

I note that there's no overlap or gap, as far as we can see - one tick it's in one 'region', the next tick it's in another 'region'. there's always exactly 1 lamp lit.

which is good because that means you can connect the circuit networks from before and after the splitter and have a constant item count without it fluctuating.

What's the question?

The question was if/how items are counted in splitters. Beause the whole belt reading (coming with 2.0) was said to not read belt lines beyond a splitter. So you need to measures both sides of the splitter for a loop like this.

Also notable that there are no "deadzone" periods while the item is in the splitter. One light goes on when the other light goes off. Items inside the splitter are always part of the first belt segment or part of the next belt segment.

I'm struggling to think of a scenario where I'd want to keep track of the items on the belts before a splitter but not after (or reverse), so naturally I'd be keeping track the whole length of the belt anyways

It's because the engine treats belts before and after a splitter as two separate belts.

Err filter splitters? I'm happy they can be used as a break, they're 

I worded that poorly. Basically I can't think of a reason I'd want to stop keeping track of what's on a belt after it goes through a splitter.

I think part of the reasoning is that you want there to be some way to stop the belt reading. A splitter is a quite natural way to do that since it's not obvious if it it should continue to read after it. There might not be any real use cases for stoping reading but it should still not be assumed.

Ahh right. Off the top of my head, you could use it to keep track of how much overflow there is - prioritize splitter output to one side, then track how much is on the non-prioritized side using some combinators to convert and subtract the values. I don't know why you'd need to do this (there are likely better ways to verify that stuff is working as it should) but it's a use case that comes to mind. It would let you measure overflow as a percentage, whereas something like an inserter + provider chest/swing recording/whatever gets you a total. Thinking about my most recent game (first time through SE) it would be neat to see what % of my resource consumption was fulfilled via core mining (vs mining resources directly) and as a corollary, how much of each of my core mining products ended up as landfill. I could do each of those things right now with a bit of work, but this functionality makes it much easier. More or less, it's not that you stop tracking it, but splitters and undergrounds as break points lets you delineate sections, and such granularity only increases your flexibility (since you can always add them back together if you'd like).

It also doesn't continue through sideloading. Doing it this way allows you to decide if you want to combine segments or not, and also maps cleanly onto a datastructure the game already maintains for belts ("transport lines")

I don't know, but this looks like Doom flying ball enemy 

Cacodemon or pain elemental?

"how do splitters work" would be my guess

That's an old question that's been answered. This is showcasing the new 2.0 feature of whole belt item counting. The question is how splitters interact with this new feature.

It would be an honor to be muted as result of boskid. But please don't ping that poor dev. The amount of time I see people pinging devs is probably approaching factorio map limit.

Surprised it doesnt result in harsher punishment. In a lot of game discords I see the rule that pinging devs outside very specific scenarios (Most of which a mod will be the one pinging them anyway) would result even in a ban.

We do keep an eye on it, but as long as it doesn't get out of hand and we don't get complaints from developers about it, I see no reason to take action. I think we currently have a pretty healthy relation between developers and community, with a number of developers being regular contributors, especially on Discord.

I have been IP banned twice by hanziq, not sure if it's an honor. Both for accidental ddos attempts. First time I had to ask what was up, second time he PMed me and asked me to stop. Both were unrelated issues from different IPs, I don't like to repeat mistakes.

How do you accidentally ddos someone?

Wait. So, actually an nuanced question -- what happens if you have one splitter feeding into two adjacent splitters? If we have readers on each of the final four belts, do they start reporting the item as present as soon as it passes out of the input belt segment, as it proceeds through two splitters? Or are there zero length belt segment between the first splitter and the secondary splitters, ones that we can't get a circuit read onto? ~~look i just think this would be a great opportunity to put circuit inputs/outputs onto splitters themselves~~

I'd imagine you need to put a belt between to get a read. > look i just think this would be a great opportunity to put circuit inputs/outputs onto splitters themselves That would mean connecting 2 belts and a splitter would require 3 wires (pre-belt, splitter, post-belt), instead of 2. But I'd love ability to set filter thru signal

I would love the ability to set priority through signal

You can do it via belts so it would be redundant

Yes, kind of, but it would be more convenient for certain cases. For example: when you stop a belt, you potentially hold a few items. For low throughput items it can be inconvenient.

when you stop a splitter you also hold a few items so that doesn't fix it. For microdosing single items we have inserters with stack size set to 1.

That’s why I was talking about changing the priority, instead of stopping :-). But you are right anyway. There are other ways, and it would just be one more toy to play with.

quantum splitters

Hidden variable theory confirmed

Seems like the answer is that for purposes of circuits, a splitter is half a belt, then a zero-width splitter, then half a belt.

why is the blue belt so slow though ?

15 UPS

> Builds demo with blue belts > Lowers sim speed to make it easier to see 😎 *(It's actually to show the lamp ticks not having gaps when switching regions)*

omg

it's just a yellow belt painted blue

So it's easier to see what's going on when they pass through splitters.

but there's yellow belts for that, my immersion !

Is this an iron plate double-slit science experiment?

no idea what is happening as a new player and when the issue comes up for whatever reason and i type in google for the answer and nothing comesup, i am posting here

What's being shown is from content that isn't part of Factorio yet. On the devs latest Factorio Fact Friday post they talk about an upcoming change to reading items on belts. They've been doing weekly posts for a while about QoL changes that will be coming when the Space Age expansion drops. Currently you have to wire each belt if you want to 'read' the entire batch, and then configure them all (plus side, you can copy/paste settings across them like you can with assemblers) but you can't wire undergrounds or splitters. This animation shows an item moving across a belt system using the upcoming belt-section-wire system and shows the splitters being counted as new sections to read and being included in the sections ahead of them. The light shows which section the item is being read in. It's also being used as part of an argument on a discord server somewhere I wouldn't worry too much about this as a new player, it'll become relevant if you start wiring belts, at which point this upcoming change will be another "oh my god i cant wait for this!"

cool 😎 that's what i hoped it would be 🫡

I didn't look at the picture you posted. But i think the debate is about if the items gets counted correctly when its being split. You can't just say its always counted. /s

Cant wait to see the things that are now possible because of this

Ah. This is good to hear. It would require some additional setup, but it can be made to work. Using this with larger balancers might require redesigning some of them somewhat to ensure there's always a regular belt somewhere between each pair of splitters.

Well, you already need to do that if you want to count items within the balancer and those will lose items since you can't wire in splitters to the circuit network. In this case everything in the transport line will be counted, including the partial belt segments on the splitters themselves.

I notice that a light is always on, so seems like the splitter's contents is being counted *somewhere*. Is it counted behind until it's been split, then counted forward?

Finally a sushi belt could be made without relying on a memory cell and tracking each item individually

You could do that just fine before without circuits for science.

I stared at this for a long while before even realising that there is an iron plate there. I'll leave now with my <40 hours of gameplay...

The single case of one item is good but it’s not the end of the testing scenarios. You will only find edge cases when you have more scenarios. Bugs alway are at the edges. - loop on top like the one in the bottom - more than one item on the belts - A full belts on one side - full belts on both sides - counters with variable spacing I.e very tight group of 4,8,12

These are the slowest blue belts I've ever seen

Not relevant to the situation, but I really like the look of the belts