Mtasa-blue: Revamp of the server browser

[Woovie]

Is your feature request related to a problem? Please describe.
The server browser is unnecessarily complex and somewhat confusing when attempting to search.

Describe the solution you'd like
The current address bar should be turned into an omnibox field. It should search player names, search server names, search gamemodes, and be an address bar all at once.

Implementation of this feature would require significant changes to the overall server browser. We should consider altering how various click events occur.

• Single clicking a server should do no adjustments to the omnibox
• Double clicking should "navigate" to a server, aka connect, and change the omnibox
• Addresses and searches should be stored
  
  
  
  • Whenever a search is done followed by a connection, store the search and then the connection in the history
  
  
  • Maybe also store searches if enter is pressed
  
  
• Add a history clear for servers and search results
• Whenever searching for a word that matches players and game modes as well, we should do sections within the scroll area which are for each match type (server, player, gamemodes)

[CrosRoad95]

don't forget about searching by countries

[Woovie]

Country filtering would be done by geoip lookup of the server. Otherwise you can just search the name of the server. I'm not sure we want to add geoip. I guess it could be a column. We could do it like the admin resource does.

[qaisjp]

Worth noting that server location != _"server country"_, and both are equally useful to have around for latency/language purposes.

[sbx320]

I think the ideal option would be to allow servers to specify a list of supported languages. That way multilingual servers would also be possible.

I'm not sure if searching by server location is worth implementing. Whether the server is located in Amsterdam or Frankfurt has no significant impact for most European players. I think just keeping ping should be enough here.

It should search player names

That would require a massive rework of the masterlist. Currently player names are requested individually from each server once you click on it. To be able to search for player names, we'd need to get all players from all servers before being able to search.

[Woovie]

That's fair, and I agree about server location. Language "support" would be nice. Perhaps an item that is just a text row, but a dropdown if multiple supported.

[Haxardous]

759

[Woovie]

Going to start documenting this issue a bit. Here's some notes:

• Search should not kick in unless the field is at least 2 characters
• Search should occur on another thread. CAsyncTaskScheduler? (Pirulax said this scheduler, I personally am not familiar enough with the codebase to say for certain that is correct, but the naming convention seems correct from my experience.)
• There is notable lag when searching for a single character and as well when emptying the searchbox. Emptying the searchbox is even laggier than searching for one letter. This has lead me to believe the searchbox is searching for an empty string when fully emptied. This is very bad design.

I'll add more notes soon. I do still want to do the omnibox idea.

[Pirulax]

Its probably lagging, because youre deleting characters one by one, and its searching for that string.

Regarding the CAsyncTaskScheduler may not be an ideal solution, as theres no way to cancel the task(there should be), so perhaps just having a thread created every time the browser is opened would be a better idea.

[Woovie]

Its probably lagging, because youre deleting characters one by one, and its searching for that string.

No, I'm highlighting all of the text and removing it. It's lagging once I've emptied the box. Even in the example you gave, let's say you have 1 character left and you backspace it. It should have zero discernable lag on that last character removal. The filter should be trashed and the list rendered in full. We are still going off assumptions here, so I'll read over the code and infer the exact circumstances occurring.

[Woovie]

Some more notes. We use a handler that does a callback to OnFilterChanged.

m_pEditSearch[type]->SetTextChangedHandler(GUI_CALLBACK(&CServerBrowser::OnFilterChanged, this));

This then calls UpdateServerList

bool CServerBrowser::OnFilterChanged(CGUIElement* pElement)
{
    UpdateServerList(GetCurrentServerBrowserType(), true);
    // SaveOptions ( );  Slow

    return true;
}

UpdateServerList calls AddServerToList

void CServerBrowser::UpdateServerList(ServerBrowserType Type, bool bClearServerList)
...truncated...
    // Loop the server list
    for (CServerListIterator it = pList->IteratorBegin(); it != pList->IteratorEnd(); it++)
    {
        CServerListItem* pServer = *it;

        // Find info from server cache for favourites and recent
        if (Type == ServerBrowserType::FAVOURITES || Type == ServerBrowserType::RECENTLY_PLAYED)
            GetServerCache()->GetServerCachedInfo(pServer);

        // Add/update/remove the item to the list
        if (pServer->revisionInList[Type] != pServer->uiRevision || bClearServerList)
        {
            pServer->revisionInList[Type] = pServer->uiRevision;
            AddServerToList(pServer, Type);
        }
    }

AddServerToList checks if the searchbox is not empty for every item in the list.

This seems inefficient and I have some ideas to speed it up.

[Pirulax]

I really love the fact that in MTA, we do this:

std::list<T*> vals;
vals.push_back(new T());

It doesnt make any sense, especially because we're using std::list, which doesnt invalidate other iterators when inserting.
I'd be nice if youre there to just refactor it.