Technical stuff : make Underrail more Dropbox/btsync/whatever-friendly

[Tramboi]

Hello and thanks for the gorgeous game (discovered on the Codex and preordered a whiiiile back).
I cloud manually my saves and I'm having a little trouble with quicksave and autosave.
When I press F5, procmon tells me that you rename "quicksave" to "quicksave (previous)" and then create a new quick save folder.
Except it often fails because my clouding tool is locking the folder to synchronize it (because a) I'm a save scummer b) my upload is low).
It's even worse with the autosave because when it fails, the game quits !
I suggest a few tiny changes to help player with this scenarios.
* When doing any save, set a max retry count and loop trying to save while it fails, sleeping maybe 1sec between tries. If it fails 10 times, for instance, you can consider it a real fail
* Use more previous slots (4? 8?), and destroy/rename to the least recently used one (it allows the player to have more backups and leaves more time to the clouding tool to do its job)
* Failing the autosave should report but not prevent going to the next map
These are not perfect solutions but they would help very much with my setup (and probably with other people's )
Hope you'll have the time and energy to consider this
Cheers and thanks for the good work,
Tramboi

[ShadowRun]

I've been using SyncThing for that purpose and had no troubles with autosave or quicksave. SyncThing even intelligently figured out that the majority of each save is duplicate data from existing saves in my repository and so only bothers to copy the files / blocks that are different in the latest save.

I would be wary of more auto/quick -save slots; they eat quite a bit of disk space.

I would think a better approach would be for a failing save operation to notify the GUI with a standard Abort/Retry/Ignore dialogue box. That way if your autosave fails, you can Ignore it. If your manual save attempt fails, you can Abort which takes you back to the name entry field. If your quick save fails, you can Retry it until it gets through. Once the failing save operation is either ignored or successful, play resumes.

[Tramboi]

Hi, I didn't try SyncThing, I'm using btsync.
I quite agree that the cleaner thing (in the sense it is orthogonal to any external stuff we're doing) to do would be a abort/retry/ignore dialog.
Coupled with fact that an ignore for an autosave failure should load the next level
Cheers

Edit: And SyncThing is supported on FreeBSD too! I might switch.
I found a log of the autosave problem :
Game Version: 1.0.1.4
Error: System.Exception: Failed to save game 'autosave'. Exception: System.IO.IOException: Le r

[ShadowRun]

an ignore for an autosave failure should load the next level

Yes - a failure to autosave shouldn't take the game down because being launched is the only copy of the current progress, when a save fails. But an unsuccessful save shouldn't be silently swept under the carpet either - a notification upon arriving in the new zone (or re-emerging on the previous zone's exit grid) will let the player know that an automatic save didn't happen and their progress is in jeopardy until they save.

I found a log of the autosave problem :
Game Version: 1.0.1.4
Error: System.Exception: Failed to save game 'autosave'. Exception: System.IO.IOException: Le r

Yep. There are a lot of those reports on the fora, generally titled "Zone Transition Fail" (by which they meant "Failure", "Failed" or "Fails" - not everyone has English as their first language).

[Tramboi]

Semi-offtopic : And thus I switched to SyncThing. It lacks a decent installer on Windows, so you have to be eager to do a bit of administration but it certainly is nicer regarding to locking files and folders. And fewer problems with Underrail. But it's mostly because enumerating is done less frequently.