Short delay when changing logistic request numbers

[Maoman]

There should be a short one or two second delay between when you change the number for a logistics or auto trash slot and when that number is actually sent to the logistic network (or applied to your inventory, for auto trash slots). This would go a long way toward preventing people from accidentally requesting too much of an item or all of an item in your inventory being dumped into logistic trash slots when you edit a logistics rule.

(I know of the "request 1 item instead of stack" option, but that only helps when you initially create a request. It does nothing to help when editing an existing request or when creating and/or editing an auto trash slot.)

This isn't very easily expressed via screenshots, so here are two example scenarios, one for request slots, and one for trash slots:

If you request some iron, drag the slider to 200, then accidentally go too far and it hits 300 for just a second before you slide back down to 200, currently the request for 300 is applied instantly and the bots will bring you 300 iron. If it waits a second or two and only sends the bots a request once you've stopped on a number, you would instead get 200 iron like you actually wanted.

If you have an auto trash slot for iron currently set to 500 and you change it by manually typing in 100, you have to type "1" first. Currently, that "1" is applied instantly, even if you continue typing "100," so all but 1 iron immediately goes into your trash slots. Then you have to manually put the iron back in your inventory if you're outside of the logistics network, or your bots come out and take the iron out of your trash slots and you need a matching logistic request for 100 iron to have the robots put it back in your inventory instead of just taking it all away. If it waits a second or two for you to finish typing "100" and only applies the rule to your inventory once the number stops changing, all this is prevented.

(You may also want to consider a similar sort of delay when initially creating an auto trash slot, so it only sends all of that item to trash if you leave it at the default zero for a couple seconds, and you have a chance to raise the number a bit if you want to keep a stack or two of the item.)

[bobingabout]

I agree that this is a bit frustrating. when I was actively playing, I used to do that all the time.

[steinio]

Ok i read your wall of text and agree surprisingly.
How about saving the request only after closing the player inventory so changes take no effect during changing numbers.

[Ghoulish]

Totally agree, we've all requested more than we intended at some point. steinio's solution is pretty solid imho.l

[eradicator]

+1

Also going the extra step to only apply changes on explicit player action (closing menu, pressing "apply", etc) would make it even better.

[Koub]

Actually, this is a part of a wider issue that existed before. When the default logistic request became 1 stack (from 1 item) this became a common suggestion: a delay (or even better : an explicit validation) for any kind of modification to logistic request, but the devs chose to add an option "set logistic request stack size 1 instead of stack size" instead, half solving half the problem. This is one of the rare suboptimal decisions I can account on the dev team. I hope an explicit validation ("that's exactly what I want") will come and replace this wobbly feature. I can be either an OK button, or simply wait for the player to close the current menu (even better).

[Jap2.0]

Yeah, I think waiting for the player to close their inventory (or possibly something like 10 seconds of logistic setting inactivity) would help with this a great deal.

[bobingabout]

but the devs chose to add an option "set logistic request stack size 1 instead of stack size" instead, half solving half the problem.

I believe this is because the game is pretty hard wired for changes to take effect immediately, and to change the behaviour would have required more work than they were willing to do mid-version when the request originally came in.

Since we're currently between versions (0.17 in the works), this is the best time to ask again, and it may be considered.

honestly, this is one of those QoL things, and would make a large difference to anyone trying to set up logistic requests. Not just on the player, but chests too.

[eradicator]

or simply wait for the player to close the current menu (even better).

Btw, while it certainly would be an improvement over the current situation i still think this is bad gui design. Factorio GUIs are closed by pressing esc/e, and not a usual "ok/apply" button like in e.g. windows. In most applications pressing esc would throw away any pending changes and restore the original values. So applying something when closing the window is completely intransparent to users who don't already know that this is happening.

Imho both solutions (timer + on_close) require some sort of text display to make the user aware of the situation, so they might just as well be combined. A (configurable) timer and on_close could display something like: "Changes will be applied in [27] seconds or when you close this window." where the [number] constantly ticks down. It might be feasible to hide the text as a tooltip on a number-only countdown to preserv factorios "guis don't have text" style.

[Maoman]

Btw, while it certainly would be an improvement over the current situation i still think this is bad gui design. Factorio GUIs are closed by pressing esc/e, and not a usual "ok/apply" button like in e.g. windows. In most applications pressing esc would throw away any pending changes and restore the original values. So applying something when closing the window is completely intransparent to users who don't already know that this is happening.

Imho both solutions (timer + on_close) require some sort of text display to make the user aware of the situation, so they might just as well be combined. A (configurable) timer and on_close could display something like: "Changes will be applied in [27] seconds or when you close this window." where the [number] constantly ticks down. It might be feasible to hide the text as a tooltip on a number-only countdown to preserv factorios "guis don't have text" style.

I was thinking a little "3... 2... 1... Applied" could appear near the bottom of the logistics slots or something, then the "Applied" will slowly fade away like text in the console/chat does (or to maintain "guis don't have text," a green check mark or something instead of the word applied).

[bobingabout]

Btw, while it certainly would be an improvement over the current situation i still think this is bad gui design. Factorio GUIs are closed by pressing esc/e, and not a usual "ok/apply" button like in e.g. windows. In most applications pressing esc would throw away any pending changes and restore the original values. So applying something when closing the window is completely intransparent to users who don't already know that this is happening.

Imho both solutions (timer + on_close) require some sort of text display to make the user aware of the situation, so they might just as well be combined. A (configurable) timer and on_close could display something like: "Changes will be applied in [27] seconds or when you close this window." where the [number] constantly ticks down. It might be feasible to hide the text as a tooltip on a number-only countdown to preserv factorios "guis don't have text" style.

I was thinking a little "3... 2... 1... Applied" could appear near the bottom of the logistics slots or something, then the "Applied" will slowly fade away like text in the console/chat does (or to maintain "guis don't have text," a green check mark or something instead of the word applied).

That might be a little fancy.