It goes from the active face in both directions at the same time, so there is no bug.

7 6 5 4 3 2 1 0
              0 1 2 3 4 5 6 7
_ _ X X X X _ _ _ X X X X _ _

In T73836#872274, @Yevgeny Makarov (jenkm) wrote:

It goes from the active face in both directions at the same time, so there is no bug.

7 6 5 4 3 2 1 0
              0 1 2 3 4 5 6 7
_ _ X X X X _ _ _ X X X X _ _

so it's Useless for loops and needs to be face selected perfect or cycle through offset and controlled by EYE? This is useless and an unreliable method! what if I wanted to use it for more then 50 faces? Saying there is no bug is not an answer if the tool provided is ify at best!
No wonder why so many users select and deselect each face by eye to begin with!
This tool/script needs to be reliable not frustrating.
At least add an option for us to choose if we want both ways or one way.

@Mobin (Weekend) select loop > deselect one face > checker deselect > re-select one face if needed.

Thanks for the workaround.
Still think this this tool/script needs a bit of attention put to it.

I have to agree with Mobin here - just because it's working based on the current algorithm, doesn't mean it's working as designed. It's designed to deselect by a user specified pattern, and it is not doing that.

The most simple repo case for just how wrong this is:

• Create a default cylinder (32 sides, ngon caps)
• Select all the sides
• Perform checker deselect with a pattern of Deselected: 2, Selected: 2.
• It's really obvious the users expected behaviour here is not what is performed by Checker Deselect.

Please consider re-opening this, as it is indeed a valid bug.

+1 This should be re-opened.
The current behaviour is clearly not correct in accordance to the name of the function and the expected behaviour. It is near impossible to predict what the result will be without knowing the internals of the algorithm; "Checker deselect" by definition is intended to give alternating even distributed pattern of selected and deselected. Even the most simple use case beyond 1x1 does not fit the expected behaviour, as Richard's example above demonstrates.

As this isn't getting any traction, I've created a new report here: https://developer.blender.org/T78138

Issue here is, that this site is bug tracker, so if something is not working as it is supposed to, it is reported here. We could change or improve this behavior, but from available resources I can see that current behavior is correct. https://docs.blender.org/manual/en/latest/modeling/curves/selecting.html#checker-deselect

I personally don't know if by changing this feature, no workflow would be rendered difficult or impossible, so I can't consider if current behavior is appropriate.

Please use other channels for user feedback and feature requests: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

@Richard Antalik (ISS) : Sorry to be so persistent on this, but the current behaviour is absolutely not what is described in the documentation: https://docs.blender.org/manual/en/latest/modeling/meshes/selecting.html#selection-tools

Changes the current selection so that only every Nth elements (vertices, edges or faces, depending on the active selection mode) will remain selected, starting from the active one.

From my repro steps (32 sided default cylinder).
Before:

This is not the behaviour described in the documentation. It just isn't. The documentation does describe the intended behaviour (which is what we want), which is why this is a valid bug.

This tool walks on topology in all directions and deselects every Nth element starting from the active one (just like the tooltip says).
It was originally called "Select Nth". Just the term "checker" gives a better description of the result.
Actually not every Nth, but Nth with Skip. But this "Nth" and "Skip" logic is not intuitive, so it was changed in the UI to the number of "Selected" and "Deselected" elements.

So it works as designed.

Again, what you're describing is the internal details of the algorithm - just because it's doing what the algorithm is expected to, doesn't mean it matches either the documentation nor what users expect. Users don't (and shouldn't have to) know the implementation details.

If you look at the second screenshot, there are *3* deselected faces adjacent at the start (and thus a single deselected face on the far side). Yes the algorithm is walking both directions and deselecting 2 faces including the active face. That is indeed what the algorithm is meant to be doing. But that's not at all what a user wants when they've selected "Deselected: 2, Selected: 2". There are no settings this works for as expected other than "Deselected: 1".

A simple fix would be the pattern starts with deselect in one direction, and when walking the other direction it starts with selecting instead.

What I'm trying to say is that there's no bug in the tool. It's just such a weird tool.
If you think that the documentation or tooltips do not describe it well, then suggest improvements to the documentation, it is easy to fix.

The documentation does not say that the result will be "2 selected, 2 deselected",
it says that the tool will "deselect 2, select 2" starting from the active.

I understand that you might want to see that result:

but this tool is designed to do that:

Moreover, in your simple case with one loop, there's no difficulty to deselect one element (to unclose the loop), and get an even pattern as you want.

@Yevgeny Makarov (jenkm) On behalf of all confused users: Thank you for explaining how to use this tool :).

select loop > deselect one face > checker deselect > re-select one face if needed.