Replies: 9 comments 40 replies
-
|
OK, making this to initiate updates, Looking forward to seeing where it all ends up. |
Beta Was this translation helpful? Give feedback.
-
|
Prototype for grouping main menu categories for readability. Possibly unnecessary
|
Beta Was this translation helpful? Give feedback.
-
|
It seems to help and should lay the groundwork for future management of favorite lists if we have both the IP and ID methods and lots of granular settings. The only thing to note is that the labels themselves are in the list, so you can erroneously click them, but they won't do anything if you try to select them. In case you didn't know, you can also double click to select menu options. I also fixed a small thing that was causing the app to take longer than necessary to boot up, so should have a slight uplift in time-to-start now. |
Beta Was this translation helpful? Give feedback.
-
|
I did not know of the double click and love it now that I do! |
Beta Was this translation helpful? Give feedback.
-
|
Keyboard works as well (arrows/enter) |
Beta Was this translation helpful? Give feedback.
-
|
Didn't even stop to think about that as an option! NICE! |
Beta Was this translation helpful? Give feedback.
-
|
Guess I'll add it to the manual. |
Beta Was this translation helpful? Give feedback.
-
|
Progress report on automods: Arch Linux: working end to end I have added the ability to toggle automods on via the options menu, and restored the file picker dialog as a way of specifying an alternate download location in case /tmp is too small. (/tmp will be used as a fallback if something goes wrong). However, the alternate drive or path must be writable by the Also added a disclaimer when enabling automods about what to expect. With automods on, the process spawns in a separate window and requires minimal input from the user. After supplying a steam ID, it will prepare the parameters for headless invocation through steamcmd. However, if this is your first time running steamcmd, it will ask you to log in and (optionally) use your 2FA token if enabled. Valve generates a long-lived token when you log in to steamcmd, so it shouldn't be necessary to reauthenticate on subsequent times, but I haven't been able to reliably determine how long this cache lasts or what causes it to be overwritten. So after some days (?) or if you change users, you may be asked to log in again. But for the most part, once you set it up, future passes should be automatic. The only thing we ask for is the user's steam ID in order to kick off the routine and pass these parameters to steamcmd to tell it to look for the token. I didn't want to ask for any other credentials, even if masked, since the user might get the wrong idea. I wanted to make sure the user has to type it themselves into steamcmd so it is transparent to them what is happening. It can take considerable time to download mods if there are tons of large ones, but you don't have to do anything while it runs. When finished, the secondary window exits and returns you to DZGUI. If something went wrong, it will revert to manual mode for the remaining mods. We also generate an informational log of the process in case something needs to be reported. This took way longer than expected because Steam kept having a cloud sync problem and I wasn't able to launch DayZ despite everything in the pipeline seemingly working. I finally had to disable cloud sync (not sure why I needed it for a game with no saves). I will do integration testing on Steam Deck tomorrow and push a preliminary release. My expectation is that there will be some bugs. I plan to gradually whitelist more distros on an as-needed basis after the "big three" are supported. The good thing is that the mods are all downloading automatically, but we just need to get it to click together correctly with different environments. |
Beta Was this translation helpful? Give feedback.
-
|
I have run into the cloud sync thing, I think, a couple of times. When DayZ will not launch after invocation by DZGUI I just log out and log in and try again and it has always worked after the log out. Wow that is a lot of work! Looking forward to giving it a go once I see it....Thank you for all the work! |
Beta Was this translation helpful? Give feedback.
-
|
OK, it seems to be working, ironing out a few kinks on Steam Deck. When you launch, go to Advanced Options at the bottom of the main menu, then select to toggle automods on. You'll get some instructions onscreen. Probably best to leave the default directory of /tmp for now. When you try to get new mods for the first time, it should ask you to pick a preferred terminal emulator from among the ones it found on your system. This just lets you have a "familiar" looking terminal while the download process is going. On Ubuntu, the default terminal is usually
Once steamcmd kicks off, it should ask you for your password and 2FA token the first time inside of Valve's prompt. Once this is done, it SHOULD start downloading a bunch of mods and moving them to the right place, then notify you when the process has completed (or failed). If it fails, it will go back to the application and give you the manual mod process. The main question mark will be whether the steamcmd prompt behaves and doesn't time out. It seems to be finicky at times, and can take a long time to synch when first logging in. If anything goes wrong (which it will), you can find the |
Beta Was this translation helpful? Give feedback.
-
|
I have a double-header of updates today: I got this idea to simplify the manual mod install process for those who can't or won't use the automod method. I created a process called DZG Watcher that opens the mods in Steam directly and prompts you to subscribe to them. When one starts downloading, it foregrounds the DZG Watcher progress bar and notifies you of its status. When it finishes and gets moved into the mods directory by Steam, it opens the next mod in the list directly and lets you subscribe to it. So essentially, you just keep pushing Subscribe and the progress bar foregrounds itself and tells you how far along you are (e.g. I believe this is something @SteveIDusa originally asked for, but there were some limitations to being able to implement it before. Now I noticed how simple it actually is within our current pipeline. So we don't need that annoying HTML page with links you have to click yourself. I think this is pretty good for someone who just wants to sit there and slap the subscribe button over and over again. Note that in order to foreground the notifications, you will need to install the tool Anyway, it appears to be working fine, as I only had to drop in the DZG Watcher process and not really change anything with how we set up and load the game. But hopefully this makes it way less cumbersome. However, using automods is still going to be preferable for those times you have 50+ mods to install (and just in general). If you do have problems, you can drop back to the Stable branch in order to get mods the old way. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I believe I have an internal way of foregrounding the DZG Watcher in Steam Deck desktop mode, since we can't install external utilities as freely there. This gives: Steam Deck game mode => use legacy method of switching back to the "next" prompt after subscribing (since game mode applications take full control of the screen) |
Beta Was this translation helpful? Give feedback.
-
@aclistHad a chance to use the new server browser today! Really like how you have implemented the auto-magical downloads! It literally walks you through it! My experience:
Do you think at some point you will be able to auto download the entire list with a single click or? Either way, it is still a very nice feature to see implemented, and if you ask me not really any different than the original launcher, just more explicit in what it is doing and I for one like it like that. Great Work! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, did not see the previous post explaining this workflow, but yeah it works great! Not sure that I asked for exactly something like this, but even if you interpreted in a way that is different from what I asked for or what I thought I asked for, it is still a nice way to get the mods, and see the progress! |
Beta Was this translation helpful? Give feedback.
-
|
Also, if this is not the right place to post responses of this nature, let me know, as it seems this may not be the place for it considering your content posted here. But as you can see, still willing to provide feedback! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Actually, I posted two updates yesterday: one for the improved manual installation (which you used), where you have to click subscribe. The other update I posted is for the fully automatic installation of all mods. The updated progress bar was just an idea I had on a whim.
Each grouped "thread" on here should be for a single topic, with replies on that feature nested below it. You can reply to those and I will delete/merge this thread. |
Beta Was this translation helpful? Give feedback.
-
@aclistJust ran into an issue that you might want to consider. Attempted to login to a Deer Isle map today after the 1.19 update and got a Data Mismatch Error. Now, I know that this has nothing to do with DZGUI, and that I just have to wait for the server to get updated so it has the correct version of the mod since it told us our client version is newer than the the server version. However, As I was thinking of how I might help the server owner, since we are members of their discord, it occurred to me that you had added listing the mods from within DZGUI. So on that thought I figured perhaps I could get the version number for the mod I am running to provide it to him so he could check it against what he is running and ensure to get the correct version installed. But a version number was not available in DZGUI. I am not sure if that would actually be useful, as I know that the client side updates automatically when a mod gets updated. So perhaps that is the case with the server as well? If it is, then this is all mute, but it was something that I might be able to provide as assistance. Would having a version number next to the mod name in the list be something that would be useful? Something even possible? Or just a waste of time considering it is possible that they get updated with a Steam Restart? |
Beta Was this translation helpful? Give feedback.
-
|
Nice! Will probably be able to give it a try this weekend! Looking forward to it! |
Beta Was this translation helpful? Give feedback.
-
|
Alright, also let me know whether you think it would be viable to replace manual mode altogether with this (having manual mode as a fallback only). It may be a bold idea, but I think it's potentially OK. |
Beta Was this translation helpful? Give feedback.
-
|
OK, got a chance to turn on Auto Mod Install! That seems to work pretty well, though I did not have xdotool installed. So I had to install that, which sounds like it can be invoked to do just about anything. That made me a little nervous I have to admit. Since I do not know anything about it....But I bit the bullet so to speak and went forward. It launched the steam cli and grabbed all of the mods for a new server I had never joined previously. 61 Mods in all and they finished and launched the game when prompted with the O.K button. That was quite nice, I have to admit. However, after getting all of them installed and exiting, I decided to check my steam workshop for DayZ and compare, since I only had 12 mods installed previously to joining the new server today, I expected to have pages of mods listed. Except, I had a total of 14 mods subscribed to....so.....Is it attempting to subscribe or not when in auto mod install mode, or it is attempting to but some mod authors do not conform to a process you are attempting to use? I have now deleted all of my mods and unsubscribed from everything. Now going to try headless mode and see how it is different. OK, so after unsubscribing and deleting all my mods, turned off "Auto" and turned on headless, got the prompt to read, clicked OK and chose xterm from the available list, as it was the only option listed. Provided a password to steam command, got a pop up on xterm that would not allow me to choose the OK button at the bottom of it. Used Ctrl+C which seemed to either kick me out of the that prompt and continue or ended one process incomplete but started the next process which asked for my steam ID and password but the it all broke and reverted back to manual mode. I tried again to the same results, so I have now turned off headless mode and will try auto again. Of Note, it seemed that downloading mod at the steam side also got broken, noticed that the install progress kept starting and stopping, with some nearly unreadable text in red being displayed so quickly that it took me a while to interpret what it was saying, as in I had to just keep watching it and piece together letter by letter as I could see them. "Missing Files" So am now doing a validation of local files in steam. After validation, and using auto mode it downloaded: Nope, afte getting back into the game, I then jumped into the Steam workshop for DayZ and checked my subscribed items which showed Zero, so.....I kinda like the manual mode as of this writing. Did I miss something? Or is it not implemented yet, not being implemented? What am I thinking? Did we already discuss not having a viable way to carry that out? What ever, auto worked, while headless failed for me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed feedback! I'll try to address your questions and assuage your concerns.
I think I'm honestly going to drop headless mode. There are too many things that can go wrong. It is technically the more "correct" solution versus the visually repugnant approach of auto mode of just typing "download this mod" into the Steam developer console, but at the end of the day auto mode is guaranteed to work on any setup since it just runs directly on top of Steam with nothing else. Fortunately, no matter what mode you choose (even auto mode), if something goes wrong, it is always going to revert to the manual mode as a failsafe.
xdotool is a virtualized input automation tool that lets you raise and unfocus windows, move the cursor, and type keys. It's similar to AutoHotkey from Windows, if you know that one. It can't do anything more nefarious than DZGUI itself can. That is to say, it can't actually interact with programs besides just clicking and typing on them where we told it to. The Steam developer console does not provide a way of sending a single-shot command saying "download this whole list of mods for me," so we have to issue them one at a time. It also doesn't download them in a batch, but just queues them up one after another, which is why you see single files in the Downloads pane being fetched. That might be why you saw it stopping and starting repeatedly? I don't know about any red text or warnings, but I think it does sometimes emit informational warnings in the console that can be ignored. I believe we didn't do anything wrong here with regard to any missing files.
We have no way of actually subscribing to the mods so they show up in Steam this way. While it would be nice to queue up each mod page like in manual mode and "hit" the Subscribe button, this is not reliable due to the fact that the button is never going to be in the same place. Consider someone using 1920x1080 or someone using 2560x1440, different window position, different size, etc. So queueing up the mods in the console is a necessary evil to reliably achieve what we want to do. However, DZGUI does internally "subscribe" to and track the mod versions when using auto mode. After downloading mods, it tracks the version internally. Next time you run DZGUI, it always checks your local mods against the upstream versions to see if any need to be downloaded to upgrade the version. Even if you're connecting to a server you have all of the mods for or don't need to fetch new mods, it will always check versions for mods you are tracking and download them if there is a change. So in other words, if you connect to a usual server that you have all of the mods for but there is a "new" version of one of the mods, it will jump into the auto-mod installation routine again and download that mod and update it. This is what Steam does internally when you click "Subscribe" for a mod. We've just sort of recreated the process in DZGUI since we don't have a physical way of telling Steam to do it. This all happens under the hood, though, so yes, it will appear as a side effect (in Steam) like you have no mods. I knew that being able to upgrade mods on a rolling basis would be important to have if using this method, so I made sure to include it. This is the trade-off we have to make. Does looking at subscribed mods in Steam provide some useful information beyond confirming that you "have" those mods? Is there some information there that you want to have? There's nothing to stop us from having a dedicated page for this in DZGUI with this information. Basically, when using auto mode, if you see a mod in your "list installed mods" page in DZGUI, then you are subscribed to it. It always syncs your downloaded mods and keeps updating and tracking the version internally. (This is always happening provided auto mode is on.) If it's just about seeing a list of subscribed mods with some info like date, author, picture, etc., we could mock that inside of DZGUI, but I'm not sure what the objective here is. Is it just the peace of mind of having them in your Workshop? I totally get it, it's just a limitation of what we have to work with. In short: |
Beta Was this translation helpful? Give feedback.
-
|
OK, that actually explains it very well. Regarding the reasons? I was only asking so that I could wrap my own mind around how it is working so I can know how to proceed when interacting with DZGUI and the mods. I have gotten fairly proficient with using the Workshop to "unsubscribe all" when I want to test a new feature and then delete all of the mods in my installation. Thus I know that I am starting with a clean slate, so to speak. If now there is no going to the workshop to "unsubscribe all" which has led me to believe there must be a manifest kept some where, I have to know where to find the manifest for each of the servers? Or is that all handled and stored in my mods folder? Or is it just a part of the routine that DZGUI runs and is able to interface with DayZ each run to tell it which to load for which server or what to download? I am really just trying to understand what I can not see. Which is way above my head at this point, but no harm in trying to comprehend it all and I just have a natural curiosity about such things anyway. And of course, for testing that is actually pretty useful.... Regarding the stopping and starting of downloads, No, it seemed more like Steam was confused. It was grabbing a single MB or 10 MB's at a time for downloads on a 200 MB connection. So my total downloaded was growing very slow along side the "Missing files" warning in Steam on the Download Interface that you access by clicking the link for "Downloads" at the bottom of Steam. But after the file validation it seemed to correct the issue. I likely deleted something I was not supposed to when removing all of my mods and unsubscribing from them. That was the impression that I a had anyway, did not think it was related to DZGUI, just me mucking around for testing purposes. Regarding xdotool, I guess I am not sure about it, because I do not know its full capacities, or how much a very knowledgeable developer could actually access if using such a tool. I understand why it would be invoked, it can carry out commands that need to happen for the deployment of DZGUI and facilitate what I want DZGUI to do, allow me to play modded DayZ servers. But could it do more without me knowing it. I suppose it could, because I have no additional information to base any other reasoning on. So of the modes listed above, which of them is utilizing xdotool to carry out the interfacing between DZGUI and Steam? Of course, if manual mode is retained as a fall back, or can be invoked as the default means of handling the process, then I could always just use that and not have xdotool installed correct? If I am that concerned about it being used by a script.... |
Beta Was this translation helpful? Give feedback.
-
Great question. Your assumption is exactly correct. There's actually a manifest file located in To force redownloading everything, you'd have to replace the timestamps listed in that version file with something invalid (e.g. 0000). Simply deleting this file won't do it, as if the file is absent, we assume auto installation has never been run before, so we just take the local mods installed at face value and don't update them. (Sort of necessary for bootstrapping the version file, otherwise we'd have to force you to redownload every mod you have the first time you enable automod mode, which would be a lot of mods, and probably pointless.) So in lieu of modifying that file yourself, I could see there being a menu option that just blanks out this file for you at a click and then triggers an update if you wish to "refresh all" mods. Unfortunately, the mods themselves don't contain valid information in their folders. The "version timestamps" listed in the mods are just the timestamp when the mod was created on the developer's local computer, not the time it was officially uploaded to the Steam CDN, so the timestamps inside the mods themselves are useless as version identifiers.
I've actually been having severe degradation of apparent download quality on Steam recently as well, not related to DayZ, but just globally. My hypothesis is that some downloads are being fetched in hunks and aren't just linearly downloaded, but files get extracted in atomic pieces partway through the process, at which point the download speed ramps down while it performs actions on disk, then after extraction, the download actually resumes and ramps up. This seems to happen when preparing shaders as well. Another thing you can try is changing your download location in Steam's settings menu to an alternate region. Generally the speed shouldn't be affected, even if it's a less proximate region (downloading is not really latency bound here and all of the servers use a fat pipe).
I guess what I am trying to say here is that the concern over this element in particular is unfounded, because if it wanted to, the DZGUI application itself could delete your entire hard drive. xdotool just moves the mouse and keyboard around. When using a script like this, you are putting implicit trust in the process, and as a testament that it does what it claims to, the code is provided open-source on the repository so that you can audit it if you choose to, or you can reasonably assume that the code has been audited for anything nefarious by the other large numbers of users looking through it. But as with anything, it's provided on an as-is basis. If you don't audit the code yourself (which is reasonable), then you are trusting that, by virtue of it being open-source, there's no way for nefarious activity to be obfuscated in there. The full source of the C binaries we use to calculate geolocation is also included in the repository. DZGUI already downloads files and creates/deletes directories, sends launch parameters to Steam, checks the Internet for latest version info, etc. If you don't like the feeling of a "ghost in the machine" that visually interacts with windows onscreen, manual mode is indeed an option, although a better way of clarifying this for yourself would be searching for "xdotool" inside of the script and inspecting the lines in which it is invoked (total of 6 lines):
In answer to your question, both manual and auto mode currently use xdotool. Manual mode at a minimum uses it to raise the progress window when mods are downloading. (We were previously using wmctrl, another generic tool bundled on most systems that can be used to raise/focus a window.) |
Beta Was this translation helpful? Give feedback.
-
|
Status update: v. 3.1.0-rc.11, testing branch
|
Beta Was this translation helpful? Give feedback.
-
|
Just got the update to 3.1.0-rc.16. After download, when attempting to run it, get a "Requires python >=3.0" error. Current python version is very much newer than 3.0. Not sure if you have run into this, so thought I better let you know. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the report. Can you tell me the output of |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, took awhile to figure out the correct command, but finely got Python 3.10, hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
OK, try now. It should only check the Python version during first-time setup now. This is related to a change around faster/simplified path discovery of the DayZ directory, as I was still unsatisfied with initial setup for people with large/multiple drives. If curious, you can test it by backing up your config file and re-running initial setup. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, took a while to figure out what dzgui.sh I had to revert, but finally figured out I could find it by looking at the properties in Steam for it. But finally got it reverted to the previous version and got the 3.1.0-rc.17. That seems to work now without the python error. Really want to say thank you again for the hard work I can see you are putting into it. However, I am having to go back to work full time, and not sure how often I will have time to assist with this. The schedule is pretty different from what I would typically work, so it will take me some getting used to. It may have no impact, but going from self-employed with to much time on my hands, to back to a full time job is going to be interesting to say the least. First day is tomorrow. If you have anything specifically you want me testing in the new version please let me know and I will see about it when I have time. |
Beta Was this translation helpful? Give feedback.
-
|
Sometimes I forget that people have this added to Steam, making it more immutable and less easy to change. Perhaps we could add a "rollback" feature that would fetch the last known working version in the event that the application fails to load or set up. It seems a bit overkill to me at this point in time, however. Congratulations (?) on the new position and thank you kindly for your support thus far. Best of luck. There is nothing major of note planned at the moment, just working on bringing the changes from Testing into mainline and streamlining some of the setup and ways of managing servers. I did recently add a "Recent servers" option in Testing that should show you the last 10 servers you connected to via any method. I was also thinking about whether it would be good to prompt to save a server to your favorites list when you are just connecting ad-hoc to one, but this would necessitate further overhaul of the way we manage server IDs/IPs. Unless something else breaks, I think server management/adding is the only thing that could be worked up a bit better. I can't think of too much else we can add at this point, but maybe there is something. |
Beta Was this translation helpful? Give feedback.
-
|
@SteveIDusa Hi, hope you are well. Due to a lack of interest/need from users for a dedicated discussions area, I am archiving this channel. Please direct future correspondence, if necessary, to the Issues page. |
Beta Was this translation helpful? Give feedback.
-
Discussion of features-in-progress on the testing branch that do not explicitly fall into the category of bug.
Beta Was this translation helpful? Give feedback.
All reactions