Factorio Forums

Steps to reproduce:
1. Import provided blueprint into Factorio:
Copy blueprint
2. Inspect the blueprint (before pasting!),
note that both undergrounds at the top point upwards.
3. Paste the blueprint -> the unpaired underground exit changes into an (unpaired) entrance
4. Fix the underground by rotating it.
5. Copy and paste the fixed setup -> it stays fixed
6. Copy and paste the newly pasted setup -> the same underground reverses again


Blueprint that works for pasting:
Copy blueprint
Note that copying or blueprinting setups pasted by this blueprint will result in the broken blueprint again.

Extra notes:
I haven't found any difference between copying and blueprinting either setups, so I use the terms interchangeably here.

Does it always happen:
It always happens, with the limitations mentioned above.

What I expected:
I expected the state of the entities to remain the same after copying, pasting, and blueprinting.

Theories:
A possible cause could be that the functions encoding and decoding a blueprint are not or no longer functional inverses (in a way that matters).

I tried to trim the blueprint down into something smaller that still behaves the same. I got the following blueprint that changes when pasted:
Copy blueprint
This is the "fixed" blueprint:
Copy blueprint
Copying it after pasting, and copying that after pasting, each time placing them directly underneath each other, makes the second-generation copy break.

Pasting them going eastwards with more space between them requires more generations of copy-pasting (4-7) before the unpaired underground exit changes into an underground entrance (not sure what the minimum space for breaking is, but it's more than 2 empty tiles).

The behavior depends on close the blueprints are pasted together, but since the underground belts can't and don't link up, this shouldn't be the case.

So the problem here is that this upper underground gets flipped? That sounds like duplicate of 56695

Not precisely, I think the main problem is that of the two blueprint pairs posted, one of each pair always works, while the other never works, and that it is possible to transform the working versions into a non-working version by repeated pasting and copying.

Here I define working as:
a) the blueprint preview matches the blueprinted entities, and
b) the ghosts match the blueprint preview, and
c) the built entites match the ghosts.

In this case the broken blueprints break case b, and not case a. Case c was not broken by "instant blueprint building" in sandbox mode for either of the first two blueprints, but I haven't check them with robots or in "survival" mode.

56695 seems like it breaks case c, when built by robots at least. And your screenshot here seems like it breaks case b.

And to be clear, in light of that bug report being "won't fix", I would like you to fix this inconsistency in a way that all the blueprints provided here work, or that the broken ones can't be created anymore without JSON-editing (in vanilla at least).

Well, the problem here is basically a build order: when blueprint is placed, entities are not placed all at once but they are placed one at a time, and in some orderings the outer undergrounds will pair up and adjust their direction and in other orderings they wont connect due to other entity in between being there already and a direction will be preserved. There are some ugly heuristics that could be applied (trying to first build undergrounds that were paired up in the blueprint, then building the undergrounds that are left alone) but they would risk having a weird corner cases (possibly about interaction of undergrounds in the blueprint vs undergrounds existing on the surface; deciding about proper order since paired undergrounds can also influence each other if they are close enough in-line and build order is unfavorable). There could be an additional step applied after a blueprint is placed to reapply underground type so it matches what was placed, but that risks making modders angry because they will often react to entity build events and adjust entities not expecting them to get affected again later. Best solution would be if all undergrounds were added as they are without connecting and then making them all connect, but that causes a lot of problems with consistency if mods would start interacting with partially setup entities where a mod could see intermediate state with 2 undergrounds both being output and connected to each other.

Its not that there is an intentional code that makes this behavior appear, it is a consequence of build order. Given that blueprints preserve positions of the entities a blueprint was made from there may be some effects of which blueprints are "good" or "bad", but most likely the issue will arise just from the order of entities in the blueprint as they usually are going to be built from first to last and when blueprint is created the order of entities being collected is quite complex to describe.

Thanks for explaining. Is it a simple solution/improvement to change the collection order for blueprint-making so that unpaired undergrounds come after all paired undergrounds in the blueprint? (Or before, if the ghosts are placed in the reverse order.)

Of course I don't know how hard this would be to implement.

I don't see any answer to this that won't have bigger issues. The engine is simply not setup to deal with the scenario you're giving it. The simple answer is: you just can't do that and expect it to work.

Sad, but thanks for considering it.
I have found a workaround that seems to work: super-force-build the blueprint on top of the ghosts after placing it once.