[1.1.2] Disabling "Change quickbar by clicking with item" does not prevent filters from being moved.

[eradicator]

What?

In response to user reaction to the quickbar behavior change of 1.1. @koravex implemented a new interface option (thank you) that's supposed to prevent quickbar filter changes from (accidential) left-clicks, but it's not completely working yet.

I will make an option that locks the quickbar

Description

As i already said here here: If the player currently holds a quickbar-linked item stack and left clicks an empty quickbar slot the filter will be moved to the empty slot.

Aka the left-click-with-stack-on-empty-quickbar-slot behavior depends on whether the cursor-stack was taken from the quickbar or an inventory.

Reproduction

1) Disable "Change quickbar by clicking with item".
2) Left click a filtered quickbar slot.
3) Left click an unfiltered quickbar slot.


Expected Behavior

When "Change quickbar by clicking with item" is disabled the filters should never be moved. The left click'ed slot could have it's filter set (like in pre-1.1) or simply stay empty (more consistent with the option name).

[kovarex]

The option specifically says that it is related to setting filters versus selecting item, it can be argued that it is useful to prefer one action over another.
But in this case, if the other alternative is nothing, it is not really useful to have nothing as an option.

[eradicator]

if the other alternative is nothing

The alternative is not nothing. In pre-1.1 left clicking empty slots sets filters without moving the "origin".

[kovarex]

if the other alternative is nothing

The alternative is not nothing. In pre-1.1 left clicking empty slots sets filters without moving the "origin".

Which was actually inconsistent with every other filter slot in the game, that select the slot in cursor when clicking on it, so it is actually a bugfix.

[eradicator]

Which was actually inconsistent with every other filter slot in the game, that select the slot in cursor when clicking on it, so it is actually a bugfix.

I don't quite understand what you're saying. Would you be so nice an elaborate? As far as i can tell no other filter slot in the game even supports "moving" filters like the quickbar now does, they dont even support left-click filter interactions at all - it's all middle click.

[valneq]

Which was actually inconsistent with every other filter slot in the game, that select the slot in cursor when clicking on it, so it is actually a bugfix.

I don't quite understand what you're saying. Would you be so nice an elaborate? As far as i can tell no other filter slot in the game even supports "moving" filters like the quickbar now does, they dont even support left-click filter interactions at all - it's all middle click.

You can click onto filter slots of filter inserters or splitters with item in hand to set the filters. Also works with logistic requests for character and requester chests.

[eradicator]

Which was actually inconsistent with every other filter slot in the game, that select the slot in cursor when clicking on it, so it is actually a bugfix.

I don't quite understand what you're saying. Would you be so nice an elaborate? As far as i can tell no other filter slot in the game even supports "moving" filters like the quickbar now does, they dont even support left-click filter interactions at all - it's all middle click.

You can click onto filter slots of filter inserters or splitters with item in hand to set the filters. Also works with logistic requests for character and requester chests.

Ok, for the "no left click" statement i only considered filterable inventories (cars, cargo wagons) which obviously don't set filters with left click.

But i don't get what kovarex calls "inconsistent" here - because the behavior you describe with filter guis is not at all what this thread is about. Left-click-with-stack = set-gui-filter is fine. What i'm talking about is the additional removal ("moving") of the "source" filter that was added in 1.1. None of the guis you describe move filters. Maybe you both didn't watch the GIF in the opening post to the end (it's a bit long i admit)?

[eradicator]

For comparison here's what happens when you double-left-click a row of filter slots...

...in the quickbar:

filtermove.avi_gifsicle.gif (282.72 KiB) Viewed 1932 times

...in a filter inserter gui (or a pre-1.1 quickbar, or a post-1.1 quickbar when the stack you're holding is not a quickbar link):

filterset.avi_gifsicle.gif (293.75 KiB) Viewed 1932 times

[valneq]

For comparison here's what happens when you double-left-click a row of filter slots...

Kovarex possibly referenced consistency because initially with 1.1 the quickbar would behave exactly like the filters for filter inserters as you show in your second gif.
But people complained about "messing up their quickbar", so they added an interface setting "Set quickbar filter by clicking with item" which is off by default, and produces the behavior you have in the first gif. Enabling it makes the interactions with filters more consistent in that you always set filters when clicking with item.

[eradicator]

For comparison here's what happens when you double-left-click a row of filter slots...

Kovarex possibly referenced consistency because initially with 1.1 the quickbar would behave exactly like the filters for filter inserters as you show in your second gif.
But people complained about "messing up their quickbar", so they added an interface setting "Set quickbar filter by clicking with item" which is off by default, and produces the behavior you have in the first gif. Enabling it makes the interactions with filters more consistent in that you always set filters when clicking with item.

I'm not sure you completely understand why i made this thread. I can't agree with your interpretation because filter-inserter guis etc, are different from the quickbar in many ways - it's not like you can pick up stacks from them. They are conceptually write-only. The quickbar is much closer to inventory filter slots, showing the item count, etc, being read/write. So making it more "consistent" with something completely different is not an argument i can follow.

But there's no point in us two speculating about what exactly @kovarex meant. So i'll just wait if he answers.