The latest 1.1.0 seems inspired by Arumba's latest Factorio mmo/swarm stream, near the end where they were talking about splitter mechanics and priority lanes X3

Very nice though, I like! :D

Heh, I saw the kerfuffle about a large MP on reddit and caught the last part of it--the part you mention (even got in for about two minutes). I had had requests to do something similar before and the stream was my confirmation bias to finish it. :D

This is excellent. I was thinking of making a mod to do this myself. Thanks!

Edit: I may have got over-exited before testing this properly XD

Hey Murdersquish, I just ran some tests with the new version and it... doesn't really work.

With low throughput it worked perfectly, 100% priority to the selected lane. But the more full the belts on the input side are the worse it performs. I used 4 inserters, 2 per lane, both sides of the belt, and ran a 400 item test. The priority side got 209, the non priority side got 191. That's barely above 50/50. And the belts weren't full, so it should have been able to do more.

I don't think this current iteration of the mod works well enough to use it instead of circuit network setups like we used on the stream. It's a step in the right direction though!

Thanks for the feedback. I believe what you are reporting may not be readily addressed using the default splitter as a base object. What happens is four items simultaneously (or close enough) enter the input side. Those four objects need to be placed. Two are placed on the priority side. That lane is now full and it leaves only the secondary side for the remaining two.

Because hacked-splitter uses the base splitter, it must make a decision before the default splitter logic takes over and makes the decision for me. I've avoided creating a mini-buffer internally, but perhaps it is one of the only paths forward.

Regardless, I agree with your assessment. There's another systemic bug that I am not happy with leaving in the wild, too. I'm taking the walk of shame and pulling the release.

Hmmm... interesting.. he's right, it's definitely not working as intended.
*First test with yellow belt on the input, output, and splitter
If input is one belt with one side of items, then it sends all properly to the priority output (plus belt balanced), but as soon as the input has items on both sides of one belt, the output gets muddled, being almost a near even split, with only slightly more going to the priority lane.

However... I tested it again with a red splitter instead, everything else the same, and it properly sent the full yellow belt to the priority lane. Makes me wonder if the logic of the yellow splitter is too slow to actually handle yellow belt?

Third test, added another half-full belt to the input, and upgraded the output lanes to red belt. About 2/3 of the items went to the priority lane, but still not the expected result (of a full red belt for priority output)

Fourth test, upgraded the splitter again to express and then I started getting... inconsistent results. Sometimes it worked perfectly, sending all of the input (still one and half yellow belt) to the priority output (red belt), but other times, it would mess up and do something similar to before. It seems to depend on the timing of when I attach the input to the splitter.

Gif Attached

...I spent over an hour trying to record and upload as gif with this comment typed up and ready to send, didn't even see that you had responded already... ;-;
The priority input was working fine though! At least.. as far as I could tell.. (with 2 fully compressed input belts and one output belt)

Nice work, Kryzeth. Thank you. It'll be useful when I revisit the code!

I wonder if you could implement it something like a loader, and have itself be the inventory... eh, or maybe that might not be possible. Definitely seems like a challenge, but hope you can make it work somehow!