Difficult to add modules to machines with recipes having the same modules as ingredient

[SWeini]

At the moment it's really cumbersome to add modules when these are ingredients at the same time.

In vanilla, this issue only applies to the speed/efficiency modules, which might not be a big issue, but some mods (PyAlienLife for example) use modules as ingredients on a regular basis.

So if I start with an empty assembling machine (or a lot of them) like this

2023-02-17 07_04_45-Factorio 1.1.76.png (429.14 KiB) Viewed 2842 times

there isn't really a way to insert 4 speed-1 modules without opening each assembling machine individually.

Status quo:
- Taking a stack from my inventory and Ctrl-clicking the assembling machine inserts all 50 modules as ingredients, the second time inserts another 44 modules as ingredients and only the third time inserts 4 modules as modules
- Opening an assembling machine and Shift-clicking on a stack of modules in my inventory follows the same pattern
- Dropping single item (using Y key per default) follows the same pattern

Things I could do as workaround:
- Open each assembling machine by hand, take a stack of modules and click on all 4 module slots. That's very tedious.
- Remove all assembling machines, build 1 by hand, add modules, copy&paste, let construction bots do their job. These behave as I expect them to - insert modules first. But I'd rather like to not start from scratch.
- Ctrl-click & drag over all assembling machines 3 times. In the end this fills all module slots. Unfortunately this requires a lot of modules (98 per machine instead of 4 per machine). And if machines are working while dragging it's possible that you'd need to drag another time.
- Remove the recipe from all assembling machines, Ctrl-click & drag over all assembling machines, reassign recipes. Tedious, and I end up with a lot of ingredients in my inventory.

I'm not really happy with any workaround. All have drawbacks, in some mods might not even be possible. For example construction bots might be really late in some overhaul mods.

Expected behavior:
Ctrl-clicking, Shift-clicking and dropping single items fill module slots first. So I can take a stack of modules from my inventory and Ctrl-click & drag over all assembling machines once and all module slots are filled.
I do like the current behavior, that a single click does NOT insert into two different inventories at once. So Ctrl-clicking the first time should only fill the module slots. Ctrl-clicking a second time with full module slots should insert as much of the stack as possible as ingredients.

Related topics:
The insert method currently works using the same (IMHO wrong) priority of inventories. It should fill into module slots first.
Some mods rely on this method, e.g. Nanobots where I have opened a bug as well. The Nanobots mod especially ideally would not rely on the insert method at all and instead replicate the construction bot behavior as best as possible. Maybe you could share the priority of those, so that mod authors can replicate it.

It's really difficult to upgrade said recipe from assembling-machine-2 to assembling-machine-3. If I start with AM2 having 2 module slots and want to upgrade to AM3 having 4 module slots I can use an upgrade planner to upgrade the machine, but not to add modules. After upgrading I'm stuck with this bug and can't easily insert the last 2 modules. I even can't use construction bots because I can't copy&paste an AM3 with 4 modules over the AM3 with 2 modules. Unfortunately there is a real need for mods like Module Inserter. I expect that the described copy&paste adds an item request proxy with the missing 2 modules to the existing machines.

[Xoriun]

Kind of sounds more like a suggestion and not a bug.

Also, I sounds like a really bad idea to insert modules into the module slots of assemblers AT ALL.
There would then be modules in assemblers which are not supposed to have any.
The worst case could be that you blueprint assemblers with module type A in them but the recipe need module type B. Now it becomes a race between bots and inserters which basically rely on the randomness of which entities are placed first. So you could mess up ratios, consume way more power for a lack of efficiency modules or waste resources for a lack of prod modules. And that might happen every time to place a blueprint. On the contrary, how many times do you change modules for existing assemblers?
Yes, this is a worst case, but for me it's enough of an argument against it.

[boskid]

I am not considering this to be a bug. Its always possible to insert modules when assembler has other or no recipe set, when modules are already inserted to one machine its possible to make a copy with a blueprint and let construction robots do the rest. Moving to ideas and suggestions.

[SWeini]

The worst case could be that you blueprint assemblers with module type A in them but the recipe need module type B. Now it becomes a race between bots and inserters which basically rely on the randomness of which entities are placed first. So you could mess up ratios, consume way more power for a lack of efficiency modules or waste resources for a lack of prod modules. And that might happen every time to place a blueprint.

I can't follow your logic. I don't want to change the behavior of blueprints, bots or inserters, only of manual interaction with existing entities. So when you place a blueprint and let construction bots do the work nothing will change.

[SWeini]

I am not considering this to be a bug. Its always possible to insert modules when assembler has other or no recipe set, when modules are already inserted to one machine its possible to make a copy with a blueprint and let construction robots do the rest. Moving to ideas and suggestions.

Thanks for your response. I can understand your decision to not see this as a bug, everything works as intended. Nevertheless a bad user interface is a kind of bug in my opinion.

I also agree with you that using constructions robots is the intended workaround. Unfortunately this workaround has a bunch of negative side effects, which I will highlight here. Perhaps this will make you reevaluate the situation.

1. Some overhaul mods move construction robots to 50+ hours. To rely on construction robots for solving a bad user interface is not reliable.
2. Making a blueprint and let construction bots do the rest is not possible when the entities are already built and just need the modules now. Pasting an assembling machine with modules over an assembling machine without modules does not add the modules as item request proxies. You'd need to deconstruct everything first.
3. Deconstructing everything first can be time-consuming. As you might know, construction bots with their limited cargo capacity do a very bad job in emptying inventory of entities when deconstructing them.
4. Clearing the recipe, inserting modules manually, reassigning the recipe is also not great. This will move all the items already in the machines to places where you don't want them (logistic chests on the other side of your base, or your inventory which is always too small).
5. Some mods (PyAlienLife again) have recipes with item loops, that you ideally prime with enough items for 2 crafts. If you clear the recipe or deconstruct to rebuild with bots you have to redo the priming which is also a time-consuming task.

In my initial bug description I tried to keep it to vanilla, because it also happens in vanilla. But the annoyance can be a LOT higher in some mods. Buildings are bigger. Required building count is higher. Bots not available yet. High number of module slots you need to insert manually. High amount of items in machines before deconstructing them. Is this an issue with the mod? Perhaps. But the root issue is the bad UI when it comes to inserting modules into machines when it conflicts with the recipe. (And the issue that you can't copy&paste modules on top of existing machines.)

[Xoriun]

The worst case could be that you blueprint assemblers with module type A in them but the recipe need module type B. Now it becomes a race between bots and inserters which basically rely on the randomness of which entities are placed first. So you could mess up ratios, consume way more power for a lack of efficiency modules or waste resources for a lack of prod modules. And that might happen every time to place a blueprint.

I can't follow your logic. I don't want to change the behavior of blueprints, bots or inserters, only of manual interaction with existing entities. So when you place a blueprint and let construction bots do the work nothing will change.

Take level 3 assemblers which produce rcus and are filled with prod3s.
When copying the whole production (and maybe even being low on prod3s), some of the speed modules might arrive on the belt/chest earlier than the prod3s are delivered by bots. By your proposed change, the inserters would now insert those speed modules into the free modules slots in the assemblers and only after that fill the ingredience slots. When the bots arrive with the requested prod3s and see that the module slots are already filled by the speed modules, they will just turn back.
You are now left with assemblers that have a unpredictable amount of speed modules and prod3s in their module slots.

[FuryoftheStars]

Expected behavior:
Ctrl-clicking, Shift-clicking and dropping single items fill module slots first. So I can take a stack of modules from my inventory and Ctrl-click & drag over all assembling machines once and all module slots are filled.
I do like the current behavior, that a single click does NOT insert into two different inventories at once. So Ctrl-clicking the first time should only fill the module slots. Ctrl-clicking a second time with full module slots should insert as much of the stack as possible as ingredients.

Related topics:
The insert method currently works using the same (IMHO wrong) priority of inventories. It should fill into module slots first.
Some mods rely on this method, e.g. Nanobots where I have opened a bug as well. The Nanobots mod especially ideally would not rely on the insert method at all and instead replicate the construction bot behavior as best as possible. Maybe you could share the priority of those, so that mod authors can replicate it.

This idea runs under the assumption that you always want modules put into the available module slots, which isn't always true.

And as Xoriun mentioned, this also creates a situation where placing a new assembler with a recipe that takes (for example) speed modules but you wanted production modules in its slots creates a race situation where you need to fill in the module slots by hand or robot before the inserters feeding ingredients fill them up with the speed modules. Then you're having to deal with correcting that by hand instead.

The only change I could really get behind in allowing the player or inserter to fill these first if the recipe happens to accept the same ingredients is if the assembler was blueprinted with modules in the slots and the blueprinted modules match what is being inserted exactly. Otherwise, it should be left as is.

[SWeini]

I can only repeat: I DO NOT want to change the behavior of inserters. Inserters currently to not insert into module slots of assembling machines and I'd like to keep it this way. I'm talking about grabbing a stack of modules from your inventory and Ctrl-click-dragging them over a bunch of assembling machines.

You're right though: RCUs might be an example where even then the player might want to put ingredients first. But normally the modules are already filled with prod modules. In case there is an item request proxy requesting prod modules this could prevent the module slots from being filled with speed modules. Also players often rely either on bots or on manual actions, rarely on a mix of those.

[FuryoftheStars]

I can only repeat: I DO NOT want to change the behavior of inserters. Inserters currently to not insert into module slots of assembling machines and I'd like to keep it this way. I'm talking about grabbing a stack of modules from your inventory and Ctrl-click-dragging them over a bunch of assembling machines.

Sorry, that wasn't explicitly clear in the original post.

That said, I'm still not behind it (as proposed). You're simply changing the logic from assuming the player wants to fill recipe input first to assuming the player wants to fill module slots first. Neither assumption is strictly true. If the module slots had requests on them for that exact module, then fine, I'm good with that. Anything else, though, and you're having to assume intention and you're never going to get it right.

You're right though: RCUs might be an example where even then the player might want to put ingredients first. But normally the modules are already filled with prod modules. Also players often rely either on bots or on manual actions, rarely on a mix of those.

You're making assumptions on the way other people play with no data to back it up. As it happens, I'm one that all of your assumptions so far do not apply to. Aside from that, you still need to consider that the game needs to work through all stages of play, not just late stage where you're simply plopping down more blueprints to expand the factory even further.

[otakushowboat]

I believe the root issue here is that the action for manually putting items into a building's recipe slots and the action for manually adding modules to a machine's module slots are the same keybinding. This would be fine if their mechanics never overlapped. Sadly, they do in the case presented by the OP.

This circumstance has shown that sharing the same keybinding for these two actions isn't a great idea. In my own experience, I have never, ever, in thousands of hours playing this game, intended for a ctrl + click action on a building when holding modules to add them to anything other than a building's module slots. And yet I can understand the default behavior being what it is, prioritizing the ingredient input over module insertion.

My suggestion is to split these actions into two separate keybindings. Two discrete manual actions should absolutely have two discrete keybindings, or at least the ability to change one or the other. So that everyone isn't forced to learn a new keybind for adding modules, I also suggest that the defaults for these actions be made the same for both. In this way, those who want to avoid this behavior may do so if they wish by changing the keybindings.

[SWeini]

If the module slots had requests on them for that exact module, then fine, I'm good with that.

If it were possible to add module slot requests when upgrading I wouldn't have the issue in the first place. Maybe the root cause is exactly this. I'm not able to upgrade assembling machines and let bots fill the additional module slots.

You're making assumptions on the way other people play with no data to back it up. As it happens, I'm one that all of your assumptions so far do not apply to.

Sorry if that was the case. Nevertheless, please tell me which of my assumptions were wrong. I'll repeat them here explicitly because you'd need to read between the lines of the rest of my posts.

A) Players use prod modules for RCUs instead of speed modules.
B) Players who hand-feed their RCUs with speed modules while having empty module slots actually want to insert them as modules.
C) Players who use construction bots to build RCUs with production modules do not hand-feed ingredients to them.
D) Players who hand-feed their speed module 2s with speed modules 1s while having empty module slots actually want to insert them as modules.
E) Players learn to automate insertion of ingredients by using inserters very early. When they hand-feed modules they intend to do what they can't automate that easily - inserting them as modules.
F) Something else I didn't even notice was just an assumption.

Aside from that, you still need to consider that the game needs to work through all stages of play, not just late stage where you're simply plopping down more blueprints to expand the factory even further.

Late game would be easy. I'd have decent construction bots with speed and cargo capacity upgrades and final builds and just need to copy&paste builds. That is something I don't have an issue with - and my suggestion wouldn't change that. I try to improve the stage before bots or the stage when you're still upgrading buildings, and you need to get your own hands dirty.

I kind of understand where you're coming from and maybe there are scenarios where the user really intends to hand-feed modules as ingredients into a machine that could have these as real modules and the user still doesn't want them as modules. However, given the circumstance that Factorio is all about automation I'd expect a manual interaction with a machine to favor something that basic automation can't do over something that basic automation could do for me. And I believe, whatever scenario you would give me, I could show you a good way to solve it efficiently, even with my proposed changes. However I dare you, upgrade a running build of 30 AM2 with 2 speed module 1s building speed modules 2s into AM3 with 4 speed module 1s. Maybe there is an easy way I'm just too dumb to see.

[FuryoftheStars]

My suggestion is to split these actions into two separate keybindings. Two discrete manual actions should absolutely have two discrete keybindings, or at least the ability to change one or the other. So that everyone isn't forced to learn a new keybind for adding modules, I also suggest that the defaults for these actions be made the same for both. In this way, those who want to avoid this behavior may do so if they wish by changing the keybindings.

I could support this, too, though that is also starting to get to be a bit of a long list.

If the module slots had requests on them for that exact module, then fine, I'm good with that.

If it would be possible to add module slot requests when upgrading I wouldn't have the issue in the first place. Maybe the root cause is exactly this. I'm not able to upgrade assembling machines and let bots fill the additional module slots.

Sounds like a great suggestion: mark-for-upgrading when blueprinting over fast-replaceable entities
If that can be pushed through (which I believe would be a good improvement for the game on its own right) and it was made so that this also applied to modules and ctrl+clicking a module onto a machine filled any module requests of the same type first, that would be ideal.

You're making assumptions on the way other people play with no data to back it up. As it happens, I'm one that all of your assumptions so far do not apply to.

Sorry if that was the case. Nevertheless, please tell me which of my assumptions were wrong. I'll repeat them here explicitly because you'd need to read between the lines of the rest of my posts.
[snip]

No need to read between anything:

But normally the modules are already filled [...]

Some players, like myself, may rarely (if ever) use modules in their machines. As such, they'll normally not have anything in them. Even with players that regularly use modules (or the situations where folks like me would use them), this still doesn't apply to newly constructed or upgraded assemblers. But ultimately, what does this situation even matter to the conversation? If they're already filled, then they're already filled. It's the cases where they're not already filled that we're wanting to focus on, here.

Also players often rely either on bots or on manual actions, rarely on a mix of those.

I very regularly mix it in many different scenarios. As one example that's more relevant to this topic, while the bots are still assembling a new factory, I'll sometimes start preloading some of them, either as a way to get rid of some extra resources that I haven't had a chance to offload elsewhere, or because I know it's going to be a while before any other resources come around for them to start assembling and so I want them to at least start on some things while waiting (maybe I need some of the products now?).

However I dare you, upgrade a running build of 30 AM2 with 2 speed module 1s building speed modules 2s into AM3 with 4 speed module 1s. Maybe there is an easy way I'm just too dumb to see.

Well, you're unfortunately in a situation made tedious by a mod author doing something without considering the consequences of said action. In most cases, this wouldn't even come up as most things where this could be an issue outside of mods don't need to be manufactured on that scale. Can it be made better by the devs affecting a change? Yes, absolutely, and I would support a change even if it could only ever have an affect in modded play. We're just disagreeing on said change.