[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.