Allow multiple item requests of the same item in player logistics requests

[BenSeidel]

TLDR; Allow the player to have multiple requests of the same item in their logistics requests, summing together all of the selected values for the logistics network.

At the moment it's an error to select two of the same item types in the player logistics requests screen (center panel)

Center panel.png (1.06 MiB) Viewed 3930 times

It would be extremely useful to allow multiple of the same item types to be selected within a grid, with the minimum and maximum values seen by the logistics grid being the sum of all the selections.

Eg, if you have belt selected and have a minimum and maximum value of 50 and 100 then you select it again with min and max values of 500 and 500 then the logistics system should treat it as a single selection of 550 and 600.

Why?
Because there are many scenarios where you want to temporarily ask the network for more than your "usual amount". Eg, train fuel or construction robots.

If instead of having to
1) Locate the existing request
2) edit the amounts
3) Do what you want
4) edit the amounts back to previous values.

you could
1) Request the extra
2) Do what you want
3) Clear the extra requests.

It also helps when you're requesting items to build something. Instead of adding up how much you need for many different items across either different blueprints or different recipes, you could add in each item multiple times, one for each of your source task. Likewise you can clear these items either as you craft or build the recipe/blueprint.

Personally I would absolutely love to be able to put in a bunch of deconstruction planners to extend the row count of the item request panel as I use whitespace to break up various items into groups that are more easily locatable.

[ssilk]

We had this suggestion a long while ago — but into the other direction — didn’t found it… I remember the best argument against it was that it is then very unclear, what’s going on. Think of very long lists where you need to scroll. A player has already problems to keep the overview.

The use-case is ok. But I think we can move this into “not implement”, because of above reason. I will bring it back if there are much better arguments.
Keep in mind: There are better suggestions for such one-time-requests!

[BenSeidel]

The other use case is with spiders. At the moment I'm putting in many zero-zero requesting slots to keep their inventory clean. Eventually I create a base/template spider with ALL the items set to zero then I can copy that to any new spiders, editing in what they should be holding as separate requests. It makes quick edits to my personal spider a bit tedious, but the alternative of trying to empty it manually is worse (especially when you have a team following you).

Granted a "keep the spidertron clear of everything else" tickbox would also achieve the same thing (eg, the auto-trash mod), but this is an alternate implementation that offers a bit more of a use case as it can be used in a couple of ways.

[Kyralessa]

The other use case is with spiders. At the moment I'm putting in many zero-zero requesting slots to keep their inventory clean. Eventually I create a base/template spider with ALL the items set to zero then I can copy that to any new spiders, editing in what they should be holding as separate requests. It makes quick edits to my personal spider a bit tedious, but the alternative of trying to empty it manually is worse (especially when you have a team following you).

Granted a "keep the spidertron clear of everything else" tickbox would also achieve the same thing (eg, the auto-trash mod), but this is an alternate implementation that offers a bit more of a use case as it can be used in a couple of ways.

This seems like a completely different request, but I like it. There's already an * everything item with circuit conditions. Imagine if, when used in logistics requests, it meant "everything else" and indicated that no more that X "other items" besides the explicit requests were allowed in inventory. X could be 0, of course, meaning to trash everything not explicitly requested, or it could be a higher number, say 500, so that after more than 500 items not explicitly requested are in inventory, the extras are sent to trash.

Of course, each request also has a lower bound, and I'm not sure what that would mean in this case. It seems like only the upper bound would be meaningful.

This could also be simply done with a checkbox instead, though: [ ] Trash all non-requested items.

[BenSeidel]

This seems like a completely different request

Yeah, it is; with an existing mod that solves the problem. Hence I left it out of the original post. But after Ssilk's post I thought I would put forward another use case.

[ssilk]

I still think it would create more problems to have two items of the same type in the personal/spider logistic, than it solves. Just to prove it, there are some threads about finding items in it:

viewtopic.php?f=6&t=90902 Findling personal logistic requests via filter GUI / Flash Logistic Request slot when already exists
viewtopic.php?f=6&t=96352 Three Personal Logistics improvements - save/restore, move, and highlighting

And I found the thread I was looking for with the same suggestion:
viewtopic.php?f=66&t=7692 Multiple occurrences in requester chests
I will not merge it together, it’s too old, but you see the feedback at that time is also negative and one reason, why it was removed to be possible to add two equal items into personal request slots.

Which points out the biggest problem with this suggestion. Other reason is, that it makes eventually sense to add two items and they add together. But I have no idea what should happen with three or four equal item-types. There is really no use-case for that. And the UI becomes illogical: you can add two equal item-types, but not three or more.

A much better idea is to implement the auto-trash mod into vanilla. Something which allows you to semi-automatically change requests.And/or temporary slots:

viewtopic.php?p=558327#p558327 trash unrequested items with auto-trash mod
viewtopic.php?f=6&t=15274 Temporary Logistic Slots

Another idea is to implement this
viewtopic.php?f=6&t=39474 Roboports should output missing materials to circuit network / Roboports emit signals with missing blueprint items
Which is my personal favorite, because it enables you to automate things much, much more.

[BenSeidel]

Just to prove it, there are some threads about finding items in it

God yes, I would agree with this whole-heartedly. Sometimes it's impossible to find the existing item request. But the problem already exists. Additionally, any solution that would solve the already present issue would also solve the exacerbated problem if you could have more than one item type selected.

Personally, I don't suffer from it as I use whitespace to group similar items together, making it easy for me to find what I'm after (you can see it in my screenshot). Although it's not the thread for it, but I would suggest that keeping it hard to find things creates another challenge for an engineer to overcome. One that any programmer, painter or interior decorator should already have a solution to.

I will not merge it together, it’s too old, but you see the feedback at that time is also negative and one reason, why it was removed to be possible to add two equal items into personal request slots.

Yeah, that's really old. Although I don't get a negative feedback vibe from the whole discussion, only that there are two interpretations of what the behaviour could be (and quite rightly so). I can also see that the original behaviour was one that fell out of an oversight (not specifically designed) and was an unintended consequence of how the code worked internally. It's nice to walk down nostalgia lane sometimes .

A much better idea is to implement the auto-trash mod into vanilla. Something which allows you to semi-automatically change requests.And/or temporary slots:

I disagree. 1 general solution is much better than 3 bespoke solutions in a game all about finding unique solutions to problems. This one suggestion allows a player to create their own way of achieving both of those outcomes, in addition to many more. Eg, temporary requests for the hand-crafting of different items or blueprint quantities without a bunch of mental maths. Or even having a "build mining outpost" set of requests that can be grouped together for easy modification, regardless of if the "build smelting outpost" also contains a belt request.

P.s. I also really wish the auto-trash mod was in vanilla. I don't understand why it's not, so don't take me as me not wanting an "autotrash all" feature in the base game. My only point is about the generality of this suggestion and how it could be used by creative players to solve issues that may not have been raised, not as it being mutually exclusive with other suggestions. But I also really like Kyralessa solution to the problem:

There's already an * everything item with circuit conditions. Imagine if, when used in logistics requests, it meant "everything else" and indicated that no more that X "other items" besides the explicit requests were allowed in inventory

It goes hand-in-hand with the way the circuit network works, making the game seem more cohesive.

Another idea is to implement this
viewtopic.php?f=6&t=39474 Roboports should output missing materials to circuit network / Roboports emit signals with missing blueprint items
Which is my personal favorite, because it enables you to automate things much, much more.

Sorry, I have no idea what this has to do with the original suggestion and I don't want to go off-topic.

[ssilk]

Additionally, any solution that would solve the already present issue would also solve the exacerbated problem if you could have more than one item type selected.

Ahhh. No. The human eye is not good in tracking two changes at once.

Personally, I don't suffer from it as I use whitespace to group similar itemsz

I personally would do many things in Factorio differently.

[BenSeidel]

I personally would do many things in Factorio differently.

Hence I love the game. Seeing peoples solutions to problems is like seeing peoples creations in Minecraft or other sandbox games

Ahhh. No. The human eye is not good in tracking two changes at once.

Sorry, I don't understand your point.

[FuryoftheStars]

If additional identical item requests were all classed as temporary, and thus automatically cleared once fulfilled, that could solve the issue.

[ssilk]

Personally, I don't suffer from it as I use whitespace to group similar items together

I personally would do many things in Factorio differently.

Hence I love the game. Seeing peoples solutions to problems is like seeing peoples creations in Minecraft or other sandbox games

Sorry, I was a bit tired, when I wrote that, so there is a hidden sarcasm in it. What I meant was that your personal solution works for you, but you cannot argue, that it is a solution for everyone.

Ahhh. No. The human eye is not good in tracking two changes at once.

Sorry, I don't understand your point.

We are talking about highlighted items, which are highlighted because you hover it somewhere else or searched for it. I mean when you search for an item in a group of dozens items, and you highlight it to see it, your eye will immediately see it. It’s a reflex. You don’t need to think about it, the eye focuses to the highlighted item within some milliseconds.
If you do that with two items (not very near together), your eye recognizes the highlighted changes, but can focus only to one and it takes for hat more time, because it’s not longer a reflex, your brain needs to select, which of the highlighted item it should look to. It takes significantly more time for that.

So, no, highlighting two (or more) items in a group of many is not the same as highlighting one.

If additional identical item requests were all classed as temporary, and thus automatically cleared once fulfilled, that could solve the issue.

An extra “space” for that… Yes, that would be a good solution. It would make the focus problem clear, explains itself, because it can be researched and many more advantages.

But that’s a new suggestion.

[BenSeidel]

What I meant was that your personal solution works for you, but you cannot argue, that it is a solution for everyone

That's not what I'm trying to do. I simply stated that it's not a problem for me as I have a solution. I never intended to say that my solution is a solution for everyone, only that there exists a solution as a way to show that it's not something that is bad enough to outright prevent a system such as this from being adopted into the base game.

So, no, highlighting two (or more) items in a group of many is not the same as highlighting one.

Still not understanding your point. I think what your saying is that people are too stupid to understand that 2 items may be highlighted at once? I don't get why having to think a bit more than with a single item would be so detrimental to the game. It already exists in many areas of the game already: There can be multiple flashing map notification icons, running with you inventory not automatically sorted also creates many flashing icons, none of which make it hard for me to figure out what's going on.

I would also put the argument forward that the extra mental strain caused by having the user move their eyes around a bit is far, far less than trying to do some of the mental arithmetic required to request the appropriate amount of items for more than one blueprint or recipe. Additionally, as it's possible to have the request far enough down that it's hidden and has to be scrolled to, I think that the user already has to have some idea of what and where they would be looking for such an item and that the millisecond reaction time doesn't play much of a role.

I believe you are incorrectly using the results of a research paper on the use of highlighting UI elements and the appropriate way to do it. In the paper it put forward the argument that highlighting lots of items, eg a "find text" in a word processor is bad if all the highlighted items look the same. Instead one item should initially blink to draw the users attention to what should be the "first in the list". Otherwise there is wasted time where the user has to find that first item themselves (the delay I believe you are talking about). This eventually evolved into the idea of a "next" and "previous" and a different colour for the current position in the result set, but I digress. Anyway, it's a really old paper (circa 1970) and I have no idea where to find it or what it's title was or even if I'm remembering it correctly at all.

From what I gather from previous posts your issues are as follows
1) It would allow people to make a bigger mess of their item request list, but only when the feature is used.
3) It makes finding things in a spot that is already hard to find things harder, but only when the feature is used.
2) There exist other suggestions that are less flexible but hand a solution to the player on a silver platter, none of which are prevented by this suggestion.

And yes, I agree with those points. But I also feel that the flexibility and creativity that is enabled by this feature mean that it's a small price to pay.

An issue that hasn't been raised is that maybe someone uses the feature without realising they were using it. eg, they clear a request yet they still get the items delivered to them. I could see many a bug report with this scenario happening, but I think that it would be possible to create a UI experience to show that there are multiple requests, eg by showing a total below the min/max slider. This would prompt most people to question why there is a "total" section that differs from their current selection. It wouldn't stop everyone, but it would stop most.

Likewise it's also a feature that could be enabled in the user or game settings, like how the item categories or the research queue can be enabled or disabled. Hell, even if they allowed a mod to enable it that would be awesome. But as it stands the only way I can figure out how to implement this is to create an entirely new logistics request UI that modifies the characters requests indirectly.

If additional identical item requests were all classed as temporary, and thus automatically cleared once fulfilled, that could solve the issue.

Yeah it might, but it might cause more issues than it solves (and I think it's the same issues that plagues the other temporary requests suggestions)
The biggest issue I can see is when the original request is for 500/500 (min, max), and you add in another request for 100/100, then as soon as the extra 100 was delivered and automatically cleared, the 500/500 request is the only one left. This then causes the extra 100 you just requested to be auto-trashed as it's above the max limit of 500.

One solution is to require some user intervention to say that the temporary request is now not required anymore. This could be something as simple as putting some of the items into a trash slot (or clearing the duplicate request hint hint).
It could also modify the original request's maximum, but that leaves a permanent modification after something that was supposed to be temporary. You could put a restriction on the temporary items that the max must be big enough (eg, inf.).
And it could always keep track of the user actions - eg hand crafting or putting items into a chest and decrement the values accordingly, maybe in a fist set, first decremented style?