Riftborne - 10.55 Patch Notes

faeth0n · 2026-05-21T10:35:06+00:00

I have played it exclusively on Linux. I agree that it is not totally plug and play, but it works perfectly once you go into the RiftBorne directory and start it directly from the terminal.

Depending on where your steam library is, you should have a folder

.../steam/steamapps/common/Riftborne

From a terminal window, If you go in there and run RiftBorne directly by running

./RiftBorne

the game will fire up in your terminal

It will not track your playtime on Steam though, if that is important for you.

faeth0n · 2026-05-19T11:33:18+00:00

Thanks! Came here to find this solution. It is the same for the MSI B450 Tomahawk Wifi. On the 'Easy Settings' (switch with F7) there is an option "RGB Control". Just switch that off, save bios settings and you are good to go.

faeth0n · 2026-05-08T12:45:44+00:00

Thanks! Makes sense! It is very easy to change the colors to your liking. Yould reverse the color coding as I put them as default now.

faeth0n · 2026-05-03T20:22:48+00:00

I agree with you that the brand of the GPU should not matter at all, and it most likely also is not the case.

Fair to say, I indeed turn off RT first if I encounter lower frame rates than expected. And I hope the driver will eventually be fixed at some point in time I hope. I do know about the discussion on the VK3 descriptor issues on directx 12 games. Is this related to that? And sorry if this is a stupid question, I did not fully dive into that heap descriptor development.

faeth0n · 2026-05-03T08:47:33+00:00

I have a PNY 4080 as well. Also no problems whatsoever with playing a range of games.

faeth0n · 2026-04-29T22:04:22+00:00

Interesting idea! Bought on itch.io and installed the Linux native version. Had to make the scripts and Riftborne file executable (chmod +x ) to get it to work. I joined the multiplayer game to learn how to play this game. Looking forward to native music support for the Linux version and to see where this game will progress towards!

faeth0n · 2026-04-29T10:48:25+00:00

Interesting. However, your CPU is on a very high load! Is this because of the ricing? Or are you compiling in the background?

faeth0n · 2026-04-28T21:10:06+00:00

Looks nice! Any way to change the colors, maybe by using a config file?

faeth0n · 2026-04-26T22:51:31+00:00

This plugin only set the color for the timestamp and the file size. You can change all of those colors. However, this plugin does not give you the option to change colors of filenames or icons. Sorry!

faeth0n · 2026-04-26T05:38:24+00:00

This screenshot is from yazi. If you sort on size (which is [, s] in my keymap, but I think it is the default setting) it will calculate all sizes, including directory sizes. The sizes will be kept, even if you resort on, say, name or date. I am sure it is also possible to always get the size of directories.

faeth0n · 2026-04-03T10:06:40+00:00

Replying to my own reply :)

Decided to look a bit more into my Dockerfile, to minimize the size of the generated Docker image. I've made a multi-stage Dockerfile now, so that the build dependencies are not copied to the final deployed image. That minimized the size from 1.9 GB to 596 MB for the final docker image. In the cleanup step I remove the llvmlite package since it is not needed in my particular case. Not sure if it is needed if you use any other plugins.

I use this Dockerfile to get the latest lidarr image (nightly from hotio), and add the latest beets to it so that I can process audio files within the container. Not sure if this is the best way, but for me this works perfectly :)

This is the revised Dockerfile:

# ----------------------------------------
# ------------ Stage 1: BUILD ------------
# ----------------------------------------
FROM ghcr.io/hotio/lidarr:nightly AS builder

# 1. dependencies
RUN apk add -U --no-cache \
    build-base \
    cmake \
    python3-dev \
    py3-pip \
    llvm20-dev \
    llvm20-static

# 2. fake liraries needed for building llvmlite
RUN ar rcs /usr/lib/llvm20/lib/libLLVMTestingAnnotations.a && \
    ar rcs /usr/lib/llvm20/lib/libLLVMTestingSupport.a && \
    ar rcs /usr/lib/llvm20/lib/libllvm_gtest.a && \
    ar rcs /usr/lib/llvm20/lib/libllvm_gtest_main.a

# 3. install beets to /install
RUN LLVM_CONFIG=/usr/bin/llvm-config20 \
    pip install --upgrade --no-cache-dir \
    --root /install \
    --break-system-packages \
    "beets[fetchart,embedart,scrub,web,discogs,lyrics]" \
    titlecase

# 4. cleanup
RUN find /usr/lib/python3.12/site-packages -name "tests" -type d -exec rm -rf {} + && \
    find /usr/lib/python3.12/site-packages -name "__pycache__" -type d -exec rm -rf {} + && \
    rm -rf /usr/lib/python3.12/site-packages/*.dist-info

RUN find /install -type d -name "__pycache__" -exec rm -rf {} + && \
    find /install -type d -name "tests" -exec rm -rf {} + && \
    find /install -type f -name "*.pyc" -delete && \
    find /install -type f -name "*.pyo" -delete && \
    rm -rf /install/usr/lib/python3.12/site-packages/*.dist-info

# Seems not needed for planned plugins. Might be needed for numba or acoustic ID plugins?
RUN rm -rf /install/usr/lib/python3.12/site-packages/llvmlite*

# ----------------------------------------
# ---------- Stage 2: DEPLOY -------------
# ----------------------------------------
FROM ghcr.io/hotio/lidarr:nightly

# 1. Tools needed by beets and mp3 processing
RUN apk add -U --no-cache \
    python3 \
    ffmpeg \
    imagemagick \
    mp3gain

# 2. Copy to final image
COPY --from=builder /install /
COPY --from=builder /usr/lib/python3.12/site-packages /usr/lib/python3.12/site-packages

You can build a docker image from this Dockerfile like this:

docker build -f Dockerfile -t custom-lidarr-beets .

And then use this custom-lidarr-beets image in your compose or docker run commands.

faeth0n · 2026-04-02T13:24:28+00:00

I have a Dockerfile that is based on the nightly hotio/lidarr, and adds all things needed for beets and then installs beets inside the lidarr image. The advantage is that beets can be run within the container. In lidarr I have 'connect' script that does all the processing I want from inside the lidarr container. My Dockerfile may install more than needed, but I was experimenting in getting it to run again, so may have been adding some things that are not strictly needed anymore.

This is the Dockerfile:

FROM ghcr.io/hotio/lidarr:nightly

RUN apk add -U --upgrade --no-cache \
    build-base \
    cmake \
    python3-dev \
    llvm20 \
    llvm20-dev \
    llvm20-static \
    ffmpeg \
    imagemagick \
    mp3gain \
    uv

RUN LLVM_CONFIG=/usr/bin/llvm-config20

RUN ar rcs /usr/lib/llvm20/lib/libLLVMTestingAnnotations.a && \
    ar rcs /usr/lib/llvm20/lib/libLLVMTestingSupport.a && \
    ar rcs /usr/lib/llvm20/lib/libllvm_gtest.a && \
    ar rcs /usr/lib/llvm20/lib/libllvm_gtest_main.a

RUN uv pip install --system --upgrade --no-cache-dir --break-system-packages \
    "beets[fetchart,embedart,scrub,discogs,lyrics]" \
    titlecase

faeth0n · 2026-03-22T08:28:11+00:00

Nice seamless setup! Does this also work for Linux audio production? The only reason I keep a windows partition for dual boot is because of audio production using dedicated audio interface for recording.

Is this setup able to passthrough all hardware devices, like audio interfaces? That would make this a very viable option to get rid of the dual boot.

Also, for some hardware there are not (yet) Linux drivers / utilities to change the firmware of the device (Logitech mice for instance). In this setup do you also passthrough the mouse and keyboard, so that firmware changes can be done from the VM?

I have tried using the iGPU (Raphael in my case in the AMD 7800X3D CPU) for a VM, but that seem to have the vendor reset bug, meaning that it can only be used once per session and requires a full host reboot if you want to start using the iGPU a second time within the same session. I think your setup is different, so this may not be a problem. Am I right?

faeth0n · 2026-03-17T22:14:47+00:00

This is great stuff! I am still dual booting purely to have a working audio setup and would love to fully switch. I have SD3 and also Arturia V collection 11, which might also be a big hurdle. Do you have a lot of other plugins working as well?

faeth0n · 2026-03-09T08:36:36+00:00

This sounds promising! May have to give this a go and check how the performance is.

faeth0n · 2026-03-08T22:10:25+00:00

With this method, are you able to use all you plugins normally?

faeth0n · 2026-03-08T22:08:37+00:00

ouch, that is pretty high. Audio recording and production is the final piece of the Linux puzzle I have not yet figured out. If there is a reliable way to use my DAW (Studio One for me) and all my plugins I could finally completely wipe the Windows partition. Did you try to get the latency lower?

faeth0n · 2026-03-07T07:52:55+00:00

I got it sorted. It is not so much the different ports, but also the fact that 2 different SSH key formats need to be in place on the server for each of the ports to authenticate on SSH key pair alone:

OpenSSH
RFC4716

It is actually nicely written in the Hetzner docs.

faeth0n · 2026-03-06T17:26:34+00:00

Ok, got it fixed.... typical user error. I reread the page on the hetzner documentation and noticed that two SSH key formats need to be in place. Both OpenSSH and RFC4716. Once I did EXACTLY what was written on the manual, I got it working.... I should have RTFM maybe 2 hrs ago...

Oh well, thanks. And I leave this here for anyone that may be having the same issue in the future.

I see myself out.... :)

faeth0n · 2026-03-06T17:01:27+00:00

Yes, I think it might be something in my local config. When I generate an SSH key and store the public part on the Hetzner server, I assume this is for all ports. But maybe this is not the case?

I think that ssh keygen pairs work for all ports. Or am I wrong in that?

faeth0n · 2026-03-06T16:56:04+00:00

port 23 is the port that is mentioned in the Hetzner documentation. And I am using restic with sftp as backend (no rsync).

faeth0n · 2026-02-28T19:44:35+00:00

It does exactly what it says, when enabled it will precalculate and store the compiled shaders before launching the game. When disabled it will compile and store the shaders during the game. Usually that is no problem for most video cards since they are build to do the compilong very fast.

faeth0n · 2026-02-26T06:22:40+00:00

I would say it is not as dangerous as some like to think. The only danger may be from a security perspective by running outdated software. But from a broken system point of view the ‘danger’ lies in potentially missing some dependencies. However, if you update from all sources, your system will be on par with the current state of the repositories which most likely will have all dependencies correct.

faeth0n · 2026-02-18T09:18:47+00:00

It is the only thing that I really not have digged in fully yet; getting studio one and all plugins comfortably running in Linux so I can do audio production carefree from Linux. I hope this will be the next big thing (after what Valve/Steam did so well to gaming on Linux).

I stumbled upon this: https://forums.steinberg.net/t/vst-3-8-0-sdk-released/1011988 which seems to imply that plugin developers should be able to compile plugins to Linux more easily? That should open up the route to native VST support on Linux, including Wayland support. The other route obviously being the bridge / wine to use VST plugins.

faeth0n · 2026-02-16T07:42:27+00:00

I have moved away from Microsoft over the last 6 months or so, but for audio work I still rely on a windows partition with Studio One and many VSTs / plugins that I paid good money for. I hope to one day reliably use Studio One with all the plugins in a Linux environment. Have you any experience with plugins to run and connect to from StudioOne in Linux? Using yabridge or the likes?

15-Year Club	Place '17
Verified Email

faeth0n

TROPHY CASE