Stardew Valley has nondeterministic save times

[coolkirby2000]

Hi Clément, thanks for fixing my previous issue.

Stardew Valley (GOG version) runs from the binary outside of libTAS 1.4.7. However, it gives an X Error in libTAS terminal, fails to create the window and crashes.

Using Xubuntu 24.04 amd64, libTAS 1.4.7, Stardew 1.6.15.24357.8705766150 GOG.com version.

• Repro

1. Download Stardew's 1.6.15.24357.8705766150 installer .sh from GOG.com
2. Make the script executable (chmod +x)
3. Run with Terminal (I did this so it didn't try to open in a text editor)
4. Install to default path, accepting EULA, then close the Terminal
5. Open libTAS 1.4.7, set clock_gettime() monotonic in its Runtime options, and use:
   /home/[user]/GOG Games/Stardew Valley/game/Stardew Valley
   as the Game executable, substituting your user for [user]
6. Click Start

With libTAS' standard video options, I get this:
Attempt 1: Connected.
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 12 (X_ConfigureWindow)
Value in failed request: 0x0
Serial number of failed request: 138
Current serial number in output stream: 139
No movie recording was selected. A backup movie was saved to /home/xubuntu/.local/share/libTAS/movie/backup.ltm

And by setting Video>Screen resolution to any Common value (e.g. 1280x720), I get slightly different values:
Attempt 1: Connected.
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 12 (X_ConfigureWindow)
Value in failed request: 0x0
Serial number of failed request: 126
Current serial number in output stream: 127
No movie recording was selected. A backup movie was saved to /home/xubuntu/.local/share/libTAS/movie/backup.ltm

Using "Start with GDB" with Stardew seems to softlock libTAS. After 10 "Couldn't connect to socket" messages, it dumps a movie file, then the Start, Start GDB, and Stop buttons remain greyed out until you close the program.

I only have one 1366x768 monitor, and have verified that echo $DISPLAY returns :0 for me. I can launch xeyes (X server is working), glxgears (OpenGL is working), and the game itself continues to launch from the executable path outside of libTAS.

The integer parameters out of range may be the window size or position too low or high, but nothing I changed in /home/[user]/.config/StardewValley/startup_preferences fixed it, like skipWindowPreparation, windowMode, displayIndex, vsyncEnabled, fullscreen, or any of the four resolution values.

I would appreciate any help getting this running.

[clementgallet]

v1.4.7 is buggy for a lot of games. I was able to run this game fine using latest interim. I had to also check "Wait timeout > Full waits" to avoid a very slow speed.

[coolkirby2000]

Thanks @clementgallet for your response, and informing me about v1.4.7's bugs. Unfortunately Full waits causes inconsistent desyncs when playing a TAS in both v1.4.6 and latest interim, so I will stick with Native waits. I did learn from playing around with waits though (like that Finite waits is even slower), and I'll remember it when testing games in the future. v1.4.6 didn't have that slow speed, is it a regression or just more accurate emulation?

I also found a new issue in both interim and v1.4.6 on default settings, which is even more pronounced in interim: inconsistent save times. The game saves after you start a new adventure (Prevent writing to disk is on), but this takes different amounts of time every time I close the game and play back the TAS from the start. (Let me know if a new libTAS issue should be made for this.)

In v1.4.6, I've had the ingame text turn green to indicate saving has finished on frame 1228, 1221, 1226, 1209, 1229, 1221, 1223, and 1248. On some of these, the input after it will still sync. Maybe it's close enough, or somehow the input updates with the delay? Values like 1209 and 1248 are too far off for input following it to sync though.

The interim from 3-16-2026 you mentioned varies more wildly: 1124, 1022, and 1050. I didn't test as much because of the slow speed with Native waits. At first I thought the game saves around 100 frames faster than v1.4.6, but now I have no idea what baseline to sync a submittable TAS at if they're so different every time.

Here is a movie file to test a few times and see what I mean. This was partially resynced to interim. If opening it in v1.4.6, remember to add 2 empty frames to the beginning or it won't skip the pink ape intro correctly on frame 16.

[clementgallet]

In v1.4.6, I am getting inconsistent speed. Probably because the game start is also more inconsistent, and we end up in a different portion of the game engine frame length, so that we have a different amount of time to advance.

However I could run the game at full speed without any wait setting, by setting the game to 50 fps.

Concerning the save, that is unfortunately the cause of all assets loading as well as savefile handling being done on a separate thread. This game is using .NET, and I have not done a lot of work on this runtime. It would need a lot of work to hook .NET internal functions and understand the structure of those games.