Improvement to item placement on belts

[Ralimist]

What ?

The change I propose is: if the direction of belt/underground belt is opposite of inserter/drill direction then put item on the other lane

Untitled2.png (1.64 MiB) Viewed 1020 times

Original post (I thought it was a bug): viewtopic.php?f=47&t=59699

Why ?

I belive this change will make how items are being placed on belts a bit more consistent.
It will also allow for setups like these (which will be automatically lane balanced):

Untitled.png (1.33 MiB) Viewed 1020 times

[SuicidalKid]

Can I ask why you would want this? In your example, it unbalances it from 2 miners on either lane, to 3 on 1 lane and 1 on the other. That seems like a regression to me, as it would make it so you would need to balance the belts afterwards anyways.

[dood]

How does your example tile and get power?
How is it any better than just 4 miners, 2 undergrounds, 1 power pole?

[Hedning1390]

I belive this change will make how items are being placed on belts a bit more consistent.

It would make things less consistent. Right now it follows the right hand rule, which also inserters follow. I have nothing against it though, as long as your next step isn't trying to do the same with inserters. Stay away from the inserters.

[Tekky]

Related threads:
viewtopic.php?f=6&t=49059 Consistent, relative lane-placement by inserters
viewtopic.php?f=16&t=46034 Inserter drop point inconsistency

[Ralimist]

Can I ask why you would want this? In your example, it unbalances it from 2 miners on either lane, to 3 on 1 lane and 1 on the other. That seems like a regression to me, as it would make it so you would need to balance the belts afterwards anyways.

The picture shows how it works at the moment. If the change gets implemented, it will be balanced (2 miners per lane).

How does your example tile and get power?
How is it any better than just 4 miners, 2 undergrounds, 1 power pole?

It was just an example not a way to arrange miners.

I belive this change will make how items are being placed on belts a bit more consistent.

It would make things less consistent. Right now it follows the right hand rule, which also inserters follow. I have nothing against it though, as long as your next step isn't trying to do the same with inserters. Stay away from the inserters.

Capture.png (361.98 KiB) Viewed 944 times

The change will affect inserters too, the miners were just an example.
As you can see everything gets placed on the right lane from the belts perspective - that's how it works at the moment.
If my change would get implemented, the first and third inserter (which have opposite directions to the belt) would place items on the other lane.
And it will be more consistent with how inserters and miners place items on the belt if they are perpendicular to the belt as seen in the next picture.

Capture2.png (180.34 KiB) Viewed 944 times

[Hedning1390]

And it will be more consistent with how inserters and miners place items on the belt if they are perpendicular to the belt as seen in the next picture.

Is it more consistent just because insterter direction is considered in both cases? Not really. Perpendicular and parallel are fundamentally different anyway so you still need two rules (also corners are treated as perpendicular).
From: Perpendicular = Far side (insterter). Parallel=right side (belt). Two rules
To: Perpendicular = Far side (insterter). Parallel=right side (inseter). Also two rules.

Right now all insterters placing on a belt going around will output on the same line, and all insterters placing on belts going underneath will also place on the same line. This is easy to understand and hard to mess up, and I expect this is why they made it this way to begin with. If you mix which side (left right) the inserter is placing on depending on the inserter direction that means inserters outputting from the same machine may fill both sides of the belt. This seems to be what you want, but it also means you have to be incredibly careful if you have 2 lanes with different items. I don't think it's a good idea, and it would also break every save file forcing people to either restart or spend a lot of time fixing their factory (though that's less of an issue considering its EA status).

[darkfrei]

Try this mod:
Fix Inserters And Mining Drills Output

[Ralimist]

And it will be more consistent with how inserters and miners place items on the belt if they are perpendicular to the belt as seen in the next picture.

Is it more consistent just because insterter direction is considered in both cases? Not really. Perpendicular and parallel are fundamentally different anyway so you still need two rules (also corners are treated as perpendicular).
From: Perpendicular = Far side (insterter). Parallel=right side (belt). Two rules
To: Perpendicular = Far side (insterter). Parallel=right side (inseter). Also two rules.

Right now all insterters placing on a belt going around will output on the same line, and all insterters placing on belts going underneath will also place on the same line. This is easy to understand and hard to mess up, and I expect this is why they made it this way to begin with. If you mix which side (left right) the inserter is placing on depending on the inserter direction that means inserters outputting from the same machine may fill both sides of the belt. This seems to be what you want, but it also means you have to be incredibly careful if you have 2 lanes with different items. I don't think it's a good idea, and it would also break every save file forcing people to either restart or spend a lot of time fixing their factory (though that's less of an issue considering its EA status).

Good points. This wasn't such a good idea after all...

[Ralimist]

Try this mod:
Fix Inserters And Mining Drills Output

That's awesome, thanks!

[bobingabout]

Try this mod:
Fix Inserters And Mining Drills Output

Very nice.

though, the implementation is quite crude and applies the maths to both X and Y drop positions without checking anything. This could be potentially dangerous if you try to adjust an inserter that has a drop location that already has a negative offset, as it could set the new offset to a position outside the allowed area, causing some mods to be unable to load.

For the inserter at least, I would change the code to...

Code: Select all

for name, prot in pairs (inserters) do
  if prot.insert_position then
    if prot.insert_position[1] % 1 == 0 then --check the modulo of the value to see if there's a fraction.
      prot.insert_position[1] = prot.insert_position[1]-0.2
    end
    if prot.insert_position[2] % 1 == 0 then --check the modulo of the value to see if there's a fraction.
      prot.insert_position[2] = prot.insert_position[2]-0.2
    end
  end
end

To note, 0.2 is the proper offset, check inserter's values and you'll see that their reach is set to 1.2 and 2.2 for long.


Mining drills are a little more generous with their placement, but I'd consider checking for a result of 0 and 0.5 on the same check also.

[darkfrei]

though, the implementation is quite crude and applies the maths to both X and Y drop positions without checking anything. This could be potentially dangerous if you try to adjust an inserter that has a drop location that already has a negative offset, as it could set the new offset to a position outside the allowed area, causing some mods to be unable to load.

Thanks for your help. The mod was written in 5 minutes, just proof that it works. Of course place position must be checked before. But this mod works with vanilla and it's some type of success. Enough for 0.0.1

[bobingabout]

though, the implementation is quite crude and applies the maths to both X and Y drop positions without checking anything. This could be potentially dangerous if you try to adjust an inserter that has a drop location that already has a negative offset, as it could set the new offset to a position outside the allowed area, causing some mods to be unable to load.

Thanks for your help. The mod was written in 5 minutes, just proof that it works. Of course place position must be checked before. But this mod works with vanilla and it's some type of success. Enough for 0.0.1

I can understand that, First versions often are just a case of trying something, and if it works, go with it.