I had a problem where my save files were all invalid. Very annoying when I fell into a hole and had to restart from the beginning.
Nobody else seemed to have the problem and I was being ignored on Discord, so did some research. It seems to be an old issue (+5 years) with Unity and XFS filesystems larger than 1GB. A workaround is to soft link ${HOME}/.config/unity3d/Twirlbound/ to a place on a EXT4 partition.

Also, what is the lag time for Linux patches? I see 3 sets of patch notes, but Linux still seems to be on the original release.

Hi! Thanks for reporting this, not sure how best I can handle that specific case though.. glad to hear there is a workaround.

As for the Linux patches - I was uploading them at the same time as the Win/OSX patches so I was unaware it was lagging behind. I will see whats going wrong...

I've attached what we see in the GoG download area for linux and windows. Linux version available is 0675043e.


I'll look more into the save file issue later, and see if I can determine this is, in-fact, the problem, but relevant links:
* steamcommunity.com/app/221410/discussions/0/620695877288637183/
* forum.unity.com/threads/tyranny-fails-on-large-xfs-partition-linux-unity3d-5-3-5p3.440949/
It affects 32-bit games running on filesystems with 64-bit inodes. Solutions: 1. compile game to 64bits 2. Use filesystem specific types (size_t, off_t, into_t, etc) and compile with -D_FILE_OFFSET_BITS=64

I'll ensure that this is a 32-bit game, recreate the problem, take a screenshot of the load screen for you, and do my best to compare a good save versus a failed save file. Is there a debug switch I can use to dump some logs for you? Or do you have access to a 1TB XFS disk?

It seems like a lot of games with this problem won't load, at all. That I could close the game, then launch and pick up where I left off got me far enough in to get invested, instead of dropping the game. It's only trying to load a save that breaks.

System details: 64-bit ArchLinux. Home partition is a Stratis filesystem in a 1TB pool on a single 1TB NVMe SSD.

The game is compiled for 64-bit, so there goes that idea. Still seems to be filesystem related.

I'm also having save file issues, but my partition is xt4, so I'm not sure what the real issue is.

I've checked permissions, and I have read-write permissions on the directory, but the group does not.

Both manual saves and autosaves have a big red "FAILED" listed with them. If I try to load them, it takes me back to the very begining of the game.

I'm on OpenSuSE Leap 15.0.

Martin,
It's not filesystem related. I removed my link and started Pine fresh, in order to get some bad save screenshots for you. And managed to get it to work. The xfs thing was a red-herring.

The problem is, every time you start a "New Game," any saves to a new slot are invalid, until you save into an existing slot. Once that happens, all new saves for that session seem to be valid.

There's no game interaction in any of these. I loaded the game and went straight to options.

Brand new Twirlbround config directory, New game, nearly immediate save (unusable):
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine

Another save, new slot, no game interaction (unusable):
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine
.rw-r--r-- 30k craig 23 Oct 18:58 Profile_1_2.pine

Again (unusable):
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine
.rw-r--r-- 30k craig 23 Oct 18:58 Profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 18:59 Profile_1_3.pine

4th save, in the 2nd slot (2nd and 4th slot OK, 1st and 3rd unusable):
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine
.rw-r--r-- 30k craig 23 Oct 18:58 Profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 18:59 Profile_1_3.pine
.rw-r--r-- 30k craig 23 Oct 19:00 profile_1_2.pine

5th save, in new slot (2nd and 5th slot OK, rest unusable):
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine
.rw-r--r-- 30k craig 23 Oct 18:58 Profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 18:59 Profile_1_3.pine
.rw-r--r-- 30k craig 23 Oct 19:00 profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 19:01 Profile_1_4.pine

Go back to main menu and start New Game, save (fail), then save again in the first slot - two slots OK:
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_A.pine
.rw-r--r-- 30k craig 23 Oct 18:56 Profile_1_1.pine
.rw-r--r-- 30k craig 23 Oct 18:58 Profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 18:59 Profile_1_3.pine
.rw-r--r-- 30k craig 23 Oct 19:00 profile_1_2.pine
.rw-r--r-- 30k craig 23 Oct 19:01 Profile_1_4.pine
.rw-r--r-- 31k craig 23 Oct 19:06 Profile_2_A.pine
.rw-r--r-- 31k craig 23 Oct 19:06 Profile_2_1.pine
.rw-r--r-- 31k craig 23 Oct 19:07 profile_2_1.pine


All of these files, for a session are identical. The only difference is the names. It seems like you need a lowercase profile_*.pine for saves to be read by the game.

As a final experiment, I deleted the Twirlbound directory, again, started a new game, played a bit, saved (failed), then exited, renamed the Profile_1_1.pine to profile_1_1.pine, and started pine again. The save session is there and valid.
The bug looks like some kind of lowercase/uppercase issue with your save file naming.

I can confirm, saves on top of used save slot works. New save slots do not.

Thanks for the investigation!

Adjusting our save system to have case insensitive file names was something I did right before we launched, and I might have done a sloppy job - thanks for the workaround and I will spend some more time properly cleaning it up.

I’m a little surprised that the problem is still there.
It will be reassuring if you can confirm the resolution of the problem in the future.
I’m patient, but a year later I wonder if we’re forgotten?
Thank you for your reply Martin.

Can confirm as well that the issue is still there. Fortunately my session was only 15 min, so not much to get back, but still quite annoying. At least there is a workaround, but weird that such a simple issue (with a root cause known) is still there.

Just a small addition to the @blitzcrepe's debugging;
The autosave does not have the issue, so ignoring any manual saving, the Continue always seems to work starting from scratch. Of course, this prevents alternative profiles, but it is weird that the autosave works, but the manual saves do not...