splitting outputs into different belt speeds bug?

Question

Belt	mk1	mk2	mk3	mk4
Displayed	60	120	270	450
Actual	64	128	256	448

I found this out by having a 450 belt splitting into a 60 belt a 120 belt and a 270 belt (thus splitting the outputs into 30 pm belts is easy) but ended up getting slanted results when I place 450 items in the input, making life confusing. but place 448 i get a nice 64,128,256 output.

can anyone else try and see what they get? it's likely the splitter not being about to keep up. but in my mind, 60/120/270 split should work. 

Comments

I would say "lying" is a bit harsh as that would imply a deliberate attempt to deceive. Who knows what happened there? Bugs happen and it's great to point it out as it's entirely possible the devs have not noticed this themselves, but there's no need for accusations of lying.

---

Didn't mean to sound harsh was more of a jest.

---

Is it possible that maybe the 60 and/or 120 belt outputs were backed up at any time in the process? If they were, then the splitter would have no option but to send the output to the belt that could take it, thus skewing your evenly distributed results to the belt(s) that could handle more.

---

I just did a simple test of one belt between containers, for 1 minute per belt, and the follow numbers result:
Mk1 (60) belt: 60 in 1 minute
Mk2 (120) belt: 120 in 1 minute
Mk3 (270) belt: 270 in 1 minute
Mk4 (450) belt: 450 in 1 minute

So the belt numbers are spot on, I think the splitters are doing a ratio of 1/2/4 on the 60, 120, 270 belts, effectively making the output of 60/120/240 not 270, and the remaining 30 would be added (4 or 5)/~9/~18 to the belts but take longer than 1 minute

---

I am wanting to do something similar with my steel plant. I have a pure iron feeding it so with mk2 miner (and some sparks) and mk4 belt I can get 450 out.

my plan was to do the 60/120/270 and merge the 60 and 120 to get a 180 line and a 270 line. which i can split both down to 5 nice 90 lines to cary closer and then do a final split to 45s.

my question is even though the numbers are off eventually it will work out as some back up and the overflow would fix itself right? so even though the first hour it may note be perfect after that it would basically.

Answer 1

I just did a simple test of one belt between containers, for 1 minute per belt, and the follow numbers result:
Mk1 (60) belt: 60 in 1 minute
Mk2 (120) belt: 120 in 1 minute
Mk3 (270) belt: 270 in 1 minute
Mk4 (450) belt: 450 in 1 minute

So the belt numbers are spot on, I think the splitters are doing a ratio of 1/2/4 on the 60, 120, 270 belts, effectively making the output of 60/120/240 not 270, and the remaining 30 would be added (4 or 5)/~9/~18 to the belts but take longer than 1 minute

Just tried the 60/120/270 split and the splitter is definitely not working optimally with those belts, if you want a cleaner output you'd want to split the 450 into 2x 225 (on 270 belts) or 3x 150 (on 270 belts) and go from there.

I don't believe splitters will work optimally for uneven splits (i.e. splitting 60/120/270) which means perfectly splitting a 450 belt to 30 belts if not possible as you can only perfectly split by 2 or 3, and since 450 is 2 x 3 x 3 x 5 x 5 and you can't split by 5 perfectly with the current tools it's impossible. Bear in mind that with the oversupplied machines backing up the system will self balance so you shouldn't lose too much production as a result.

I would appreciate if the devs put in a special case on the splitter logic for connecting 450 in 60/120/270 out since it looks so neat to do that and would allow us to split by 5 implicitly (2/4/9 ratio) and make the numbers nice and neat, but I imagine it's a low priority.

I found out the splitter doesn't care about the speed of the belt when it splits if you put 150 items in, and have a 60 belt and 2x 120 belts out, all 3 belts will get 50 items, so the logic must try each output in sequence and skip an output when that output is still full, which would result in suboptimal splits when trying to not even split by 2 or 3.

Comments

I think the merger suffers from the same problem.
i got 1x 60 and 2x 30 going in and one 120 coming out and the 120 belt only got about 90 per minute. When you merge the 2x 30 in one 60 first and then the 2x 60 it works as intended.

Answer 2

My question is when a machine says 30 or 60 per min, does it actually mean 32/64 per min? 

im not sure if this is the answer that youre looking for but, when you have a constructor for example saying the input is 30/min and the output is 60/min thats only a basic calculation that the game does based on a fixed output, when you overclock it to 200% the game divides whatever the value of the output is by 2, but it doesnt actually detect the real speed of the inputs and outputs, another example if you let a constructor making concrete it's gonna make 15 per minute demanding i think 30 or 45 limestone per minute, if you space out each limestone its still gonna go in in a slower rate but it keeps showing 45 per minute, the result is that the concrete instead of making 15 per minute is gonna do less.

so again, those numbers are fixed constants in the game code, they don't actually change based on the actual speed of the items going in and out.

Comments

Yeah so if I put let's say 40 input into a constructor that's 30 per min, it will bottleneck.

I am trying to split 450 into 30 per min belts, hence why I am splitting 450 into 60/120/270 because that can be split into 30 pm belts easily, however when I tested it, it ended up with
wrong results. but when I assumed the belts were 64/128/256 the outputs made sense.

unless I am not seeing something. try it out yourself.

Maybe I am not explaining it right..

---

I tested it myself and i got the same result.
But I don't think that the belt capacities are wrong. I noticed the 450 belt sometimes stopping. When I measured the time, it took  to get the 448 Items out the container . But it should only be about 60 seconds. So when you look at the 64 seconds the result of 64/128/256 makes sense when the belts are 60/120/270. That would point to a problem in the splitter which seems to have problems handling belts with different speeds.
Maybe the rate at which the splitter checks if one belt is full, is to slow for the 450 belt so it has to stop from time to time.

And the outputs of the machines are depending on the productivity of the machine. So for example a constructor produces 15 Iron plates per minute and consumes 30 Iron ingots per minute at 100%. At 200 % it produces 30 Iron plates per minute and consumes 60 Iron ingots.

---

yeah that would make sense, the times I recorded for it to empty was about 60 seconds tho, when I give it a constant stream of items it splits it 64/128/256. and i get a shortage of stock one the 270 belt and more on the other two channels..

Just trying to think of a way of splitting 450 into 15 belts equally. thus having no bottlenecks in 30pm machines.

Thanks for contributing.

---

try:

split 450 in 3x 150 then the 150 in 3x 50 then you got 9x 50.

then split 3 50 belts in 1/3 and 2/3 and send the 2/3 in the machine ( not 100% efficient because the 2/3 will be about 33 per min ) when the machine is full 20 per min will go on the 1/3 belt split this up in 2x10 and add the 10 each to a 50 belt. Split these 6x 60 belts up again and you have 15x30.

Its not the  best solution but when it runs some time it will spread equally.

---

Yeah thought of doing it that way but this just triggered me because it should work XD

Answer 3

I just did a test of 900 copper wire, extracted via 450 into splitter, to 60/120/270 containers. ..

First container got 129, second container got 257, third got 514. ... what even the hell. You're definitely correct, the conveyors are not 60/120/270.

Comments

Some sort of wizardry, was getting so confused why I was getting strange splits when 60/120/270 should totally work, at least in my mind. but i can work with 64/128/256 split tbh, its actually better if anything.

Answer 4

Could not understand your statement. Kindly attach GIF or JPG where possible.