Everything here is behind the Settings button in the launcher's bottom bar.
Settings
- Battle.net prefix: where Battle.net lives. Leave it empty for the launcher's own prefix, or point it at an existing Steam, Lutris or Bottles prefix to reuse installed games.
- Proton build: leave it empty for the automatic choice (Proton-CachyOS, else the newest GE-Proton), or give the folder of a Proton build.
- NVIDIA render offload and Display scaling: see Setting up Battle.net with the launcher.
Diagnostics
- Run doctor shows which umu, Proton build, prefix and offload setting are in use, and where the config file is. Paste it when you ask for help.
- Show log shows the end of the launcher log. Repeated lines are folded into one with a count, like
(×126) …. The full log is the file ~/.cache/blizznux/blizznux.log.
- Report a problem sends a bug report to the BlizzNux staff. Describe what went wrong; your setup and the end of the log are attached, with home folder paths replaced by
~. You can open "What will be sent" before you send it.
Common problems
- "Battle.net did not start within two minutes." Press Show log. On the very first start this can simply be the download of Proton and its runtime.
- The AppImage does not start and mentions FUSE. Install your distribution's
libfuse2 package, or start the AppImage with --appimage-extract-and-run.
- The AppImage stops with "version GLIBC_… not found". That is a release older than 0.2.8. Download the current one.
- The deb or rpm refuses to install because of umu-launcher. That is a release older than 0.2.9. Download the current one.
- The log says "GStreamer skipped a plugin built for the other CPU architecture (harmless)". It is harmless. Proton lists its 32-bit and 64-bit plugins for both kinds of program, and each skips the other's.
- The launcher window stays blank on an NVIDIA card. Try starting it with
WEBKIT_DISABLE_DMABUF_RENDERER=1 set, for example WEBKIT_DISABLE_DMABUF_RENDERER=1 ./BlizzNux_*.AppImage.
- The game stutters for minutes after every start (NVIDIA). The NVIDIA driver's shared shader cache stops storing at 1 GB, and a large game such as Overwatch 2 needs about 2 GB, so the rest was compiled again at every start. Since version 0.2.11 the launcher keeps its own shader cache in
~/.cache/blizznux/shader-cache with a 10 GB limit. The first start after updating compiles once more: several minutes, heavy on CPU and memory, so it is best to wait in the menu. After that, starts load from the cache (about a minute on our test laptop, instead of 5 to 7). A game patch or a driver update causes one new compile. Only NVIDIA is affected, and values you set yourself for __GL_SHADER_DISK_CACHE_PATH, __GL_SHADER_DISK_CACHE_SIZE or __GL_SHADER_DISK_CACHE_SKIP_CLEANUP are kept. Deleting the folder is safe; it only costs one compile.
- Overwatch 2 uses far more memory than the machine has (NVIDIA). The NVIDIA driver kept every shader pipeline that DXVK created for the game in memory, whether the game was still using it or not, so Overwatch 2 grew to about 19 GB once its shaders were loaded; on a 16 GB machine that means swapping and stutter. Since version 0.2.12 the launcher tells DXVK to free the pipelines a game is not using: on NVIDIA it sets
DXVK_CONFIG to dxvk.trackPipelineLifetime = True. On our test laptop Overwatch 2 then settles at about 6 GB and starts as quickly as before. This applies to games running through DXVK (Direct3D 9 to 11) on NVIDIA graphics; a game in Direct3D 12 mode, such as World of Warcraft with its default setting, is not affected and never had the problem. If you set DXVK_CONFIG yourself, the launcher leaves your value alone; add dxvk.trackPipelineLifetime = True to it for the same effect. If a game hitches where it did not before, use Report a problem in Settings.
- A brief red error at the bottom left after logging in or out inside the launcher (version 0.2.17 and earlier). Fixed in 0.2.18; nothing was lost.
- Anything else. Use Report a problem, or post in the forum with the Run doctor output.
