[kovarex] [0.16.22] Inserter belt compression is orientation dependent

Bugs that are actually features.
Post Reply
Syhn
Inserter
Inserter
Posts: 43
Joined: Mon Jan 22, 2018 9:13 pm
Contact:

[kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by Syhn »

A bot to belt loading design I am working on is only producing fully compressed belts when oriented facing the north or west. When facing south or east, belts drop to about 75% full load.

Image

Rseding91
Factorio Staff
Factorio Staff
Posts: 13171
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [0.16.22] Inserter belt compression is orientation dependent

Post by Rseding91 »

This is almost certainly related to the other compression issues belts have. If this issue still persists after they're fixed then please let us know.
If you want to get ahold of me I'm almost always on Discord.

Novalith
Burner Inserter
Burner Inserter
Posts: 10
Joined: Wed Sep 06, 2017 10:24 am
Contact:

Re: [0.16.22] Inserter belt compression is orientation dependent

Post by Novalith »

20180304171835_1.jpg
20180304171835_1.jpg (710.57 KiB) Viewed 3851 times
Rseding91 wrote:This is almost certainly related to the other compression issues belts have. If this issue still persists after they're fixed then please let us know.

No sir. I just tested this with 0.16.27 and it is alive and kicking. Same bug. North and West showed some minor decompression, but South and West showed a much greater decompression/loss. Let me know what else you need.
Attachments
1 More Please.zip
Save File
(22.53 MiB) Downloaded 105 times

kovarex
Factorio Staff
Factorio Staff
Posts: 8078
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by kovarex »

None of the direction actually produce fully compressed belts. Inserting into splitter works, but it is more tricky, as the area to place it is pretty small, so it is possible for gaps to happen.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by eradicator »

@OP:
That's not a problem caused by inserting onto splitters but rather of the highly fragmented belt that is created by chaining splitters like that. Inserters never reach their full potential speed on belts fragmented like that because they have to waste too much time on waiting for a gap to come by.
ontothesplitters!.jpg
ontothesplitters!.jpg (62.84 KiB) Viewed 3672 times
As you can see here properly timed inserters outputting to a single belt lane work just fine even with chained splitters. But without proper timing even this does not work as inserters do not synchronize to each other automatically.
untimely.jpg
untimely.jpg (57.77 KiB) Viewed 3672 times

Syhn
Inserter
Inserter
Posts: 43
Joined: Mon Jan 22, 2018 9:13 pm
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by Syhn »

Whether or not this results in full compression is not quite what I intended this report to be about. I was merely expecting the result to be consistent regardless of orientation.

Dominik
Former Staff
Former Staff
Posts: 658
Joined: Sat Oct 12, 2013 9:08 am
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by Dominik »

Is it just me, or there is a pattern in the blue chests?

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2631
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by steinio »

Dominik wrote:Is it just me, or there is a pattern in the blue chests?
It's just you...
Image

Transport Belt Repair Man

View unread Posts

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: [kovarex] [0.16.22] Inserter belt compression is orientation dependent

Post by mrvn »

Syhn wrote:Whether or not this results in full compression is not quite what I intended this report to be about. I was merely expecting the result to be consistent regardless of orientation.
If it's a timing issue as has been suggested then it should be random. Have you tried blueprinting a few versions of this to see if they always behave the same?

Post Reply

Return to “Not a bug”