Stop LFG window auto-sort about premade-groups-filter HOT 35 OPEN

Thanks for testing. I have not yet found out why cancelled or declined_full jump to the bottom. Looking at the code, they should not. But I'm confident that we'll find a solution.

from premade-groups-filter.

I do not have this behaviour, also I do not know of anyone else. Does the resorting still happen if you disable all addons? It really sounds like an addon is triggering the resort.

from premade-groups-filter.

Yes, I have disabled every addon and it still happens.

from premade-groups-filter.

Looks like I can no longer reproduce this with all addons disabled, but I can with only PGF enabled.
So now it actually is PGF that's doing the auto sort.

from premade-groups-filter.

And it is not happening if PGF is enabled but the filter window is not open.

from premade-groups-filter.

Tried deleting the filter expression, deleting the sorting expression, big filter window, little filter window, no search string, to no avail.
The only thing that makes the auto resort stop is closing the PGF window.

from premade-groups-filter.

Which version of the addon do you have installed? The 5.6.0-beta or the 5.5.1?

from premade-groups-filter.

Tried both, this behavior was the same. I made the video above with 5.6.0-beta and it was the only addon enabled.

from premade-groups-filter.

I'm asking because the 5.6.0-beta does trigger sorting on event GROUP_ROSTER_UPDATE which might fire too often.

However if the 5.5.1 behaves the same, I am a bit confused. The only thing that triggers sorting is if Blizz is sorting the events itself.

What about other premade group categories like raids, do the also behave the same?

from premade-groups-filter.

Rolled back to 5.5.1 and confirmed it behaves the same.
It is, however, category specific: doing this in Dungeons and Raids - Legacy but not Raids - Dragonflight.

from premade-groups-filter.

Could you type /run PremadeGroupsFilter.EnableDebugLogging() into your chat window? This should print many logs in your chat. It might be a start to debug the issue.

from premade-groups-filter.

This happens when a group state is updated (in this case, delist):

[14:44:59] "" has been delisted.
[14:44:59] 14:44:59 PGF [D] PGF.OnLFGListSearchPanelUpdateResultList
[14:44:59] 14:44:59 PGF [D] PGF.FilterSearchResults
[14:44:59] 14:44:59 PGF [D] PGFDialog:GetFilterExpression
[14:44:59] 14:44:59 PGF [D] MiniPanel:GetFilterExpression
[14:44:59] 14:44:59 PGF [D] Main: exp = ((not aa) and partyfit and (mprating>3000 or riomain>3100 or mpmaprating>370 or rioprev>3400) and not declined and not harddeclined and blfit and druid_dps<1 and (age<6 or (age<10 and members>2))) or (friends>0 and partyfit)

from premade-groups-filter.

Exact same printout when applying to a group, getting declined, canceling a signup or pressing the Search button.

from premade-groups-filter.

Sorry, I just realized that the "Raids - Dragonflight" category was not behaving like this because there I didn't have the PGF window open.
Now it's open and produces the issue there too.

from premade-groups-filter.

That helps.

I checked Blizz Interface code and it looks like Blizzard is now additionally calling LFGListSearchPanel_UpdateResultList on LFG_LIST_APPLICATION_STATUS_UPDATED which causes the list to be filtered and sorted again.

For 99% of players, this is not an issue because they use the almost-stable default sorting expression.

May I ask what your sorting expression looks like?

I will implement a fix tonight (only have a mobile phone right now).

As a workaround, I suggest using a different sorting expression or none at all.

from premade-groups-filter.

My sorting expression is the following: appduration desc, friends desc, mprating desc, agesecs asc

But the same thing happens if I delete the sorting and the filter expressions altogether.

from premade-groups-filter.

Interesting. What if you use just agesecs asc?

I also wonder why nobody else is complaining.

Will have to take a deeper look tonight.

from premade-groups-filter.

That is very weird.
If I use "agesecs asc" it is OK.
But ANY other filter by itself or in any combination, OR no sorting filter at all, triggers the issue.

from premade-groups-filter.

This got me wondering about this maybe having something to do with group age so I removed the age restrictions from the filter expression but it didn't change anything.

from premade-groups-filter.

I think it is like I assumed:

Since 10.2.7, Blizzard is resorting the list on every application update like if someone delists the group you applied to. Before, it was only resorted if you did a new search.

PGF resorts the list right after Blizz to restore your custom sorting.

Now if a group you applied to is delisted, it switches its state from an applied group to a normal group because appduration is set to zero (like for all non-applied groups). Hence, it moves down the list to its previous position.

If you apply to a group, it jumps up because appduration is now greater zero.

I cannot prevent Blizz from sorting the list. The only thing I can do is resort the list back to its old state.

However, this means that sorting by appduration is no longer possible without having jumping entries.

Any filter that does not change the order on an application update is still fine.

This also means that I can't fix the issue.

from premade-groups-filter.

I'm not sure it's because of appduration. I removed that from the sorting expression, tried with "mprating desc, agesecs asc", "friends desc, mprating desc, agesecs asc" and other combos without appduration but when I apply to a group, it always jumps up.

from premade-groups-filter.

I think the solution would be to move the full sort call from OnLFGListSearchPanelUpdateResultList to where the Refresh or Search buttons are pressed.
I tried to remove Main.lua L394: PGF.FilterSearchResults() - it was almost good but then the mprating sort did not happen.

from premade-groups-filter.

With the suggested change, you will get your custom sorting on every search button click, but the list is re-sorted to Blizzards default sorting on every update to an application.

Blizzard resorts the list every time the function LFGListSearchPanel_UpdateResultList is called. That's why I sort the list again which makes items jump depending on the sort order.

I don't fully understand yet why mprating desc, agesecs asc is causing jumps as well. One reason might be that the rating info is loaded with a slight delay, which means that when the first sorting after a search happens, it could not take all the rating info into account, so the second search (triggered through an application update) does change the order again slightly.

I see the following options:

1. Do nothing and live with jumps depending on your sort order.
2. Overwrite Blizzard's global function to prevent them from sorting the list on application updates, but this taints a lot of code and will cause "addon action blocked" errors.

from premade-groups-filter.

Blizzard doesn't resort the list on application update, the jump only happens if PGF is open (they just call LFGListSearchPanel_UpdateResultList which in itself doesn't sort the list, PGF does that via PGF.OnLFGListSearchPanelUpdateResultList).

from premade-groups-filter.

Im pretty sure they do. Have a look at the code, the function UpdateResultList calls SortSearchResults.

The reason you do not see it if PGF is not active is that the initial order is the same as the one after an application update. So no visible changes in the sort order.

from premade-groups-filter.

Interesting, but I get what you mean.
But this just means that if you do what I suggested, there still could be occasional jumps, but only a very few (when blizz sort actually happens which apparently is very rare).

from premade-groups-filter.

I think the solution would be to move the full sort call from OnLFGListSearchPanelUpdateResultList to where the Refresh or Search buttons are pressed.

Not really sure if separating filtering and sorting is possible (because of concurrency and timing) and if it will fix the problem. This suggestion means that the list will switch from PGF to Blizzard sort order as soon as you do an application to a group or an application is updated. In this case I could just give up custom sorting and use Blizzards sorting all the way.

Looking at the video, I think the main problem is that groups that you applied to are moving to the bottom if you're declined or the group is delisted. The easy solution would be to sort delisted/declined groups to the top. In this case they would only jump within the max five applied groups and keep the rest of the list almost stable.

from premade-groups-filter.

I think that would work, yes.

Another thing that comes to mind is slightly change the appduration sort (or introduce another one) that does the following:

• not move group when the application status is changed if possible (not even on apply)
• sort applied groups to the top, regardless of application time, maybe sort by groupID, that would make the applied groups' list stable
• sort (or not move) groups that changed status to the top (any of expired, full, delisted, declined)

Preserving the order of applied groups would be also very important because it often happens that they jump (because of status change) the same moment I want to cancel an application, making me to cancel the wrong one.
If that is only possible by forgoing appduration sort it's fine, much easier to glance at 5 durations that are at the top but not in order than seeing the future and not clicking a button the same time some other group changes status.

from premade-groups-filter.

I'm testing apporder desc and it's a big improvement already.
I guess nothing you can do about jumping on apply, but would it be possible to also preserve canceled apps? Example use case:

1. applied to 4 groups
2. cancel 1
3. click on another group to apply - but the same moment, one of the applied groups changes status and the canceled one jumps to bottom -> now i applied to the wrong group

from premade-groups-filter.

On a second thought, what if you only sorted applied groups to the top if their appduration is more than, say, 10 seconds?
This would prevent jumping on apply and give us 10 seconds to apply to multiple groups at once and then we can hit Search to sort them or wait for something to change so it happens automatically.

from premade-groups-filter.

Also, declined_full still jumps to the bottom for some reason.

from premade-groups-filter.

Just in case I didn't describe it well enough: cancelled does not jump immediately, it jumps upon appstate change (of other groups).
However, declined_full jumps immediately.

from premade-groups-filter.

I tested today with both the standard UI as well as the avanced filters using apporder desc, mprating desc and applications are absolutely stable at the top.

Debug info in title was printed using self.Name:SetText("r:"..self.resultID .. " a:"..select(2, C_LFGList.GetApplicationInfo(self.resultID)).." "..self.Name:GetText()) after line 293 in Main.lua

from premade-groups-filter.

Maybe having partyfit in the filter expression can be the cause of the difference?

from premade-groups-filter.

Canceled always jumps when any other group changes state:

Applied and declined_full always jumps immediately.

from premade-groups-filter.