Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teslagrad hardlocks during gameplay load in LibTAS 1.4.3 and 1.4.4 but not 1.4.2 #515

Closed
BoursinBurger opened this issue Dec 22, 2022 · 2 comments

Comments

@BoursinBurger
Copy link

Teslagrad is a Unity game obtainable via Steam for Linux. I am attempting to create a TAS but encountering an issue where the game freezes in the latest version of LibTAS upon gameplay load. I am using a Linux PC running Ubuntu as the platform.

Setup instructions:
Install Teslagrad via Steam for Linux, then set its version to 1.3.1 via Properties -> Betas.
Install an additional dependency for Teslagrad: sudo apt-get install libglu1
Launch Teslagrad natively from Steam and set it to Windowed mode in Options -> Graphics, then Exit.
Launch LibTAS and set properties as follows:
Game Executable: ~/.steam/debian-installation/steamapps/common/Teslagrad/Teslagrad
Command-line options: -force-gfx-direct
Runtime menu -> Check Virtual Steam Client
Frames per second: 120

Start a new game, then either let the opening cutscene play until fadeout, or press Esc and return to the Main Menu, then load the save game slot named Home.

Three logs are attached: one from LibTAS 1.4.2 where gameplay loads successfully, one from LibTAS 1.4.4 where the game freezes at frame 1059, and the GDB dump after the freeze occurs. Comparing the two logs, the freeze seems to occur before enterFrameBoundary can be called on frame 1059.

Troubleshooting efforts: Checking the individual debug options (Uncontrolled time, Native events, Keep main first thread, Native file IO) does not resolve, nor does any of the other various Runtime options that we have tested.

Teslagrad_Logs.zip

clementgallet added a commit that referenced this issue Dec 26, 2022
Before, we were storing the pointer of the thread start routine.
Teslagrad was soflocking during the intro cutscene because one of the
thread classified as loading thread by libTAS was not waiting and was
sleeping instead. This thread has the right start routine pointer, but
was started from a different address than the other threads.

So I changed the condition so that both the pointer of the start
routine thread and the pointer of the caller must match to classify
as a loading thread. This may cause desyncs in other Unity games, so
I might revert that change.
@clementgallet
Copy link
Owner

Should work now.

@clementgallet
Copy link
Owner

I never explained the change btw. Starting from v1.4.3, libTAS implements special code to add determinism for Unity titles, by detecting loading threads and waiting for them on main thread. It seems that for this game, one thread occasionally sleeps continuously for some reason instead being in its rest state (wait).

fcd8500 was breaking determinism on other Unity titles (Dandara at least), so I reverted the change and added a timeout. Now it runs fine, and you get very occasionally a .5 sec timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants