Rotating belt.

[steinio]

Well i read about this topic in the bug section and it was declinded - legitimately.

My suggestion is, that a filled belt keep on movin until only one sort of items or nothing (how about stop empty belts?) are on it.

Usecase:
belt loop from mixed output with different maschines to use them:

rotating belt.png (630.49 KiB) Viewed 6118 times

The assembler can't reach the white item because the belt stopped.
If all white items were filtered out and only brown are on it, it would be reasonable to stop, because everytime the other machine can reach a brown item.

Btw: the belt keeps on moving but the items are not transported, what don't makes sense furthermore.

Greetings steinio

[Deadly-Bagel]

There are a lot of other ways to solve this logistically. Split the items into two belts, have a buffer chest (bonus points, only pull items if required), stop the input feed once the belt loop is almost compressed (would need to swap the lanes of the belt to prevent one becoming backed up).

[zebediah49]

It appears that your actual proposal is "splitters should search down their outputs to attempt to find loops, and if one is found, that input should be given priority."

See, what you have looks like a loop made of belts, but it's not -- the splitter fundamentally changes it. In the basic combining case, splitters use a pretty simple algorithm -- accept item from left; accept item from right; repeat. Now, the key here is that when it accepts an item from the left, it is not accepting an item from the right.

For your application, this means that the splitter is currently ejecting an item from its top input into the output. It's waiting on space in the output to finish this task (after which it will process an item from the bottom input). The only problem is that the belt is blocked... but the splitter. Because it's currently handling that top item, the bottom input is blocked; it might as well be a wall for its effectiveness in accepting items.

So, what you really want here, is for the splitter to not be accepting that top item without spare space to put it somewhere. Aside from a fundamental change to splitter behavior, you have a couple options to enforce that prioritization:

1. Side-load the belt. This prevents you from over-filling it (as long as you don't mix colors), so it will always keep spinning.
2. Use circuit wire to disable the top input belt when there is no space to accept its items.
3. Use a chest/inserter contraption to handle it.

[aeros1]

Or make priority feeder. This is wrong design your sorting loop should look like this.
...o-o ..../-\
.--o-o-> | >---|
..|----< o| | <-
........--o--/
..(in)/

Where (in) is input
/, -, | are Belts

o
o is splitter

and > > underground belt. The construction of 2 splitters on both sides of belts is optional mostly to prevent items getting between gaps, But as far as I know you wouldn't need it. Basic idea is feed your sorting loop from both sides. And pretty sure there can be priority splitter compound 1/8 or 1/16 to refeed back to chest for farther sorting should need to renew sorting belt arise.(splitter works per item type).

[steinio]

Well the letters are not spaced evenly so it was hard to se what you mean but i guess it's like this:

But also both lanes stop.

rotating belt 2.png (402.36 KiB) Viewed 6053 times

[aeros1]

Well the letters are not spaced evenly so it was hard to se what you mean but i guess it's like this:

But also both lanes stop.

The attachment rotating belt 2.png is no longer available

Close enough I found usuing splitters on loop. Just to split 6 size belt to 3 and 3 than link helps with splitter(single belt holds 6 items, so just putting splitter is enough. Reason the loop stops here I think is when itemsa re not dense enough and spacing between is less than one item in total. So having this buffer helps to setup loop once it fills enough, and help full belts not to jam. You might need some belt space on both sides because splitters don't have storage space?

P.s. Which makes me belive belts don't hold devisible amount of tems on their length. Because, buffer required to expand belt storage to hold items in a row.
P.p.s. Also tested this belt, and it seems mostly oughter part jams it could be because coner belts add stoarage, so putting equaliser on loop may help un jam belt too.
P.p.s also noticed this thing compresses resources even on fastest belts making them as efficient as normal belts.

Here is my friend's version of correct loop feeder it doesn't jam and doesn't back up fully. At least if you have one feeder it'll work for sure for more loop might require more buffers to extend belt. As I told it seems belt doesn't holds exact number of items so it jams. you need give a little bit more space without reducing density.

[Deadly-Bagel]

Or make priority feeder. This is wrong design your sorting loop should look like this.
...o-o ..../-\
.--o-o-> | >---|
..|----< o| | <-
........--o--/
..(in)/

Just a note you can use code tags to format examples as it gives everything the same spacing:

Code: Select all

   o-o     /-\
 --o-o->  | >---|
  |----< o|  | <-
        --o--/
  (in)/

Can also use whitespace so as to be less confusing. Of course this example still doesn't line up but you get the idea.

[ssilk]

Sorry, such "Factorio coding" is only a good idea for very simple things. In my opinion we need some kind of "workshop" in the game to fast create sample constructions like the above.

Nevertheless, I think this can be closed.

[Deadly-Bagel]

Come full release and if I can relatively easily get my hands on all the entity graphics this would be a good way to learn Java...

[steinio]

Nice little hack - works fantastic.

But what about stopping empty belts?
Does this save computing time?

It can start again if an item or player is on it.

Greetings steinio

[ssilk]

But what about stopping empty belts?
Does this save computing time?

It can start again if an item or player is on it.

No, indeed it would take more computer time to compute, if a belt now needs to be rotated or not.
The rotating belts are just graphical. The graphics card does all that, no CPU needed.

[steinio]

Ok so i'm finished with this thread

[zebediah49]

I mean -- the game-state is incremented by the CPU, so stopping animations would technically cut down on load... but it's entirely negligible.

Sorry, such "Factorio coding" is only a good idea for very simple things. In my opinion we need some kind of "workshop" in the game to fast create sample constructions like the above.

No, we need a workshop out of game. A javascript implementation of belts and splitters (and object source/sinks), so that "share" links can exist -- think the Factorio equivalent of sqlfiddle. Bonus points if it's compatible with some kind of blueprint string mod. Also, a "slow motion" button.

[mrvn]

I noticed that a simple looped belt, an O, that is filled by e.g. a miner, will stop moving items when it gets full. I think the problem is that the turns compress the inner lane and expand the outer lane. So going into the turn the item has to wait for the inner lane to clear, which never happens because that waits on the next turn and so on. Similar on leaving a turn the item has to wait for the outer lane to clear with the same result.

Adding a turn in the other direction balances the stretching and compressing and keeps the belt moving:

Code: Select all

+---------------+
|               |
+-+ +-----------+
  +-+