[BUG] Config file install path is inserted incorrectly upon version upgrade

[rcbevans]

Got an in-app notification that a new version of dzgui was available, and since upgrading, dzgui no longer detects any installed/installing mods, and every startup it gives an error that the config file is malformed.

[aclist]

Thanks for the report. It sounds like the path to the game's installation directory became malformed somehow.

Please attach the contents of your current config file ($HOME/.config/dztui/dztuirc), redacting any sensitive information such as the api_key and steam_api fields. When upgrading, a copy of your old config file should also have been made under $HOME/.config/dztui/dztuirc.oldapi. Please also attach the contents of that file, redacting any sensitive information.

In addition, if you are able to get into the Advanced Options menu, please use the "Output system info" option to generate a log file. The file will be named DZGUI.log and is output in DZGUI's root directory (usually $HOME/.local/share/dzgui).

[aclist]

Updated the above message to clarify paths to config files

[rcbevans]

dztuirc:

#Path to DayZ installation
steam_path="/home/rich/.steam/steam/steamapps"

#Your unique API key
api_key="..."

#Favorited server IP:PORT array
ip_list=(
    
)

#Favorite server to fast-connect to (limit one)
fav_server=""

#Favorite server label (human readable)
fav_label=""

#Custom player name (optional, required by some servers)
name="... [NPA]"

#Set to 1 to perform dry-run and print launch options
debug=""

#Toggle stable/testing branch
branch="stable"

#Last seen news item
seen_news=""

#Steam API key
steam_api="..."

#Auto-install mods
auto_install=""

#Automod staging directory
staging_dir=""

#Path to default Steam client
default_steam_path="/usr/bin/steam"

#Preferred Steam launch command (for Flatpak support)
preferred_client=""

dztuirc.oldapi (identical to what gets created)

#Path to DayZ installation
steam_path="/home/rich/.steam/steam/steamapps"

#Your unique API key
api_key="..."

#Favorited server IP:PORT array
ip_list=(
    
)

#Favorite server to fast-connect to (limit one)
fav_server=""

#Favorite server label (human readable)
fav_label=""

#Custom player name (optional, required by some servers)
name="... [NPA]"

#Set to 1 to perform dry-run and print launch options
debug=""

#Toggle stable/testing branch
branch="stable"

#Last seen news item
seen_news=""

#Steam API key
steam_api="..."

#Auto-install mods
auto_install=""

#Automod staging directory
staging_dir=""

#Path to default Steam client
default_steam_path="/usr/bin/steam"

#Preferred Steam launch command (for Flatpak support)
preferred_client=""

dzgui.log

Distro: EndeavourOS
Kernel: Linux 6.6.2-arch1-1 x86_64
Version: 4.0.4
Branch: stable
Mode: normal
Auto: ON
Servers:
    
Steam path: /home/rich/.steam/steam/steamapps
Workshop path: /home/rich/.steam/steam/steamapps/steamapps/workshop/content/221100
Game path: /home/rich/.steam/steam/steamapps/steamapps/common/DayZ

Mods:

[rcbevans]

Realized it's because the steam_path in the config included steamapps.

No idea why, this isn't something I manually set.

If I update steam_path in the config to steam_path="/home/rich/.local/share/Steam" then dzgui launches, and it detects mods correctly

[aclist]

Thank you for the additional information; this appears to be a regression. I have some initial insight into the problem, although I have not been able to reproduce it yet.

[aclist]

After much thinking about this and looking at other user reports in the intervening months, my conclusion about what happened in your case is that the location of DayZ had changed, and the old path was being erroneously stored in the configs.

I uncovered a bug yesterday in the setup logic that would try to warn the user if an old path from an existing config file no longer existed, but the new path was not being updated accordingly after triggering first-time setup again. With the latest fix, this value will be wiped from memory before updating the config file, ensuring that stale directory paths are not carried around if the user had an existing config file.

This was effectively kicking users back into the first-time setup routine every time the application launched, but not actually making their changes sticky.

[aclist]

Closing as resolved; please reopen a new ticket if you encounter this issue or one like it again.