0004002: Add ability to filter "You are banned" servers from Doomseeker list while leaving all others.

Notes
(0022231) WubTheCaptain (reporter) 2022-05-28 12:29	First, thanks for detailing the issue. I've understood it easily. I'm afraid proposals 1 and 2 may be a step towards feature creep and cluttering the user interface (UI) more (counter-productive for issue 0003984 I've reported), so I'm opposed to this as a feature request unless an agreeable proposal (not described herewithin) can be made to improve the UI in general to support this change. Such changes have not been formerly planned as far as I know, can require extensive changes, and I'm not ready to step up to take this work. Proposal 3 probably doesn't work well in practice for servers the client has been banned from, and it'd be hacky for the UI. If a game server denies a response because the client's IP-address is banned, the server information is not sent to the client so strictly speaking there is nothing to search by "server name" (if I've understood the launcher protocol from Zandronum's wiki correctly). And then there's also possibly legitimate servers which could be affected by this, if they included in their server name the word "banned". It could possibly be done, but in comparison the checkbox boolean approach is way more refined or precise, more favorable. Proposal 4 seems more sensible, but an user would probably want to a way to toggle it, which I see brings up the same concerns as proposals 1 and 2. If I had to pick an option I would like the most, it would be proposal 1 or 4. But so far, I'm also okay keeping the status quo of toggling the "Show only valid servers" when needed. I also considered a possibility of ignoring the "You are banned" denied response from servers and treating the response as valid / accepted with server information, but I've understood this is technically impossible with Zandronum at the moment (unless the upstream changes this behavior in Zandronum, which I've also understood would not apply retroactively to older Zandronum server versions, unless the master server would also enforce excluding old servers). I don't feel opposed to a feature request excluding servers by name, if the UI is not intrusive (such as minus-sign prefixed -"TSPG" syntax to exclude servers with "TSPG" in server name, because this is a commonly accepted/used feature available in many web search engines online today). In fact, I think imo the way to go in the future about advanced filtering of servers in Doomseeker is by text-based syntax, such as -name:TSPG and -response:banned. (PS: I'm keeping this issue as "new" until Zalewa acknowledges it.)

(0022233) WubTheCaptain (reporter) 2022-05-28 12:55 edited on: 2022-05-28 12:56	Another alternative proposal (though I still prefer my text-syntax proposal) is to tweak the "Show only valid servers" checkbox to have three states (if this is possible to hack with the Qt framework): Show valid and invalid servers Show valid servers and servers I've been banned from / Show valid and banned servers Show only valid servers The second option would show as a filled square, instead of a checkmark. Currently it's just a boolean checked / unchecked for 1 and 3.

(0022234) WubTheCaptain (reporter) 2022-05-28 13:25	By the way, those "You have been banned from this server!" servers are no concern with the "Put populated servers on top" checkbox too, because the client doesn't receive the server information and thus doesn't have the data to put them on top. Quote A way to display these servers while removing troublesome "You are banned from this server!" listing(s) would make things more usable and help remove clutter. They get pushed anyway to the bottom of the server list (which can be quite long, especially for Zandronum). I don't see them too intrusive as it is with my network connection. Those bottom of the list servers with "NO RESPONSE" I cannot make use of anyway, even if I refresh them manually. All the useful servers are on top. Quote A typical start procedure is to start Doomseeker, get the servers, then sort by server name, and select all <Refreshed too soon> servers to refresh them and get the full list. My typical sorting is by latency and by populated servers on top, but this makes both of our use scenarios indifferent (I tested both ways of sorting). I don't experience the need to refresh servers manually, but perhaps it is because I don't have multiple Doomseeker refreshers from the same network IP-address. Even with "very aggressive" refresher settings, I have trouble to hit the limit (I experienced it more a few years ago, though nothing changed on my end). I mostly look at the populated servers on top, if I know a server should be there but is not (that's very rarely the case), I do a full refresh for the list of servers. I can understand hitting the rate limitations more with a NAT'd IPv4-address, particularly in LAN parties or when using a mobile data carrier (CGNAT). Perhaps implementing IPv6 support in Doomseeker (0003531) is also a way forward to resolving some of the underlying symptoms for shared networks, in hopes that more network providers will also adopt IPv6 (or transitional methods such as 6rd, which is still a pain in the rear to configure automatically from DHCP options due to lack of widespread software support, unless a consumer household router has implemented that functionality with all the caveats of shit security and questionable software updates that drive at least advanced users to not use those devices).

(0022235) WubTheCaptain (reporter) 2022-05-28 13:37 edited on: 2022-05-28 13:38	People often want to treat the symptoms they're experiencing. I wish to cure the root causes, so that there are no sick behaviors or symptoms of sickness.

(0022236) WubTheCaptain (reporter) 2022-05-28 13:40	The root causes I've understood in this issue are: Shared IPv4 networking (implied) Badly foundational and inflexible search / filtering system

(0022237) WubTheCaptain (reporter) 2022-05-28 13:59 edited on: 2022-05-28 14:06	Also proposal 3 for hacky filtering by word "banned" would be more difficult to implement anyway (if some masochist ever wanted to attempt this for no good reason), because those "You are banned" messages are strings programmed into Doomseeker (src/core/gui/models/serverlistrowhandler.cpp) and localized into multiple languages. Those "banned" strings are not from the server itself, only a binary IP-adddress is banned response is received before being localized by Doomseeker. It would then beg to question how filtering by localized strings should then be done, especially across configuration changes. The server names from server information are from the servers themselves, those can be filtered.

(0022241) Bill Buchanan (reporter) 2022-05-28 19:24 edited on: 2022-05-28 19:56	I'm not leather bent on any one way of doing it. Those four are also merely ideas I had. It's certainly not meant to be an exhaustive list or imply those are the only options worth considering. It's also not as if I have a dozen or more of these servers to delist. It's a very minor annoyance for now that I could see being an issue for some of the more 'lively and active' users. Considering we're talking about bans here, both cluttered server lists and 'reminders of past shame' are also both reasons this might happen. And again, if you've got a particularly lengthy ban history, the subject matter becomes, in essence, how to remove clutter (from the server list) without adding too much clutter to the UI itself. I've included some mockups of what this might look like. Doomseeker_UI_000 and 001 show what it looks like currently. 002 and 003 show what a mildly adjusted UI on the filter side might look like (one possibility, not the only one). 004 shows what an option inside of Preferences might look like. If worst comes to worst here or elsewhere with feature creep, something in the vein of a web browser's "about:preferences" like in 005 could be used to display values for all options, including those excluded from normal UI view. Quote They get pushed anyway to the bottom of the server list (which can be quite long, especially for Zandronum). I don't see them too intrusive as it is with my network connection. Those bottom of the list servers with "NO RESPONSE" I cannot make use of anyway, even if I refresh them manually. All the useful servers are on top. I (usually... o_o) can't make use of <NO RESPONSE> servers either. However, I do get a lot of <Refreshed too soon> servers, and most of them I can fix by refreshing them. I can't speak from an experienced first hand position given I only have one banned server, but if I were hypothetically banned from several servers and wanted to also refresh <Refreshed too soon> servers, I could see the list of servers I was looking at and refreshing being longer than I wanted or needed it to be. Quote I'm afraid proposals 1 and 2 may be a step towards feature creep and cluttering the user interface (UI) more (counter-productive for issue 0003984 I've reported), so I'm opposed to this as a feature request unless an agreeable proposal (not described herewithin) can be made to improve the UI in general to support this change For what it's worth, 'too cluttered or hard to read' has never crossed my mind using Doomseeker. I've always found it to be a pretty ergonomic and usable tool that's never really frustrated me in any way. I do happen to appreciate all the information it does display, and never found any of it useless. I guess your mileage may vary. E.g., I experience <Refreshed>, but others don't. (As far as the <Refreshed too soon> thing goes, I'm not technically citing that as an issue that needs to be fixed, rather as a mildly relevant case in my situation where I want to keep those servers but filter out other servers Doomseeker considers invalid response types. If there's an easy fix for this then that's great, but for now I accept it as a quirk of using the program on certain internet connections.)

(0022251) Zalewa (developer) 2022-05-30 21:33	Quote from "Bill Buchanan" can't make use of <NO RESPONSE> servers When a server doesn't respond it's most likely a problem with the server and such server will never respond. Doomseeker tries hard to ensure that no connectivity issues will make servers appear as <NO RESPONSE>. So, when it can't reach the server, it probably means that no one else can't reach that server either. Such servers are probably behind firewalls or NATs and the people who host these servers either aren't aware of that or don't care. Quote from "Bill Buchanan" For what it's worth, 'too cluttered or hard to read' has never crossed my mind using Doomseeker. I've always found it to be a pretty ergonomic and usable tool that's never really frustrated me in any way. Thank you. Quote from "Bill Buchanan" However, I do get a lot of <Refreshed too soon> servers, and most of them I can fix by refreshing them. I can't speak from an experienced first hand position given I only have one banned server, but if I were hypothetically banned from several servers and wanted to also refresh <Refreshed too soon> servers, I could see the list of servers I was looking at and refreshing being longer than I wanted or needed it to be. So you're saying you wish to have the "banned" servers hidden because it will make it easier for you to refresh the "too soon" servers? Is that it? Because if so then maybe the better solution for you here isn't to filter out the "banned" servers but to help you deal with the "too soon" ones. The one thing here is that Doomseeker doesn't spend so much effort with the "too soon" servers as it does with the "<NO RESPONSE>" ones. It simply gives up and leaves them up to the user. But maybe Doomseeker could auto-refresh those servers with some extra delay? Instead of telling the user to "wait a while and try again" it would instead say "retrying in a few seconds ..." and then do that on its own? Of course, the problem with the filtering of the "banned" servers still holds but I'm not sure yet if we should add another filter for them, plainly treat them as invalid or add an option to the "Appearance" config box that will allow the user to treat the "banned" servers as "invalid". I'm not considering adding an advanced filtering method as viable for now.

(0022254) Bill Buchanan (reporter) 2022-05-30 23:55	Quote When a server doesn't respond it's most likely a problem with the server and such server will never respond. Doomseeker tries hard to ensure that no connectivity issues will make servers appear as <NO RESPONSE>. So, when it can't reach the server, it probably means that no one else can't reach that server either. Such servers are probably behind firewalls or NATs and the people who host these servers either aren't aware of that or don't care. Once in a great while (and I do mean rarely), a <NO RESPONSE> server will pop back up after refreshing it with my above procedure (start Doomseeker or hit refresh all, then select all the irregular response servers sorted at the bottom). However, this is very infrequent and rare, much more than recovering <too soon> servers. Quote Of course, the problem with the filtering of the "banned" servers still holds but I'm not sure yet if we should add another filter for them, plainly treat them as invalid or add an option to the "Appearance" config box that will allow the user to treat the "banned" servers as "invalid". At least for the Appearance config box, mockup 004 (first post attachment) is a demonstration of what that might look like. I would be intrigued if there's a way to address the amount of <Refreshed too soon> that happen. Though I should note that I haven't and don't touch the query response time and frequency options, since I trust the default options and don't want to do something silly that would start breaking things. I also don't want to hijack a different issue here with a tangent (unless with permission of course). That's really the bottom line of where I am now. I'd like to remove Banned servers but keep other invalid response types, in a way that's satisfactory without adding a bunch of UI options.

(0022257) Zalewa (developer) 2022-05-31 06:18	The query options are there to help with the issues you're having, so feel free to touch them. The default setting is "Aggressive", so you should try "Moderate" or "Cautious" or even modify the settings by hand.

(0022569) Zalewa (developer) 2022-12-29 20:45	First of all, I've provided a straight-forward solution to the title of this ticket by adding the 3 checkboxes to offer a fine-grained control for the bad server filtering:'https://bitbucket.org/Doomseeker/doomseeker/commits/927012acf19bb3646d1faa6646d42ee4e916adec [^]' See the "ds-extra-bad-servers-filters.jpg" pic. As for the broader picture: I will be going out of scope here, but the comments below may lead to more (separate) tickets. Firstly, I wish to state that expanding the filtering options is a feature on its own. It is standalone - not just a symptomatic treatment of some larger issue with some different root cause. It doesn't mean that this larger issue doesn't exist, just that the means that reduce the severity of that issue can have merit on their own and don't have to just be band-aids glued on a bursting water tank. More filtering options give more control to all users, regardless of their reasons to use them. The downside of this is that now there are 3 more checkboxes added to the filtering panel. These are 3 more items that further clutter that panel. Here I agree that this may become a problem of its own (it isn't yet) and that a certain overhaul of the filtering UI may be needed in the future. The text-based advanced filtering as proposed by Wub is an interesting idea, and I can agree that it would be nice to have it, but we couldn't have it alone. The text-based search is good for technical/corporate/"advanced" users. We can't forget that we're building a GUI for the purpose of there being a GUI and not a command line with an esoteric language for people to learn, and that we're also building that GUI for gamers. The checkboxes, combo boxes and other form items will need to stay, even if there will be a feedback loop between them and an advanced text-based search. People still need to be able to "click-out" their configuration. However, I don't see the prospect for implementing that for reasons explained at the bottom of this comment. One thing that can be done to improve the GUI now is to ensure that the filtering panel also works well when docked horizontally. Currently it is possible to dock this panel like this, but it won't adapt in a humane way to having more horizontal space and will look very bad instead. As for the other things mentioned here: Quote from WubTheCaptain I also considered a possibility of ignoring the "You are banned" denied response from servers and treating the response as valid / accepted with server information, but I've understood this is technically impossible with Zandronum at the moment (unless the upstream changes this behavior in Zandronum, which I've also understood would not apply retroactively to older Zandronum server versions, unless the master server would also enforce excluding old servers). I doubt that a change in Zandronum will happen here, because the servers intentionally reply with minimal packets on all the "bad" responses. You dun goofed on the server? Be happy that the server has the courtesy to tell you that you're no longer welcome. It does so very tersely in a packet that is 8 bytes long, as to not waste the bandwidth it needs for the players who use the server in a well-behaved manner. The same happens with the "refreshed too soon" response. Quote from WubTheCaptain The root causes I've understood in this issue are: Shared IPv4 networking (implied) [...] Perhaps implementing IPv6 support in Doomseeker (0003531) is also a way forward to resolving some of the underlying symptoms for shared networks, in hopes that more network providers will also adopt IPv6 The shared IPv4 networking is only one of the reasons why the "too soon" servers may appear. Does IPv6 fix all the networking issues that can happen on the net? Lost packets? Transmission errors? Bad connectivity? Hosts going down suddenly? The recently reported UDP MTU issue (0004064)? If not, then IPv6 is not a magic bullet to fix the problem with the "refreshed too soon" servers. Yes, Doomseeker could be doing a somewhat better job on trying to recover those servers, but a) I still believe that this is a separate matter that doesn't collide with the filtering options, b) some servers may be particularly difficult to recover and Doomseeker will have to give up on them anyway, bringing us back to the point where the faulty servers will appear on the list, and c) the auto-refresh (auto-fix) of the "too soon" servers would somewhat collide with the already implemented auto-refresh of the master server. To fix that last point properly it would be necessary to, at least partially, tear apart the current server tracking system and the master server refresh process, which I wanted to do already but couldn't find a good reason for (also considering potential plugin API/ABI breakage) and also couldn't find a way to do it that wouldn't have its own problems. Implementing an auto-fix for the "refreshed too soon" servers isn't out of the question and can be done well-enough within a reasonable effort and without tearing apart the refresh system, but it's a task for a separate ticket if anything. Quote from WubTheCaptain The root causes I've understood in this issue are: Badly foundational and inflexible search / filtering system I don't appreciate working on features for free, spending my free time on them and then have them ignorantly insulted like this. You're a technical person and you wish to input your search as a text query? I can understand that and most likely I would use it myself. But adding such a feature is another great effort. To do that you need a lexer, a parser, an AST tree, error recovery, operator definitions, a reverse Polish notation, bindings to the underlying data in a much greater scope than it is now, well defined column and enum names, a help page on the wiki (or in the program), and then ensure that the performance of all of that is still good. A lot of work that would require spending my time on. And then, after all that work, you would still need a damned GUI for all the people who don't want to learn your wiresharkesque field names and enum names and just want to click on things and narrow the server list down easily. And then the GUI and the text query would have to be bound in a loopback, so that clicks in the GUI would modify the query and modifying the query would reflect the filter state in the GUI. Good luck with your goodly foundational and flexible search system! I'm out. Unless there is a ready solution for all of that, the clicks are the best you're gonna get.

(0022651) Zalewa (developer) 2023-01-05 12:20	Beta package for Windows available at the beta auto-update channel and at: 'https://devbuilds.drdteam.org/doomseeker/doomseeker-1.3.3~beta-230105-1140_windows.zip [^]' Please test.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	WubTheCaptain

Issue History
Date Modified	Username	Field	Change
2022-05-26 23:25	Bill Buchanan	New Issue
2022-05-28 12:29	WubTheCaptain	Note Added: 0022231
2022-05-28 12:55	WubTheCaptain	Note Added: 0022233
2022-05-28 12:56	WubTheCaptain	Note Edited: 0022233	View Revisions
2022-05-28 12:59	Zalewa	Status	new => acknowledged
2022-05-28 13:25	WubTheCaptain	Note Added: 0022234
2022-05-28 13:37	WubTheCaptain	Note Added: 0022235
2022-05-28 13:38	WubTheCaptain	Note Edited: 0022235	View Revisions
2022-05-28 13:40	WubTheCaptain	Note Added: 0022236
2022-05-28 13:59	WubTheCaptain	Note Added: 0022237
2022-05-28 13:59	WubTheCaptain	Note Edited: 0022237	View Revisions
2022-05-28 14:03	WubTheCaptain	Note Edited: 0022237	View Revisions
2022-05-28 14:05	WubTheCaptain	Note Edited: 0022237	View Revisions
2022-05-28 14:06	WubTheCaptain	Note Edited: 0022237	View Revisions
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_000.png
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_001.png
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_003.png
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_002.png
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_004.png
2022-05-28 19:15	Bill Buchanan	File Added: Doomseeker_UI_005.png
2022-05-28 19:24	Bill Buchanan	Note Added: 0022241
2022-05-28 19:24	Bill Buchanan	Note Edited: 0022241	View Revisions
2022-05-28 19:25	Bill Buchanan	Note Edited: 0022241	View Revisions
2022-05-28 19:56	Bill Buchanan	Note Edited: 0022241	View Revisions
2022-05-30 21:33	Zalewa	Note Added: 0022251
2022-05-30 23:55	Bill Buchanan	Note Added: 0022254
2022-05-31 06:18	Zalewa	Note Added: 0022257
2022-12-17 23:17	Zalewa	Target Version	=> 1.4.0
2022-12-29 15:49	Zalewa	Assigned To	=> Zalewa
2022-12-29 15:49	Zalewa	Status	acknowledged => assigned
2022-12-29 19:10	Zalewa	File Added: ds-extra-bad-servers-filters.jpg
2022-12-29 20:45	Zalewa	Note Added: 0022569
2022-12-29 20:45	Zalewa	Status	assigned => needs review
2023-01-05 12:20	Zalewa	Note Added: 0022651
2023-01-05 12:20	Zalewa	Status	needs review => needs testing
2023-02-19 14:12	Zalewa	Status	needs testing => resolved
2023-02-19 14:12	Zalewa	Fixed in Version	=> 1.4.0
2023-02-19 14:12	Zalewa	Resolution	open => fixed
2024-11-03 19:12	Zalewa	Status	resolved => closed

Relationships