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.Neotix wrote:Ok, my bad. Don't know why it worked strange before, but when i built it second time on new map it worked correctly.
Splitter not working properly
Re: Splitter not working properly
Re: Splitter not working properly
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!
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!
My LP Factorio series (in czech)
-
- Filter Inserter
- Posts: 549
- Joined: Fri Jan 29, 2016 2:48 am
- Contact:
Re: Splitter not working properly
I figured out a way to sort using dumb inserters only without glitching the game. Behold:Twinsen wrote: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.
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.
Re: Splitter not working properly
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
Instead it's taking alternately from the left and right sides.
It's a bug or feature?
https://gyazo.com/65925d8c73aa831f81bf100f4dbb7f59
-
- Burner Inserter
- Posts: 14
- Joined: Thu Mar 17, 2016 4:01 pm
- Contact:
Re: Splitter not working properly
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?
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?
Re: Splitter not working properly
Here is compact version witch "defense" viewtopic.php?f=8&t=6008&start=290#p133106guitarmanmike wrote:Snip
Re: Splitter not working properly
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.guitarmanmike wrote: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?
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
Names
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)
See this post, where Kovarex mentions [-5, 5]: viewtopic.php?f=11&t=511#p3031
Designs: v0.16 | Automated nuclear | Centrifuge ratios | Solar + Accumulator
Re: Splitter not working properly
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.
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.
Re: Splitter not working properly
If you don't have more than 2 items per belt (like you shouldn't) then it has no purpose.js1 wrote:is there any real application of per-item-type behavior? I don't see any.
Re: Splitter not working properly
Can you be more specific about the real application of the current behavior for more than 2 items?Zeblote wrote:If you don't have more than 2 items per belt (like you shouldn't) then it has no purpose.js1 wrote:is there any real application of per-item-type behavior? I don't see any.
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.
Re: Splitter not working properly
If you split the belt per lane, you could get something like this:
Re: Splitter not working properly
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.Zeblote wrote:If you split the belt per lane, you could get something like this:
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.
Re: Splitter not working properly
js1 wrote: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 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.js1 wrote: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.
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.
Designs: v0.16 | Automated nuclear | Centrifuge ratios | Solar + Accumulator
-
- Fast Inserter
- Posts: 239
- Joined: Wed Mar 02, 2016 10:09 pm
- Contact:
Re: Splitter not working properly
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!
And animated!
Re: Splitter not working properly
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).
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).
- Attachments
-
- Splitter Magic.png (1.04 MiB) Viewed 12718 times
Re: Splitter not working properly
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
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
Re: Splitter not working properly
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.
Outputsides are quite easy to change by reversing some undeground belts.
One belt
Two belt
Minor edit to output arrangement
Last edited by rk84 on Fri Sep 15, 2017 9:43 pm, edited 1 time in total.
Test mode
Searching Flashlight
[WIP]Fluid handling expansion
[WIP]PvP gamescript
[WIP]Rocket Express
Autofill: The torch has been pass to Nexela
Searching Flashlight
[WIP]Fluid handling expansion
[WIP]PvP gamescript
[WIP]Rocket Express
Autofill: The torch has been pass to Nexela
Re: Splitter not working properly
I improved the 2 belt throughput version to make it even more compact.
Re: Splitter not working properly
Hmm, seems like I've found a repeatable pattern
Re: Splitter not working properly
You've gone too far!