Steamdeck decky plugin

[binarygeek119]

What's your idea?

It be nice if there was a plugin to back up in steam deck game mode. There's a plugin for decky call decky cloud sync. But I would like to use one tool and not too. Decky cloud save could be a good template/starting point.

[GedasFX]

Hello, I am the person who made decky-cloud-save. I was actually working on a port to support Ludusavi. The code base is almost done. I am just wrapping up with polishing.

If you could figure out a way to sync paths from linux to windows, it is good to go!

[GedasFX]

The primary issue here is that the paths really do not like being consistent when jumping between Linux and Windows (example below)

(the path here is /emulators/GBA/saves.

I could try to push the plugin as is, but if I can get proper support/steps for Windows/Linux interop, that would be great!

[mtkennerly]

@GedasFX That sounds cool :D I can try to help, but this is definitely a difficult area.

On Windows, Ludusavi currently treats /foo as C:/foo, which isn't too bad, although it can be confusing for redirects (#185) and could result in some meaningless placements (e.g., restoring /home/foo to C:/home/foo isn't very useful compared to C:/Users/foo).

On Linux, it'll treat C:/foo as ./C_/foo, which isn't great and requires setting up some redirects. The most "correct" solution would probably be to flag those paths as invalid on the current OS and refuse to process them unless there's an appropriate redirect defined, but it would also be nice to streamline things for users.

Aside from the / vs C:/ handling, if you really want cross-OS interop, then the bigger issue is Wine prefixes (#194) and games that store saves in fundamentally different places on different OSes (e.g., %USERPROFILE%/Saved Games/foo vs ~/.config/foo). How do you handle that in decky-cloud-save?

[GedasFX]

How do you handle that in decky-cloud-save?
Well short answer, I don't support bisync 😎. I know Its a massive rabbit hole, and decided to not even ATTEMPT to figure it out. Its basically a glorified rsync tool :D

From my issues and pokes on Discord, I can very much see that the biggest demand for this is Emulation (shocking I know). Very few people play on Epic Games (or maybe my plugin works great there for the few that do :D), so requests are usually to support Emulation, which at very least we can precisely(ish) control the paths under Custom Games. I just never was able to figure out how the Redirects worked. If we can get some tutorial for this part, I know it will cover like 90% of all Steam Deck users :D

[mtkennerly]

Well short answer, I don't support bisync 😎. I know Its a massive rabbit hole, and decided to not even ATTEMPT to figure it out. Its basically a glorified rsync tool :D

That's fair 😅 That makes this use case a lot simpler.

I just never was able to figure out how the Redirects worked

There's a section in the README here: https://github.com/mtkennerly/ludusavi?tab=readme-ov-file#redirects , but if it's unclear or you have any specific questions, I'd be happy to try to answer.

To work around the /home/deck/C_ issue specifically, you could set up some redirects on the Steam Deck like this (although I don't have a Linux system handy to test):

(Those may be too general, since you probably don't want to end up with a /Users or /Program Files folder on Linux, but you can narrow them down more specifically if you only want to include some subfolders, like ~/C_/emulators/ -> /emulators)

On Windows, the /-initial paths should all restore to C: by default, so you wouldn't need any redirects on Windows unless you want them to go to another drive.

[GedasFX]

Yeah I checked on README, but ultimately just everything was failing. One thing that I found out that I spent so much time on, is that every time I changed Redirect, it didn't actually reflect in the UI until AFTER I restarted the program.

In the README itself, the actual redirects are explained clearly, just not the Linux/Windows compatibility.

This is the thing I was trying to achieve:

Windows side:
Bidirectional: C:\Users\gedim\Desktop\Ludusavi Gaming\GBA\saves -> /emulators/GBA/saves

Linux side:
Bidirectional: /run/user/1000/doc/1764bcab/saves -> /emulators/GBA/saves

When I push from Linux, path gets correctly overridden, then when I restore from Windows side, all works good too. However, when I go to back up, the files are marked as new?

And this is where I am stuck as it seems like it should correctly detect, but just doesn't? It is also almost 11 PM right now, and I spent almost all day getting this thing to work so my brain is fried. Feedback is appreciated on what I did wrong.

[mtkennerly]

One thing that I found out that I spent so much time on, is that every time I changed Redirect, it didn't actually reflect in the UI until AFTER I restarted the program.

Hmm, the latest redirects should apply to any game when you (re-)scan that game. If it really requires a whole relaunch, then that's a bug.

Windows side:
Bidirectional: C:\Users\gedim\Desktop\Ludusavi Gaming\GBA\saves -> /emulators/GBA/saves

Unfortunately, this means on Windows that the backup will contain C:/emulators/..., which then won't match your redirect on Linux. The same issue came up in #185. For now, as a workaround, you could configure it this way, where each OS restores from the other OS's path:

• [Windows] Restore: /run/user/1000/doc/1764bcab/saves -> C:\Users\gedim\Desktop\Ludusavi Gaming\GBA\saves
• [Linux] Restore: C:\Users\gedim\Desktop\Ludusavi Gaming\GBA\saves -> /run/user/1000/doc/1764bcab/saves

When I push from Linux, path gets correctly overridden, then when I restore from Windows side, all works good too. However, when I go to back up, the files are marked as new?

That's an interesting case! When Ludusavi checks which files are new to back up, it finds the files, computes how the path would be stored as a key in mapping.yaml, and then checks if that key already exists in mapping.yaml. When you do the backup scan on Windows, the keys will start with C:/emulators, which does not match against the /emulators keys from your Linux backup.

Because of the bidirectional redirect you made, the backup keys on Windows really should start with /emulators and not get translated to C:/emulators. I'll spend some time and see if I can fix that.

[mtkennerly]

@GedasFX I've just finished some significant refactoring of how Ludusavi handles paths, so now your two bidirectional redirects should work correctly. Could you give it a try and let me know if you still run into any problems?

• Windows (64-bit): ludusavi-v0.22.0-post.46+fcbc488-win64.zip
• Linux: ludusavi-v0.22.0-post.46+fcbc488-linux.zip

[GedasFX]

Hey, well I tried to get around to doing this as soon as possible, and I guess now is the time 😄

The UI on Steam deck is completely whack with the scaling, but it may be a weird binary issue? I always used the flatpak and it worked fine. Using CLI worked okay though. I tested the windows flow and it seems to be working great now!

[mtkennerly]

Ah, yeah, the Flatpak fixes the scaling automatically. You just need to set the WINIT_X11_SCALE_FACTOR environment variable to 1 to fix it.

[TeamLinux01]

This sounds like an awesome idea. I really look forward to it.

I have also started playing around with Bazzite on my desktop and Steam Deck LCD again; that version allows for easily setting up decky.

The only issue I am waiting on for Ludusavi to tackle is the weirdness that happens because ublue atomic OSes store /home/ in /var/home and use a symbolic link to /home. Right now I have my paths as /var/home and some redirects.

Just wanted to say that I support both of your works. Thanks!