[0.10.x]Blueprins do not copy modules

[erikem]

When blueprinting buildigns and then building them modules are not inserted.

I expect they should be as basically every other aspect is copied including limits, rotation and logic.

All in all blueprints shoudl allow you to copy setup and replicate it with 0 extra efforts.

[ssilk]

Is in my opinion not a bug, cause there are also reasons, not to copy the modules in every case.

Hm. Some examplex: I copy my current furnace-area and I want to automate it so, that when I lack resources, it uses the furnaces with productivity modules in it and otherwise those with efficiency modules. In that case I would need to remove the blueprinted modules after it was constructed first, before I could set new.
Other example: I can change the modules by dependencies of some circuit network logic? Or like in other games: I multiselect all entities of the same type (e. g. ALT+LEFT CLICK) and then I can change the modules for all selected entities.

[hoho]

Just as anyone can make valid reasons for not copying modules people can make similarly valid reasons for copying them
I remember a similar problem with blueprints that they didn't copy automation limit settings for chests and people need to manually set them instead.


I wonder how hard would it be to add options when one places the blueprint to include/exclude stuff like logic wiring, filters, chest settings, modules etc.

[erikem]

I agree that there might be valid reason for not copying them. As well as there could be many otehr aspects.

But agree with me it's strange that action designed to do a carbon-copy misses/omits some stuff? I'd say all stuff like "place without modules" or "place without rules/limits" might be an optional "nice to have" while "exact copy" should be the default behaviour.

[ssilk]

Other view to this: this isn't a bug, cause before this can be "fixed" we need to have introduced, that the bots can place modules in entities. This isn't the case yet.

It's a nice to have. A suggestion.

[erikem]

Good thing about posting a defect, is that you should not really pay attention to the implementatuion details. It's defect and that's it. It might get rejected, postponed, treated as minimal or explained as a feature later though.
In current case if the feature required to fix a defect is not available than the most logical action is to postpone it and move to "known issues' instead of calling it a feature.

[ssilk]

Well, cause there where some other postings, I need to explain, what a bug is (Wikipeadia is in that case not a good help, ok, the German article is quite better):

A bug is, when software doesn't behave as planned. The software does not something, what it should or does something, what it shouldn't.
That the definition, what I've learned. This isn't here the case: It does, what was planned. So, it is not a bug.
A bug here would mean: The assemblies get filled with modules, even, if there are none available. Or assemblies with modules inside cannot be blueprinted.

That's bugs.

In other words: If your definition of a bug would be true, then nothing could be changed, cause nothing can be in a state, where it is not working. Never seen a maintainance-sign on an elevator?

[erikem]

Your definition of a bug is perfectly good for development team which has actual "specification" and knows what is "expected/planned" and what is not. In case of alpha/beta testing we (players) have to do a lot of guessing including the common sense. This is why the expected "reject" ratio of beta/alpha testing reported bugs is much higher than during internal testing by the development QA team.

My personal common sense (expectations of the blueprints feature) says "copy feature copies it all unless explicitly explained ingame which aspects are not copied". When my personal expectation (not desires and wannahaves but rather common sense expectations) are not in line with how the feature behave there's a good chance I will post a bug. Or adjust my expectations in certain cases.

[ssilk]

It's not my definition.. This is the definition of a bug. The reason why I point so strong to it, is, that other definitions don't work. In the 60th-80th of the last century software developers gave their bleed to fix those "bugs" which aren't bugs, but only some discomfort of the department chief.

What I admit, and yes, that is quite correct, is that we as players have in some cases not enough information about that. And if you think about it, there is just no other solution, then that this is a planned issue.
And we have trust. I wouldn't have begun this discussion, if I'm not so quite sure, that this is on the todo-list. It's just a thing of many, which is not working yet with the blueprints.

[erikem]

Then you have an answer! It's a "known issue" and should be categorized as one.

[ssilk]

Yessir!

(I hope this is really as I said )

[atehxx]

I suggest improvement to blueprint GUI which would stop this bug/not bug discussion and also would allow us to make better blueprints!
Basicly, when we select some area for a blueprint (for example part of existing factory) all the entities inside this area are taken into blueprint, and in GUI window shown afterwards where you choose icons etc, there is a list of this items (Totals).
Here's the suggestion:
Make this items clickable (in Total, not on preview ..) - and clicking on item would remove it from blueprint! May it be - all items of same type, to make it easier to implement.
Then you could show the modules from inside the buildings in items list! So if someone wants to make blueprint without modules then he would just remove them before clicking Create Blueprint button.

One more thing missing here is that bots can't put modules into buildings right now... so would need to implement "ghost modules" or something like this But even before it's made (if...) my suggestion seems still useful!