aclist / dztui

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

Clean Linux Mint 21.3 Install, DZGUI is unable to find Steam Path to DayZ #105

Open SteveIDusa opened 5 months ago

SteveIDusa commented 5 months ago

Possibly related to Issue #86

Hey ACLIST! How is it going? Just did a major upgrade to my system, installed a new faster NVMe drive and have been trying all morning to get DZGUI to setup, but it keeps giving me a weird error about the steam path....

When I run the command line option with dzgui.sh, it starts the process of wanting to "Start first-time setup now?" Select Yes button

Requests name, Steam API key and BattleMetrics API Key I provide all three and click on the OK button

It then provides the Question Dialog, "DayZ not found or not installed at the choosen path." I select the Choose path manually button. (Of note, I have already installed and loaded into a Vanilla Server, DayZ is installed and is located at /home/stephen/.steam/steam/steamapps/common/DayZ) <- Might be important.

Zenity then opens and I navigate to /home/stephen/.steam/steam/steamapps where I can see the libraryfolders.vdf file. But when I select the OK button the terminal spits out these 2 errors. usage: vdf2json [-h] [-i INPUT] [-o OUTPUT] vdf2json: error: argument -i/--input: can't open '/home/stephen/.steam/steam/steamapps/steamapps/libraryfolders.vdf': [Errno 2] No such file or directory: '/home/stephen/.steam/steam/steamapps/steamapps/libraryfolders.vdf'

Is it adding an extra steamapps folder search? It seems be indicating it is by the error.....

Anyway, I hope you are still enjoying the challenge of DZGUI, it has been an excellent solution that I continue to use and promote.

Thanks again for all the hard work!

SteveIDusa commented 5 months ago

@aclist Just discovered that my ".steampath" (Hidden in my Home Folder) indicates that it is broken. I also have been doing dome poking around in your files, and note that in your /helper/funcs script that it is calling for steam_path.

Just wanted to include here that I noticed these, could these be related to the issue? I even deleted the hidden broken link (to clarify it is a broken simlink) and closed and reopened steam, but as soon as it started the .steampath link was created anew and showed broken again.....

SteveIDusa commented 5 months ago

@aclist Well, I did something, like went and downloaded an older version (5.0.0) got it to run, and all of a sudden it was telling me that I had an older version and asked if I wanted to upgrade to 5.2.0 (I confirmed). Either way, suddenly it was able to launch without ever asking me for my steam API, or BM API keys. Not sure what just happened, perhaps you were pushing a fixed update while I was messing around......?

aclist commented 5 months ago

Hey ACLIST! How is it going? Just did a major upgrade to my system, installed a new faster NVMe drive and have been trying all morning to get DZGUI to setup, but it keeps giving me a weird error about the steam path....

Hello Stephen, I hope you are well. I'm sorry you had some difficulties getting DZGUI set up again. Due to its similarity to the other issue you linked, I am inclined to believe there is a bug in here somewhere.

It then provides the Question Dialog, "DayZ not found or not installed at the choosen path." I select the Choose path manually button. (Of note, I have already installed and loaded into a Vanilla Server, DayZ is installed and is located at /home/stephen/.steam/steam/steamapps/common/DayZ) <- Might be important.

Some time ago, functionality was added per the discussion here: https://github.com/aclist/dztui/discussions/94

It may be that we need to look into this a bit further to see if the path is getting resolved correctly. Each distribution does things a bit differently.

Zenity then opens and I navigate to /home/stephen/.steam/steam/steamapps where I can see the libraryfolders.vdf file. But when I select the OK button the terminal spits out these 2 errors. usage: vdf2json [-h] [-i INPUT] [-o OUTPUT] vdf2json: error: argument -i/--input: can't open '/home/stephen/.steam/steam/steamapps/steamapps/libraryfolders.vdf': [Errno 2] No such file or directory: '/home/stephen/.steam/steam/steamapps/steamapps/libraryfolders.vdf'

In this case, this is user error. You navigated to deep into the directory hierarchy. Unless I am mistaken, you should have specified /home/stephen/.steam/steam. Per the documentation:

Specify the top-level entry point to Steam, not DayZ. E.g., /media/mydrive/Steam, not /media/mydrive/Steam/steamapps/common/DayZ

The reason you see two instances of steamapps conjoined here is because the suffix was added to the path you gave, which already (erroneously) contained steamapps in it.

I think maybe I should add better error handling here to try to parse out the path even if the user selects the "wrong" directory depth, since it seems like users often have this problem.

Just discovered that my ".steampath" (Hidden in my Home Folder) indicates that it is broken. I also have been doing dome poking around in your files, and note that in your /helper/funcs script that it is calling for steam_path. Just wanted to include here that I noticed these, could these be related to the issue? I even deleted the hidden broken link (to clarify it is a broken simlink) and closed and reopened steam, but as soon as it started the .steampath link was created anew and showed broken again.....

Steam does tend to create symlinks for its own internal purposes that point back to the master Steam directory. I wouldn't worry about this, it is standard behavior.

Well, I did something, like went and downloaded an older version (5.0.0) got it to run, and all of a sudden it was telling me that I had an older version and asked if I wanted to upgrade to 5.2.0 (I confirmed). Either way, suddenly it was able to launch without ever asking me for my steam API, or BM API keys. Not sure what just happened, perhaps you were pushing a fixed update while I was messing around......?

Hypothesis 1: during the initial install attempt, you created a partial config file with the API keys, and this was present in your configs when you upgraded Hypothesis 2: when you upgraded your system, it contained an old $HOME partition with existing config files

5.2.0 has been out for about week+ and I have not made changes since that time. The path discovery logic has not changed for several months, so nothing happened on the remote end here.

I do think there might be something wrong in the path discovery process, so we should attempt to fix it. The default Steam path on Linux Mint is in a well-defined place, and if your DayZ was installed in the default location, it should definitely have been picked up without extra user intervention. I will prepare some tests.

By the way, how are you liking the new UI?

aclist commented 5 months ago

I did find a small bug now that was preventing path auto-discovery from loading correctly, but it doesn't relate directly to your problem above.

Here's a small test you can run to see what paths DZGUI expects to find:

Attachment: test.txt

SteveIDusa commented 5 months ago

The new UI was intuitive, button presses made sense when arriving at sub menus. Liked it! Though, for adding a server to favorites, I had to add one by ID# then discover that it was not saved after comming back to DZGUI a day later. Then add it again and while able to see it in the UI, right click and then add to favorites to get it to save. That threw me off for alittle, but it worked out.

One thing of note, for some reason, my DZGUI installation launches at every start up, is this intended? I have checked every location that I am aware of to set up a program to start when I login and none of them are indicating that they are turned on for DZGUI.

Attempting to run the script as test.sh, it launches but after a few moments it just crashes to the Desktop. Even attempted as admin, and it crashed just the same.

aclist commented 5 months ago

Though, for adding a server to favorites, I had to add one by ID# then discover that it was not saved after comming back to DZGUI a day later.

Have not heard about this before, will try to repro it.

One thing of note, for some reason, my DZGUI installation launches at every start up, is this intended?

Check your start menu applications, it varies by distribution. DZGUI does not explicitly change anything here other than create a .desktop file.

Attempting to run the script as test.sh, it launches but after a few moments it just crashes to the Desktop. Even attempted as admin, and it crashed just the same.

Make sure you run this from a terminal and not by double-clicking/right-clicking the file.

aclist commented 5 months ago

Though, for adding a server to favorites, I had to add one by ID# then discover that it was not saved after comming back to DZGUI a day later.

If a server in your saved servers if offline or unreachable, it will be culled from the My Servers list since it cannot return any meaningful info. The list of your saved servers shows active, currently reachable servers. If the server you saved was temporarily down for maintenance, this could have been the reason. I might change this behavior in the future and add a placeholder entry if the server is down.

SteveIDusa commented 5 months ago

@aclist Ah, OK, so perhaps it was offline. Maybe a "Online" column is in order with a "Y" or "N"?

Of other note, one that I forgot to mention in my original post. The buttons on the right hand side, have a different color font (gray) from the "Main" menu button. I have already figured out that they are "not grayed out", just a different color. However, this did on first appearance cause me to consider them as "unavailable" at first. Just an FYI that I encountered this morning when the application auto ran and grabbed an update. So it reminded me this morning when it opened.

I actually have already checked the "Startup" apps and gone into the menu and right clicked the menu based launcher which it does not include a "Launch when I login" check mark.....So I do not understand why it is doing the auto startup when I start the system.

Though I did find that the icon for the menu was blank or missing this morning, so I went to add it by going into /.local and found that of all of the image files present it was the only one missing a .png extension. Once I added it, the icon worked as expected at my menu level. I also then decided that since there was a new update, to log out of my account on the PC and log back in to see if there was any change to the behavior. There was, it did not auto load when login occurred. Weather this was due to the change of version or because the .png extension was added I can not say.

aclist commented 5 months ago

Ah, OK, so perhaps it was offline. Maybe a "Online" column is in order with a "Y" or "N"?

This is a weak point, but I have to think about it, because we intentionally don't store enough metadata on servers to make this viable at the moment. The "name" of a server is constantly changing, because server operators use this area to list things like when the last wipe occurred, whether an event is ongoing, or to just rename the server title outright, so there isn't always a canonical, immutable server name. So we choose not to store it and store the server IP as the record of reference. If the server is unreachable, we won't be able to get the server name back, so this would make identifying the server difficult. Again, because the server title is not a reliable value to store, I don't necessarily like the idea of saving this metadata, since it could change from time to time.

Of other note, one that I forgot to mention in my original post. The buttons on the right hand side, have a different color font (gray) from the "Main" menu button. I have already figured out that they are "not grayed out", just a different color. However, this did on first appearance cause me to consider them as "unavailable" at first. Just an FYI that I encountered this morning when the application auto ran and grabbed an update. So it reminded me this morning when it opened.

The "highlighted" button is supposed to indicate which menu context you are currently in. You can only have one button context at a given time, since clicking one activates the contents of the menu to the left. I understand what you are saying, so perhaps there is a more familiar way of describing this contextual change. I can't make too many drastic changes here, since the UI inherits the user's system settings, which could look widely different on different setups.

Though I did find that the icon for the menu was blank or missing this morning, so I went to add it by going into /.local and found that of all of the image files present it was the only one missing a .png extension. Once I added it, the icon worked as expected at my menu level. I also then decided that since there was a new update, to log out of my account on the PC and log back in to see if there was any change to the behavior. There was, it did not auto load when login occurred. Weather this was due to the change of version or because the .png extension was added I can not say.

I think there is some behavior where the icons only get installed on Steam Deck devices, since users there need to have a clickable icon on the desktop for easy access, whereas on desktop PCs it just creates a shortcut but doesn't install the extra images. This should probably be changed, since I looked at the .desktop file and it's pointing to a non-existent icon, at least on my system.

aclist commented 3 months ago

I have made a few changes today that should make it more difficult for path errors to occur when DZGUI prompts you to regenerate your config file. There was a bug being caused when the user moved their DayZ path but Steam did not update its internal records. There was also an issue you alluded to above:

It then provides the Question Dialog, "DayZ not found or not installed at the choosen path."

There was a bug in the config regeneration logic that was not wiping out the old path from memory but still asking the user to update their configs. This meant the old path would be reinserted in the config file instead of being updated accordingly, causing this warning to appear every time the application was restarted.