Smart Splitters

[MeduSalem]

Could be interesting to have in some cases to reroute item flow more dynamically.

[NateMcCloud]

TL;DR

Connect signal wires to splitters to determine input and/or output priorities.

What ?

We should be able to connect signal wires to each side of a splitter to set the splitter's input and output priorities. Perhaps green wires control input, and red wires control output. Or vice-versa, it doesn't matter. Separate conditions can be set for each side, and for inputs and outputs.

If the condition is satisfied for one side, but not the other, the side with the satisfied condition is prioritized. If both or neither side's conditions are satisfied, neither side is prioritized.

Why ?

It would be an easy way to send our resources down an alternate path when we need to, e.g. when we have too many of one resource, and are lacking another resource that uses the same materials.

[Tekky]

This has already been suggested two months ago in the following thread:

viewtopic.php?f=6&t=56520 Circuit network connections for splitters

@Mods: I suggest that the threads get merged.

[mp0011]

Honestly, I would separate "regular" splitters from "smart" splitters. And, possibly, make smart ones bigger, eg. 2x2.
They are to powerful right now, after 0.16 changes...

[NateMcCloud]

This has already been suggested two months ago in the following thread:

viewtopic.php?f=6&t=56520 Circuit network connections for splitters

@Mods: I suggest that the threads get merged.

Oh...huh. I guess I didn't look back far enough. Thanks for the link!

Honestly, I would separate "regular" splitters from "smart" splitters. And, possibly, make smart ones bigger, eg. 2x2.
They are to powerful right now, after 0.16 changes...

While I disagree about them being too powerful, a 2x2 smart splitter would make controlling input and output priorities easier, since the color of the wire wouldn't matter.

[adam_bise]

This really is needed. Especially in the case of split logistics networks along a fortified resource bus, which itself is a workaround for not being able to control bot traffic. Those split networks still need robots, repair packs, walls, etc.. and drones cannot deliver them if the bus snakes through enemy territories over a long distance.

Having to set up train stops for each separate logistic network is currently the only simple option, but becomes bulky for many small network segments. Yea you can multiplex order requests along the bus but that is a pain to manage.

Being able to set splitter function via signals would be an obvious fit. You could send an outpost ID up the wire and have supplies flow down a shared supply belt, among other things.

Still, being able to control bot pathing is also needed. I posted an example on how to achieve bot pathing here: viewtopic.php?f=6&t=62033

[Engimage]

I strongly agree this will add much gameplay value

[Cadde]

It's been what's coming up on a year since this suggestion and nothing yet?

It really boggled my mind when i realized that splitters had no circuit network capability... It has a filter, surely it should have a circuit network condition to set said filter!
And to touch on the priority discussion, i would rather have a specific signal for that. "Left priority signal" and if it's high it going to set left lane priority. Same for right. And finally, a "neutral priority" signal which will set the splitter to no priority and no filter.

If neutral, left/right lane priority and filter signals are IGNORED.
If left AND right lane priority signals are high, it would default to neutral. Undefined state.

[morsk]

I suspect a programmable filter is useless. Compared to the filter inserter, a splitter guarantees its item will back up, instead of passing through. Letting an item back up on a mixed belt is almost never what you want, as it easily deadlocks. If an item is so toxic to the system ahead of it that it's better to have backup than let it through, it should be filtered 100% of the time, not programmably.

I would absolutely use programmable priority though, even in early-game so my mall passively draws gears, but takes "all the gears" if buffers get low. (I've faked it with multiple splitters, etc., but I'd do this kind of thing more often if it were easier.) No harm in the filter either; I just don't see the point.

If neutral, left/right lane priority and filter signals are IGNORED.
If left AND right lane priority signals are high, it would default to neutral. Undefined state.

There is input priority too, not just output. That's making a lot of signals. Why not just <0, 0, >0 for each?

[Cadde]

I suspect a programmable filter is useless. Compared to the filter inserter, a splitter guarantees its item will back up, instead of passing through. Letting an item back up on a mixed belt is almost never what you want, as it easily deadlocks. If an item is so toxic to the system ahead of it that it's better to have backup than let it through, it should be filtered 100% of the time, not programmably.

I would absolutely use programmable priority though, even in early-game so my mall passively draws gears, but takes "all the gears" if buffers get low. (I've faked it with multiple splitters, etc., but I'd do this kind of thing more often if it were easier.) No harm in the filter either; I just don't see the point.

If neutral, left/right lane priority and filter signals are IGNORED.
If left AND right lane priority signals are high, it would default to neutral. Undefined state.

There is input priority too, not just output. That's making a lot of signals. Why not just <0, 0, >0 for each?

I use splitters for more than just backbones. I split items up from belts to their respective train loader and it would really help when i have an automated station (that is, items change based on what recipe it's currently doing) to set up which train loader gets what items.
I don't intend to explain the full picture here, but it's not a matter of "useless" when the problem is completely different from what you expected. There are no backups at that station, there never will be. If there are backups then it's intentional as i've stopped fetching items from that station.
No matter how hard you try, you will ALWAYS have a backup at some point unless you use ALL items equally. That's what buffers are for.

BTW, i don't want the items to just continue on someplace else. That item is at it's last possible stop.
And the type of item changes dynamically based on what's being processed down the line.

I wanted the signals rather than the <0, 0, >0 shenanigans because i truly hate conditions like that. It would still help to have dedicated signals that show at a glance what they are meant for. Rather than having A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, Å, Ä, Ö, BANANA... What was "N" for now again?
A signal that reads "left lane priority" is so simple. In fact, there should be some other common type signals too. Not just colors and letters but "count", "alarm", "power on" and so on. Sure, many of the signals can use the respective items they refer to but the point still stands, sometimes you just need a "count" signal rather than using "C" because that's "count".

[morsk]

I use splitters for more than just backbones. I split items up from belts to their respective train loader and it would really help when i have an automated station (that is, items change based on what recipe it's currently doing) to set up which train loader gets what items.
I don't intend to explain the full picture here, but it's not a matter of "useless" when the problem is completely different from what you expected. There are no backups at that station, there never will be. If there are backups then it's intentional as i've stopped fetching items from that station.
No matter how hard you try, you will ALWAYS have a backup at some point unless you use ALL items equally. That's what buffers are for.

I'm not sure I have this right, but are you unloading mixed belts from trains, then using a series of splitters to separate them? I can see how that wouldn't deadlock, if you have enough buffers that 1 train load will always pass the splitters completely. Less sure why unloading mixed belts is a good idea, but I guess it's more modular.

I agree this is something the filter inserter won't do as well as a splitter.

[Maslofski]

so can we get this? im using them as a space efficient way to side load and wanted to hook em to a circuit so i dont have to manually set them for every smelter

[Serenity]

so can we get this? im using them as a space efficient way to side load and wanted to hook em to a circuit so i dont have to manually set them for every smelter

The filter is kind of unnecessary in this case. It works just well if you simply use the priority function

[MrBadDragon]

TL;DR

Allow splitters to become programatically "smart" in their operation.

What ?

Connecting splitters to the circuit network would allow for conditional branching of resource flows. I.e. the ability to have a splitter send items to one side as a priority based upon down stream requirements.

Why ?

You can do something similar by using circuits on belts post splitter, however the logic involved becomes tricky. What I was envisioning was being able to control the priority status on/off via a circuit condition. i.e. plant A was starved for a resource make the junction to that resource become a priority feed.

[foamy]

I'd like to have full control of splitter filters, as well, like how filter inserters work. I'm not sure how you'd distinguish left from right, though.

[ssilk]

Why double an already working function? You already admit it is possible to do “something similar by using circuits on belts post splitter”. What would make this a better game-play?

[steinio]

Why double an already working function? You already admit it is possible to do “something similar by using circuits on belts post splitter”. What would make this a better game-play?

You can't set a priority in/output or a filter to belts. This functions are relatively new to splitters so you may have missed them.

[MrBadDragon]

The first application came about when I wanted to set the priority function of a splitter to on when the number of an item down stream dropped below a certain number.

I was happy with two branches of my factory each getting 50% of the inbound resources, however the loads on each branch were not equal under certain conditions. One was producing gears for blue belt production, and when I initiated an upgrade process, the gear production would starve due to dimished resources. I have implemented a buffering system, but in order for this to be effective it needed to be disproportionately large leading to there being dead resources when the downstream demand subsided.

By being able to toggle the priority setting, I could run a significantly smaller buffer and when the levels of that buffer dropped below a set threshold, all resources were directed to that buffer. Once it had been replenished to a certain threshold, the condition would unset, and load would once again become 50/50.

To do this by circuits is very complex as you have to count belt contents across multiple belts, and then use the circuits to throttle each side of the splitter instead of just setting one flag if buffer < 500 (enable), and a second flag when buffer > 1000 (disable).

[Koub]

[Koub] Merged into older topic with same suggestion.

[sparr]

I, too, want this, but this would make me even more annoyed that filter splitters aren't locked behind filter inserter technology. Ever since splitter settings were introduced I have thought they were available too early and made early game base layout much simpler than it should be and was before this feature. I'd love to see this feature added AND splitter filtering be locked behind the filter inserter tech.