[2.0.15] Unexpected Inserter/Belt interaction.

Bugs that are actually features.
Veni
Burner Inserter
Burner Inserter
Posts: 16
Joined: Thu Jun 29, 2017 5:22 am
Contact:

[2.0.15] Unexpected Inserter/Belt interaction.

Post by Veni »

Factorio mathematics seem to be broken and it is hurting my soul. It is also hurting my brain figuring out how to describe it.

From what I understand, the inserters have the following rules prioritize picking up from the near side of the feeding belt; only dropping on the far side of a receiving belt. As a result a horizontal inserter will push from right, near first, to far left only; or from left, near first, to far right only. The behavior is similar on the vertical alignment of the inserter. My engineering mine attempts to treat this behavior as being vectored. But the vectored treatment ends up breaking down when it comes to the placement of items on belts sharing the axis of the inserter. Where the orientation of the belt didn't matter before, all of a sudden it does matter. There are also some other unexpected behaviors.

I have attached three images. In the first, in my mind, I show a few situations labelled with red numbers. In the second there are display panels showing letters representing how the same blueprint was flipped. I will discuss the third later.

Image 1:
img 1.jpg
img 1.jpg (84.84 KiB) Viewed 321 times
  1. Situation 1 is the normal dropping of chips on the far side of a belt running perpendicularly to the inserter.
  2. Situation 2 is an inserter being able to put data in what should be expected to be an illegal position for a deposit on the belt given the other behaviors.
  3. Situations 3 and 4 show that inserters with opposite facings place on the same side of a parallel belt, and the side is determined by the direction of the belt.
Image 2:
img 2.jpg
img 2.jpg (93.15 KiB) Viewed 321 times
  • O is the original micro blueprint for demonstration.
  • H is the horizontal flip of O.
  • V is the vertical flip of O.
  • B has been flipped both horizontally and vertically.
The belts on their own show the expected symmetry for the flips that have happened. However the items placed on the belts do not show the mirror symmetry. If there were separate items in the lanes, they could end up being mixed. Also because of the geometry the same issue would happen with rotation. Each horizontal/vertical flip is equivalent to a 180 degree rotation.

These behaviors may be intended, but they are counter to the normal mathematics. I would expect i x j = k, j x i = -k, etc. relationships to hold true. Otherwise a blueprint is more likely to break when rotated. A belt that normally had item M on the right side relative to the facing of the belt, could have it on the belt-left side if the blueprint is flipped vertically. I think you can fix this.

More seriously, I am a major fan of you guys and the work you do. I hope some of the detail and drama here make you laugh. Ironically, "fixing" this will probably break a few things that work because it is broken. I can think of a few ways you could trivially make a fix work only for newly designed blueprints and builds, but I don't think you want to maintain that patch forward.

The third image is a design that would work if the inserters didn't violate the laws of mathematics. I spent over an hour searching for this bug being reported. There are no reports I can find. I suspect most people who might have noticed this didn't think it might be a bug and redid their design. I already see a small change I could make to fix this. Others who encounter this have probably done so too. I am posting it because A. it is interesting. and B. it does cause other unexpected issues as I described. I imagine fixing the bug also justifies looking into optimizing the placement/removal of items on belts.
img 3.jpg
img 3.jpg (192.56 KiB) Viewed 321 times
I don't know how or why this behavior was programmed in. It feels like there is a weird override somewhere that it was decided the placement should be on the right side of the belt when the axis is like this. Though more particularly it seems to be when an item is in the center of a tile relative to the axis of the belt, it will be shifted to the right lane. The easiest fix would probably be to have an inserter drop the item being placed slightly off center from the tile based on direction of facing. Since it seems inserters prefer counter clockwise rotation, an inserter placing north would be slightly to the east, an inserter to the west would be slightly to the north, an inserter placing south should be placing slightly to the west, an inserter placing east should be placing slightly to the south. etc. Whether the hood of the underground belt should block things is up to you and how much chaos you want to cause. This also could necessitate slightly increasing the rotation speed of inserters. They seem to over time prefer picking up from the arriving direction of supplied products and this will override the counter clockwise rotation paradigm. You could alternatively totally give inserters a handedness where they rotate preferentially cw or ccw dropping on the first lane encountered and this gets flipped if the blueprint is mirrored.
User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 3335
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [2.0.14 and 2.0.15 and 1.0.11] Unexpected Inserter/Belt interaction.

Post by boskid »

Thanks for the report. I am not seeing anything broken here.

Transport belts are never able to reject insertions onto them so inserting onto underground belt will snap to the closest valid position. All insertions are guided by the position at which inserter drops the items and when items are dropped at the exact center line between left and right side of a belt then there is a tie-breaker rule that says the item should be inserted on the right lane of the belt. I made sure all the rotations of a blueprint obey rotations so there should be no cases where rotated blueprint would stop working because of inserter to belt interactions. It will however fail when blueprint is flipped because in such cases inserter still drops at the center line and belt still proposes right lane even when the belt was built as flipped.
Veni
Burner Inserter
Burner Inserter
Posts: 16
Joined: Thu Jun 29, 2017 5:22 am
Contact:

Re: [2.0.14 and 2.0.15 and 1.0.11] Unexpected Inserter/Belt interaction.

Post by Veni »

It does affect the way lanes need to be combined upon rotation. If the belt orientation is south to north the player-left belt is fed onto the player-right belt. If the belt-orientation is north to south the player right belt needs merged onto the player left belt. So if the production is rotated and then the drain line is connected, the drain line will only work for the production being in one orientation.

The "bug" is really a question on the intended logical hierarchy.
Is the rule about inserters dropping in the exact center of the tile more important than the rule that inserters facing opposite directions should have opposite actions?

The parallel inserter/belt loading ends up having opposed inserters have equivalent results to their action where the perpendicular does not.

I did spend close to 6 hours triple checking the versions and the behavior before filing the report. I would appreciate an affirmation that the hierarchy of rules is
"Inserters placing items in exact tile center" is more important than "Inserter facing determines inserter behavior" and "Opposite facings should have opposite effects". I totally understand if that's how you want it. It just is a surprise to me because I conceptually have treated item placement as being completely inherent to the facing. Probably because of the rigidness in belt loading.
User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 3335
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [2.0.14 and 2.0.15 and 1.0.11] Unexpected Inserter/Belt interaction.

Post by boskid »

Lets take a look at transport belt since it is most complex. It has 3 shapes (straight, turning left and turning right) and can have 4 directions relative to an inserter.

All 12 setups here are rotationally consistent, so my question here is: where is the problem with blueprint rotations?
11-08-2024, 14-24-23.png
11-08-2024, 14-24-23.png (1.11 MiB) Viewed 279 times
Post Reply

Return to “Not a bug”