Semi-physical analysis on how belt compressing should work

[TheRaph]

I don't know if this is in the right sub forum ... at first I attempt to put it into suggestions section ... but I hope the devs may read it, even it is here.

First I like to recapitulate about the actual physics of belts.
We know that items may stuck on belt but the belt itself will continue to run - and I think there is no frictional heat. That show, that belt and item are not sticking to each other and therefor the Items lie loosely on top and can slip around.
Also there are an invisible wall between left hand lane and right hand lane, so items can not slip from one lane to the other.

Now we have to check 4 compression methods: splitter/balancer, underground-belt-loading, inserter-compression and side-loading.

Splitter will compress if both corresponding lanes of inputs have a (little bit) greater amount of items than the output can handle. That was in past and is at the moment (and should be in future).

Underground-belt-loading was a trick. Physically the entrance ore outlet of underground belts should behave like on floor belts. So the current behavior is fine.

Inserter compression is not so easy to explain. Imagine what happens if an inserter will place an item on belt, and the gap isn't wide enough:

compress1.png (6.86 KiB) Viewed 2170 times

An Inserter may be smart enough to decide if an gap is wide enough or not, but it cannot jam the previous belt, to insert an item in a small gap.
You see, this is the reason why - in my opinion - inserter compression should be only possible by circuit network.

Sideloding is an other thing. Since we know the items lie slackly on the belt and can slip around (in their lane), we can imagine what will happen on side loading:

compress2.png (7.32 KiB) Viewed 2170 times

The same mechanics should work with miner-insertions, in my opinion it is some sort of side loading.
That's why I prefer to have side-loading as compression method back in game.

So based on a semi physical sight, belt-compression should be mostly as it is now, but side-loading-compression should work again, cause there are a semi physical explanation how it could work

[cogwheel]

Both diagrams show the same thing. The only difference is the machine doing the pushing (inserter vs belt) and the dimension along which the object is being pushed (x/y vs. z). Why should the belt be able to push items back any more forcefully than the inserter? The inserter actually runs on power so it should be able to be more forceful. It can also adjust the angle of insertion, and be helped by gravity pulling the item down.

If inserters were able to compress belts, realistically they would have to consume a little extra power each time. The free energy nature of belts makes it unsuitable for the kind of workload you're demanding.

[TheRaph]

Both diagrams show the same thing. The only difference is the machine doing the pushing (inserter vs belt) and the dimension along which the object is being pushed (x/y vs. z). Why should the belt be able to push items back any more forcefully than the inserter? The inserter actually runs on power so it should be able to be more forceful. It can also adjust the angle of insertion, and be helped by gravity pulling the item down.

If inserters were able to compress belts, realistically they would have to consume a little extra power each time. The free energy nature of belts makes it unsuitable for the kind of workload you're demanding.

It's not really the same thing. The problem is, that an inserter (in reality ... and I think ingame too) never push anything on a belt (especially not with force) due to not do any damage to the belt. Every robot-arm I know will positioning an item just some cm or inch (or some mm) about the belt and then release it, let the g-force doing the rest.

If then the released Item make its way down to the belt is heavily depending on shape of that item.
So in case of marbles, my first picture wouldn't never occur. In case of blocks it would happen as shown.

Side-loading is a different thing. First in reality I only know about side loading on an empty belt (like here). Side loading (with 90° as in factorio) in case of an already semi-filled belt I've never seen in real-live. An example how side loading in reality works, you may see in this video at 1:52 : https://www.youtube.com/watch?v=dh-IwQFFtIw
So I think this also depends on shape of items. In case of cubes, I think, it will jam both belts, therefor I've used flat cylindrical objects in my pictures (top view and side view).

[golfmiketango]

Some factorio-development-historical background you may find interesting/relevant. Here's a (slightly munged in order to preserve link integrity) great summary from daniel34 from about a year and a half ago about changes to belt dynamics moving from 0.11 to 0.12 factorio releases:

Note: This post was largely made before Shokubai made the post with the nice white/red drawings.

You have a different understanding of the word compression than we (Factorio players) do.

From the gif in your previous post I gather that for you compression means items on both sides of the belt stay next to each other after taking a turn and no side falls behind.
For us, compression means that the belt is completely saturated and transports items at the highest possible throughput (fully compressed belt).

In Factorio 0.11 items lost compression at corners, which was changed for Factorio 0.12.

Factorio 0.11 (compression loss at the corner):

Factorio 0.12 (belt stays fully compressed):

In 0.11 the items on a belt were actual entities in the world, and had to be checked for collisions at each corner which took a lot of performance. Now in 0.12 the belts are split into two lines with virtual items that do not directly interfere with other entities/items unless required to do so (e.g. inserters), which doesn't require collision checks.
More information: Friday Facts #82 - Optimisations (scroll down)

The reason why items on the inner side of the corner are faster than on the outer side is that the way is shorter, and the belt line doesn't know/care internally if it is at a corner or not (imagine the belt was rolled out to a straight line, the inner line would be shorter).