[Twinsen][for 0.16][0.15.31]Reopening: Bug with blue prints and circuit network

[gexxo]

After having had the problem again multiple times, I would like to reopen discussion on my bug viewtopic.php?f=47&t=51191, which was closed as a duplicate of a bug, which was closed as "Not a bug" by a moderator.

As none of the two threads has any comment from a dev, I would like to reopen this bug to get a second opinion from a dev whether this is really considered "not a bug", because for me it really is one of the most annoying things lately.

For a full description of the bug, check the thread I linked.

Here is the reason why I honestly think this is a bug:
My understanding of blueprints was, that given I can place them without having to hold shift (i.e., nothing obstructs the placement), I can be sure to get exactly what was in the blueprint. When using the blueprint to upgrade an old factory part to a new one (e.g., by adding circuit network stuff), if it works without Shift (which it does on my blueprints!), then the process will work and I can be sure to correctly have upgraded my factory part to match the contents of the blue print.

But with the bug, this is not the case! I upgrade a part of the factory by using the blue print without the shift key, and afterwards everything is screwed up, because the entities do not have the circuit settings that were stored in the blue print. I have a blueprint where like 40-50 circuit connections are added, and it takes me 10 minutes to fix them all one by one afterwards. The blueprint is therefore completely useless to upgrade an existing factory. This has gone so far, that my latest strategy is to completely bulldoze the factory part and then apply the blue print on the empty ground to be sure to get a valid result. I don't think this how blue prints were meant to be.

If you really consider this not a bug, then maybe you should at least disable placing such blueprints over old factory parts without holding shift and displaying the entities which would not have their circuit network conditions updated in red. Then at least the user would have feedback that applying this blue print will not go smoothly. So I think either it should be fixed or the UI must be changed to reflect what is going on. Right now, it is very confusing and leads to screwed up parts of the factory that have to be fixed manually.

[BenSeidel]

It's an issue (aka "current behaviour") with all the entities when placing blueprints: the settings of the already built entities are not changed because the blueprint has been placed.

Try it with an inserter. Make a blueprint with an inserter (optionally attached to a circuit network) with any configurations and place it over an existing inserter. None of the settings from the blueprint are transferred to existing item.
In your case I would suggest you use the deconstruction planner to pick up all your belt then your blueprint can be safely placed without any collisions occurring.

[gexxo]

It's an issue (aka "current behaviour") with all the entities when placing blueprints: the settings of the already built entities are not changed because the blueprint has been placed.

But has the current behavior any use? Would there ever be a case where a player wants to paste circuit connections over a factory wihout pasting their settings?
Circuit connections are totally worthless without their settings. You build them to satisfy one specific purpose and this purpose is usually not satisfyable without the settings.
And in the case I describe, there was even no circuit connection before, so a player could not have even set other settings before. Thus, one also cannot argue that this is intentional since the player might have want to keep the old settings (from a player perspective, there were none before!).

[BenSeidel]

But has the current behavior any use?

You raised it as a bug report, not as a feature request/suggestion, therefore I am only arguing that the behaviour as implemented is correct according to the other aspects of the game.
If you want to put forward your opinion that the current behaviour is poor for gameplay or other mechanics are better then it needs to be raised the appropriate sub-forum.

Also, the mechanic applies to ALL entity settings, not just the wired network. All settings from the wireless network as well as any entity specific settings such as assembler/chem factory/refinery current recipe, requester chest request, chest size reductions, inserter stack size, filtered stack inserter filters, etc are all saved in the blueprint but is not overwritten when pasting.

[gexxo]

But has the current behavior any use?

You raised it as a bug report, not as a feature request/suggestion, therefore I am only arguing that the behaviour as implemented is correct according to the other aspects of the game.
If you want to put forward your opinion that the current behaviour is poor for gameplay or other mechanics are better then it needs to be raised the appropriate sub-forum.

Also, the mechanic applies to ALL entity settings, not just the wired network. All settings from the wireless network as well as any entity specific settings such as assembler/chem factory/refinery current recipe, requester chest request, chest size reductions, inserter stack size, filtered stack inserter filters, etc are all saved in the blueprint but is not overwritten when pasting.

The line between a bug and a feature is thin here. If a behaviour makes no sense to any player, it is doubtable whether it can be considered just a missing feature.
Otherwise, you could treat everything that does not lead to a game crash a feature request.
For example, you could also consider trains not deadlocking in a roundabout as a feature, yet it is treated as a bug.

And even if keeping the settings of old entities is the current desired behaviour, then shouldn't a blue print at least require shift key to be pasted on top of an entity with different settings? As mentioned above, I though that the idea behind shift/no-shift was that if I can place a blueprint without shift, this guarantees me that it is placed thoroughly.

Yet however, I don't want to argue with you. It is your view on this topic, I have a different one and this is fine. I just want to hear the opinion of a dev on this topic. If they agree with you, I will be satisfied.

[Twinsen]

It looks like an oversight from us. Placing an entity on top should copy the settings.

Bug or no bug, I assigned this to myself before someone makes this report disappear

I will look into it but it will be for 0.16. Meanwhile let me know if anyone prefers the current behavior(not changing any settings of the existing entity).

[gexxo]

Thanks a lot . Having it for 0.16 is fine.

[BenSeidel]

I would not say that I prefer the current behaviour as a "paste over existing entities" would have made my life so far much, much, much (times infinity) easier. But I have relied on it in the past. It's extremely useful for creating chainable systems where the output of one combinator is used as the input for the next section and each blueprint "section" has a couple of items from the previous section so that you know it is lined up correct.

Also, if you allow blueprints to overwrite the current settings then you eliminate two scenarios that I feel "add" (because it's an outcome that you don't want to happen") to the game.
1) You don't have any construction roboport coverage so you can't remotely change settings
you have to run down to the area in question to change the settings because you can't deconstruct & reconstruct the setup (or affected areas)
2) You forgot to set a limit on the chests and now each chest in your 150 smelter strong setup has 4800 iron plate.
you have to run down and manually set the chest limits, otherwise the logistics robots will spend eternity deconstructing them so you can remotely construct them again.

Most other scenarios won't be changed too much, in my case anyway, as I tend to have logistics robot coverage over most of my base and the things I change only take 2 seconds to deconstruct and reconstruct to get the new settings. Also, with the new filtered deconstruction planner it makes it even easier.

Anyway, my point is that the current system requires you to either approach the problem with brute force OR surgically (usually in person) as well as keeping the blueprints tightly coupled with the logistics network (you MUST have logistics robots to use it in any way except as a "base planner").

Personally though, I don't care. Both would create gameplay that I would find enjoyable.

Some other thoughts
Mods like recursive blueprints where you can place a blueprint automatically would essentially create the "circuit controlled assembly machine recipe" thing that has been asked for quite a bit, and that would be cool.
If you change the recipe of an assembly machine, and the inserter has an item in it's hand, then you will deadlock your system until you pick up the inserter and put it down again.

[beiju]

I've had the same experience as both gexxo and BenSeidel. I've noticed that I only ever expected the blueprint to add circuit network settings if the entity didn't already have them. I think that would satisfy both use cases.

This post made me think about how blueprints and circuit networks currently work vs. how I think they should work. I posted my suggestion here so as not to derail this thread.

[DerGraue]

I would prefer it if the settings from the new blueprint would be applied to already placed entities.

Had this problem just yesterday when I placed a blueprint that included a station that reads train contents. The station was already placed by hand. After I built it I was wondering why my setup didn't work...

[quyxkh]

As a workaround until this is fixed, can you whitelist inserters and belts and maybe power in a decon planner, then rip up and re-lay just those? Probably best to dump inventory to a temp chest first so you can hold the belts...

[Xeteth]

It looks like an oversight from us. Placing an entity on top should copy the settings.

Bug or no bug, I assigned this to myself before someone makes this report disappear

I will look into it but it will be for 0.16. Meanwhile let me know if anyone prefers the current behavior(not changing any settings of the existing entity).

This would be a very welcome change, thank you! There is another issue regarding requester chests that is very closely related to this, might it be possible to take a look at also? I made a thread about it here - viewtopic.php?f=48&t=37061&p=223880#p223880

[Twinsen]

Fixed in 0.16.

When building blueprints, any already existing building of the same entity type will have their settings updated instead of showing red.
Circuit network settings will be also updated.

[Speadge]

Fixed in 0.16.

When building blueprints, any already existing building of the same entity type will have their settings updated instead of showing red.
Circuit network settings will be also updated.

does this also work for any other levels of the same entity?
i.e. having assembler2 in BP replacing assempler 1?