Programmable Splitter Even More Broken

Question

Good job guys! They added an exclusion option to the 8/9 experimental patch

"Any" is no longer useful as an exclusion, which is all I needed it for. The item list is also still incomplete, meaning there's no way to achieve the old "any" output used for these unlisted items, as everything now leaks into this output (which makes sense for "any", but we need an "other"/"rest")

Comments

100% Agree.
It's nice to change the programmable splitter to make them better, but you broke the only use we had of it : to sort items.

the former "*" should be replaced by "other/rest" to not break what people did in their games before.
and the new "*" should just be a new element of the list, not a replacement of the former "*".

an other thing that could be nice is to have a text editor for the list of items in the splitter. checking each item separately is really annoying/boring. a text editor would allow copy/paste too (really useful when you have to select exactly the same elements for an other splitter)

edit: the issue has been fixed in last experimental version by adding "any undefined" (that functions like the former "*").

---

I have a sorter set up to separate the assorted items I get while clear cutting sections of the map. (Most of it shipped back in bulk by train.) Leaves and wood go to make biomass, some of the biomass goes with some of the mycelia to make fabric, and the rest of the biomass is made into biofuel which runs two fuel generators. Part of the mycelia, the silica, and 'everything else' goes into storage containers. Now I'm getting large amounts of wood, leaves, and a bit of mycelia in the box that should just have flower petals, alien parts, assorted minerals, power slugs, etc. to be dropped into personal storage and limestone which I drop into a storage box feeding a constructor to make concrete.  Now I have to try to figure out how to fix what this change broke

---

Same problem here, with either smart splitter and programable splitter:

Selecting star (*) for "any" was not letting items through that connector if those items have been selected for one or both of the other connections ... well, until the last update. Many players did ask for a "overflow" solution cause of that behaviour, and tried to find a workaround solution, more or less successful.

Dealing with that "old" issue (not having an "overflow" solution and working around that), together with the current (changed) behavior, now it's even worse^^ The whole existing belt logistic is broken as far as smart or programable splitters are involved.

=== game situation ===

In my case there is a hughe sorting facility/building, where's a belt/storage for each individual (literaly, 94!) item, including a complex sorting infrastructure, having at least two smart or programable splitters for each item... Due to that infrastructure i was able to send every kind of item to that facility and every item got correctly sorted to the corresponding storage ... until i recognized the full/stopped belt on the other end of the map, which pointed to the fact that something is wrong at the sorting facility ... lol

Now i have to make a decision ...
• Pausing the game until there is a fix or until the behaviour is set back to it's earlier state?
• Setting all 200+ spitters outputs/connectors having "any" by now to 93 individual items which have to get through - let me quick calc that: 18600+ manual selections *cough*

EDIT:
Option 2, to set each of the 93 items for the "all others" connector, is not a solution, cause the number of rules for each connector is limited...

EDIT 2 (2019-08-21)
Problem solved due to a new selectable option "Any Undefined" at all programmable splitters as of Early Access - v0.2.1.12 - Build 103400
Tested with MK5 belts having 20 different items mixed at full workload (720/min)

---

Same...
I had to go turn off my entire crater and swamp outposts because sorting is broken.

The new base I'm working on will take a couple days before it's done, but I can't fire it up until the sorting is operational again.

Even if it's all working as before again, it'll take me hours to find and manually fix all the items that are now on belt sections where they shouldn't be.

For belts that feed as parts into buildings, this will mean removing the belt and replacing it since you can't remove an item thats way deep into an input :(

---

I had a feeling if this wasn't done right the other half of the community would start complaining. The newest changes disabled the guaranteed filtering of items in favor for a simple overflow/sushi-belt mechanic. But the truth is both modes have it's uses.

I really wished they had looked a little more in other suggestions on this topic which are floating around since launch, e.g. https://questions.satisfactorygame.com/9828/smart-splitter-any-other-any-all-for-overflow-and-sushi-model

Answer 1

WORKAROUND Both kinds of splitters (smart and programable) seem to propper work as long as belts Mk1-3 are used right in front of the splitter :D

Seems to be, that those splitters (having a small buffer included now) can't handle fast belts atm.

Possible solution: splitting the incomming Mk5 belt into 3 x Mk3, having programable/smart splitters connected and merging the output right after - ugly but working!

Comments

Tested it this afternoon. With a full mk3 (270 ipm) you still get mistakes from the splitter. However if you split a mk4 into 3 conveyors you can have mk5 conveyors everywhere in front of smart splitters but since they bring only 480/3= 160 ipm the splitters will work perfectly.
Didn't try all the possible setups but it's all about the number of sorted items per minute, not the speed of the conveyor used. 270 imp is too high, 160 seems to be fine. Maybe we can go higher. Might be computer dependent.


PS : it's not really ugly with stacked conveyors and a tight fit.

Answer 2

Issue has been fixed/patched with Early Access - v0.2.1.12 - Build 103400 due to new selectable option "Any Undefined"

Test with MK5 belt at full workload (720/min) was a success without any issue 

Answer 3

I found another workaround; it's clunky and real pain but as with most of the issues the game has had thus far I'll bet the devs will fix it pretty soon.

For high-speed belts my solution for auto-sorting was to ensure the starting storage bin was an ISC and then all I did was to take the end of the 'Sort' Belt and loop it back to the input of the 'Dump' ISC and it will just loop all items that don't get filtered properly for another run on the belt, eventually everything was fine.

Comments

Nice! I thought of that too, but hated the idea of how it would look for my setup XD They fortunately added an exclusion option to the Experimental Branch today

---

That can be simpler for many people to use such a setup, especially when they lack space for modifications. I does change the arriving order of items at the end of the system so this will not produce exactly the same result than before the update or the first workaround. This might be preferable for many situations, when your priority is the diversity of items arriving.

Now I wonder if this would reach the maximum sorting speed or not. Splitters might sort better if they're not overburdenned (let's say 260 ipm) and see their efficiency drop if you increase the input rate, eventually droppping to 200 sorted ipm or lower. This require some testing I guess :p

---

This fails for any items that aren't in the splitter item lists. If you pick up SAM Ore or something else not yet on the sorting lists, those items won't ever find a home, but will keep spinning around the sorter. IF all possible items were on the lists, then this would be fine.

Answer 4

The issue has been quickly fixed in the last experimental release (CL#103023) by adding "any undefined" in the list.

juste replace your former "*" by "any undefined" on each of your smart/programmable splitters if you want the behaviour of the former "*".