Page 2 of 2

Re: Train unloading unbalances [bug_not solved]

Posted: Wed Aug 30, 2017 12:19 am
by 5thHorseman
namek wrote:
darkfrei wrote:Please don't attach 15.42 MiB screenshot.
Please don't use mobile data to browse factorio forums.
Actually, turn images off if you're concerned about data rate or limits. There is no way you'll convince the Internet to stop posting stuff. Better to police it yourself.

(Said as someone who lived for years with a laptop tethered to a cell phone with a 3GB/month plan)

Re: Train unloading unbalances [bug_not solved]

Posted: Wed Aug 30, 2017 1:31 am
by impetus maximus
a 15MB image is also a waste of bandwidth to Factorio forum's servers.
OP image resized

Re: Train unloading unbalances [bug_not solved]

Posted: Wed Aug 30, 2017 5:29 am
by namek
Jesus, people, I feel to be forced to return to very deep past. Slowest internet connection I can get is 100/100mbps up/down no limits. 15MB picture seems nothing to me, I know me doesn't mean everyone. Also I haven't attached it because it's size is 15MB, but because of clarity and resolution. Also you can use your browsers to stop loading big size pics.

Using spoiler doesn't prevent images from automatically loading. Tried.
If You know how to make image attachments to be showed as a link or just stop them from loading, please tell me.

Re: Train unloading unbalances [bug_not solved]

Posted: Wed Aug 30, 2017 6:55 am
by Koub
Not everyone has a 100/100 Mbps internet connection. Also if you want smaller weight, png is not as efficient as jpg : a 90% quality jpg conversion will reduce the image to a 3ish MB size, for a bearly noticeable quality loss).
But all this discussion is getting seriously off topic.

With 0.16, splitters sould behave more as we expect them again, if I understand this post correctly :
kovarex wrote:Yes, there seems to be some imperfection.
I compared the results of 0.15 and our current 0.16 with the belts logic changes, and it seems to work as you would expect in 0.16 so I'm moving this to "Fixed for 0.16"
In the meanwhile, you could use this as a placeholder.

Re: Train unloading unbalances [bug_not solved]

Posted: Thu Aug 31, 2017 10:25 am
by Jap2.0
5thHorseman wrote:
namek wrote:
darkfrei wrote:Please don't attach 15.42 MiB screenshot.
Please don't use mobile data to browse factorio forums.
Actually, turn images off if you're concerned about data rate or limits. There is no way you'll convince the Internet to stop posting stuff. Better to police it yourself.

(Said as someone who lived for years with a laptop tethered to a cell phone with a 3GB/month plan)
You can do that :O?

Re: Train unloading unbalances [bug_not solved]

Posted: Thu Aug 31, 2017 5:31 pm
by SpeedDaemon
Selvek wrote:
namek wrote:
Yeah I can do that, but now I'm so unmotivated, balancing is used all over my base, kind of sad to change everything.
Quick question - what is the actual problem?

Don't say "the problem is it's unbalanced". What problem does the imbalance actually cause? There may be a simpler way to achieve what you actually care about than anything involving, say, exponential decay rolling average floating point throughput counters.
To get back on topic... :)

The problem with unbalanced balancers (input-wise) when unloading a multi-car train like this is that it tends to be biased for/against the same car all the time. So when all cars are being unloaded, you get full throughput on the balancer output.

But as it creeps farther and farther out of balance, you end up emptying some train wagons much sooner than others, so "wait for empty" trains will sit there waiting for that one last car to unload. Eventually, the buffer chests on the other cars will run dry, and your throughput drops until the last car is unloaded and a new train pulls in.

Since there's no way currently to check the contents of individual train wagons (pretty please?? :) ) to make sure they're unloading evenly, you can't directly address the problem.

Re: Train unloading unbalances [bug_not solved]

Posted: Thu Aug 31, 2017 7:16 pm
by namek
SpeedDaemon wrote:
Selvek wrote:
namek wrote:
Yeah I can do that, but now I'm so unmotivated, balancing is used all over my base, kind of sad to change everything.
Quick question - what is the actual problem?

Don't say "the problem is it's unbalanced". What problem does the imbalance actually cause? There may be a simpler way to achieve what you actually care about than anything involving, say, exponential decay rolling average floating point throughput counters.
To get back on topic... :)

The problem with unbalanced balancers (input-wise) when unloading a multi-car train like this is that it tends to be biased for/against the same car all the time. So when all cars are being unloaded, you get full throughput on the balancer output.

But as it creeps farther and farther out of balance, you end up emptying some train wagons much sooner than others, so "wait for empty" trains will sit there waiting for that one last car to unload. Eventually, the buffer chests on the other cars will run dry, and your throughput drops until the last car is unloaded and a new train pulls in.

Since there's no way currently to check the contents of individual train wagons (pretty please?? :) ) to make sure they're unloading evenly, you can't directly address the problem.
Glad to be on the same page, but dear Selvek doesn't think it's a big problem :)

Re: Train unloading unbalances [bug_won't fix]

Posted: Sat Feb 17, 2018 8:26 am
by namek
Does anyone know if this has been fixed in 0.16? Thanks.

Re: Train unloading unbalances [bug_won't fix]

Posted: Sat Feb 17, 2018 11:30 am
by vanatteveldt
(I don't have a good answer, but you will find it much easier debugging your designs in creative mode [mod] where you can simply add infinite wagons and/or infinite item sinks.)

Re: Train unloading unbalances [bug_won't fix]

Posted: Sat Feb 17, 2018 10:34 pm
by quyxkh
Is imagemagick easy to get to on windows? `convert -quality 20 screenshot_fact.png !#$:r.jpg` gets a 95+% size reduction and produces this:

Re: Train unloading unbalances [bug_won't fix]

Posted: Sun Feb 18, 2018 9:18 am
by vanatteveldt
quyxkh wrote:Is imagemagick easy to get to on windows? `convert -quality 20 screenshot_fact.png !#$:r.jpg` gets a 95+% size reduction and produces this:
Wait, what? Everything on that line makes perfect sense except for the profane part (!#$:r). I thought ! was used to find something in your event history and # was a comment. $HELLO is a variable, but $:r?

The weird thing is it actually works :) And googling does nothing because it's all punctuation.

Can you enlighten me?

Re: Train unloading unbalances [bug_won't fix]

Posted: Sun Feb 18, 2018 1:42 pm
by quyxkh
It's history expansion, after a ! it's its own overriding lexical syntax, just like ! is "the previous line", # is "the line I'm typing". $ is "its last arg" as usual, !#$ is thus "repeat the last word", :r says just the root, i.e. without the extension. `info bash history` for the full list, one I particularly like is the % wordspec, instead of by position it's by search, if you remember part of a long path you typed a while back !?part?% will fetch the whole of it.

Re: Train unloading unbalances [bug_won't fix]

Posted: Sun Feb 18, 2018 3:10 pm
by dog80
quyxkh wrote:Is imagemagick easy to get to on windows? `convert -quality 20 screenshot_fact.png !#$:r.jpg` gets a 95+% size reduction and produces this:
a 13 mb image - i cant see where the problem is - sarcasm off

Re: Train unloading unbalances [bug_won't fix]

Posted: Sun Feb 18, 2018 3:32 pm
by namek
Problem is not the picture, problem is described in the first post and the last question is has it been fixed in 0.16?

Re: Train unloading unbalances [bug_won't fix]

Posted: Sun Feb 18, 2018 5:30 pm
by quyxkh
OP, using underneathies to isolate lanes for balancers has been reliable for me, the two top rows are alternate versions, the bottom row is what you have now:
snap@T7159152=1600x1184+331.5+200.25,z2.jpg
snap@T7159152=1600x1184+331.5+200.25,z2.jpg (116.98 KiB) Viewed 5296 times
If anybody's posted full science on splitter behavior, I've missed it, I don't have a clear and convincing explanation for exactly what's going on there, my rule for getting dwiw splitting is to keep real splitters' next-scheduled output lane available. I regard the lane balancers above as black magic.

(edit: replaced top row with ever-so-slighly more compact version)

Re: Train unloading unbalances [bug_won't fix]

Posted: Fri Mar 30, 2018 8:38 am
by namek
quyxkh wrote:OP, using underneathies to isolate lanes for balancers has been reliable for me, the two top rows are alternate versions, the bottom row is what you have now:
snap@T7159152=1600x1184+331.5+200.25,z2.jpg
If anybody's posted full science on splitter behavior, I've missed it, I don't have a clear and convincing explanation for exactly what's going on there, my rule for getting dwiw splitting is to keep real splitters' next-scheduled output lane available. I regard the lane balancers above as black magic.

(edit: replaced top row with ever-so-slighly more compact version)
That's not a problem and not a solution. I have these already, you can see it in the first pic, you can even zoom in if you want, for this reason I left that picture big and high quality.

Re: Train unloading unbalances [bug_won't fix]

Posted: Fri Mar 30, 2018 10:48 am
by Aeternus
I've ran into this problem. My way to fix this:
- Use combinators to gauge the sum storage space for each wagon's unloading boxes. If there is less then a full wagon's worth of storage available, set a circuit signal red -just- in front of the station. This prevents the train from being able to unload until it can fully unload.
- Use those combinators as well to block unloading belts of the chest group with the highest cargo count. This tends to balance out the unloading.

Adds a few combinators but will reduce the need for... very creative belt configurations.

Re: Train unloading unbalances [bug_won't fix]

Posted: Fri Mar 30, 2018 11:38 am
by vanatteveldt
quyxkh wrote:It's history expansion, after a ! it's its own overriding lexical syntax, just like ! is "the previous line", # is "the line I'm typing". $ is "its last arg" as usual, !#$ is thus "repeat the last word", :r says just the root, i.e. without the extension. `info bash history` for the full list, one I particularly like is the % wordspec, instead of by position it's by search, if you remember part of a long path you typed a while back !?part?% will fetch the whole of it.
completely OT, but thank you :)
bash fun