Consistent, relative lane-placement by inserters

[gustaphe]

TL;DR

Inserters care about the direction of a belt on which they try to place things. I don't think they should.

Background

I first reported this as a bug, because I thought it only applied to underground belts, but as it turns out, the "bug" was in fact the lack of a feature which I just assumed was in there but wasn't.

I've thought that inserters always placed on belts relative to the inserter, i.e. that it would always place in the quadrant opposite and to the right.
This rule-of-thumb holds true for a majority of cases, but there are a couple of exceptions. I've included a picture of every (?) possible combination of inserter direction and belt type.
In the figure, A1, B1, C1, E1, E3, F2, G4, H3, J2 and J4 show signs of disobeying the rule.
In these cases, it seems the inserter is aware of the direction of the belt when placing, which contradicts the general appearance of inserters as mechanical entities.

Notice for instance how the items in D1 and C1 end up in different lanes, despite being almost identical setups.

consistency.jpg (1.01 MiB) Viewed 6473 times

What?

I want inserters to place items predictably, relative to their own reference frame only, preferably in the front right corner of their target square.

Why?

Planning more advanced setups is easier if there is an easy way to remember/predict where items will be deposited.
The use case that got me onto this track was two inserters facing opposite ways placing onto the entrance and exit of an underground belt respectively, where a consistent behaviour would make them deposit on one lane each.

[Engimage]

I have created a topic with similar request here
viewtopic.php?f=16&t=46034

[torne]

There aren't any "quadrants" here - they put items in the middle of the relevant belt lane, not in one corner of the tile. Inserters place on the far lane when the belt is perpendicular, on the right lane when the belt is parallel, and the inside lane when the belt is curved. This is a predictable and consistent rule, it's just not as simple as the rule you assumed it was.

Inserters always depositing onto the right lane whichever way they are facing makes some logistical arrangements more difficult; it seems like this is probably intentional. It would be very easy to just fill both sides of a belt in a lot of scenarios if you could do the thing you're proposing with underground belts

[AileTheAlien]

on the right lane when the belt is parallel

A1, B1, and C1 all violate this.

the inside lane when the belt is curved.

H1, and I2 are violating this.

place items predictably, relative to their own reference frame only

+1 to original idea.

[torne]

on the right lane when the belt is parallel

A1, B1, and C1 all violate this.

That's the right lane of the belt. Just a different perspective.

the inside lane when the belt is curved.

H1, and I2 are violating this.

That's interesting; I didn't see that in the image, sorry. There's also four more cases not in the image (the belts going in the opposite direction around a corner). When people test this normally they use short inserters, which can't be in the position pointing in or out of a curved belt, since there must be another belt in that tile to make the belt curved, so you can only see these cases with long inserters. When the inserter is on the "outside" of the curved belt (i.e. to the north or west in H/I, and the north or east in J/K), then it always places on the inside of the curve (whether long or short). When the inserter is on the "inside" of the curved belt, it turns out it always places on the outside of the curve (in both the two cases pictured here, and the other two not shown).

So, I guess a better way to put the rule here would be that it also puts it on the "far" side of the belt when inserting onto a curve, and the "outlier" is the behaviour when the belt is parallel because in that case neither side is further and so a different choice has to be made.

Thanks for pointing that out, I've learned something new I still think it's fine the way it is, though, and it feels like a more interesting challenge to me to *not* be able to fill both sides of a belt just by inserting onto undergrounds from the "middle". It also seems likely that the current behaviour is intentional, and so probably isn't going to change (especially since it would break people's factories).

[gustaphe]

I have created a topic with similar request here
viewtopic.php?f=16&t=46034

Sorry, I didn't find this. It's excactly what I'm after.

There's also four more cases not in the image (the belts going in the opposite direction around a corner).

I can't see what you mean. Both turn directions are present, being inserted onto from each of the four directions. Or is there a dependence on absolute belt direction?

[torne]

I was curious if there was a dependence on absolute belt direction or not, so I tested the other cases and there isn't. (there have been absolute direction dependencies in the past, e.g. the recently fixed issue where inserters facing north are one tick slower).

[JohnyDL]

The Is and Js because belt being placed on is perpendicular to the inserter it's ignoring the input that turns it into a corner and treating it like a normal straight conveyor. While H and K the output direction is being ignored and it's following the sides as though that conveyer continues in the same direction as the input. Feeding the inside corner is the only normal configuration of this you come across because to fill the outside corner you've got to be coming at it with the long handed inserter exactly how it is in the picture. and why would you use a long handed where it isn't necessary (the conveyor comes right past the inserter)

Also I never noticed right side of belts and undergrounds that are parallel and left side of splitters that are parallel, I can think of a few places to use that (note for sidedness I think forward, backward left and right on conveyors rather than NSEW and think a number of other people have done the same in this thread)

[ssilk]

Changed the subject title a bit.

I think so:
As long as the inserter-lane-placement is NOT predictable (which means also "is too complicated") and can change with any version (is not unit-tested), their behavior cannot be part of any gameplay.

In opposite: If
- the inserter-lane-placement is predictable (less than a handful of rules!)
- there are unit-tests, which gurantee that this behavior doesn't change anymore
I see a big potential for a very special kind of sub-gameplay.

Part of such rules should be also handling, if there are two or more inserters that can input/output at on one point, how is the order, which one comes when?

[Quezax]

I completely agree and would like to see this implemented.

There should be a way to insert to either sides of a parallel belt in this situation:

Inserter placement issue.jpg (148.89 KiB) Viewed 6094 times

It just feels very inconsistent that they end up on opposite sides if the belt if perpendicular to the inserter, but not if they are parallel.

Thanks for considering this,
Quezax

[Tekky]

I also think that the inserter behavior should be predictable and consistent.

[Ralimist]

Related: viewtopic.php?f=6&t=59806 (my thread)

[bobingabout]

I think what could fix this is if inserters had not only a 0.2 tile offset in length, they also had a 0.2 sideways offset too... so if you're saying they should all have a right side bias, then set the drop location to... let me get this right because inserters are wonky... insert_position = {0, 1.2}, would become insert_position = {-0.2, 1.2}, though that depends if you want right hand bias when inserting up, or down...

you could probably add the same 0.2 offset to mining drills for the same effect.

Also, Why is it insert_position in the data stage, but drop_position in the run time stage?

[gustaphe]

The mod in

f=6&t=59806 (my thread)

the mod mentioned in that thread (https://mods.factorio.com/mod/Fix_Inser ... lls_Output) seems to do what I want. Can't speak for the implementation at all.