Transport Belts reworking

[Raze1991]

Updated: Look here at my post #7 and below.

Do anything with distance capture of all Inserters.
I want to present three pictures (A, B & C)

Picture - A

A.png (464.92 KiB) Viewed 7219 times

Picture - B

B.png (489.42 KiB) Viewed 7219 times

Picture - C

C.png (501.89 KiB) Viewed 7219 times

As you can see at «A» - current optimal solution nowadays.
«B» seems logical, but Inserter can't grab last one.
At «C» you can see similar solution, like on «A» at other side, but it not work, cause Inserter can't put it on Transport Belt (and rightly so).

I see 2 different suggestions to resolve that (I'm talking about the first two pictures):

1) Slightly reduce Inserter's capture range from one side and add it to other. Make «B» only one possible and workable solution.
2) Make similar range for both sides of Inserter's capture to make «B» chance to exist. But I think that everyone will use the old one - «A».

At all pictures I painted a green rectangle, and at «A» & «B» you can see that corner of Iron Plate at both pictures is similar, but in second one, Inserter can't grab it.
But in the almost same time, solution at picture «C» does not work. «A» works fine, why «C» not?

In my opinion, it would be right to take a first my suggestion. It seems really logical and Transport Belts at both sides would be similar.

P.S. it seems like a small bug, but It's my idea how to resolve it.

[just_dont]

I'm all for this too.
No matter the quirks, those quirks should behave consistently at least.
Though if "A" gone there will be some tears around as some compact factory designs use that quirk extensively. So I would prefer the "A & B" way of fixing it.

Though from a programming standpoint it could be a big problem to make it behave consistently (for the player, as it is already consistent from the program's view).
I.e. the inserter can't pick the item because it's already moved into the other cell -- a belt placed on a cell moves items to the edge of the next cell, and slightly into it.
The inserter could be adjusted to pick those items, but then...

Code: Select all

  <
=O=

How would you prevent an inserter from picking things diagonally in other cases, like the one above (= belt, < inserter, O pick point on the belt)?
How would you avoid the case where a chest is placed in that point?
And so on, so on. There may be other ugly situations.

[ssilk]

The reason for that's, that when the belt ends it shifts the item onto the next tile, where the inserter can reach it.
The reason, why it can't reach the item on the end of the belt is, that it is not on the belt, it's on the next tile!

C right side: doesn't work just because it isn't clear, which belt might be meant. (You could have the possibility for belts in 4 directions. Which should be the belt, the inserter should put the stuff on?)

A left side: doesn't work cause of the same issue: you have belts from 4 directions and need to choose one, which needs to be taken; it reduces the possibilities.

So there are many logical reasons, why it is so and I wouldn't change that, cause that just works.

What I think is useful, is to have some visual sign, that there is at the end of a belt some "more belt left"... some more pixels of something like a "table", which reaches into the next tile. The items lay on that table, It's only visual, no real change in physics, but for the player it's clear, that the belt ends on the next tile.

[Drury]

I still don't understand why the belts are offset at all.

[ssilk]

That is simple: A belt works like "moving ground". Anything within the range of the belt (nearly the whole area of the tile) is moved by the physics simulation.
So, logically, when you want, that a line of conveyor belts move the stuff on it, they need to be connected somehow. So the job of a former belt in such a line is to move the item to the next tile, so that the next belt on that tile can move it to the next tile, so that the next belt on that tile can move it to the next tile and so on. So the last belt in a row moves the item to the next tile, where it stops. And can't be reached anymore by the inserters, because it is the next tile.

And from that point just_dont explained it very well.

Tip: Switch on the debug mode with F5 and zoom into full zoom (you can use overzoom, if you use the console and set zoom to very high and perhaps slow down game speed also a bit, see wiki: https://forums.factorio.com/wiki/inde ... layer#zoom + https://forums.factorio.com/wiki/inde ... e=Lua/Game ), so you can see that clearly.

[slay_mithos]

The only thing that would "fix" this would be to not push items after the last spot on a belt.

The problem with that solution is that it's this very thing that makes the whole belt system work in the first place, so "fixing" it would mean reworking the whole belt system to a more complex one, possibly more CPU intensive and glitchy.

EDIT: this was meant as an answer to the first post, in case it sounds confusing with the posts in between.

[Raze1991]

I have tested it on the debug mode, and all were right.
As all of you can see, all the problems with the last place on Transport Belt.

Picture - D

D.png (471.11 KiB) Viewed 7148 times

Picture - F

F.png (595.29 KiB) Viewed 7148 times

«D» seems not correct, and if the last one item will not come closer, Inserter would not take it and therefore this option will be not workable.
«F» seems right, but Inserter can't take last one for the same reasons. And with workable «D», it becomes irrelevant.

Needs a small reworking to all Transport Belts for more comfortable game, isn't it?

[kovarex]

«D» seems not correct, and if the last one item will not come closer, Inserter would not take it and therefore this option will be not workable.

I don't get it, does D work for you or not?

[Raze1991]

«D» seems not correct, and if the last one item will not come closer, Inserter would not take it and therefore this option will be not workable.

I don't get it, does D work for you or not?

You quoted my suggestion to solve the problem (in my humble opinion it is imperfection)

It works at both situations.
But «D» seems visually like a defect.
And «F» at the same time seems more right decision.
But «F» useless until «D» works.

[DrNoid]

I would say the belt should push the item a bit further onto the empty space, so it's clear the item has landed on that empty space. The problem comes from the item stopping right on the border, with its centre point just across the border.

That would make sense, since it would mimic real life. At the end of a belt an item will fall off, and be completely off the belt.

[ssilk]

The belts are still nearly on the ground... :}

[drs9999]

The belts are still nearly on the ground... :}

and because of the friction applied to the item it cannot be pushed further away from the end of the belt.

So for me it made and still makes totally sense.

[tonberrytoby]

I would say this is mainly a problem with the belt's graphic.

The lonely plate in picture B looks as if it is still on the belt. So if there is no grid displayed, it looks as if it was in the square that also contains the belt.

Probably the best solution would be to make the belt's graphic confined to the are that it effects.
I suppose this might make single square belts look stupid and require additional coding to make belts connect graphically.

[Raze1991]

What about the fact that to add a Buffer stop (Bumper) at all ends of Belts? That Bumper will be automatically set at the end of the Belt's path, and it will prevent object movement to the last line. And if you add the Belt to the zone between the two Belts, they will be connected like it work at nowadays.

Picture - G

G.png (279.93 KiB) Viewed 6925 times

As a result: «A & D» does not longer work, and «B & F» works as it should be.

[Garm]

I fail to see a problem here.

what is wrong with belts dumping items to nearby cell?

this is common in RL belts

[badminton]

What about the fact that to add a Buffer stop (Bumper) at all ends of Belts? That Bumper will be automatically set at the end of the Belt's path, and it will prevent object movement to the last line. And if you add the Belt to the zone between the two Belts, they will be connected like it work at nowadays.

There would also have to be a check to see if there's a belt running perpendicular to the end of the first belt so that it still pushes the item onto a separate belt running in a different direction.
I think they do something similar with pipes. If there's no pipe joining then the pipe end is added automatically.

I like the flexibility of having items pushed off the end of the belt though. I means I can end 3 belts at a single inserter and have it pick up 6 different items from one tile. This wouldn't be possible if the item stopped at the end of the belt.

[Raze1991]

I know, many have become accustomed to the current state of affairs.

But see «A, B & C» pictures again.

«C» looks the same at both sides. But it not works.
«B» looks great and symmetrically, but it not usefull.
«A» looks not correctly.

As you look, to make shorter the last part of the Belt?
The part, that I like to draw at «G» as Bumper, imagine that this part disappears. And last part of Belt becomes shorter. But if you add the other Belts in the path of the current Belt, they connect the way it works nowadays. I mean, that this change will affect only the last part of the Belt, and thats all.

[Garm]

I am sorry, but A looks absolutely correct to me.