SubnauticaNitrox
Provide a packaged build for Linux releases
Describe the issue
Some Linux users would like Nitrox as a package instead of loose files. We should investigate which packaging format serves Nitrox best.
Package requirements
- Cross-platform meaning it can generate the packed exe on windows
- Allows us to specify what packages we need, rather than forced auto-detect
- Free
- Headless compatible & compatible with as many distros as possible
Things to check
- Can the package work for both launcher and server executable? Can Launcher find the server this way?
Ok so I just made the app image myself.
set -e
# ------------------------------
# Variables
# ------------------------------
NITROX_URL="https://github.com/SubnauticaNitrox/Nitrox/releases/download/1.8.0.0/Nitrox_1.8.0.0_linux_x64.zip"
ICON_URL="https://github.com/SubnauticaNitrox/NitroxWebsite/blob/master/public/assets/img/favicon.png?raw=true"
WORKDIR="$HOME/Games/Nitrox.AppDir"
OUTPUT_DIR="$HOME/Games"
APPIMAGE_TOOL="$HOME/Downloads/appimagetool-x86_64.AppImage"
# ------------------------------
# Prepare AppDir
# ------------------------------
rm -rf "$WORKDIR"
mkdir -p "$WORKDIR/usr/bin"
# ------------------------------
# Download Nitrox zip
# ------------------------------
TMPZIP="$HOME/Downloads/Nitrox_1.8.0.0_linux_x64.zip"
echo "Downloading Nitrox 1.8..."
curl -L -o "$TMPZIP" "$NITROX_URL"
# ------------------------------
# Extract linux-x64 folder into AppDir/usr/bin
# ------------------------------
echo "Extracting Nitrox..."
unzip -q "$TMPZIP" -d "$WORKDIR/usr/bin"
rm "$TMPZIP"
# ------------------------------
# Download favicon for icon
# ------------------------------
echo "Downloading icon..."
curl -L -o "$WORKDIR/Nitrox.Launcher.png" "$ICON_URL"
# ------------------------------
# Create AppRun script
# ------------------------------
cat > "$WORKDIR/AppRun" << 'EOF'
#!/bin/bash
HERE="$(dirname "$(readlink -f "$0")")"
cd "$HERE/usr/bin/linux-x64"
./Nitrox.Launcher
EOF
chmod +x "$WORKDIR/AppRun"
# ------------------------------
# Create .desktop file
# ------------------------------
cat > "$WORKDIR/Nitrox.desktop" << EOF
[Desktop Entry]
Name=Nitrox
Exec=AppRun
Icon=Nitrox.Launcher
Type=Application
Categories=Game;
EOF
# ------------------------------
# Set .DirIcon for AppImage
# ------------------------------
ln -sf Nitrox.Launcher.png "$WORKDIR/.DirIcon"
# ------------------------------
# Download appimagetool if missing
# ------------------------------
if [ ! -f "$APPIMAGE_TOOL" ]; then
echo "Downloading appimagetool..."
mkdir -p "$(dirname "$APPIMAGE_TOOL")"
curl -L -o "$APPIMAGE_TOOL" \
https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage
chmod +x "$APPIMAGE_TOOL"
fi
# ------------------------------
# Build AppImage
# ------------------------------
echo "Building AppImage..."
"$APPIMAGE_TOOL" "$WORKDIR"
# ------------------------------
# Move AppImage to output folder
# ------------------------------
mv "$WORKDIR/Nitrox-x86_64.AppImage" "$OUTPUT_DIR/"
echo "✅ Done! Nitrox AppImage is at $OUTPUT_DIR/Nitrox-x86_64.AppImage"
Describe the issue
Investigate if creating an AppImage can work for Nitrox, then implement as MSBuild task when making a release.
One thing, this all needs to be done from linux. since the app image tool needs to be run in linux in order to make the .appimage file.
Things to check:
- Can AppImage work for both launcher and server executable? Can Launcher find the server this way?
I tested it and the server launches just fine with the appimage.
here is my output after i made everything
📦[Kiaos@fedora-toolbox ~]$ ~/Downloads/appimagetool-x86_64.AppImage ~/Games/Nitrox.AppDir
appimagetool, continuous build (commit 5735cc5), build <local dev build> built on 2023-03-08 22:52:04 UTC
WARNING: appstreamcli command is missing, please install it if you want to use AppStream metadata
Using architecture x86_64
/home/Kiaos/Games/Nitrox.AppDir should be packaged as Nitrox-x86_64.AppImage
WARNING: AppStream upstream metadata is missing, please consider creating it
in usr/share/metainfo/Nitrox.appdata.xml
Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
for more information or use the generator at http://output.jsbin.com/qoqukof.
Generating squashfs...
Parallel mksquashfs: Using 16 processors
Creating 4.0 filesystem on Nitrox-x86_64.AppImage, block size 131072.
[==============================================================================================|] 472/472 100%
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
compressed data, compressed metadata, compressed fragments,
compressed xattrs, compressed ids
duplicates are removed
Filesystem size 22304.90 Kbytes (21.78 Mbytes)
49.25% of uncompressed filesystem size (45288.10 Kbytes)
Inode table size 3189 bytes (3.11 Kbytes)
43.40% of uncompressed inode table size (7348 bytes)
Directory table size 2257 bytes (2.20 Kbytes)
45.07% of uncompressed directory table size (5008 bytes)
Number of duplicate files found 0
Number of inodes 187
Number of files 178
Number of fragments 48
Number of symbolic links 1
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 8
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
Embedding ELF...
Marking the AppImage as executable...
Embedding MD5 digest
Success
Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io
📦[Kiaos@fedora-toolbox ~]$
@Measurity You do realize that what we want will never work on windows. Appimage and flatpak would be what linux needs. You just cant do that in msbuild. You need to offload it to a linux envorioment and build it in a container or something. I would recomend keeping this a linux only issue cause windows doesnt use Appimage or flatpak.
Free using the appimage tool https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage is free
Headless compatible & compatible with as many distros as possible
appimage and flatpak is compatible with most if not all modern distros
Things to check Can the package work for both launcher and server executable? Can Launcher find the server this way?
Yes I tested it today. Works just fine. Server is being used in appimage right now by me.
@Measurity You do realize that what we want will never work on windows. Appimage and flatpak would be what linux needs. You just cant do that in msbuild. You need to offload it to a linux envorioment and build it in a container or something. I would recomend keeping this a linux only issue cause windows doesnt use Appimage or flatpak.
Free using the appimage tool https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage is free
Headless compatible & compatible with as many distros as possible
appimage and flatpak is compatible with most if not all modern distros
Things to check Can the package work for both launcher and server executable? Can Launcher find the server this way?
Yes I tested it today. Works just fine. Server is being used in appimage right now by me.
there is no reason that it can't work on windows. We want to investigate options before we make a decision, please give us time to do that
You just cant do that in msbuild.
MSBuild allows you to call external executables. It runs on Linux too. This isn't the issue.
I would recomend keeping this a linux only issue cause windows doesnt use Appimage or flatpak.
Of course, but we have Windows devs and they need to be able to release Nitrox without omitting Linux builds. How this will look like (GitHub runner or finding exotic ways to bundle AppImage on Windows), we'll see.
So most gamers are gonna use Bazzite or steam os. Those two mostly support discover store flatpak or appimage. The other distros have their own managers for installing or running software. Bazzite and steam os are immutable file system so no yay, yum or dnf. Most average users that use Linux wont be installing via manager that way. NON power users are gonna install stuff through flatpak or appimage.
The snap store only works on debian. So No for fedora = bazzite and no for arch = steam os Its only one place of many. Snap also has shit tons of bugs. Which is why I don't run ubuntu or debian based distros. I perfer other packagemanagers so i dont use those distros.
steam os does have pacman but no yay. (I have gotten yay to work but It invovles breaking steam os its a pain)
bazzite only has layering with ostree which they don't recommend. Bazzite has Appimage and flatpak. Or runing it in a distrobox container you can use dnf which installs rpm. OStree install is rpm based as well.
Let me clarify Appimage is a like a folder your server and launcher along with all the things in linux-64 are in the bin folder and are accessible by what ever you use to run the app which is the launcher. The launcher has built in console server support. It works just fine as i have tested it.
AND LIKE I SAID the server and launcher work just fine in an app image Since I have tested it.
The app image only points to the launcher and the launcher has access to the server. APP IMAGE is only for average user.
The other zip that you provide is for docker people or power users.
*You are not providing appimage for all users as the only source for linux. Your providing it as an option to use it along side other options for linux. As far as sandboxing goes I would have to make a flatpak of my own and test.
For most releases you would provide all of them. You crossed out the others. But debain is a pretty bad os. Limiting it to only snap is pretty cruel since most of the other distros will never be able to use it.
when people release any software for linux they would provide
.appimage .flatpak .rpm .deb and the zip you provided in your releases.
They don't just do one type. They have an autobuilder that does it all so they just hit a button and bam they are all made.
Snap seems to work everywhere but gotta enable it:
- https://snapcraft.io/install/snap-store/fedora
- https://snapcraft.io/install/snap-store/arch
- https://snapcraft.io/snap-store (ubuntu)
- Mint:
sudo rm /etc/apt/preferences.d/nosnap.pref
apt update
apt install snapd
Ideally we package it in everything but as a first task, starting with one would be good.
did you not see what i wrote Bazzite and Steam os are immutable so that does not work. APT is only on debian.
Snap can be installed on a open system. But steam os and Bazzite arnt.
You can't just install what ever manager you want and you shouldn't do that.
Garenteed most users arn't installing a open linux system. Because they can break it. Look what linux tech tips's Linus did with his linux.
If your making something for people that don't know what their doing. You make it for all distros if you can. .appimage is clean and works for me right now on Bazzite.
did you not hear me Bazzite and Steam os are immutible so that does not work. APT is only on debian. Snap can be installed on a open system. But steam os and Bazzite arnt. You can't just install what ever manager you want and you shouldn't do that. Garenteed most users arn't installing a open linux system. Because they can break it. Look what linux tech tips's Linus did with his linux. If your making something for people that don't know what your doing. You make it for all managers.
making it for all managers is a lot of work, and many of the managers like flatpak has sandboxing which will likely break our launcher logic. Please refer to the graphic I posted earlier for why snap was my first choice.
when you release software on git hub you make a build manger for it and have it automated.
Devs who use windows only don't need to do all the work, They just hit build and their project goes brrrr. WSL is not hard to get running. If wsl doesn't work on Windows 11 its cause you don't want it to work or are not interested in figuring it out.
WSL is intregrated with Visual studio and VScode. Don't use unbuntu for your wsl image use arch.
If you need to have two separate people build the linux and windows. Cause If using linux is a barrier for windows people. either automate it and get wsl running or have a linux person do it and release all of them. Their are guides on the internet for releasing a project in all those formats.
Saying we are only gonna release it for snap is gonna basicly limit it to those that can use snap on their system. Snap is debain based and even if you can install it on other distros doestn mean you should. There are nightmare videos about it messing up their system. which is why i dont use snap.
did you not hear me Bazzite and Steam os are immutible so that does not work. APT is only on debian.
Snap can be installed on a open system. But steam os and Bazzite arnt.
I would recommend you to cool down. We released an experimental linux version just a few days ago and are carefully investigating each option. Just bc it doesn't fit into your use case doesn't mean it doesn't benefit others or a wider range of people. Just blurting out opinions isn't really productive. Looking at the Steam Hardware Survey, Arch is top (probably bc of SteamOS) followed by Mint, Ubuntu, Endeavour, Manjaro and THEN Fedora). So snap would in my understanding cover a huge range, excluding immutable distros. How I read the documentation Flatpack is not possible/ideal for us bc of the sandbox environment, we need full file access to detect stores and the game. Maybe even access to processes (would need investigation how in detail we implemented the game launch logic). And like Meas said we also need to take into account how reliable the packaging can be done (needs to be done by all higher team members or on in CI/CD pipeline). We value the input from you and will evaluate Flatpack/AppImage in regards to the described criteria. Until we found a good solution one unfortunately has to be satisfied with downloading a zip with an executable (and regrettably manually installing missing dependencies).
Btw today I publish nitrox to the AUR as a first test on packaging and dependencies management. But the main priority right now is fixing the most annoying bugs our users have/tell us.
did you not hear me Bazzite and Steam os are immutible so that does not work. APT is only on debian. Snap can be installed on a open system. But steam os and Bazzite arnt.
I would recommend you to cool down. We released an experimental linux version just a few days ago and are carefully investigating each option. Just bc it doesn't fit into your use case doesn't mean it doesn't benefit others or a wider range of people. Just blurting out opinions isn't really productive. Looking at the Steam Hardware Survey, Arch is top (probably bc of SteamOS) followed by Mint, Ubuntu, Endeavour, Manjaro and THEN Fedora). So snap would in my understanding cover a huge range, excluding immutable distros. How I read the documentation Flatpack is not possible/ideal for us bc of the sandbox environment, we need full file access to detect stores and the game. Maybe even access to processes (would need investigation how in detail we implemented the game launch logic). And like Meas said we also need to take into account how reliable the packaging can be done (needs to be done by all higher team members or on in CI/CD pipeline). We value the input from you and will evaluate Flatpack/AppImage in regards to the described criteria. Until we found a good solution one unfortunately has to be satisfied with downloading a zip with an executable (and regrettably manually installing missing dependencies).
Btw today I publish nitrox to the AUR as a first test on packaging and dependencies management. But the main priority right now is fixing the most annoying bugs our users have/tell us.
Yea I got hot headed for no reason. Thanks for elaborating. I was just worried about it. Cause I get a lot of linux software that's only made for one or two distros sometimes. For Immutable people like me its a bit of a pain. I understand flatpak is sandboxed and their are some things to consider about that. Thank you for your hard work. I'll be patient.
Btw today I publish nitrox to the AUR as a first test on packaging and dependencies management. But the main priority right now is fixing the most annoying bugs our users have/tell us.
didn't the devs say nitrox was dependent on .net 9.0. most of your dependencies on aur for this are not .net 9.0 or am i missing something?
.net 9.0.9 is the one without version number which is on there: https://aur.archlinux.org/packages/dotnet-runtime-bin and https://aur.archlinux.org/packages/dotnet-sdk-bin
Hi, just wanted to install nitrox through the aur on archlinux, but building it, is giving some errors:
yay -S nitrox AUR Explicit (1): nitrox-1.8.0.0-1 :: PKGBUILD is up to date, skipping download: nitrox 1 nitrox (Build files exist) ==> Rebuild packages? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4) ==> 1 nitrox (Build files exist) ==> Show differences? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4) ==> ==> Making package: nitrox 1.8.0.0-1 (Mon 13 Oct 2025 13:09:46 CEST) ==> Retrieving sources... -> Updating Nitrox-1.8.0.0 git repo... -> Found nitrox.desktop ==> WARNING: Skipping PGP signature check for source files. ==> Validating source files with sha256sums... Nitrox-1.8.0.0 ... Passed nitrox.desktop ... Passed :: (1/1) Parsed SRCINFO: nitrox ==> Making package: nitrox 1.8.0.0-1 (Mon 13 Oct 2025 13:09:48 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating Nitrox-1.8.0.0 git repo... -> Found nitrox.desktop ==> Validating source files with sha256sums... Nitrox-1.8.0.0 ... Passed nitrox.desktop ... Passed ==> Removing existing $srcdir/ directory... ==> Extracting sources... -> Creating working copy of Nitrox-1.8.0.0 git repo... Cloning into 'Nitrox-1.8.0.0'... Done. Switched to a new branch 'makepkg' ==> Starting prepare()... Restore completed (2.9s)
Build succeeded in 3.0s ==> Sources are ready. ==> Making package: nitrox 1.8.0.0-1 (Mon 13 Oct 2025 13:09:55 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Removing existing $pkgdir/ directory... ==> Starting build()... /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. /usr/share/dotnet/sdk/9.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1083: The specified RuntimeIdentifier "--no-restore" is not recognized. For more information, see https://aka.ms/netsdk1083. ==> ERROR: A failure occurred in build(). Aborting... -> Failed to build: nitrox-exit status 4 -> The following packages could not be installed. Manual intervention is required: nitrox - exit status 4
Can someone fix it?
@Schnurzel700 I updated the package. If you could test it out and write if it worked it would help us a lot.
Hi, I rebuilt it, and everything is working perfectly now. The app is running smoothly, and Subnautica launches with multiplayer enabled without any issues. Thanks so much for fixing it!
[user@archlinux ~]$ yay -S nitrox AUR Explicit (1): nitrox-1.8.0.0-2 :: (1/1) Downloaded PKGBUILD: nitrox 1 nitrox (Build files exist) ==> Rebuild packages? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]t installed or (1 2 3, 1-3, ^4) ==> 1 nitrox (Build files exist) ==> Show differences? ==> [N]one [A]ll [Ab]ort [I]nstalled [No]t installed or (1 2 3, 1-3, ^4) ==> ==> Building package: nitrox 1.8.0.0-2 (Thu Oct 16 2025 12:21:19 PM CEST) ==> Retrieving sources... -> Cloning Nitrox-1.8.0.0 git repo... Cloning into bare repository '/home/user/.cache/yay/nitrox/Nitrox-1.8.0.0'... remote: Enumerating objects: 109334, done. remote: Counting objects: 100% (1178/1178), done. remote: Compressing objects: 100% (437/437), done. remote: Total 109334 (delta 914), reused 790 (delta 740), pack-reused 108156 (from 3) Receiving objects: 100% (109334/109334), 107.02 MiB | 28.13 MiB/s, done. Resolving deltas: 100% (85900/85900), done. -> Found nitrox.desktop ==> WARNING: Skipping PGP signature verification for source files. ==> Validating source files with sha256sums... Nitrox-1.8.0.0 ... Passed nitrox.desktop ... Passed :: (1/1) Parsed SRCINFO: nitrox ==> Building package: nitrox 1.8.0.0-2 (Thu Oct 16 2025 12:21:26 PM CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating Nitrox-1.8.0.0 git repo... -> Found nitrox.desktop ==> Validating source files with sha256sums... Nitrox-1.8.0.0 ... Passed nitrox.desktop ... Passed ==> Removing existing $srcdir/ directory... ==> Extracting sources... -> Creating working copy of Nitrox-1.8.0.0 git repo... Cloning into 'Nitrox-1.8.0.0'... Done. Switched to a new branch 'makepkg' ==> Starting prepare()... Restoration completed (2.8s)
Build succeeded in 2.9s ==> Sources are ready. ==> Building package: nitrox 1.8.0.0-2 (Thu Oct 16 2025 12:21:32 PM CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting build()... /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxModel/DataStructures/GameLogic/AbsoluteEntityCell.cs(23,50): warning DIMA001: The DI container should not be used directly in type 'AbsoluteEntityCell' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxClient/GameLogic/Helper/BatteryChildEntityHelper.cs(21,66): warning DIMA001: The DI container should not be used directly in type 'BatteryChildEntityHelper' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxClient/Helpers/UnityObjectExtensions.cs(22,30): warning DIMA001: The DI container should not be used directly in type 'UnityObjectExtensions' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxClient/Helpers/UnityObjectExtensions.cs(22,79): warning DIMA001: The DI container should not be used directly in type 'UnityObjectExtensions' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxClient/Debuggers/Drawer/Nitrox/NitroxEntityDrawer.cs(33,17): warning DIMA001: The DI container should not be used directly in type 'NitroxEntityDrawer' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxClient/Debuggers/Drawer/Nitrox/NitroxEntityDrawer.cs(59,17): warning DIMA001: The DI container should not be used directly in type 'NitroxEntityDrawer' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(147,41): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(169,13): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(170,13): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(171,13): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(174,13): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(175,13): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/Serialization/World/WorldPersistence.cs(185,52): warning DIMA001: The DI container should not be used directly in type 'WorldPersistence' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/GameLogic/Entities/WorldEntityManager.cs(227,20): warning DIMA001: The DI container should not be used directly in type 'WorldEntityManager' as the requested service can be supplied via a constructor parameter /home/user/.cache/yay/nitrox/src/Nitrox-1.8.0.0/NitroxServer/ConsoleCommands/HelpCommand.cs(49,45): warning DIMA001: The DI container should not be used directly in type 'HelpCommand' as the requested service can be supplied via a constructor parameter ==> Entering fakeroot environment... ==> Starting package()... ==> Tidying install... -> Removing libtool files... -> Purging unwanted files... -> Copying source files needed for debug symbols... -> Compressing man and info pages... ==> Checking for packaging issues... ==> Creating package "nitrox"... -> Generating .PKGINFO file... -> Generating .BUILDINFO file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: nitrox 1.8.0.0-2 (Thu Oct 16 2025 12:22:14 PM CEST) ==> Cleaning up... Loading packages... Resolving dependencies... Checking for conflicts...
Packages (1) nitrox-1.8.0.0-2
Total installed size: 54.40 MiB
:: Proceed with installation? [Y/n] y (1/1) Checking keys in keyring [###########################] 100% (1/1) Checking package integrity [###########################] 100% (1/1) Loading package files [###########################] 100% (1/1) Checking for file conflicts [###########################] 100% (1/1) Checking available disk space [###########################] 100% :: Processing package changes... (1/1) Installing nitrox [###########################] 100% Optional dependencies for nitrox hicolor-icon-theme: freedesktop icon support [Installed] :: Running post-transaction hooks... (1/3) Arming ConditionNeedsUpdate... (2/3) Updating icon theme caches... (3/3) Updating the desktop file MIME type cache... [user@archlinux ~]$
The package built successfully despite some dependency injection (DI) warnings during compilation. However, these didn’t cause any issues. Everything installed and runs as expected. Not sure if these warnings are relevant for you. Just sharing them in case! ;)
on the appimage and flatpak front we now have this https://github.com/SubnauticaNitrox/Nitrox/pull/2539
The AUR package currently fails to built with:
/home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxModel/DataStructures/GameLogic/AbsoluteEntityCell.cs(23,50): warning DIMA001: The DI container should not be used directly in type 'AbsoluteEntityCell' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/GameLogic/Helper/BatteryChildEntityHelper.cs(21,66): warning DIMA001: The DI container should not be used directly in type 'BatteryChildEntityHelper' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/Extensions/UnityObjectExtensions.cs(21,30): warning DIMA001: The DI container should not be used directly in type 'UnityObjectExtensions' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/Extensions/UnityObjectExtensions.cs(21,79): warning DIMA001: The DI container should not be used directly in type 'UnityObjectExtensions' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/Debuggers/Drawer/Nitrox/NitroxEntityDrawer.cs(33,17): warning DIMA001: The DI container should not be used directly in type 'NitroxEntityDrawer' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/Debuggers/Drawer/Nitrox/NitroxEntityDrawer.cs(59,17): warning DIMA001: The DI container should not be used directly in type 'NitroxEntityDrawer' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/CinematicController/RemotePlayerCinematicController.cs(102,21): error NUSL001: '?.' is invalid on type 'GameObject' as it derives from 'UnityEngine.Object', bypassing the Unity object lifetime check /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/CinematicController/RemotePlayerCinematicController.cs(182,13): error NUSL001: '?.' is invalid on type 'GameObject' as it derives from 'UnityEngine.Object', bypassing the Unity object lifetime check /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/GameLogic/Spawning/Metadata/Extractor/Abstract/EntityMetadataExtractor.cs(20,16): warning DIMA001: The DI container should not be used directly in type 'EntityMetadataExtractor' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/GameLogic/Spawning/Metadata/Processor/Abstract/EntityMetadataProcessor.cs(18,16): warning DIMA001: The DI container should not be used directly in type 'EntityMetadataProcessor' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/Gui/MainMenu/ServerJoin/JoinServerBackend.cs(104,9): warning DIMA001: The DI container should not be used directly in type 'JoinServerBackend' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/Gui/MainMenu/ServerJoin/JoinServerBackend.cs(106,30): warning DIMA001: The DI container should not be used directly in type 'JoinServerBackend' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/Gui/MainMenu/ServerJoin/JoinServerBackend.cs(108,30): warning DIMA001: The DI container should not be used directly in type 'JoinServerBackend' as the requested service can be supplied via a constructor parameter /home/christian/.cache/paru/clone/nitrox/src/Nitrox-1.8.0.1/NitroxClient/MonoBehaviours/Gui/MainMenu/ServerJoin/JoinServerBackend.cs(182,9): warning DIMA001: The DI container should not be used directly in type 'JoinServerBackend' as the requested service can be supplied via a constructor parameter
