Hi, love what you've built here. The third-party API you shipped in v2.1.5 is a really clean design, and I'd like to be the first one to use it on Linux.
I maintain SLSsteam-Plus, a SLSsteam fork that has drifted from upstream in a couple of ways that matter for CloudRedirect. The config format is TOML now, not yaml, so CR's current config parser wouldn't find ours. And more importantly, app unlocking has mostly moved to Lua scripts. We took inspiration from OpenSteamTool's Lua system and use addappid() as the primary unlock path, where depot keys, DLC flags, and hot-reload all live. There's still a static app list in the config as a baseline, but most users don't touch it.
So the current Linux self-hosted mode has two blind spots for us: it's looking for a yaml file that doesn't exist, and even if it could read ours, the Lua apps (usually the majority) never get written to any config file. Users end up having to manually duplicate every Lua entry into the config just to get cloud saves working, which kind of defeats the purpose.
On Windows none of this is a problem. OpenSteamTool PR #138 just pushes the live app set through the API and re-syncs on hot-reload. The host owns the list, CR doesn't need to know how the host stores its config, done.
The header already has the Linux visibility macros and all seven function signatures, but there's no implementation on the Linux side yet. If that was in place, I could write a thin host module on my end (same pattern as OST) and both problems go away.
There's also a practical bonus: we already hook several of the same vtable slots CR patches in self-mode, so two agents fighting over the same entries gets fragile fast. If the host is driving, CR can skip installing its own hooks entirely and the conflict disappears.
Would you be open to landing a Linux implementation of the API? Happy to do the work and send a PR if the direction sounds right. And if you had something different in mind for Linux, I'm curious to hear it.
Hi, love what you've built here. The third-party API you shipped in v2.1.5 is a really clean design, and I'd like to be the first one to use it on Linux.
I maintain SLSsteam-Plus, a SLSsteam fork that has drifted from upstream in a couple of ways that matter for CloudRedirect. The config format is TOML now, not yaml, so CR's current config parser wouldn't find ours. And more importantly, app unlocking has mostly moved to Lua scripts. We took inspiration from OpenSteamTool's Lua system and use
addappid()as the primary unlock path, where depot keys, DLC flags, and hot-reload all live. There's still a static app list in the config as a baseline, but most users don't touch it.So the current Linux self-hosted mode has two blind spots for us: it's looking for a yaml file that doesn't exist, and even if it could read ours, the Lua apps (usually the majority) never get written to any config file. Users end up having to manually duplicate every Lua entry into the config just to get cloud saves working, which kind of defeats the purpose.
On Windows none of this is a problem. OpenSteamTool PR #138 just pushes the live app set through the API and re-syncs on hot-reload. The host owns the list, CR doesn't need to know how the host stores its config, done.
The header already has the Linux visibility macros and all seven function signatures, but there's no implementation on the Linux side yet. If that was in place, I could write a thin host module on my end (same pattern as OST) and both problems go away.
There's also a practical bonus: we already hook several of the same vtable slots CR patches in self-mode, so two agents fighting over the same entries gets fragile fast. If the host is driving, CR can skip installing its own hooks entirely and the conflict disappears.
Would you be open to landing a Linux implementation of the API? Happy to do the work and send a PR if the direction sounds right. And if you had something different in mind for Linux, I'm curious to hear it.