aclist
commented
2 years ago Thanks for your interest.
Fundamentally speaking, my plans are to add any features that players want or need, provided they fit within the design limitations and time constraints of the project. The features you asked for are technically possible.
To clarify on what I mean by design limitations, I'll answer that in the second part.
As for time constraints, I am also developing concurrently with this project some other launchers and utilities (unreleased) to improve games on Linux. I try to stay on top of adding new features to DZGUI, backporting them to DZTUI, fixing bugs, updating the documentation, and so on. Elaborating a new feature thus requires a lot of testing (desktop environment, Steam Deck workarounds, checking results on actual servers, different mod configurations, etc.) to ensure that it's safe to release to users and won't break existing functionality.
Certain features will be very labor-intensive to add, so we kind of have to look at what is the most reasonable in terms of complexity.
OK, getting on to your questions:
- Server browser: this is a complex topic. I do have a long-term plan to make a custom API used to query the A2S protocol. It's possible to get the complete list of servers that are broadcasting and then query them for player count, modlist, server rules, etc. However, there are over 10,000 servers.
Loading this list all at once would destroy the application from a performance standpoint. The reason is because it doesn't have pagination. The reason it doesn't have pagination is because we are limited by the GUI utility being used: zenity. But the reason zenity is being used is for coverage: in order to make the application run on the most generic environments, even the Steam Deck, with no additional dependencies, zenity is the most commonly installed tool on most distributions that gives us a way of building up a simple GUI and passing it all the data we transformed. However, it has very rudimentary functionality.
A server browser needs to handle pagination, buffering, have some kind of search implementation (live search? what parameters are people searching by? keyword search?), etc. Actually, the current GUI allows us to search and can load a list in real-time, but there is no elegant way of paginating, so you'd be getting blasted with a list of 10K servers and waiting forever for it to load. The whole GUI would have to be rewritten in a different framework, and that would greatly change how/whether the app will work on any distribution out of the box.
Hmm...thinking...technically, pseudo-pagination could be done in the current GUI by chunking the results into pages and having a "Next Page" entry at the bottom of the list, but it's going to be a bit weird unless we filter the results first with some kind of query. And I'm not clear on what users would be searching for from among 10K servers. Would you want to search by name? By map? By geographic proximity? This could be doable if we break it down into something manageable, but I'm having trouble imagining a scenario where it's fun to page through so many pages. In order to make it viable, we have to rank the results before printing them, so that what you are trying to find is more likely to be within the first 3 pages.
That is not all: Bohemia Interactive is sending data with a special encoding in its A2S responses. This goes against the conventions of Valve's A2S protocol, which is supposed to return human-readable data. But they wanted to add complex modlists into the response, so they invented their own binary format and stuck it inside the A2S response. This needs to be unscrambled in order to get the actual modlist.
On the one hand, a custom query API would be very beneficial for us, because we could drop the dependency on third-party APIs like BM and do everything internally in the app. Users wouldn't have to create an API key on the web site, etc. It would streamline the code and let us grab exactly the parameters we want. So it's definitely a plan.
Taken individually, these pieces are reasonable to do, but put together (custom API + browsing/search + rewrite the GUI), it's quite a large undertaking. It would actually be fairly easy to do with a terminal client, since you could arbitrarily index and search the server list with a fuzzy finder without worrying about drawing a GUI around it. I could probably do it as a plugin to DZTUI, but I question how many people want/need a terminal based server browser for 10,000 servers.
Anyway, the main thing is elaborating a custom API, which then facilitates various things down the road. I've intentionally put that as a low priority because it's going to be a lot of work.
-
Inclusion of non-standard servers in the list: sorry, you'll have to clarify what you mean here. I think you are talking about adding official, non-modded servers into the list?
-
Connect by IP and port: I think connecting by IP and port would be a quick fix at this stage, since we have a lot of internal methods that would facilitate this. It could probably be an additional menu option, and you just enter IP:PORT and it does the rest. However, we still need a verifiable way of getting the modlist, so this still requires a custom API to do, because we need to get and decode the binary-encoded modlist data that servers send down. (Currently BM does this for us when we specify servers by ID.)
-
Connect to a local server: so you're referring to a server using whatever server admin tools Bohemia provides? How does it report its own modlist? Does it respond to A2S queries? We could query localhost and get the modlist back. I assume a local server keeps its mod info or a manifest stored in a defined location? We could also just find the server mods in the local filesystem and prepare the launch params this way, without querying the server itself. And you seem to be saying it's not possible to connect to your own server unless you launch DayZ through Steam?
I'd say 2, 3, and 4 are doable in the short-term. Item 1 is a vast undertaking.
VIrusR
Thanks for the great launcher! I'm using the stable branch (version 2.4.1 at the moment) - works flawlessly! Great project! Thanks again! However, there are a number of problems, first of all - the lack of its own server browser and, most importantly, the non-standard inclusion of servers in the list. Still, I would like to see a solution to the issue of connecting servers via IP and port, as well as connecting to a local server installed on your own machine. This functionality is sorely missed! Will you be doing this in the near future and should we expect a decision? Or is it not included in your plans at all?