search

aclist / dztui

DayZ GUI server browser and frontend for Linux
https://aclist.github.io/dzgui/dzgui
GNU General Public License v3.0
89 stars 10 forks source link

Can't connect due to mod links being outdated/dead #4

Closed scandalouss closed 2 years ago

scandalouss commented 2 years ago

Hey, I found something else thats causing some issues with your script. When browsing battlemetrics to find a server, you can see the list of mods required to join that server. I've discovered that there are a handful of servers that have mods in their list that don't exist anymore (see https://www.battlemetrics.com/servers/dayz/13887048 for an example: The last 3 mods no longer exist, and can't be downloaded, as their download pages leads to either a completely unrelated item or nothing at all)

As such, attempting to connect to these servers with the script results in not being able to connect:

[ERROR] Missing mods. Open these links and subscribe to each one, then reconnect
https://steamcommunity.com/sharedfiles/filedetails/?id=%s1314079816
https://steamcommunity.com/sharedfiles/filedetails/?id=%s1936941389
https://steamcommunity.com/sharedfiles/filedetails/?id=%s2054775140

But these links are dead. (Also for any mod links to work I have to remove the %s from the id line in the link, but that's something else.)

Using https://daemonforge.dev/Server/ to query the server however shows a mod list that doesn't contain these 3 mods, and if I painstakingly go through manually creating the launch options (Because I can't get debug output from the script because it needs all the mods downloaded) without those 3 mods, I connect fine.

I'm not sure if this is necessarily an issue with your script or if the problem is beyond your control.

aclist commented 2 years ago

I appreciate the additional due diligence on this.

The problem is multi-pronged:

Basically, what I'd like to get around to doing is including a custom A2S query module alongside DZTUI. This has to be written from scratch and also complicates installation for the end-user a bit, but it does offer the following benefits:

So basically, if we front-load configuration a bit with this, it'd potentially make setup easier for the user and solve a host of edge cases.

At the same time, it potentially changes the entire way we look for servers. You'd no longer be dependent on finding server IDs in BattleMetrics, but we still need some way of finding the server addresses, and I don't think a full-scale live search is the answer, here, so would probably need to ask the user to supply IP addresses.

Also, I'm not entirely sure what is the entirety of information that servers report over the A2S query interface and whether it always contains mod info. I believe it does, juding from the Daemonforge API, but I need to explore A2S more (on to-do list).

Also for any mod links to work I have to remove the %s from the id line in the link, but that's something else.

Will look into that to see if it's affecting anything else.

Because I can't get debug output from the script because it needs all the mods downloaded

Should be able to push a hotfix to decouple the debug method and not make it dependent on all mods downloading successfully by changing around the order of operations, since it's important to have working debug output.

As for possible workarounds for the time being:

Basically, we've been assuming the incoming mod list is in fact a valid source of truth. But what we could do is validate the list and check whether the incoming links are real/working; if not, skip those. This should allow for getting around this speed bump in BattleMetrics for now, while I look into the A2S method.

I don't see any pitfalls in that solution, and should keep the rest of the functionality intact.

aclist commented 2 years ago

Also for any mod links to work I have to remove the %s from the id line in the link, but that's something else.

Resolved by #5

aclist commented 2 years ago

I've pushed a hotfix for this issue per https://github.com/aclist/dztui/commit/aac5fb656c4567dda17dbc4deaec26c9b9e33a6b if you want to test. It should be working correctly on the server you mentioned, and omit the last three invalid mods.

This method manually walks through each mod and checks its status on the Steam workshop, removing invalid entries before giving you back the final mod list. This is not the slickest approach, but it should mostly be safe for now unless Steam itself is down. This change does come at the expense of some additional time needed to validate each mod, but you get a live progress indicator.

This fix also includes some superficial stylistic changes to aid readability, such as printing the menu options after the long mod list if using manual mod, to prevent the menu from being scrolled up too far.

Do you find you are using manual mode more than auto_install_mods?

As for

Because I can't get debug output from the script because it needs all the mods downloaded

I've created #6 if you want to discuss this idea further there. I'm leaning towards treating this as invalid, if only because showing launch parameters in the event of mods not installing correctly is a recipe for failure, since the mod installation failing is itself an indicator of a problem. While debug parameters could theoretically help here, it seems like it could invite user error, instead of blocking further progress and moving you towards diagnosing the mod installation first. I kind of want a mod failure to block further progress so that we can diagnose these issues instead of just proceeding with phony launch parameters.

scandalouss commented 2 years ago

Tested and works on the server mentioned before, awesome. The readability is a plus, too!

I go with the manual mod installation route simply because I don't have steamcmd installed, and it's not really that bad enough of a process to warrant automation. I just haven't considered it, but maybe I'll look into setting it up when I have time.

As for #6, if more problems would be introduced to show launch parameters anyway, then it should be probably be avoided.

aclist commented 2 years ago

Great. Happy to hear it.

I think the manual method depends on a few assumptions for convenience: that you have a default browser configured to open links, and that you have a terminal configured to make opening links directly easy. This should be fine for most users, but it could be a bit tedious if using a more stripped-down environment (which I am). In those cases (or if you just dread clicking 25 links), automation is handy, particularly on those servers with a bazillion mods.

For the other issue, I think it's best to sort of prevent further progress and halt catastrophically with an error to avoid confusion. However, I'm thinking of generating a full text log in the event of errors that would contain all of the necessary info for users to report the issue more easily and aid with troubleshooting. That log could definitely contain launch parameters inside it. I still think your point is valid--that decoupling the dry-run launch options is useful on some level--but the launch options themselves are generated by inspecting the content of mods after downloading, so changing the order of operations would mess with that control flow a bit, as we need both mod IDs and names, and we can't easily get that info without successfully retrieving mods.

aclist commented 2 years ago

Just a heads-up that there is a new minor version out that fixes some edge cases and adds future-looking functionality.

The main fixes for this minor version (0.3.0) are:

Still to come: detailed changelogs, standalone releases on GitHub

The reason I wanted to mention this update is because, with the last fix, the script will now notify you if there is a new version available to download (but not download it for you). This is forwards-compatible with future versions, so you shouldn't miss any future bug fixes.

Thanks.

aclist commented 2 years ago

Resolved by https://github.com/aclist/dztui/commit/aac5fb656c4567dda17dbc4deaec26c9b9e33a6b