When I use blueprint of Fast underground belt in/output set, output parts can paste over input side.
Is this a Intended operation?
I use this blueprint
https://i.imgur.com/vP8Zjkb.jpg
output can paste on input parts.
https://i.imgur.com/Ly58ZpO.jpg
[Twinsen][0.16.25] Wrong part of underground belt blueprint overlapping allows normal BP placement
-
- Burner Inserter
- Posts: 7
- Joined: Tue Jun 13, 2017 3:50 pm
- Contact:
Re: [16.25] Underground belt exit blueprint overwrites entrance
Can not reproduce, you surely can hover over it with the BP but placing the PB does not change the already existing entity, or am I misunderstanding?
-
- Burner Inserter
- Posts: 7
- Joined: Tue Jun 13, 2017 3:50 pm
- Contact:
Re: [16.25] Underground belt exit blueprint overwrites entrance
Sorry my English was not good.Loewchen wrote:Can not reproduce, you surely can hover over it with the BP but placing the PB does not change the already existing entity, or am I misunderstanding?
>placing the BP does not change the already existing entity
I knew this rule.
In Factorio program, underground belt input and output parts is same entity?
I don't use force pasting mode(Shift key), but can paste on second image place. (Robot install right side input parts only)
I think, this case reject paste is good because underground belt input and output are different function.
Re: [16.25] Underground belt exit blueprint overwrites entrance
I understand now. Underground pipes do not allow non-forced placement if different parts are overlapping, so this is at least inconsistent.metallis666 wrote:In Factorio program, underground belt input and output parts is same entity?
I don't use force pasting mode(Shift key), but can paste on second image place. (Robot install right side input parts only)
I think, this case reject paste is good because underground belt input and output are different function.
Re: [Twinsen][0.16.25] Wrong part of underground belt blueprint overlapping allows normal BP placeme
I still probably do not understand what the issue is.
To your question - the two sides are different entities.
I don't know if this includes what you are describing, but there are intentional inconsistencies between belts and pipes. Pipes are generally more restrictive in what you can do, in order to prevent placement mistakes that can pollute the pipes, which you really do not want.
To your question - the two sides are different entities.
I don't know if this includes what you are describing, but there are intentional inconsistencies between belts and pipes. Pipes are generally more restrictive in what you can do, in order to prevent placement mistakes that can pollute the pipes, which you really do not want.
Re: [Twinsen][0.16.25] Wrong part of underground belt blueprint overlapping allows normal BP placeme
Simply put: Have a blueprint in hand that contains an underground belt, now you hover the entrance of the BP underground belt over a "real" underground belts exit (or vice versa), you can place the blueprint without pressing shift, since the overlapping underground belt is not placeable, one would expect you had to press shift to place the BP. Doing the same with an underground pipe requires pressing shift to place the BP.
Re: [Twinsen][0.16.25] Wrong part of underground belt blueprint overlapping allows normal BP placeme
Not sure what everyone's exact expected behavior is, but it fixed it so if the two underground belts are visually facing the same direction, you can build the blueprint on top, regardless of their internal direction, as the internal direction is usually set automatically after building.
In other words: Fixed that some underground belts would not be correctly marked as ignorable(blue) when building blueprints.
Fixed in Version: 0.16.29.
In other words: Fixed that some underground belts would not be correctly marked as ignorable(blue) when building blueprints.
Fixed in Version: 0.16.29.
Re: [Twinsen][0.16.25] Wrong part of underground belt blueprint overlapping allows normal BP placeme
I thougth the problem was that the blueprint part was blue, where it souldn't be...