[BUG] Steam flatpak version cannot run DZGUI as non-steam game.

[not-kaz]

The GUI works when running straight from the console but adding it as a non-steam game to the library and running it from there fails with this message: "Requires jq >= 1.6".

Seems like Steam flatpak has no access to those dependency binaries. (jq, xdotool)

Some things I've tried:

• Using flatseal to give access to my /usr/bin (as unsafe as that is), but Steam flatpak refuses to allow that path.

  F: Not sharing "/usr/bin" with sandbox: Path "/usr" is reserved by Flatpak
  F: Not sharing "/bin" with sandbox: Path "/bin" is reserved by Flatpak
  F: Not sharing "/sbin" with sandbox: Path "/sbin" is reserved by Flatpak
  F: Not sharing "/usr/lib" with sandbox: Path "/usr" is reserved by Flatpak
  F: Not sharing "/usr/sbin" with sandbox: Path "/usr" is reserved by Flatpak

• Commenting out the related dep check functions in the dzgui.sh, it allows me to pass the checks but I get API errors, as expected.

• Giving access to the whole filesystem host/host-os. In this case, Steam flat out refuses to launch until the permissions are removed. It even warns this is a mechanism to prevent you from borking your home dir.

• Symlinking the binaries to a default location Steam flatpak is allowed to access. I get the same dependency check error.

So I've tried some stuff from the top of my head but unfortunately I have no idea what do next. I like the convenience of running this as a steam library entry, so hopefully there is a work around?

Great work with this project by the way, I am a fan!

[aclist]

Hi, thanks for your message.

For better or worse, development of DZGUI proceeded in a rapid and ad-hoc fashion in order to add in support for the myriad use cases that cropped up as users reported esoteric ways of interacting with Steam/their system/Steam Deck/etc, and at some point the objective became getting people's DayZ experience up and running by any means possible rather than adhering to a unified but limited scope. As a result, some of the methods fall squarely into the "experimental" category, with support having been extended only enough to get it up and running, but without extensive testing into the ramifications thereof, or what happens when chaining through other processes.

For the record, running DZGUI as a non-Steam application in the non-flatpak version of Steam will work. So as a fallback, you have vanilla Steam if you really want the library integration, or console flatpak if you want the containerization. Not a solution, just a workaround.

Using flatseal to give access to my /usr/bin (as unsafe as that is), but Steam flatpak refuses to allow that path.

I would try something more generic here like $HOME, or you could even stuff the binaries in the DZGUI dir if you want. If for some reason it is unable to traverse the symlinks themselves, you could also just copy the binaries wholesale.

Commenting out the related dep check functions in the dzgui.sh, it allows me to pass the checks but I get API errors, as expected.

Regarding the dependency, jq is instrumental to parsing the JSON responses in a sane fashion. Writing a native parser in DZGUI to interpret the JSON would be extremely arduous due to the complexity of the responses returned from servers. So commenting out the dependency checks here and trying to proceed without jq is predictably going to get you API errors and, ultimately, malformed server results. And for that matter, we need xdotool as well for some things like raising the mod window, so trying to get by without external dependencies is a non-starter.

Question: did this problem always exist for you (i.e., were you able to add DZGUI as a non-Steam application before?), or only recently? I ask because Valve has been rolling out some upstream changes to the way non-Steam applications are handled internally, so there will be some subtle changes to this functionality over time. I also ask because a Steam Deck user recently reported a similar problem with the jq dependency that wasn't present on SD before.

Symlinking the binaries to a default location Steam flatpak is allowed to access. I get the same dependency check error.

I think you are on the right track here. Have you tried the command flatpak override <package_name_here> --filesystem=<path_here> and pointing to that path? Have you restarted Steam after whitelisting this path?

If this continues to fail, I think you could debug it more easily by unit testing it: create a dummy shortcut pointing to a simple program that generates a log indicating whether (and where) flatpak found the binary files and if they can be run, rather than the overhead of launching DZGUI and trying to make it past the startup messages and associated checks. Let me know if you need help with that.

[aclist]

Hello, sorry to disturb you on this old ticket. I hope you are doing well.

If I'm not mistaken, it looks like you made a post on ProtonDB stating that you strongly recommend against using DZGUI because it requires a Steam API key. Obviously, this is your choice, but just to give some context, I try to keep up with reports to see if anyone is having problems that need fixing.

I understand if this design choice is not your preference, but I want to clear up some points here, because there is a significant number of users with limited technical ability, and I believe there is some misinformation going around. For the benefit of those readers, I am concerned about spreading unnecessary fear and uncertainty. I am not saying that you yourself hold these misconceptions, just that they come up from time to time by inexperienced users as a worry, so it's something I'm aware of.

All third-party launchers (DZSA, etc.) use the Steam API. DZSA and Battlemetrics crawl Steam's API and present those results on their sites. In turn, all of the Linux launchers except DZGUI get server info from DZSA's server using an undocumented API endpoint, piggybacking off of DZSA. This introduces a host of issues, such as inconsistent uptime when using a third-party API, incomplete results, and having to pass all of the user's queries through a third party server with or without permission of both the user and the third party server operator.

DZGUI is the only launcher that gets its server information directly from the source: Steam. It does this by letting the user be solely in control of their own API key and the application in an authenticated way. Users explicitly get permission to use an API key instead of scraping DayZ server info from third-party sites. Everything that happens between DZGUI and Steam takes place solely on the user's computer, and no information gets sent back to the developer. Lastly, I do not want DZGUI to scrape someone else's API without permission just because it is "convenient."

There is some misconception that a Steam API key could be used to gain information about a user's account or control their account. To reiterate, the API key is used solely by the user and is protected by Steam Guard.

Does this add an extra step that is a bit inconvenient? Yes. I totally understand if this is annoying for people who want an OOTB experience. But a Steam API key in and of itself is not a bad thing; it is the most strict way of getting authentic, reliable, and consistent server information in a zero-trust model.

In light of the above and for the benefit of inexperienced users, I would humbly appreciate it if you considered revising your ProtonDB submission, because the current wording is liable to exacerbate feelings of fear and uncertainty in inexperienced users, and these things tend to take on a life of their own. To do so, you can submit a new report that overrides the old one, or you can post a request on the ProtonDB discord to revise the report.

Thank you.