Player Request Confirmation Not Needed

[KatherineOfSky]

When I am requesting items from the logistics system through the player interface, it feels so natural to change the number and then hit Escape... and then I realize that a confirmation button needs to be hit, (or Enter), because my changes are lost.

Because a player spends a lot of time adjusting sliders, it's clearly a deliberate action. I feel that the extra confirmation step is definitely not needed and is just extra clicks/keypresses.

I suggest removing the confirmation necessity and allowing Escape to save.

[Koub]

I respectfully disagree. There needs to be a "On second though, I don't want this" and a "Please proceed".
In other words, <Enter> to proceed, <escape> to cancel. That's the way I'd expect it to work, and so it does.

[jamiechi1]

I agree with Koub on this one. Standard procedure in most well behaved programs is to press 'ESC' to cancel. I would actually prefer an 'Apply' button but the current way works fine.

[Koub]

I agree with Koub on this one. Standard procedure in most well behaved programs is to press 'ESC' to cancel. I would actually prefer an 'Apply' button but the current way works fine.

Actually, there IS an apply button (lower right, the green one).

[jamiechi1]

What I meant was a button that had the letters 'Apply' or 'Apply Now' printed on it.
But the Arrow button works. I guess I can get used to it.

[Koub]

Actually, it's a "Check" icon :

2020-08-09 08_10_10-Factorio 0.18.45.jpg (6.27 KiB) Viewed 5333 times

[posila]

I think ESC should cancel the change, and E should confirm it. Enter is just too far, so I am closing dialogs with E and on the second try I click the green checkmark with mouse.

[Koub]

I almost always use the numpad when I request something, the default value rarely being how many I want. And the NumPad Enter key is so conveniently placed for that I would be shocked if it didn't work.
And for the rare cases where the default request is exactly what I want, The numpad enter key is once again the go-to solution, as it's in right thumb range (without even leaving the mouse).

[KatherineOfSky]

I think ESC should cancel the change, and E should confirm it. Enter is just too far, so I am closing dialogs with E and on the second try I click the green checkmark with mouse.

E would be an OK compromise. Enter is too far when using the sliders with the mouse. I do sometimes type the numbers in and use the Numpad like Koub, so having both would be nice.


I think he reason I feel that Esc would be good in this situation is that we aren't actually making a mountain of changes... we are just changing, at max, two values. I don't feel that that is something that's disastrous to revert the changes on, (e.g. Esc to cancel changes).

To give some perspective: as I have been playing the game recently, loading up an end-game save, I needed to change the values on some 70 different requested items, mostly sliding the sliders on the max downward from infinity. I went through 15 or so before I realized they weren't saving as I Escaped out of each dialogue. I love the Esc button to quickly navigate menus, etc. and it just feels natural to set it and be done.

Assemblers and other machines work that way. There is no confirmation on setting a recipe. You Esc out of that particular UI to get back to building.

[ssilk]

I prefer also using the numpad. If I have one. But as things are, I play most times on laptop, where I miss the numpad. So “E” would be a good second input key, instead of enter.

When the game would give visual/acoustic feedback for “apply” and “cancel” I would be really satisfied.

[Yokmp]

I tend to agree with KoS.
A confirmation is unnecessary because we are used to close windows with E / ESC and also keep the changes.
Although i see/understand the reason for a confirmation button, it feels "not in line" with the rest of the game.

If one accidentially orders eg. 2000 Pipes instead of 200, deleting the request or even deactivating the logistics to solve the mistake is imo an easier thing to do then clicking the button over and over again. Especially the first time one gets the logistic delivery system up and running setting up all the things can take some time. [SideNote: There is a Mod which lets you save/load your Requests as a template]

Changing reciepes, editing Trains and so on. None of these act like this window. The only one i currently can think of is the combinator setting widget which has a different confirm button but works the same IF the user sets a number instead of a signal (which btw is also a bit weird).

[wobbycarly]

I think ESC should cancel the change, and E should confirm it. Enter is just too far, so I am closing dialogs with E and on the second try I click the green checkmark with mouse.

This!

[SkiCarver]

Put me down for Esc = cancel - E = accept.

i am forever closing the GUI and my selection disappears!

[nbird]

I support this change as well.

With one hand on WASD and the other on the mouse reaching ENTER is really slow and I have to move one of my hand off.
Also the checkmark is quit tiny and if you miss it, you have to start again.

[jodokus31]

Same problem with entering a request in a requester chest or a value in a constant combinator.
I type in the number and have to press 2 times Enter to get the value saved.
Often, I press E and notice afterwards, that the value was not applied.

So I vote for E to apply value

EDIT: entering a value in a constant combinator only needs one time Enter

[Theikkru]

+1 for E to apply. The way I see it, as most consistently used in-game, E should only manipulate windows (open/close) without affecting anything inside them (e.g. you can grab an item from inventory and E to close without it disappearing from cursor). Esc is already widely recognized to have "exit and revert changes" behavior.

[Squelch]

However this might be addressed, I sincerely request that the same behaviour is also consistently applied across the whole UI.

It is nice that filters are not immediately applied while changing values, and we need to apply/accept the new value before leaving. This behaviour is now universal.

Escape to cancel, and E to accept as keyboard shortcuts is also my preferred universal solution. This would essentially mean a double tap of E to apply on the first press and then close the UI if desired.

[yugatha]

The way I see it, as most consistently used in-game, E should only manipulate windows (open/close) without affecting anything inside them

This might be controversial, but you've come so close to realising you're arguing the other point. 'E' currently, in every scenario, manipulates without affecting anything within them. The numbers you choose within the slider options *don't* take effect until you accept them. 'E', following suite, should not then apply these changes as it would be affecting the options / windows without an explicit "a-ok" from the player, especially if you accidentally set the number too high / low and all your stuff gets trashed / inventory fills up with 1,000's of unwanted items.

[Theikkru]

[...] The numbers you choose within the slider options *don't* take effect until you accept them. 'E', following suite, should not then apply these changes as it would be affecting the options / windows without an explicit "a-ok" from the player[...]

Except that's not what "not affect the window contents" means. If you grab something out of your inventory and press E, the item stays on your cursor; it doesn't jump off the cursor back to its spot in the inventory just because nothing had been done with that item yet. By the same token, the sliders you set in the window should stay right where you left them when you pressed E, and not jump back to wherever they were when you opened the window. That the numbers don't take effect until the window closes is an internal game mechanic separate from the GUI control exerted by E, much like dumping an item from your cursor into a container after you close the inventory window is a game mechanic separate from the closing of inventory that E does. The fact that said separate game mechanic so happens to be triggered by the GUI closing is incidental, and shouldn't affect how the control itself behaves.

[NotRexButCaesar]

I think ESC should cancel the change, and E should confirm it. Enter is just too far, so I am closing dialogs with E and on the second try I click the green checkmark with mouse.

Or make it configurable, so that each person can change the "confirm"/green button key to whatever they like.