Closed aclist closed 2 years ago
As directed, I will now add a 3rd Server that no longer works: 13193240. This is the one that I have been playing with my Wife for last few weeks with out any issue. Logged several hundred hours with here in fact since finding DZGUI. But all of a sudden it too has the malformed character and links.
I am beginning to wonder if some one is being malicious....this was working perfectly! And yes I did notice the malformed links.
Heck, for that matter, how about I just explore the server list on their site: 15269094 - First Mod = Malformed 15082587 - No Mods 13864540 - First & Second Mod = Malformed 14669757 - First Mod = Malformed 14879780 - First to Ninth Mod = Malformed 14876019 - First to Third Mod = Malformed 10208960 - First Mod = Malformed 13667986 - First to Forth = Malformed 13864537 - First to Fifth = Malformed 14944597 - First to Third = Malformed
I will stop here, this is the first 10 Highest ranked servers on their list. I have recorded these as I think it might to be interesting to come back in a few days/weeks and just see if the malformed links have changed in any way. As in, "are they growing?"
Another interesting note, While I was typing this out, the last on the list was still open on the Battlemetrics website in another window, it suddenly refreshed and all of the mods are no missing completely....maybe being worked on? Even refreshing the webpage for it does not bring the list of mods back.
I have also sent them an email to bring this to their attention.
Preparing a hotfix...they are forcing my hand. It is working, but need to test that the game launches correctly.
Yeah, the modlist for your server is a complete mess now.
@SteveIDusa
Here is a hotfix, please test: https://raw.githubusercontent.com/aclist/dztui/testing/dzgui.sh
This is outside of the auto-download functionality, so you'll have to save the contents into a text file, make it executable, then run it. I disabled the version check, so it won't prompt you to fetch a different version.
Once this is working, I'll push it to the main branch. (Maybe there should be a mechanism for downloading different versions from inside the app, (e.g. stable/testing branch) but seems kind of overengineered.)
Thanks.
By the way, regarding server 15082587, this is one that unusually doesn't have any mods by design (note the name of the server). This was helpful to find, so I added an exception for the scenario where no mods exist on the remote server.
I had noticed the name for 15082587, I only included it as it was in the top 10 and I was just really taking a look at if the problem was prolific or not. It seems it is prolific or is either becoming prolific, so nice boon that it made you consider something perhaps not really considered previously since it was not part of the problem that you are addressing.
Regarding the Hotfix, do I need to place this inside the folder with my other dzgui downloads or place it somewhere else?
I dropped it into a folder adjacent to my original downloads, saved it as a .sh as the others and set to executable. When run the Newer Version available dialog does pop up which shows that my version is 2.2.1-rc.1 and wants to point me to 2.2.0. I have told it No.
The last thing that I was doing last night was removing mods to try again when I realized I was to tired to continue, so this did cause DZGUI to prompt to download the mods. Which was likely a good test...
Oh.....trying to download via Steam Client rather than the website?......Nice! Slower, but nice! No need to sign into Steam on their website. Did I mention it being slow previously which caused trying to speed it up that has resulted in all of this? I hope not....but my brain is trying to remember something here I think......:(
I really wish Steam would update the Steam Client to show you what is downloading from the Workshop for DayZ. It just says DayZ and stacks them all up. Is it like this for all games and the Workshop? That is irrelevant and you do not need to address that.
All of the mods downloaded as expected after clicking the subscribe button.
Loaded into the game without an issue!
Thank you! What is different? What crossed your mind to see a way around BattleMetrics?
Sorry, I think I intended to comment out the version check, but then I made some changes, and I ended up overwriting everything again. Anyway, I pushed this version to the mainline branch, so you shouldn't get a version conflict popup anymore, unless you use the old file. Happy to hear it is working.
Yeah, I noticed we were listing the web site URLs and just figured might as well use the internal Steam URLs instead. I think they just queue up the mods under the games in the downloads page. I don't know if you can expand the info on that page, never tried.
I'll outline what was changed tomorrow, kind of tired right now. I also started experimenting a bit with a method that would use Steam native APIs to get server status, fetch mod list, and find IDs of mods, but it's a bit flaky at the moment and I need to ensure it's reliable. If we go that route, it would mean the user has to generate a Steam API key instead of a BM one, but it should be much more reliable than a third party service.
Sounds good, looking forward to it, but no hurry. Sounds like you could use some rest! Thank you again!
I do not know how you do it, but to be able to implement a fix in less than 24 hours and I am able to get back to both servers, WOW!
One thing that occurred to me as I was downloading mods, would it be much work to add a list of numbers next to the mods download links, as in 1. 2. 3. 4. 5 etc No it is not necessary, but would be a nicety for keeping track of where one is in the process/progress. Obviously, the other option is to just click next in DZGUI and have it present a new shorter list after so many subscribes, but thought I would at least ask about it, as I kept having to count links and make mental notes and such....Thank you again. I suppose this should be in a different location?
New development, after joining the Hard Home Melkart Map once just to confirm it would work, I logged out and had some lunch while I waited for my wife to finish up an event she was participating in. When she had finished, I attempted to login using my favorite server link. Now, since I had messed with the configs and removed mods, I can not remember if I ever actually choose a fav. But when I did that, it seem to try and join the Melkart server which I have never used as a Favorite and this caused .pbo errors. But the .pbo errors seemed to reference the other server rather than the Melkart server. But then when I choose using the List of Servers and Optimistic Army, it loaded just fine without issue and we got several hours of play. Seemed weird so I thought I should mention it.
It looks like I introduced a regression having to do with the fav server select during the hasty hotfix (https://github.com/aclist/dztui/issues/17). I just pushed a new fix for that. I believe that probably relates to the issue you described, but I was a bit unclear from your description what exact steps led to it occurring. It sounds like a variation of an old bug where when you launched a server from the main menu, then exited back, then selected favorite, it was sourcing the parameters from the first server instead of updating.
Try the new version and see if it goes away. There shouldn't be any situations where the main server select leaks into the fav server at this point, so far as I can see.
As for the fix, it's definitely a workaround and not a beautiful solution. Now we're using Yet Another Third-Party API to fetch the correct mod IDs, and only using BM to get the basic server info (since their mod info can no longer be relied upon--"fool me once"). This is fine, but the weakest link is still these third party APIs. It looks like Valve's first-party API lets you get all of the server information we are currently getting, but when it comes to the mods, only returns the literal names reported by the server, so would have to do a reverse lookup on the names using a different Valve interface to find their actual IDs (for downloading).
This all seems to work OK from testing, but getting the proper names back from the server encoded without any garbage is a bit problematic still. I did also find a method of getting the list of every DayZ server reporting as public (10k+ in one shot) without a third party API, so we could theoretically even make a full-scale server browser, but that seems totally unnecessary for now. I guess the basic workflow would be that you'd use the BM web site to browse for servers you like (lots of info about uptime, proximity, etc. that is probably more useful than a generic server browser I could make), then use the IP/port as an identifier instead of the server ID, and process the rest directly through the Steam APIs. I need to make a proof of concept and see how it all works end to end.
Numbered mod list: I added it.
I have introduced a method of toggling between stable/testing branches of DZGUI from within the app. I want to use this to deploy new features "over the air" in testing without affecting other users.
If you toggle debug mode from the main menu, then enter the debug options mode, this exposes a "toggle branch" feature. This lets you switch to the testing branch, and will use the existing download logic to pull down the latest version if there is a new one. You can switch between branches on the fly and it'll always check whether you are in synch.
I'd like to start using that to trial fully automatic downloading of mods, since I think I finally conceptualized a way of using steamcmd that is going to be low-impact for the user. Downloading 20 mods is extremely annoying, particularly when troubleshooting, so I'd like to see if this can be automated while still being user-friendly. Fully automated downloading is already working on DZTUI, so it's just bringing that functionality over while making it a bit more intuitive. If you want to be a guinea pig for that, I'll start working on that and release it to the testing branch when ready.
Currently, both stable and testing are running the same version.
Priority for now is:
Got home this evening and deleted all of my mods, unsubscribed and deleted my config. Launched DZGUI and everything seems to work as expected. Numbered list is a nice touch, thank you! Did not remember however to us the "Toggle Branch" Feature, will take a look at it tomorrow evening. Looking great so far!
Toggled Debug and found the Change Branch, though I did not see any changes take place, even restarting DZGUI did not prompt to download anything. But was able again to login to server and play for a few hours with the wife. Let me know if I missed anything or if you want anything tested specifically. I have read the above post a couple of time but it always after I am tired and ready to unwind...lol. I may be missing things.
It's nice of you to always go the extra mile and clear out your mods and reinstall them when testing.
The stable and testing branch are currently on the same version, so even if you toggle to testing, there will be nothing new to download--yet. When new features are elaborated on testing, they can be grabbed by switching to that branch.
This is just a backend change that will facilitate introducing unstable features without affecting the rest of the population.
@SteveIDusa
Hi, hope you are having a good weekend.
I pushed a release candidate to the testing branch that contains a large number of small features. If you switch to testing and update versions to 2.4.0-rc.1
, you should see numerous quality of life changes listed in the changelog.
Ones of note are:
The last one is important. It changes the way symlinks are created by encoding them into shorter IDs, instead of verbatim mod names. There were some servers with so many mods, that the launch options are too long for Steam to handle, and the mod names have to be minified.
To counteract the names becoming more obscure, the List Installed Mods option now also displays the corresponding symlink ID next to the real mod name. The user shouldn't need to touch the symlinks under normal use, but it's there just in case.
This last part should be working, but it does affect the way we prepare the launch options for Steam, so please test it. You should also see that in your DayZ path, the symlinks now have short alphanumeric names. It should also be smart enough to update your existing mod links to the new format, so I would recommend testing in two ways:
Thanks in advance.
Got a chance to try the new rc today, sorry about the delay, family came down with covid. Was able to connect to old server with out issue today. Will follow up regarding testing fetch of mods in the next couple of days.
Sorry to hear that. Hope you will feel better soon.
Had a chance to test further today, added a third server that needed mods downloaded. Seemed to work just fine and only added missing mods. One thing that I did notice is that every time I click on the DZGUI generated html page with the links and click on the first link for the first time, it always asks me if I want to have my web browser to always remember my choice, but it only does it for that session. Next time I have to download mods it will do that again. Is this an issue with my web browser?
Well, darn, after loading the mods, I got the pbo error.
So, I down graded the version to the 2.3.0 and that allowed me to connect to the new server.
steam://
links as always openable in Steam, correct? That's a browser-side issue. I'm not sure why it's not persisting, but I can test it. What browser are you using?This is done deliberately to prevent the casual user from switching to the Testing (unstable) branch unless they explicitly open the debug options.
As for versioning, it works like this:
If you are on Stable => checks upstream Stable version for changes If you are on Testing => checks upstream Testing version for changes
When you switch between versions, you will always receive a warning to update, because the Testing version by definition won't be the same as the Stable version. Each time you switch branches, it just fast updates the local file with one or the other version. There is no management of versions locally, so you will always have one or the other version fetched directly from upstream.
As for the message itself, it's a bit of a misnomer to say "newer version" here, since the version check is merely checking whether local version == upstream version, in order to ensure total parity. It's never going to be the case that the upstream version is a lower version number (patches increment the version), so except in the case you mentioned, "newer version" should essentially be a true statement.
If your config is currently on Stable and you manually download a different branch from GitHub without updating your config file, such as (e.g.):
It would then appear that the "newer version" message is incorrect, since the app will be checking the Stable branch, seeing a version mismatch, then prompting you to "update." But what it is in fact doing is prompting you to synchronize your stated branch in your config file with the master version on that branch.
Newer version available.
Your branch: stable
Your version: 2.4.0-rc.1
Upstream version: 2.3.0
Note the Your branch
message when receiving an update warning. Perhaps the key hint you missed here is that an -rc
version can never appear in stable
, since those are testing versions. The message looks like a downgrade, but it's in fact a version conflict.
To alleviate these kinds of version conflicts, the in-app branch toggle always updates both the config file and the version, so you can switch between either branch and never fall out of synch.
I suggest you use the internal toggle and always accept the download when switching branches.
I'm elaborating on this because I think I will reformulate the warning to be clearer:
Version conflict:
Your branch: stable
Your version: 2.4.0-rc.1
Upstream version: 2.3.0
But in practice, this should never happen if using the in-app toggle. I also asked if you had used the in-app toggle because I wanted to know whether I made it clear enough to use, but it sounds like I hid it a bit too much (for the aforementioned reasons of not letting users hop into the testing branch unless they really want to.)
The one flaw here I can see is that if someone toggles to Testing, then toggles back to Stable, but decides to refuse the download (as you did), they are going to run into possible problems, since they won't actually be on the Stable version. I think what needs to happen here is that the download prompt when switching versions is enforced. That's an oversight on my part, will fix it.
Once you get up to speed on the in-app toggle and the versioning, you could try checking the server in question again, making note of which branch you are on.
OK, I tested the server in question and wasn't able to reproduce your issue. Sounds like a false positive. Was able to get into the server.
The testing branch uses a new method of creating symlinks, while the stable version is on the old format. When using the new version, it checks for the "legacy" version of symlinks and updates them all to the new format.
Since you mentioned only downloading some missing mods, I downloaded some of the mods for that server on the stable version, then the remainder on the new version, to see if I could trigger a conflict in the way the symlinks are being prepared, but the additional methods I added for handling legacy symlinks in the testing branch ensured that everything was created correctly. For that matter, even if you had downloaded mods with the new version first, the old version also takes care to prepare all of the mods in its old format, so I don't think there is a scenario where they could get misaligned. I added a lot of precautions to ensure that whatever version you are using, the mods don't break.
I'm working up a series of changes over on testing:
This won't be totally seamless until these changes are propagated to Stable with version 2.4.0
, which I think is basically ready to go, but I'll await your confirmation. Thanks.
You are doing a great deal of work! Thank you!
Had an opportunity today to switch to debug mode, then changed branch to testing. Attempted to connect to the offending server again while in debug. Received the dry run message with launch options and clicked on the write to file button.
Then went back into debug to turn off debug mode and launched the offending server again. This time it launched DayZ but again gave the Warning (0x00040073) message and stating that client was kicked from game due to data verification error, Client missing a Mod which is on the server. Again indicating that the (ZDS_Signs) mod is missing with the Missing PBO. message.
I then closed DayZ and relaunched DZGUI, on this launch I did not get a message about downloading a different version it just automatically loaded the testing branch. I then again toggled debug mode, choose the debug options and toggled branch back out of testing. This then caused DZGUI to display the "DZGUI 2.3.0 successfully downloaded message.
I then relaunched DZGUI again, which indicated it wrote a new config file. I then attempted to join the offending server again, this time out of the testing branch and on the stable branch. With this launch of DayZ however I now received a Connecting Failed Error (0x00020010) error "This server is currently locked" and not the missing .pbo error as with the testing branch. I then gave it a few moments and tried again, just to ensure that perhaps I had logged on just as the server was doing a restart or something. But received another connecting failed error (slightly different number) with could not connect as server is unreachable error. Though my wifes windows machine could see it at the same time.
So I don't know......I gave it a few moments more and after finishing typing up the above and using the stable branch, I attempted connecting a 3rd time and was able to connect without any errors. So something about the stable branch is slightly different then the testing branch it seems.
Thank you for the testing!
Writing the dry run launch options to a file is intended to let you keep a log of it in case you want to share the exact launch parameters with the developer. Is this clear? Maybe the dialog needs a reword.
It honestly sounds like you got unlucky with the timing and hit this server just as they were locking/unlocking it and switching some stuff around (that's fairly common). A server might show a current player count but be locked to new joiners.
I'm a bit concerned about that particular mod causing an error for you, but it is true that some servers enforce a specific load order, so if it was in the midst of some reset, perhaps something funny happened.
I'm not discounting the possibility that this is a bug, but I haven't been able to reproduce any connection errors on any servers yet.
I would greatly appreciate it if you could, when you have time, attempt to connect to this same server while on Testing and repeat the test 3-5 times. If it always happens, I will consider it demonstrable proof, and we can focus on tracking down what is going on with your setup.
It looks like Bohemia finally provided some additional info on how to decode the additional mod info they are sending over the A2S protocol, so Battlemetrics is not showing malformed IDs now. Looks like we can revert to the old method.
Emerged from a fog, the light is bright!
Regarding the launch options, it was clear to me that it was for providing to you. However it did not include a location as to where it was written, so I had no idea where to find it.
That was likely it for the server being locked to new joiners, my wife recently had the experience of playing while others could not join until they updated a particular mod. She came to the conclusion after the fact that had she disconnected during that time frame she would not have been able to rejoin until she updated the mod. She came to this conclusion after finding that the mod had updated during her play.
I also have not had the mod issue after that last one, so I think you were right, likely not a bug but rather timing. Unfortunately, It has been long enough now that I can not remember which server was having the issue.
I did note that you have done a couple of updates while I have been "mindless". The last one and the QOL changes are very nice! I saw the changes to the size and shape of the dialog boxes and I for one really appreciated these changes! I am also now fully aware that dialog boxes that display a sentence as a sentence rather than a stack of words is something that can be changed. I will never look at another Linux program the same way again....you have raised the bar!
I also noted that during my mindless phase, that at some point I stopped opening a terminal and setting the map size....and I have never made the change permanent, so am I right to think that it crossed your mind to add this to the launch options so that it just happens for any user? Either way, it is nice to be mindless when launching a game! So if you found a way to do it or if Bohemia made a change I like it!
So I am way out of the loop now, and behind in your progress. So, is there anything you would like me to test or stress? I am currently on 2.4.1 Stable Branch.
Just did a debug mode and wrote a file just to see if I could find it, found .png files instead.....setting up to add to steam as a non steam game???? OH!!! Just went back to documentation to see if you had an updated section on the launch option file and where it may have been written and found the new artwork there......lovely!
Followed the instructions for the artwork and everything except the icon was working perfectly within steam. Took a couple of minutes to fumble my way to it, but I finally realized I could change the file type from .png to all files in the dialog box and get the icon image to populate in Steam. Looks great!
Update: couple of hours later.... After playing for a bit last night, got up this morning, responded here and attempted to launch the game. Was immediately hit with missing PBO error for X2Taser (1593012445), which was not happening last night on server ID# 13193240. Attempted to unsubscribe from this mod and then re-subscribe to same result. Then unsubscribed from all mods, deleted all references on system both in .local and .steam locations. After this did a local file verification and fixed missing files, did not realize that I should not delete the "bliss" mod. Verification got it back and it showed as only mod installed. (This must be a bohemia provided mod?)
Anyway, after the clean up, launched DZGUI and downloaded all of the mods anew, only steam was not auto downloading in the back ground. I confirmed this by opening the mod folder and after subscribing to all of them and it was still empty. Restarted steam and then all of them downloaded.
After download DZGUI then would proceed however now it gave a missing pbo error for a totally different mod. I grabbed a screen shot but do not know how to attach it here.
Hey, glad you are feeling better.
Just the man I wanted to see! People keep submitting reports and then leaving after the bug is fixed without confirming whether everything worked as expected. (Which I guess means it is?)
Regarding the launch options, it was clear to me that it was for providing to you. However it did not include a location as to where it was written, so I had no idea where to find it.
OK, right, I can add that.
I am also now fully aware that dialog boxes that display a sentence as a sentence rather than a stack of words is something that can be changed. I will never look at another Linux program the same way again....you have raised the bar!
Not sure if you are making fun of me or not, lol. I noticed when testing on Steam Deck that some dialog boxes were getting super squashed, so it needed to be fixed. There may be some other dialogs that don't look right, so if you see any, let me know.
I also noted that during my mindless phase, that at some point I stopped opening a terminal and setting the map size....and I have never made the change permanent, so am I right to think that it crossed your mind to add this to the launch options so that it just happens for any user? Either way, it is nice to be mindless when launching a game! So if you found a way to do it or if Bohemia made a change I like it!
The app includes a check now at start and will prompt the user to set the map count if it's too low. It might have changed on the Proton end, I don't know. You can check your current count by invoking sysctl -q vm.max_map_count | awk -F"= " '{print $2}'
So I am way out of the loop now, and behind in your progress. So, is there anything you would like me to test or stress? I am currently on 2.4.1 Stable Branch.
There's a new pending release candidate on Testing that includes fixes for two bugs:
Followed the instructions for the artwork and everything except the icon was working perfectly within steam. Took a couple of minutes to fumble my way to it, but I finally realized I could change the file type from .png to all files in the dialog box and get the icon image to populate in Steam. Looks great!
Right, I should add a note to select All Files.
After playing for a bit last night, got up this morning, responded here and attempted to launch the game. Was immediately hit with missing PBO error for X2Taser (1593012445), which was not happening last night on server ID# 13193240. Attempted to unsubscribe from this mod and then re-subscribe to same result. Then unsubscribed from all mods, deleted all references on system both in .local and .steam locations. After this did a local file verification and fixed missing files, did not realize that I should not delete the "bliss" mod. Verification got it back and it showed as only mod installed. (This must be a bohemia provided mod?)
Not sure about the bliss mod or what it is. I suggest trying the Testing branch because of bugfix 2 listed above. There might be a collision in the symlinks.
By the way, when troubleshooting mods, you can turn on Debug mode, go into Debug options, and select "Generate debug log," and it'll write a log file containing all of the mod details and other diagnostic data.
I grabbed a screen shot but do not know how to attach it here.
I believe you can just drag/drop images directly into the text pane and it'll upload them.
Not making fun of you at all! You literally have raised the bar by which I will judge other software dialog boxes. I thought it was a linux thing for years, that it was something that the programmers had no control over. I think this no more, and as I become more proficient with programming, it will effect how I approach interfaces. The only other dialog box that I thought could use some improvement was the mod requirements satisfied box. It still seemed a bit mushed.
Speaking of interfaces, I got so fed up with my Linux Mint installation today I decided to backup what was important, nuke the drive and do a fresh install of Linux Mint 21 Mate Desktop Edition. (Discovered that I will never again attempt to boot Linux using secure boot - seems I thought this previously, perhaps even decided this previously) This gave me a chance to download the DZGUI .zip to a new installation. It has taken me all day to get DayZ up and running again. For some reason, the installation paths changed and are no longer the same as the last installation.
Previously, I had the .local/Steam/ File path, now I have /.steam/debian-installation/steamapps/common/DayZ
The DZGUI install.sh script, I set to executable, and ran in a terminal, it allows me to populate a name, the API Key, a server ID# and then immediately jumps to a Searching for alternate DayZ path progress bar. (by the way, I see a typo....it says "Searching for alternate DayZ path (make take some time)....should that be "may take some time"?
Unfortunately, it has been here for quite a while and has not found the path above.....activity light seems to indicate it is doing something , but I can not believe it would take this much time.....perhaps I am not being patient enough....would it be possible to have it ask if the user if they would like to specify the path or do an automatic search?
The only thing that I can think of that I did different, was to download steam via the built in Mint Software Store, rather than getting it from steam directly on their website.....should I consider nuking the installation and grabbing steam official?
Are you talking about this one?
Launch conditions satisfied. DayZ will now launch after clicking [OK].
There's a lot of variability in how different distributions and desktop environments render these things, so the best we can do is err on the side of generous sizing and padding and hope it looks decent in most cases. I was surprised to see that a lot of dialogs on Steam Deck were crammed into thin strips in the center of the screen (taking up 5% of the screen) until I changed the dimensions.
The path search takes quite a long while on my machine as well, since it scans literally every directory. Try waiting and seeing if it takes longer than 5 minutes? We have no guarantee of where someone could have installed the game, so I thought this was safer. But maybe certain paths it absolutely can't be should be excluded altogether. But maybe this is trying to be too smart about it...alternatively, we could just present a file selection dialog and let the user find it themselves IF it's not in the default path. Thoughts? This might just invite a lot of questions of "I don't know where DayZ is installed," though... ( I can see it now)
The only thing that I can think of that I did different, was to download steam via the built in Mint Software Store, rather than getting it from steam directly on their website.....should I consider nuking the installation and grabbing steam official?
No, always favor your distribution's package over a download for the purposes of linking to local libraries.
"Searching for alternate DayZ path (make take some time)....should that be "may take some time"?
Thanks, fixed the typo.
Yeah, that is the one as far as the dialog box, so are you telling me I should not be inclined to spend extra time making sure it will look correct for what ever distribution I use cause it will likely not matter on another??? If that is the case, how is it not standardized across distro's......I have been using Linux for over a decade easy, is it that hard to get ever distro on the same page regarding something I would consider a no brain-er? I would think the community no matter how diverse would welcome some kind of design standardization....that does not happen?
Regarding, the version of steam and from where I get it, after posting that, I nuked that installation and tried the one from steam directly, but it just used the same paths, so not sure that it really mattered. They both launch steam and I can see my game libraries, so they both seem to work.
I gave the search for alternate path box nearly 1/2 an hour....but I have 3 SSD's installed, 1. NVMe 1TB, 2. SATA SSD 1TB and 3. 120GB SATA SSD. Is it set to search the boot drive first? And on a clean install with the only things installed besides the default OS being Dropbox, which I only use the free version, so it is not very large...would/should it take more than 1/2 an hour?
I guess I just have to let it sit and try, cause it will not create a config file until it does....
Yeah, that is the one as far as the dialog box, so are you telling me I should not be inclined to spend extra time making sure it will look correct for what ever distribution I use cause it will likely not matter on another???
I think it's mostly consistent, but this dialog system uses the local system's GTK settings, so depending on what window manager/skin/theme/font size/etc. you have locally defined, your windows could look vastly different from mine. This shouldn't be a problem, but the GUI parameters expect hardcoded dimension values (which is bad), rather than just letting me specify relative numbers like 50% of screen, etc. We started by taking the hardcoded 1200x800 dimensions of the Steam Deck and working around those. Basically, we can't create anything so large that it'll become occluded on the Steam Deck, so that's the weakest link.
If that is the case, how is it not standardized across distro's......I have been using Linux for over a decade easy, is it that hard to get ever distro on the same page regarding something I would consider a no brain-er? I would think the community no matter how diverse would welcome some kind of design standardization....that does not happen?
Linux is all about 14,000 ways of doing the same thing. Embrace the fragmentation, baby!
Regarding, the version of steam and from where I get it, after posting that, I nuked that installation and tried the one from steam directly, but it just used the same paths, so not sure that it really mattered. They both launch steam and I can see my game libraries, so they both seem to work.
By local libraries, I was actually referring to the equivalent of Windows .dlls, not game library.
I gave the search for alternate path box nearly 1/2 an hour....but I have 3 SSD's installed, 1. NVMe 1TB, 2. SATA SSD 1TB and 3. 120GB SATA SSD. Is it set to search the boot drive first? And on a clean install with the only things installed besides the default OS being Dropbox, which I only use the free version, so it is not very large...would/should it take more than 1/2 an hour?
OK, yeah, I can see how this would be a problem. It's probably just going through every one of them. It starts at /
(root path) and searches everything, including drives below that. I'm not opposed to showing a file dialog. Maybe we could attempt to find the path automatically and give up after a couple minutes?
Some options:
Any preference here?
I had the same thoughts, I think 1 or 2 would be a good alternative or even 3, actually all 4 would be fine. I guess I would as a person that did production manufacturing for many year and was brought up in the idea of lean manufacturing, I would suggest what ever is the least amount of work for you but provides the option to interrupt or interrupt it auto-magically after a set amount of time is how I would focus my time. Any user that is attempting to use this is likely a little more advanced than a Windows user and should be able to do a google search to get an idea as to where to look.
I have the most recent stable version of DZGUI doing a path search now, it is into it 15 mins by my phones stop watch and counting. I did save an older version, which I can implant into the DZGUI location, so as to prompt to download a newer version if you get an alternate out, until then I will just let it search and watch some vids or something.
UPDATE: 1 Hour 5 Mins, and it finally created a config file, going to start with getting the testing branch.
Sorry to make you wait, but the fix was taking over an hour anyway. I basically have it working now (file picker etc.), but had to add a slew of error handling and additional control flow for if the user breaks out of the auto-search process prematurely. Not quite finished yet. Managing subprocess IDs is a bit of a pain when doing everything by spawning GUI windows versus a pure terminal application.
I did save an older version, which I can implant into the DZGUI location, so as to prompt to download a newer version if you get an alternate out, until then I will just let it search and watch some vids or something.
By the way, you can just edit the first few lines of the file and change the version number to anything else if you want to trigger a version conflict. No need to insert new files.
No problem, it finally went, I will do some more investigating tomorrow, did get a couple of hours of play time in, so it is all good!
I was having one of those "going down the garden path" moments with the file picker idea. I spent a couple hours elaborating it, doing the path discovery stuff and then checking if the user had canceled the process or it had failed of its own accord (giving it a 45 second cutoff), then capturing the pid of the progress window and killing it, sending the user to a file picker dialog, blah blah blah. It was getting rather finicky to deal with the process IDs of these dialogs getting spawned and going away all the time, which is really the Achilles' heel of a GUI like this where everything has to be nested and recurse over and over again.
Anyway, I got up and walked around and asked myself, "What the hell are we actually trying to achieve, here?" The problem is dedicating too much time to scanning the directories, after all. I'll plead the insanity defense on this one.
So I attacked it from a different approach:
$HOME/.local/share
as the canonical path, but it's easier and faster to just check $HOME recursively for anything on the first pass, which will capture atypical locations like Debian's .steam/debian-installation
. And we don't have to add a bunch of handling for every distro.So first pass checks $HOME and should capture 99% of likely installations. Second pass checks /
but skips all of the garbage and hopefully chugs through it much faster.
I noticed a considerable uplift in scan time on my system using this new method. I mean, basically it is instantaneous now. It takes 0-5 seconds to finish, and that's for a non-standard location on a second drive.
But I'm curious to see performance on your server farm full of hard drives. You can test the following:
Checking $HOME on the first pass:
time find $HOME -type d -regex ".*/steamapps/common/DayZ$" -print -quit 2>/dev/null
Trying the root path as a fallback:
time find / -type d \( -path "/proc" -o -path "*/timeshift" -o -path "/tmp" -o -path "/usr" -o -path "/boot" -o -path "/proc" -o -path "/root" -o -path "/run" -o -path "/sys" -o -path "/etc" -o -path "/var" -o -path "/run" -o -path "/lost+found" \) -prune -o -regex ".*/steamapps/common/DayZ$" -print -quit 2>/dev/null
These should return a total time to process in seconds.
Next, try this without suppression of error messages:
time find / -type d \( -path "/proc" -o -path "*/timeshift" -o -path "/tmp" -o -path "/usr" -o -path "/boot" -o -path "/proc" -o -path "/root" -o -path "/run" -o -path "/sys" -o -path "/etc" -o -path "/var" -o -path "/run" -o -path "/lost+found" \) -prune -o -regex ".*/steamapps/common/DayZ$" -print -quit
It might return that some directories are "permission denied." I included most locations in the exclusions list, but there may be some others that could be excluded to speed up processing still further. We're basically skipping looking inside these directories altogether because it's pointless to do so or because we don't have permission.
If you see any permission denied directories that should be added to the exclusions list, you could mention them here, unless it's something sensitive.
It took 0.537s to scan the entirety of /
for me and find the DayZ path.
I'm pushing these changes to testing as well, but can further refine it based on your input.
I really enjoy hearing you think, and consider. It really does help ones brain to rewire.....when you get to see someone else doing what you do! Thank you for sharing the though process and your conclusions.
Ran all three commands and the highest time I have using them is 110 ms, so yeah that is what I would call instantaneous!
Got up this morning early, and while waiting for the rest of the family to get moving, jumped back to DZGUI and toggled the branch. Using 2.4.2-rc.6, when I select "Launch Server List" I am getting a blank screen. Toggled both debug and normal modes and still no servers are listed. When I attempt to add a server in normal mode, it provides the dialog box, and when I put in the Server ID# it then provides the "Added 13193240 to: path which is /home/MyUserName/.config/dztui/dztuirc If errors occur, you can restore the file blah blah blah - dialog box. I then hit the O.K button and it takes me back to the main screen, however when I then select Launch server list again it again is blank giving no optional server to choose.
I then switched over to debug mode and attempted to add a server, but to the same result, so it seems that there is a bug in 2.4.2-rc.6 If I switch back to release branch, it downloads 2.4.1, creates a config file, and then displays my previously selected server as if I never toggled the branch. I have yet to test if it will launch and allow me to play this morning, but I have other things to take care of before I can test that part. But I thought I should let you know about the bug....at least for now.
Well, at least the path discovery is fixed.
OK, damn, seems we have a regression. Looks like I am working overtime. I've just confirmed the behavior and will try to get a hotfix or a rollback pushed out.
Should be fixed now on 2.5.0-rc.2
2.5.0-rc.2 does fix the no server list issue. Going to load up the game and join the wife in some online play. Thank you very much for you hard work! It is Sunday however, I could have waited, all of us could have waited. It is ok to take a breather you know???
OK, good. Well, there are some people taking refuge from rare bugs in the Stable branch like trying to load very large server lists or servers with a large number of mods, so I feel like they need at least one viable branch here while I hold back the release a bit more.
Thank you again for the hard work! It is much appreciated! And, the other day when I did the full system wipe and reinstall of the OS, I had the reason to go back to protondb and find the Map Size command thinking I still needed it. Noticed a mention or two, so I did a page search for DZGUI and got quite a few hits, so you are definitely filling a gap for us Linux Users!!!! Any change to analytics? Are you seeing it grow? Can you see it grow?
Yes, I try to check that page from time to time to see if there are any issues users are facing and think about ways of preemptively addressing them.
As far as discoverability goes, this project lives inside the original DZTUI repo, so the term "DZGUI" doesn't get indexed by search engines at all, so it's still hard for people to find. I'll move it into its own repository eventually.
After today's release and after adding connect-by-IP functionality in the release after that, I'll make a post about it on forums to give people a heads-up of where we have come since the original version. I think being able to connect to some arbitrary IP a friend gives you is still highly sought-after.
I did a feasibility test for having a server browser directly inside of the application. That is, search for and browse all of the available servers out there without having to browse them on the web or add them to a list first. It seems doable now, although we are limited by the GUI framework a bit. Still, I think it can be done, but will just take some time--and I'm not sure what if it's the "must-have" functionality right now. It's a toss-up between auto mod installation and server browser, but if we had both, we'd be sitting pretty.
I'm also developing more of a general purpose launcher for Linux games that I'll have you beta test before long, if interested.
Wow! Yeah, if both server browsing and mod download/loading was in a single package, you would be on par with the native launcher. That would be very cool!
A general purpose game launcher for Linux? So like a Lutris, or Game On Linux type of thing or an alternate interface for something between the user and Steam? I am curious...
Sort of a general interface for launching games and configuring their settings on the fly in a way not dissimilar from what is done here. I'll invite you to the project when it's ready.
As for DZGUI, connect-by-IP is now live on the Testing branch.
Requires an API key from here: https://steamcommunity.com/dev/apikey
When you choose to connect by IP, it will prompt you for API key if it's the first time. IPs can be entered as-is with no additional port. If there are multiple servers behind the same IP and running on different ports (e.g. hosting different maps), it will return them all in a list and let you select the one you want. It also prints the server metadata before connecting so that you can be sure the IP you entered is what you wanted.
You might be in luck, I happen to have a family member that has been hosting a local DayZ server, but they do not know how to setup port forwarding, so they and their immediate family are the only users on their local network. Perhaps I should assist them with figuring out the port forwarding so I can test that feature......The only real problem is that they are apart of the reserves and I never know when they are home or deployed....lol
Actually, someone else was also asking about the possibility of connecting to LOCAL servers from within the app. I guess you still need to set up launch params even if playing locally on your own server. I'm curious to know more about how that usually happens. Do they connect to an internal IP (192...) or just "localhost"? The big question mark here is where we would pull the modlist from if joining a local server. I need more info about where these settings are stored, and this seems to be arcana only known by server operators.
You can test connect to remote IP by simply copying the IP listed on any BM server page.
e.g. https://www.battlemetrics.com/servers/dayz/8789747 => IP given is 135.148.136.111
This exposes multiple maps on different ports.
Ok, had a chance to add by IP the other day, it asked me to provide a Steam API key, not having one or the time to figure out how to get one, I canceled and joined a game by server list. Today, having forgotten the previous attempt, tried again to join by IP, but this time, it indicated that it had saved a Steam API key, not sure how and then attempted to add by IP again. This time it gave an error that it could not add by IP with a "Failed to retrieve IP metadata, Check IP or API key and try again." error. So at some point I have to get the Steam API Key together, but thought I would share that it for some reason thought it had one. Server IP I attempted to use was 178.239.172.24 and the DZGUI version I am currently running is 2.6.0-rc.1
Well, it's not currently possible to add an empty API key in that field. If you cancel or submit an empty field, it will just take you back to the main menu and not write anything to the config file.
It sounds like you probably hit spacebar or typed a few characters and then canceled? I could add additional validation here to make sure the key is a certain length and at least resembles the correct API key format.
You can check your config file in $HOME/.config/dztui/dztuirc and the steam_api
field to see if something got inserted into there.
The process for registering is here: https://steamcommunity.com/dev/apikey
Yep, sure did, must have misread the dialog presented and thought it was asking for the IP address, cause that is what I found in the config. To undo this, just delete what is between the " "s or set it to a "0"? In other words, what do I do to make it start asking about the Steam API key again?
Also, I note that I do not find a reference to adding a Steam API key on the document page, likely as it is a release candidate feature. Have I forgotten how to get one? Did you share steps previously above that I have neglected? Never mind, I see it up there....
OK, I now have steam asking me for a domain, such as www.google.com or www.yahoo.com, what should I put here, anything, something specific? Make something up? I imagine that this would cause other users some hesitation. Perhaps a heading in the documentation with instructions is in order for the testing branch....
API may rarely return improperly byte-decoded modlist and mangle the output, concatenating multiple mods into a non-existent mod and assigning the wrong publishedfileid of some other content.