[FEAT] Automatic workshop subscription, better game path search/picker

[jiriks74]

Feature description A way to automatically subscribe to mods

https://steamcommunity.com/app/107410/discussions/0/3974924520876888570/

Objective Manual subscribing to every single mod on a server (there can be many)

How to I have not looked into it yet, but I'm posting this now as I'd forget about it, I know myself a bit too well...

I think that a steamcmd build could be downloaded if it's not possible to do with normal steam runtime and you'd subscribe to all the mods in the script.

So far I've just seen this thread on steam community and it looks like it could be done.

What do you think?

[aclist]

Hi, thanks for your message.

Actually, the feature is already implemented in the testing branch. I've been meaning to merge it to stable, but was working on some other projects.

I agree that manually subscribing can be time-consuming if there are lots of mods.

If you switch to the testing branch (Advanced Options > Toggle Branch), the feature is available there from the Advanced Options menu. You have "Toggle auto mod install" and "Toggle headless mod install".

Headless mode uses steamcmd. However, you shouldn't use it. Use "auto mod install" -- it works better.

Explanation:

The headless (steamcmd) method took far too long to implement and does not work well. The use of steamcmd varies slightly on each distribution and system and requires elevated permissions. Steamcmd also throttles download speed. It's too brittle for mainstream use and demands too much of the user, so I am dropping it.

"Toggle auto mod install" is the simplified auto install method and uses the Steam client dev console. It requests the mods to be installed in a batch and integrates directly with the Steam client.

Note 1: requires xdotool to be installed. Note 2: when using automod install, the mods get downloaded directly instead of being subscribed to in Steam. Once you start using automod install, DZGUI will manage mod versions internally and update them if there is a new version. You won't see these mods listed in your Steam workshop settings, as they get saved directly. This is the same outcome whether using steamcmd or using the new auto method: you cannot programmatically "subscribe" to mods, only programmatically "download" them.

So, yes, using this method, you can download 80 or 100 mods and you will even see progress in the Downloads window.

I am planning to merge this feature from testing into the stable branch next week. I want to do the following:

• Drop the headless method
• Clarify some of the wording around the automod method and provide a popup explaining how mod versioning/updates work
• Add some additional checks and handling

If you want to use it immediately, you can grab the testing branch, but be aware that it might change soon. Otherwise, you can look forward to this feature entering stable next week.

[jiriks74]

Thanks for the quick reply @aclist !

Your reply was way more than expected. I thought I'd get something like Sorry, not possible as Steam is pain and it would take to do 1 and 2 which are basically impossible for me to implement.

But this sound's great! I don't really mind the mods not being subscribed as the DayZ's launcher does not work with mods through Proton.

Honestly I didn't look into this project much and thought I was using some old unmaintained thing, as I didn't see its presence on the internet very much which is pity, but I was so pleasantly surprised when I got to playing DayZ yesterdey, pulled the dzgui branch and I got a nice, wayyy better UI (I love the serer browser and everything, I'll have to figure out how to add the server to favorites from there yet, I've used this new version for like 15 mins so far).

---

One thing I'd mention is that I'd like to add would be the ability to cancel automatic game search. It works, but I'm on a HDD and manually creating the config from the README and docs didn't really work for me.

( I did it in the end, but eg. "key" was "api_key" so it took me a while to figure these things out.)

I have the game on another drive (SSD) and it took it quite long to look through the HDD and show me the game on the SSD. I'd like to manually add the path or there could be a prompt like: Initial configuration incomplete. Save config anyway?

---

So you've got yourself a great project which literally saved me! I almost thought I wouldn't be able to play on modded servers with my friend but now I can!

I'll try to look into the project a bit, but I'm not really advanced in programming. I'd love to help out as this has helped me a lot. But no promises :sweat_smile:

---

PS: Closing this as you have a working implementation of this feature already. If you think that what I said about the game search makes sense, I'll create another feature request for it and try to figure out if there's some sensible way for me to implement it. Hopefully I'll be able to LOL

[aclist]

I don't mind keeping this ticket open while I update the automod logic. I just started making some changes to it after reading your message. It would be great if you can test it when I push the next version. I will push some updates to Testing later today.

I think the project has low discoverability because I didn't create a separate repo for DZGUI, so it resides under the DZTUI project for now. Maybe at some point I will reorganize it a bit more.

For stable 3.2.0 (currently on 3.0.6), I am looking to add some methods of adding/saving servers by creating a history file of servers you have searched/browsed before. Currently you can connect by IP, connect by server browser, or add servers by ID, but I plan to update this so that you can add/search/connect by whichever method you want. The existing methods kind of grew organically out of what was available at the time, so they need to be integrated better now so that all options are available whether you want to add, connect, or just browse.

Auto path discovery is a good point. I think that even despite our best intentions, it seems to take too long for people with complex setups and large hard drives with non-standard installation paths. There is a (currently unused) logic for giving the user a filepicker dialog, but it seems like a lot of users had no idea about where their files are even kept, so I was trying to make it mostly automatic. IIRC, what we currently do is check in the most likely locations, then fallback to searching the whole drive (excluding system paths where it couldn't possibly be installed).

It makes sense that path discovery shouldn't block creation of the config file per se, although you absolutely need a path for everything else to work. I guess we could offer the user a choice of a) manually selecting the path or b) trying to search for it. It might be possible to expedite it by having the user at least provide the drive to search, so that we aren't scanning unnecessary hard drives. This is kind of a tricky issue because most users (particularly on Steam Deck) have low literacy about the process and I don't want to confuse them.

I'm open to other suggestions here. How long did it take to scan?

[aclist]

OK, after thinking about it a bit, I believe I found a method that will make path discovery nearly instantaneous. I'll include it in the next release.

[jiriks74]

Wow that was fast. I'm glad you figured something out, I hope you'll be able to make it work.

It would be great if you can test it when I push the next version.

For sure! When I get home, I'll figure out how your updates work, etc. The way I use this now is that I have the repo cloned, checked out the dzgui branch and that's it. I'll set it up properly and look into the testing branch. I currently have a server that has over 40 mods, I have installed some, I think that there are about 24 left. I don't really plan on playing there, but I wanted to take a look how does the server work so I'll hit 2 birds with one stone.

I think the project has low discoverability because I didn't create a separate repo for DZGUI

This just made me remember how I found this. I was searching how to fix the mods in the launcher when I found a post on Reddit where someone in comments mentioned DZGUI. I was looking for it on DuckDuckGo, then even Google, but I always got dztui. Took me a while to read the README to find the link to what I thought was another repository until I saw the repo name which was dztui. The simplest thing that could be done IMO is forking the repo, changing master branch to dzgui and removing/archiving dzgui branch in dztui repo.

It makes sense that path discovery shouldn't block creation of the config file per se, although you absolutely need a path for everything else to work.

Yes, that's why I thought that there sould be something like: Incomplete configuration. Save the config anyway? You'll have to modify it to make the launcher work or something like that. I'd figure out something better if it would be implemented.

Another thing I can think of is this:

1. Search the standard paths
2. If the game was not found give these options
   • Automatically search for the game (recommended, may take long time for non-standard game paths)
   • Manually pick game path

OK, after thinking about it a bit, I believe I found a method that will make path discovery nearly instantaneous. I'll include it in the next release.

That's great to hear! I cross my fingers for it to work as that would be really awesome.

[jiriks74]

changed the title so it is the same as what we're talking about

[aclist]

Once you have the app installed, you don't need to manually check out branches, as it exposes a functionality within the app to switch between stable/testing and download it for you.

Yes, forking a new repo is the way to go, but I hesitated to do so for some time because I didn't consider this product mature enough to do so. (Initially, DZGUI was an experiment based on DZTUI and created for one user with a Steam Deck.) At this point, it is featureful enough that DZTUI has become obsolete, so I think the time has come. I cannot archive the dzgui branch of dztui completely, because several links on ProtonDB etc. point to it, so it will just contain a simple README redirecting to the new repo. This is just general house cleaning stuff I haven't bothered to do.

Anyway, I will ping you when I push new commits regarding the above changes.

[jiriks74]

Anyway, I will ping you when I push new commits regarding the above changes.

Sounds awesome, thanks!

This is just general house cleaning stuff I haven't bothered to do.

Understandable. Honestly I'd probably do the same. I'm yet to update the docs on my AstroNvim configuration so.... yeah.

Initially, DZGUI was an experiment based on DZTUI and created for one user with a Steam Deck

Oh! I was wondering how would it work on a SteamDeck! I thought that the menu options would be quite small and hard to hit with a touchscreen but since it purpose at first was "just" making it work on SteamDeck you probably have that figured out. When (if) I get a SteamDeck I'll be sure to try this out.

Once you have the app installed, you don't need to manually check out branches, as it exposes a functionality within the app to switch between stable/testing and download it for you.

Oh I saw that appear but it always prompted me for update for whatever reason:

Your version:
Upstream version: X.XX

But the last update it prompted me corretly. Anyways I've setup the app like this: git clone repo && cd dztui && git checkout dzgui and then just ran the dzgui.sh file.

[aclist]

Oh! I was wondering how would it work on a SteamDeck! I thought that the menu options would be quite small and hard to hit with a touchscreen but since it purpose at first was "just" making it work on SteamDeck you probably have that figured out. When (if) I get a SteamDeck I'll be sure to try this out.

It works. Surprisingly, most of the users who submit reports are on Steam Deck. It works better on Desktop Mode. Yes, the text is small. You can use a controller layout to navigate the interface better. There are also some limitations with entering text on the Steam keyboard overlay. Apparently, a lot of people seem to be using it as their main way of playing DayZ. There are still some bugs to be ironed out, but it's not my top priority.

Oh I saw that appear but it always prompted me for update for whatever reason:

It's probably because you manually created a config file and did not set the version or branch info keys correctly when doing so. The config file gets regenerated when downloading updates, so it should rectify itself over time. Apropos of this subject, I guess we could ship a sample dztuirc file in the repository for those that skip or cancel the setup process.

[jiriks74]

It's probably because you manually created a config file and did not set the version or branch info keys correctly when doing so. The config file gets regenerated when downloading updates, so it should rectify itself over time. Apropos of this subject, I guess we could ship a sample dztuirc file in the repository for those that skip or cancel the setup process.

Oh now it makes sense. I did create my won config, I think, because I didn't want to sit through the game path lookup process. But I reinstalled my OS since then and I gues I somehow deleted the dztui forder from .config? Anyways I've sat through it this time, so that may be why it worked as it should.

[aclist]

Status update:

v. 3.1.0-rc.11, testing branch

• Dropped old headless mod install method
• Cleaned up new auto mod install method and corresponding menus to prepare for mainline release.
• Added a method of forcing refresh on all mods to trigger downloading version updates if local files get corrupted (by default, version updates will always be checked anyway when connecting to a server). Shouldn't be necessary, but good to have.
• Added connection history: keeps a list of the last 10 servers you connected to by any method (server browser, IP, ID, favorites list, etc.) and lets you list those. This was pretty easy to add. Good for finding servers you recently connected to when using the server browser.

In progress:

• Conceptualized the logic for faster path discovery during first-time setup but did not implement yet. I know what needs to be done, but it affects other parts of the initial setup and I need to overhaul some of that first and reproduce a Steam Deck bug. Should be straightforward, but have to rejigger a lot of first-time setup menus and drop some stuff.
• Save server by IP, connect by ID. Currently you can save server by ID or connect by IP, but not vice versa. I need to change around the way we store server metadata and integrate it into a unified format. This touches a lot of the internals of the app, so I have to refactor some things first to ensure people can migrate their old favorites lists.

[jiriks74]

I updated and tried installing some mods. Basically no issues!

Apart from one: When I didn't have steam launched and tried connecting to a server steam took a little longer to launch than normally and then didn't launch at all for whatever reason. I killed the process and then had to wait until all the commands were pasted into KRunner LOL

I am to reproduce this issue, so don't worry about it as of now. If I'll be able to do it again I'll post another comment. Could be nice to check for the steam process before pasting all the text though.

[aclist]

Yeah, that's a good observation. Steam generates quite a lot of PIDs, so we have to sort through them, but it seems reasonable to implement. I can also add some logic to hold and not fire commands until the Steam window has spawned, but I think the better approach here is to just fail and return to the application if the user doesn't have Steam open. The expectation should be that the user must open Steam first.

[aclist]

I added your suggestion because it was good to have from a more general standpoint: we shouldn't allow any process that involves opening Steam continue if Steam is in fact not open. This includes connecting, launching, downloading mods, etc.

[jiriks74]

I saw it yesterday. The window of steam was on another desktop and I got the error. Before it ran, when it didn't check for steam, it focused me to the steam's window on the other desktop and just ran the commands.

So it works really nicely! PS: How the hell are you making these advancements this quickly? XD

[aclist]

I think requiring that Steam be on the active desktop is the best option here, in case Steam is running on another TTY session or X display. I run Steam on TTY2 but the primary window manager is on TTY1, so obviously it should fail in this case.

The application slightly suffers from the "big ball of mud" effect due to the fact that when it was initially conceived, there was no overaching design blueprint and we just needed to find a way to connect to servers in the quickest and dirtiest way possible, so a lot of the functionality has built up over time into a complicated mess, but I've tried to keep specific functionality atomic and modular, so making a new change is usually as simple as entering the function in question and editing a few lines. We have a lot of generic functions to draw from that make it easy to drop in new features. And I happen to know the application well...

The main reason it hasn't gotten these changes sooner is because I was working on other projects, but implementation itself is not too bad once you do it. The most time-consuming part is testing, particularly making sure Steam Deck is working well (which is a moving target).

Next goal is finishing the initial setup stuff and merging all of these changes into 3.1.0 on Stable, since it's fairly behind Testing now.

[aclist]

Question for you: is your Steam on another drive, or only the DayZ installation? Working on finishing up the path discovery logic. I think we will only need to search the drives if Steam is installed in a non-standard location.

[aclist]

OK, made the update for faster path discovery. If you don't mind, can you back up your config file/rename it/delete it and try re-running version 3.1.0-rc.15?

Changelog is kind of large, as I found a couple of bugs after implementing the recent servers list:

## [3.1.0-rc.15] 2022-11-24
### Fixed
- Faster path discovery on initial setup
- Handle whitelist deletion when only one entry present
- Return to main menu from recent servers list
- Unset delete menu flags after deletion
### Added
- Add python to deps
- Add Steam API key requirement to initial setup
### Dropped
- Drop mandatory server IDs on initial setup
- Old functions and files pertaining to headless mode
### Changed
- Allow My Servers list to be initially empty

Under the new first-time setup, you don't need to supply server IDs. You mandatorily need to supply:

• BM API key
• Steam API key

And optionally:

• Player name

After that, it will try to search expected Steam locations and set the path. If it can't find those, it will prompt you with a menu to:

a) Let DZGUI auto-discover (more accurate, slower) b) Set path manually via file picker (less accurate, faster)

If you somehow manage to set the wrong path to Steam, it will bring you back to the file picker and let you try again. If you still can't find it and decide to exit out of the file picker, the config setup will fail and will prompt you to try again from the beginning.

If you choose auto-discovery and it somehow fails to find it, same thing: it will take you back to the beginning with a malformed config file warning.

Hopefully, this covers all the bases.

Note to self: warn user (in documentation?) that if picking manually, Steam path should be the root path before entering steamapps, e.g., $HOME/.local/share/Steam or /my/dir/steam/.

[jiriks74]

Question for you: is your Steam on another drive, or only the DayZ installation? Working on finishing up the path discovery logic. I think we will only need to search the drives if Steam is installed in a non-standard location.

I have a SSD on / and an HDD on /home. Steam is installed on my system (app itself in / all the data in /home) and DayZ is on an external SSD /run/media/$USER/SSD

[aclist]

Let me know when you get a chance to test the faster path discovery and I will close this stub! Thanks!

[jiriks74]

So far looks good. I'm testing on someone else's PC now so I'm running of an external SSD where the library is located in /SteamLibrary.

Tomorrow I'll report whether it worked on my setup as well.

[jiriks74]

@aclist The new setup does not seem to work for me on my PC:

[aclist]

What game path got added to your config file?

Is this on Stable or Testing? The whitelist error is not possible on the Testing branch anymore, as that code's been removed. It looks like you might have flipped between versions and created a Testing branch format config file and tried to launch the Stable branch after that. Is that the case?

These changes aren't live on Stable branch, so you should be trying Testing branch only.

[jiriks74]

It was testing, it even downloaded the rc16 update. I'll try again tomorow.

[aclist]

OK, I'll need to know whether you picked automatic or manual path discovery and what the config file contains in order to troubleshoot this.

[aclist]

Rereading above, looks like you are using /run for the disk drive, and /run was being excluded from the auto-discovery path as an unlikely location. I'll have that added in a hotfix soon.

[aclist]

This fix is now live on both Stable and Testing.

[jiriks74]

Rereading above, looks like you are using /run for the disk drive, and /run was being excluded from the auto-discovery path as an unlikely location. I'll have that added in a hotfix soon.

That might be it. Arch based distros mostly use /run/media when you mount an external drive in some DE (I use KDE).

PS: sorry that I'm really not available for some time now, there's quite a lot of stuff at school rn. I hope I'll be available for Christmas. Hope you're doing well! Don't forget to take a break XD

[aclist]

Right. I don't have a DE and always mounted my drives myself to some arbitrary location, so I wasn't aware of those mount points.

I think everything you asked for should be in the mainline release now. Hope you have a good rest of the year.

[aclist]

Are we okay to close this?

Thanks for your feedback and suggestions. I really appreciate it. If you have any other suggested features, I am always open to hearing it.