Splitter not working properly

[roy7]

Ok, my bad. Don't know why it worked strange before, but when i built it second time on new map it worked correctly.

Perhaps you ran a single copy of one of the ores through the loop by itself, so it was already going to the opposite side as the other items. When in doubt just remove and replace the splitters.

[Brambor]

This thing is great and I'm thankful for the posts all of you made but note for gif creators: Why do you just HAVE TO use blue belts/do the gif as fast as possible? If you want to explain something, you should do it SLOW so people can watch it...
In the end I needed to look at pictures and play it item by item in my head cause the gifts are unwatchable as a learning tool and then I got it, not from the crazy 1 tile/frame gifts!
I see how just the "maximal thrueput" thinking people have this kinds of ideas...

But as I said, thank you all for the posts, it was very interesting and I'm sure my viewers will love it!

[golfmiketango]

We had many talks in the office about these sorters

Initially none of us understood how exactly they work. So this was not an intended feature.

I figured out a way to sort using dumb inserters only without glitching the game. Behold:



A dumb inserter trying to insert into this chest will only pick up the type of item in the box already. Therefore, we have turned a dumb inserter into a smart one so long as we can prevent the chest from draining its contents. There are probably better ways but I figured out this one:



This can be a bit fussy to bootstrap, but if you prime the thing by putting a few items in there before you turn on the power, then the chest contents will exhibit a random walk with a substantial statistical bias towards filling up, because the inserter taking from the circular belt perpendicularly is fine, but the one trying to grab the items moving away from its direction of insertion keeps failing to grab the item (the animation for this is really cute. The inserter appears noticeably frustrated as the item it tries to grab keeps moving from it)...

Eventually the system will achieve equilibrium when the chest is full. The backflow channels will fill to capacity but everything keeps working. Compared to glitching the splitters it's slow and slightly wasteful of electricity, but it's good enough in the early game in Bobs Mod, as it requires no research.

[Neotix]

I noticed, the splitters no more prioritize left side.
Instead it's taking alternately from the left and right sides.
It's a bug or feature?
https://gyazo.com/65925d8c73aa831f81bf100f4dbb7f59

[guitarmanmike]

Sorry if there are any rules about resurrecting posts, but I figured this would be the best place to post this since this is where I found the idea.

I doubled up XKnights design and made this fairly symmetrical (and in my opinion good looking) version which will have 100% throughput (both lanes) for any of the belt types. I am sure there is a way of making it even more compact but I couldn't think of a way which didn't involve using the two different types of underground belt trick. I don't like that trick because it doesn't work if you want to use all express belts.

Only thing left to do is add some kind of backup protection because if the output is backed up the sorting will break until it is resolved. Is there anyway of "defense" which doesn't involve a loopback which will reduce throughput?

[Neotix]

Snip

Sorry if there are any rules about resurrecting posts, but I figured this would be the best place to post this since this is where I found the idea.

I doubled up XKnights design and made this fairly symmetrical (and in my opinion good looking) version which will have 100% throughput (both lanes) for any of the belt types. I am sure there is a way of making it even more compact but I couldn't think of a way which didn't involve using the two different types of underground belt trick. I don't like that trick because it doesn't work if you want to use all express belts.

Only thing left to do is add some kind of backup protection because if the output is backed up the sorting will break until it is resolved. Is there anyway of "defense" which doesn't involve a loopback which will reduce throughput?

http://images.akamai.steamusercontent.c ... 1E14BC115/

Here is compact version witch "defense" viewtopic.php?f=8&t=6008&start=290#p133106

[Aru]

Only thing left to do is add some kind of backup protection because if the output is backed up the sorting will break until it is resolved. Is there anyway of "defense" which doesn't involve a loopback which will reduce throughput?

The only way to truly prevent this, is to cut off the supply before entering the sorter. So, you could use buffer chests on the output and input, with enough inserters to keep up with the needed throughput, with smart inserters putting into the chests.

Edit: On second thought, there are other ways of doing this. After all, we have circuit networks. With smart inserters, smart chests, and combinators, you can do a lot of things. But the question is, is the defense simple enough that using splitters to sort is still worthwhile? You can sort n item types with (n-1)*2 splitters, which is probably cheaper and possibly smaller if you want to be able to support a full lane of potential output throughput for each item type.

Anyway, I had kind of a hard time fully understanding this special splitter behavior in a deterministic way, but then I did and I wrote it down as pseudocode, so hopefully some people will find this more understandable.

(Python was designed so that simple code is very legible, and can often be interpreted literally.)

Syntax summary

= is assignment, it assigns the value of the thing on the right to the thing on the left.
# indicates a comment line.
def declares and defines a function.
<= means 'less than or equal to'.
min() and max() return the minimum or maximum of the given values.

Names

place_splitter() is called when the splitter is placed, it zeroes all the item counts.

input_item() is called when an item crosses the threshold at the entrance of the splitter. The item is 'consumed' by the splitter.

output_left() and output_right() produce an item of the same type, at the left or right output belt. It's produced at the same threshold line where the item was 'consumed', without delay, and always on the same lane that it came in on (belts have 2 lanes each). Left and right are relative to the belt travel direction.

item_type represents a single type of item, such as "Smart inserter", "Advanced circuit", "Gun turret" or "Iron plate", etc.

count is a dictionary, it holds one number for every item_type. It counts the current output balance for each individual item type, so that the splitter can make up for a forcibly imbalanced output later. But, the numbers are capped to the range [-5, 5]; they can't go higher than 5 or lower than -5. Keep in mind that the piece of belt inside the splitter can house 2 items per lane.

Code: Select all

#------------------------
# Python-syntax pseudocode

# Item positions have floating point precision,
#    so that items should arrive in a definite order.
# If they truly come in at identical times, which
#    is probably very uncommon, fetch one of the
#    simultaneous items randomly.

def place_splitter(counts):
    for item_type in counts:
        counts[item_type] = 0

def input_item(item_type, counts):
    if (counts[item_type] <= 0 or right_blocked() ) and not left_blocked():
        output_left(item_type)
        counts[item_type] = min(5, counts[item_type] + 1)
    else:
        output_right(item_type)
        counts[item_type] = max(-5, counts[item_type] - 1)

It seems quite odd that a range of -5 to 5 was chosen, perhaps it was a mistake, because that yields an odd number of numbers. So, effectively, the imbalance memory is up to 5 for the right output belt, and 6 for the left. It would have been more consistent and intuitive to use [-5, 4] or [-6, 5] (with default 0 or -1) or [1, 10] (with default 5 or 6) so that each has the same memory.
See this post, where Kovarex mentions [-5, 5]: viewtopic.php?f=11&t=511#p3031

[js1]

I would definitely vote for making splitter simpler (that is, output per lane, not per item type). Aside from the sorter, which is arguably very neat, but completely useless (you're probably better off doing the same thing with smart inserters), is there any real application of per-item-type behavior? I don't see any.

On the other hand, I intended to use splitters for merging different items into a single lane. In that case, per-item-type really gets in the way, because if you want to have a certain ratio of items on the output belt, it will mess it up.

So I don't really see any advantage of having splitters working this way, and IMHO there is a big downside.

[Zeblote]

is there any real application of per-item-type behavior? I don't see any.

If you don't have more than 2 items per belt (like you shouldn't) then it has no purpose.

[js1]

is there any real application of per-item-type behavior? I don't see any.

If you don't have more than 2 items per belt (like you shouldn't) then it has no purpose.

Can you be more specific about the real application of the current behavior for more than 2 items?

I do have more items (see viewtopic.php?f=8&t=25107) - why shouldn't I anyway? And I definitely have a problem with the current behavior. Because in practice, I can sort items out much easier with smart inserters. However, I cannot easily put them back in specific ratios with splitters.

[Zeblote]

If you split the belt per lane, you could get something like this:

[js1]

If you split the belt per lane, you could get something like this:

That's true. But if the splitter worked for each line but not by item, then another splitter would fix this. However, I am not sure how to fix the merge problem I have with the current behavior.

That's why I think the discussion should be about use cases people have. Because I don't really see the use case for the current version, only some disadvantages.

[Aru]

On the other hand, I intended to use splitters for merging different items into a single lane. In that case, per-item-type really gets in the way, because if you want to have a certain ratio of items on the output belt, it will mess it up.

I do have more items (see viewtopic.php?f=8&t=25107) - why shouldn't I anyway? And I definitely have a problem with the current behavior. Because in practice, I can sort items out much easier with smart inserters. However, I cannot easily put them back in specific ratios with splitters.

I understand this splitter mechanic pretty well, I think. I don't see how it interferes with merging. This mechanic only has an effect when the splitter has two output belts. If you're merging to a single output belt, there's no effect.

Besides that, if you do have two output belts, it's inevitable that the ratios of item types coming in will be reflected in the outputs. The ratios can't be altered unless the game deletes or creates items. For the splitter to produce a specific ratio, you just feed it a specific ratio, and both outputs will have those ratios. If you want different ratios on different output belts, don't use a splitter. (You can't expect the splitter to know exactly how much you want on each output belt, you'd have to keep them separate.) Maybe I'm not understanding what you're saying? The advantage of the way it works now, compared to random outputs, is that for every two items of a certain type that come in, each outgoing belt will get one (if it can). It distributes outgoing items evenly, when you have two outputs. And the purpose of the larger memory (as opposed to one bit per type), is that the splitter can make up for interruptions where one belt is very briefly backed up or blocked or severed, especially if a lane has mixed types. If it's not backed up, then the expanded memory has no effect. A memory of more than one bit is not especially important, but it's not really disadvantageous either, capped to a small range as it is. The effect of the "safety" in the splitter sorter designs, is to extend this range from 5 to include however many items can fit on the "safety" belt.

To simply alternate every item to each output belt while considering all items to be the same type, that is the worst behavior, there's no reason to do that. I think maybe that is what you're suggesting. Either it should be entirely random, or it should alternate each type between each output belt (then only the first of each type should be random). I'd rather have the latter; why introduce this random element when you can easily alternate between outputs, producing an even distribution? Ultimately, a random output will trend toward an even distribution anyway, but is more, well... random in the short term.

I'm okay with the way it works now. Though, a memory of 5-6 per type instead of 1 per type is not a very consequential aspect.

If you really want a use case, consider where you have two identical production lines, each needs a certain ratio of incoming items, you have mixed types on the lanes, and supply is matched to demand. If it's random, one line will sometimes get more of certain items. One side will have some idle time, and the other side might even become permanently backed up with the wrong items. If the splitter produced an even distribution, there would never be any idle time, and there's no disadvantages.

[mooklepticon]

I'm not a fan of the setups that need priming. I'm too worried that they'll prime wrong and I'll get weird results, so I went with the alternate design. Seeing as I only had yellow belts, I made some changes.



And animated!

[Quint]

I played around with the "magic" splitter some more and was able to get a fully compressed belt in/out and even included a design that fully splits into two separate belts. It doesn't matter what the ratio of items coming in is (100%/0%, 50%/50%, doesn't matter) it will take them in and spit them out at the speed of the belts used. This system (like almost all of the others in this thread) does fail if backed up, so as long as the output never backs up it will continue to work.

The only priming required is to place a single item type in two locations so that it moves to the top output belt.

It took me some time to understand why this system worked as it did, but once I understood it it allowed me to improve the design to allow for the fully compressed processing. I understand that this is cumbersome and uses many splitters, but it was just an experiment to see if it was possible to do without inserters (or power).

Also it is possible to reduce the size of this contraption, I left some space to show how things worked (and got tired of working on it as it is too large to practically use).

[tzwaan]

After being reminded again that these things exist, I tried to make one as compact as possible. I ended up with a few designs. They all work with a full belt of throughput to any of the outputs.
Also they will break if the output is backed up.

Most compact version I've come up with.


A version that can be chained multiple times for multiple outputs.


A 2 belt version. Also has full throughput. I would really like to see improvements in this design, because I hope this can still be made more compact.


The controls for all version work the same. When first build, it outputs all items on all outputs. Entering the control signal on one of the "switches" sets the filter for that item (for location of switches look at the earlier posts). Switching it around again requires a signal on both switches.

Also with the addition of the circuit network it is pretty easy to protect this from a backed up output.


EDIT:
Just because seeing it running is a pleasure in itself

[rk84]

Here is mine version. It output everthing to one side after building. So you don't have to prime it for every item, just items you wanna filter.
Outputsides are quite easy to change by reversing some undeground belts.

One belt

Two belt

Minor edit to output arrangement

[tzwaan]

I improved the 2 belt throughput version to make it even more compact.

[tzwaan]

Hmm, seems like I've found a repeatable pattern

[roy7]

You've gone too far!