Factorio Forums

I created a blueprint for just an underground belt, max distance, so I could tile it across the landscape and build a long, mostly underground, conveyor belt.

When the underground belt ends are dropped by the bots, they are frequently in the wrong orientation. I suspect that what happens is that whichever end is dropped first becomes the 'input', and the second end then becomes the output. This is partly because the wrong orientation I was seeing was frequently facing away from my base.

At first I thought I'd made a mistake in belt placement, so I had bots pick it all up, then I tried again paying careful attention. Nope, I still frequently got reverse belts.

Another idea is that maybe belts take their cue as to direction from the orientation of the belts around them, and so when I tile a whole bunch end-to-end across the landscape, that messes things up. That would explain why long stretches seemed to end up with the wrong orientation.

Here's the blueprint string for my belt:

There's something weird with your blueprint - both endpoints are marked as 'input'. When I create fresh blueprint of same type - it has proper input/output marking on endpoints and this (correct) behavior survives reexporting via string. So solution to your problem would be recreating this blueprint. As for how this happened in the first place - do you remember when (which version), and under which circumstances you created that blueprint?

For example - could it be that you had blueprint of 4 underground belts and then deleted 2 intermediate ones via blueprint editor?

I created the blueprint from ghosts in 0.15.31 (I'm pretty sure, I remember Steam telling me it had downloaded and updated Factorio and going to the forum and reading about it before I did that). It could've been 0.15.30.

I'm betting it's the fact that I created it from a ghost that did it. That also explains why a similar blueprint I made of a level 2 underground belt never seemed to have that problem.

I didn't edit the blueprint at all after I created it, other than giving it a name. No right clicking to remove stuff though.

I still couldn't replicate this even with ghosts.. with slight exception - when you have normal already-built input belt, and shift-click to put output belt that would connect to it - that shift-clicked output ghosts becomes an input. so when you create a blueprint out of that partially built contraption with completely-built input belt and ghost "output" belt which actually became input during ghosting - you get what you have here.

Ahh, that's probably what I did then. In fact, that is exactly what I did. The display that shows you whether or not the belt is connected does not show up when you're shift-clicking unless one of the ends has already been dropped. And I wanted to make sure it was the max length, so I wanted to move the ghosted end until the display disappeared, then move one back.

What a weird, very specific case.

I was building (and blueprinting) from space fairly far from my base so it was taking ~30 seconds for the robot to show up to drop things when I shift-clicked.. When I made the red one, I was actually present and so could create the belt I wanted to blueprint directly from my inventory.

A glimpse into sacred 0.16 changelog:

- Placing output underground belt as ghost properly retains its type as output underground belt. Also underground belts
now respect nearby ghosts and become output if there is input ghost nearby. Underground belt and pipe ghosts when
hovered show outline of where they will connect (51271)

So now it is possible to create underground sequences with shift-clicking.

Thank you! You fixed the outright bug, and fixed the annoyances that led to the behavior that triggered it in the first place! I'm looking forward to 0.16 just for the performance belt performance upgrade you guys wrote up in your blog.

I have one more bug to post, about a UI glitch that I assume only affects high-DPI displays. But, I haven't yet collected the requisite screenshots yet.

Hi,

I'm not quite sure if this is the right place (and I surely don't want to hijack this post) but I think there is another bug concerning undergrounds and ghosts.
If you place an underground belt and place a ghost image of the same type in between the input and output, the underground belt stops working. It seems the game recognizes the ghost as actual recipient and stops providing items to the real output. I added a screenshot for better understanding. If this has been reported before, please excuse this post and just ignore it.

Silversen wrote:Hi,

I'm not quite sure if this is the right place (and I surely don't want to hijack this post) but I think there is another bug concerning undergrounds and ghosts.
If you place an underground belt and place a ghost image of the same type in between the input and output, the underground belt stops working. It seems the game recognizes the ghost as actual recipient and stops providing items to the real output. I added a screenshot for better understanding. If this has been reported before, please excuse this post and just ignore it.

I think this is intentional - and what would this even break?

A few versions back, pipes (an I now assume underground belts, as well) were changed so that they would connect to ghosts so if you had a setup as following where O = empty tile, X = underground pipe, and Y = pipe it would work corr3ectly.

XOXYOYXOX
OOOYOYOOO

Previously, if the outside underground pipes were built and the insides were not, the outside pipes would connect, potentially mixing liquids in your pipes. There could also be other places it could help, but this was just the example that came to mind.

Hmm, yeah, you're probably right. Shouldn't really break anything (happened to me, when I misplaced a BP by 1 Tile). Just found it odd. I thought ghosts would maybe logically "exist" on a different layer and shouldn't interfere with actual items. But I have to say your example makes sense from a "connection available and pluggable" point of view for ghosts.

It was implemented for belts not so long ago and then for pipes. Mostly to prevent mixing of items or fluids when construction bots place underground pieces in random order and for some time they stay connected in unintentional manner.