Requ. chests/PowerArmor should default to zero or one

[GlassDeviant]

See page 3: The topic title has been changed a bit -- ßilk

Summary

When you add an item to the logistics section of a requester chest, the value should default to zero or one. This would allow you to set your limit before a swarm of logistic robots descended upon the requester chest laden with possibly unwanted goods, when there may be a better use for those bots elsewhere in the network at the time.

Option

For people who aren't interested in this idea, the option to use this or the existing default could be added to the game settings dialog.

Explanation/example

One thing I've noticed that can be a real pain when you want to limit the number of items being delivered to a requester chest is that there are some very high defaults for certain items. So for example, if I am supplying labs, I may want to limit the requester chest for each lab or set of labs to say 10 of each red, green, cyan and purple science pack. The default is currently 200, so the instant I select the object to be delivered the logistics robots are carrying as many of that item as they can find, up to 200, so by the time I can set a limit there are already up to 200 on the way and I end up with far more than I ever wanted. This is useful at end-game when you run out of things to research, or when you want to limit the resources being consumed by assembling machines making science packs.

[FishSandwich]

I completely agree. But a dev already said no to this: https://forums.factorio.com/forum/vie ... =11&t=7997

There's a mod that does it however I can't find it right now.

Edit: Found it https://forums.factorio.com/forum/vie ... =14&t=8207

[GlassDeviant]

Ah, serves me right for doing a search for my other ideas then immediately forgetting to search for this one.

Thanks, Fish.

Unfortunate that the devs would summarily discard an idea that makes so much sense (even more so after reading the thread you linked), the whole idea of having logistics in process control is to prevent the exact thing that defaulting to 1 stack causes: too many resources being consumed too quickly.

[ofca]

So what's exactly wrong with "apply" and "are you sure you want to discard the changes you've made?" when attempting to close a window with unapplied changes? Microsoft figured it out years ago

The problem itself did bother me to some degree, too

Some way for drones to pick up excess amounts from requester chests wouldn't be bad either.

[ssilk]

I suggest that changes should take 2-10 seconds (configurable?) to get announced, as long you are in the screen, doing nothing. Until you close, then they're applied immediately.

[ofca]

yes, that would work too, and less clicking.

[bobingabout]

Doesn't it already default to 1? I think the only time it doesn't default to 1 is if you had something else in that slot, in which case the value remains as it was for the old item.

[FishSandwich]

Doesn't it already default to 1? I think the only time it doesn't default to 1 is if you had something else in that slot, in which case the value remains as it was for the old item.

No, this behaviour was changed a long time ago(see link I posted)

[GlassDeviant]

Perhaps I should put up a poll and let the whole userbase decide. If a majority want one method, would the devs pay attention or just casually discard the idea once again? I mean, if your customers want something, do you ignore it? That's why EverQuest lasted a long time (some people will take any amount of abuse) but never became remotely as big as WoW.

[ssilk]

Well, I think they pay attention for it, but what exactly will you ask?

Will you discuss this here? I think it's better to create a poll like together, cause then we can say it's the work of the community, not a single action (like many other polls).

[Koub]

Well ... both debate and poll are important and complementary.
I feel debate is vital to have different perspectives, to see how others see things. And poll, at the end, is good to see what people who have debated think after all. Some people will change their minds during the debate, some won't. The poll is there to see the result.

[ssilk]

I agree. <lazy mode> What possibilities do we currently have?

Edit: I thought a bit and I formulate it so:


I part the suggestion in now/quickfix and longterm.

Now
Values are commited to the network when you
- close the GUI
- when you are inside the GUI after a (configurable) timeout. This timeout has also a visible feedback, so that you see, that it is not immediately commited.
- optional: when you use some GUI-element (click a button or else...)

With this it doesn't matter, which the default is, case you have time enough to correct it.

Long term
The number you request depends of the category you're currently thinking. The game cannot know that. What if you tell the game that?

Add buttons below the slider:
O 1 | O 12 | O Stacks | O Wagons | O Chests

The meaning is simple: "1" is the current meaning. "12" is the number multiplied with 12 (I found that often a useful number for requests, 10 or 20 is also useful). The first two are fixed numbers, the next depend on the stack-size of the item: "Stacks" are the number of stacks of this items. "Wagons" is 30 stacks (new with v0.11.18). "Chests" is 48 stacks.

Default for the slider-number is "1" and for the unit it is "Stacks". The resulting number of items is also shown in the number-input field, where you can change it.

Example of usage:
- In my personal logistic slots I request very often 2 stack of iron plates.
- 24, 36, 48, 60,... 96 are good request value for intermediate products.
- For green circuits I want to pre-produce 20 chests full.
- Stop digging iron ore, if we have more than 10 wagons full.

This means also, that the scale of the slider don't needs to be so fine. It makes no sense for the "1"-scale to have it up to 20,000, it's more useful only up to 100.

[Koub]

Well I see these :

1) With immediate order :

• Leave things as-is (as soon as you choose an item in requester, a full stack of that item is immediatly ordered, except for some items the devs agree shouldn't be ordered by stack).
• Revert back to previous behaviour : selecting a new item to be requested only orders 1 (or 0) of that item by default. Exact wanted quantity can be set after.

2) With delayed order :

- Add a delay of xx seconds before the item chosen is ordered to the logistic network, plus :

• Leave things as-is (as soon as you choose an item in requester, a full stack of that item is immediatly ordered, except for some items the devs agree shouldn't be ordered by stack).
• Revert back to previous behaviour : selecting a new item to be requested only orders 1 (or 0) of that item by default. Exact wanted quantity can be set after.

- Order only is sent when interface (of the requester chest / logistic belt slots) is closed , plus :

• Leave things as-is (as soon as you choose an item in requester, a full stack of that item is immediatly ordered, except for some items the devs agree shouldn't be ordered by stack).
• Revert back to previous behaviour : selecting a new item to be requested only orders 1 (or 0) of that item by default. Exact wanted quantity can be set after.

- A button/set of buttons is added to manually send the order once the wanted item and quantity are set, plus :

• Leave things as-is (as soon as you choose an item in requester, a full stack of that item is immediatly ordered, except for some items the devs agree shouldn't be ordered by stack).
• Revert back to previous behaviour : selecting a new item to be requested only orders 1 (or 0) of that item by default. Exact wanted quantity can be set after.

If my propositions are not clear for people as they are clear for me (and my inner voices XD) in my head :

immediate order = as soon as you choose an item, the robots start flying to your storage to deliver
delayed order = there is some time between the moment you choose an item, and the moment the robots start flying

leave things as-is = default order is 1 stack, can be changed manually after initial selection (with eventual exceptions depending on dev's choice)
revert back to previous = default order is 0 or 1 item, can be changed manually after initial selection.

There is also the possibility to add an option that allows to choose between some or all of these different behaviours (but in my opinion, it would maybe be too much work for the benefits : as long as the default behaviour suits the most people, the unhappy minority can use mods to adapt the game to their needs).

[Edit] : rearrange lists, can't get nested lists to work

[ssilk]

I want to mention this thread: https://forums.factorio.com/forum/vie ... =16&t=9241 which is also about this.

[ssilk]

Userstory: Fix a problem with requesting a full slot of items when choosing item type.
Prerequisites: complete, but there are more than two possible solutions.
Game-value: The last change annoyed many players. Sometimes it really doesn't make sense to select so much.
Developer-costs: depends on chosen implementation.
User-opinions: Not all players have problems.

[Youri]

With such a division in opinion, and several alternatives brought up, I must say I was surprised when I didn't see the solution that I thought had potential. And while I'm at it, I'm going to give a quick run-down of the pros and cons for each of the proposed alternatives. Quick note; I've seen posts about both requester chests and the personal requester logistics panel regarding the default amount, a solution should probably be a solution to both of these at once. Below solutions may have to be slightly tweaked for one or the other in order to fully work.

First off a summary of the proposed solutions to the problem:

• Default to 0 / 1
  Pros: Should not ever give people too many, since when requesting you're always going to want at least one.
  Cons: For kovarex' and other users' most common requester use case, this means they would have to enter a number manually (and remember the stack size if they want a stack).
• Default to full stack (ie behavior at time of writing)
  Pros: Solves above cons and makes use case of setting a full stack as request as easy and simple as can be.
  Cons: When less than a full stack is required, not only requires a manual number adjustment, but usually also manual adjustments to the logistics system to 'fix' the excess of materials that were already on the way (though one can argue that this is a behavior that should be fixed by making the robots and logistics chests themselves smarter).
• Preset default values depending on item type
  Pros: Has the ability to combine the best of both above worlds by setting a full stack for some, and a small number (or even 1 or 0) for others.
  Cons: Can be a hassle and adds a whole slew of (initially) seemingly random numbers to the game which again must be memorised to make full use of the feature, plus there can be only one preset and there will still remain many people who at least don't agree with some of the numbers (you don't want to make a setting for each item's default request amount, ever).
• Add a timeout after selecting the request item to allow for possible number changes
  Pros: Has potential to solve the current problems when wanting to request less than a full stack.
  Cons: Adds unnecessary extra wait time for full stack requests, plus you must be fast to change the number if you want to, or you're just going to have the same problem again (except now you won't always immediately know if you are having a problem with too large requests, or not).
• Add a confirmation before the request is sent
  Can be done in several ways, for instance adding a confirm button or only requesting upon closing the interface. In essence, this is an improved version of the timeout solution since a user can basically manually determine the timeout before the request is executed by delaying their confirmation.
  Pros: Adds little effort to the full stack requests (a single button press), whilst completely solving the issues for non-full stack requests.
  Cons: When the confirmation is not an interface element, this can be confusing and unclear to new players, yet having an interface element like a button will make the interface more crowded (and there's a lot going on already).

And now for some suggestions of my own:

Remember and use previously entered amounts
I seem to remember a time when the requested amount for items would be somehow remembered and used in future requests of the same item. It felt nice, but at times it seemed annoying or simply not working, and I never paid enough attention to figure out the exact workings. Still, I think this method could prove useful if implemented perfectly. The current situation can remain, with the one change that your requested amount is stored whenever you make a request. The next time you're requesting the same item, this amount is used instead of the full stack (but obviously this can also be the exact size of a full stack).
I feel like this sort of lowers and divides the annoyance of over-requesting over the entire userbase. For items mostly requested in stacks, this would work fine until you're going to want less than that full stack, at which point it over-requests once. Similarly for items generally requested in various lower amounts, if you want 50 one time, and 40 another time later on, you'll get a slightl over-request.
It's not the undisputed solution by any means, but I feel like this can do a decent job at minimizing the frequency of over-requests. Heck, you're even likely to learn to make less typos in the input field so as to prevent the over-requesting.


Improved confirmation
While I do think the earlier idea of adding a type of confirmation to the request, I think this can be improved in some areas. Instead of having a single key binding for confirming the request, you can have *any*. Here's how it could work:

1. Upon selecting an item for request, the default stack size for this item is entered (but not requested yet).
2. The mouse focus is automatically moved onto this input field, and its entire value will be selected by default.
3. Press *any* key to send the full stack request, or press a number key which replaces this full stack value with whatever you' ve pressed (which immediately starts sending the request aswell), and the number can be adjusted accordingly.

The main benefit here, next to the pros already listed under 'confirmation', is that the system will be slightly faster for non-full stack requests. This is both due to the request being started (and adjusted) every key press, as well as not having to press a confirmation key after finishing the number.
There are some downsides however:

• As mentioned already, if the confirmation is not an interface element (key press obviously is not), this may confuse newer users and adds a key binding to remember. Besides the obvious alternative of adding a button, a small textual hint or tooltip that tells you what you should do could be a better option. These would then only be visible when relevant (ie when focus is on the input field). Additionally, other confirmation triggers can be added to ease the process further. For instance, you can add the idea of sending the request upon closing the interface, or even send the request when the input field loses focus. Extra triggers like these mean that even full stack requests won't need an extra confirmation key press. That'd mean that full stack requests remain unchanged, but non-full stack requests are improved!
• Another potential issue is that this adjustment will only work when adjusting the number upwards. For instance, when needing 250 of an item, you press '2' -> 2 are requested, '5' -> 23 more are requested for 25 total, '0' -> 225 more are requested for 250 total. But if you've entered this already and decide to change it to 200, or you make a typo whilst entering the number, you may end up with the same over-requesting problem as currently.

Despite some downsides (which do have several fixes themselves), I personally still feel like this is way more manageable than the current situation, especially since there are zero drawbacks for full-stack requests (not a Win-Win, but perhaps a.. Win-Tie?).


In summary

• Setting the default number to 0 or 1, vs setting it to the item's stack size, are pretty much opposite solutions with a large amount of the player base seeming to prefer either of the two, but ultimately they simply shift the problem onto users with a certain playstyle or preference, and do little to help solve the problem.
• Having a custom preset list of default values per item type sort of does the same thing, whilst also adding possible clarity issues.
• A timeout before a request is sent can definitely help reduce the frequency of the current issues, but the slowdown will end up just annoying you at some point, and again the problem isn't entirely solved.
• I can see the idea of remembering previously entered values being very similar to the timeout idea, where it lowers the frequency of problems without actually fixing the cause of the problems.
• A good 'ol Window '95 style popup dialog window to confirm your request is obviously never going to happen, it's the 21st century you know! But the idea of having some form of confirmation is definitely very interesting. And since there are many ways in which this can be implemented, devs can remain very versatile as they implement this, to help make this feature cater to their own design values. Ultimately I do think this is the solution with the most potential, and from what I can tell it's the only one that can be tweaked to have absolutely zero downsides compared to the current system.

Youri

[ClayC]

Since no one added this solution I'm going to, basically all the ideas I've read are somewhat good but not good enough.

My opinion is this, when you click an empty request slot and the item selector comes up, let the user choose a number here and the item aswell. Then when the user chose both you will send the request immediately (still can default to a stack for most like it is).

But then to modify a request leave it as is with a mouse click release and de-focus on the text field in the inventory as triggers for the order.

As complex as it may sound, it's actually the best way to go and if you want to add a bit more, look at what youri posted about remembering the previous request of the item and default that for the user

I feel like this should be the fix to this bug

- Clay

[Gandalf]

Joined -- ssilk

This is a very minor suggestion to fix a major annoyance of mine: When adding a stack to a requester chest's request settings the added stack usually defaults to it's full stack size. It takes about a second to edit that afterwards, but by then there is already a swarm of robots in the air delivering a full stack of whatever potentially expensive item you were going to request, dumping it into the chest. You can then either ignore that because the items may get used anyway, or manually bring them back where they came from.

Suggestion to solve this: Don't start executing requests until the chest's inventory has been closed.
Alternative: Just wait like 2 or 3 seconds.

This also applies to the player's logistics slots.

[Takezu]

Or instead set the default value to one not a full stack.

[Yinan]

Wouldn't be a much simpler solution the ability to turn chests on and off and giving an option somewhere wether the default is "on" or "off"?

Example:
I build a requester chest, that is turned off. Now I set some requests in it. The bots will ignore those request, because the chest is turned off.
Now, I turn the chest on. Immediately, bot will add stuff to the chest based on the requests, like they usually do.

You could even expand that in a way that we could turn it on and off via logic circuits (like with smart inserters that are connected to a chest and can be set to only insert something if the amount filled in it lower or higher or whatever than a specific amount or even a relative amount).


Another Idea would be some kind of changing state.
Meaning that you would have to apply the changes made to the request before they get activated.

Example:
I have a requester chest with one request for iron plates in it. It looks like normal.
Now I add another request for copper plates. This request now has a red background (or something like that) and would be ignored by the bots.
I would now have to press a button called "apply changes" or something like that. The background of the copper request changes to the normal background we have and bots will stark delivering copper plates, like they would usually do.



For both options the actual default amount would be completely irrelevant and could just stay the way it is now but it would prevent any kind of resource drain like it does right now because the requests would only be considered by the bots when you actually want it.