Hi there. I can't get my gamepad to work at all. I've tried 6.3, 6.10-GE, 5.13, and Experimental in the Flatpak version and in the non-sandboxed Xubuntu 20.04 version, all with Steam Input both enabled and disabled. Disabling Steam Input makes controllers work in Power Rangers BFTG, although that game is Unity, not UE4. Other UE4 games like Tekken 7 and SoulCalibur VI read controller input just fine with no fuss at all.

Is there anything we might be able to do about this in the near-ish future? Are there command line options that modify gamepad detection or behavior? I'm happy to test some things, but I don't want to go over an hour and be unable to get a refund so I can switch to the PS4 version.

EDIT: I was able to get Proton 5.9-GE-ST-8 to read my controller, but then it just freezes in character select for training mode. Coincidentally, this is also the last version of Proton where controller input works for Bloodstained: Ritual of the Night. Any version afterwards, using the Soldier runtime, does not work.

Should add that the crash appears to happen on the character select screen. I've been able to play the training missions that load you straight into the game without issue.

I tried running with a few versions of Proton GE (6.8, 6.9, and 6.10), none of which got past the crash on trying to load the video of the bird flying out the window, after the character select screen.

But per this thread on Reddit: https://www.reddit.com/r/linux_gaming/comments/nxcoxu/guilty_gear_strive_apparently_perfect_on_launch/

I deleted my prefix (I don't care about my save file, I hadn't done anything yet) and tried running with Proton 5.13-6, which worked as stated in the thread. The game still doesn't play the videos, and the character select screen's background is gray, but it at least skips past them and doesn't crash, letting you get into training or versus modes. Seems to run perfectly fine so far. The reddit thread OP says that network play works for him; I'll give it a try later if work continues to be slow today. Though network play doesn't involve the character select screen as far as I know, so it may circumvent the crash on other Proton versions anyway.

@kisak-valve Yep, running with Proton 6.3-4 and that launch option set does the same; videos are skipped and I'm able to get into training mode.

@HugLifeTiZ GE 6.10-1 over here. The game doesn't register a controller for me unless you enter the game, and then select the option to return to the intro splash screen. After doing this, the controller works perfectly.

Hello @waycooler, your feedback hints that it might be interesting to test the game with Proton 6.3 and the game's launch options set to WINEDLLOVERRIDES="mfplay.dll=d" %command%, then see if the videos are skipped in a similar way as your experience with Proton 5.13.

Running Proton-6.10-GE-1 was also unable to access training mode and the game would hang upon browsing the command lists.

WINEDLLOVERRIDES="mfplay.dll=d" %command% allows me to skip said videos alongside the stage selection screen, enabling access to training mode and a stable menu. At least so far.

Online functions have been stable since my first launch.

I don't know if this is a proton issue or a game issue, but if I disconnect my controller and try to reconnect it, it's not registered by steam until the game completely shuts down.

WINEDLLOVERRIDES=winegstreamer=d %command% allows the game to be playable here, no freeze even on my GE build.

Miraculously Arcade mode scenes seem to still play? lol

Story mode videos seem to play fine also.

Other than the eagle transition after selecting characters in single player modes, disabling the mfplay DLL also stops the preview videos on the command list in training mode from playing. But that's probably to be expected.

Compatibility Report

Name of the game with compatibility issues: Guilty Gear Strive
Steam AppID of the game: 1384160

System Information

GPU: GTX 1080 ti
Driver version: nvidia 440
Kernel version: 5.4
Proton version: 6.10-ge-1

Symptoms

After changing the graphics settings the game has occasional stutters. It is playable but not ideal for online play and the game was running before at near max settings perfectly fine.
-I change all settings to max and resolution to 2560 x 1440
The game ran fine before changing the settings from their default values
-Even if i change all the settings to low the game still stutters in matches and even in the menu.
-I have not changed any drivers or system configurations.

@jeromealane1 Sounds like shader/pipeline compilation stutter. Side effect of using DXVK. There's really nothing you can do about this except deal with it until the cache is built up, at which point it will go away (try to trigger visual effects in practice mode by landing specials and such—if the compilation happens there, it won't happen in a real match). Changing back to default settings may help because you've got more of a cache there already.

Tried playing survival mode and the game gave me a "Fatal Error" message. I wanted to try again with logging on, and the game simply froze instead.
steam-1384160.log

Already posted in #4906, but might be better suited here.

With Proton 6.3-5 RC (no launch options) the games works as good as you would expect, with the exception of (many, but but not all) videos.
The most important videos (the ones you see the most) seem to work just fine (e.g. character select screen and eagle transition).

Some command list move videos for Sol Badguy do work, but for all the other characters they do not work.

I'm not sure how valve is handling the media foundation videos, maybe they have not converted (?) all of them yet?
Is there anything I can trigger from my end to get the rest of the videos to work/play?

@notpentadactyl Not really. It's a little odd that some play and some don't. There must be some difference in API usage between them...

Does anyone have any idea why the cloud save doesn't seem to work? My Windows install works fine, and successfully recovers the cloud data on reinstall. It seems something is weird about GG in Proton specifically.

I figured out my controller problems, they were unrelated to anything Strive was or wasn't doing.

Between the Proton 6.3-5 RC and the actual release of Proton 6.3-5, something broke WRT videos. The character select screen video and eagle transition were working in the RC, and are no longer working, replaced by the test pattern video.

Does anyone have any idea why the cloud save doesn't seem to work? My Windows install works fine, and successfully recovers the cloud data on reinstall. It seems something is weird about GG in Proton specifically.

I have the same issue.

I re-tested with Proton-6.12-GE-1 and now every video seems to work. :+1:

I have some tests with two different machines -- hopefully these help iron out some of the remaining issues with this game.

Using Proton 6.3-5 on Manjaro KDE flavor. Full specs:

 OS: Manjaro 21.1.0 Pahvo
 Kernel: x86_64 Linux 5.10.49-1-MANJARO
 Uptime: 19h 57m
 Packages: 1673
 Shell: bash 5.1.8
 Resolution: 3120x1920
 DE: KDE 5.84.0 / Plasma 5.22.3
 WM: KWin
 GTK Theme: Breeze [GTK2/3]
 Icon Theme: breeze
 Disk: 1.3T / 3.8T (34%)
 CPU: Intel Core i7-4770K @ 8x 3.9GHz [42.0°C]
 GPU: Radeon RX 590 Series (POLARIS10, DRM 3.40.0, 5.10.49-1-MANJARO, LLVM 12.0.0)
 RAM: 5932MiB / 11912MiB

This machine runs GG:Strive fairly well, with some notable problems.

• There's an issue where cloud data isn't being transferred from my Windows copy, which also creates problem when trying to play online since it doesn't store any unlocks or profile information (so I think it's fairly important to fix this.) It is worth noting that Windows <=> Windows synchronization works, so if I were to take a random guess, I would say it likely has to do with caps sensitivity on Linux, but that's a shot in the dark.

• Occasionally having the sticks plugged in during the title screen will cause the game to hang. A work around is to enter the main menu with the keyboard, plug in the stick(s), and then back out to press start on one of the controllers. For reference, I have 2 Qanba EIGHTARC sticks circa 2010 or so, both set to Xbox 360 mode.

• This same machine crashed on load when running with Proton Experimental, crashing while showing the "gear loading" icon at the bottom right.

========

Using Proton Experimental on a Fedora Machine:

 OS: Fedora
 Kernel: x86_64 Linux 5.12.14-300.fc34.x86_64
 Uptime: 1d 7h 51m
 Packages: 2594
 Shell: bash 5.1.0
 Resolution: 2560x1440
 DE: GNOME 40.0
 WM: Mutter
 WM Theme: Adwaita
 GTK Theme: Adwaita [GTK2/3]
 Icon Theme: Adwaita
 Font: Cantarell 11
 Disk: 643G / 1.2T (57%)
 CPU: AMD Ryzen 5 1600 Six-Core @ 12x 3.6GHz
 GPU: NVIDIA GeForce GTX 1060 3GB (nVidia driver version: 465.31)
 RAM: 4911MiB / 15997MiB

This machine has more problems, many of which don't make the game unplayable, but add to the inconvenience...

• The game normally runs at the correct speed and frame rate when entering the character select screen. However, after entering the main "fighting" game state and backing out to the character select menu, the game will sometimes run extremely slowly during the character select state (4FPS.) This is after verifying that all shaders were cached, with background shader caching enabled as well. These performance slowdowns happen nowhere else in the game.

• Blur effects seem to be backwards. In the normal game, when you hit a big "COUNTER" hit, the blur will be applied only to distant elements. On this machine via Proton, the foreground elements are blurred by default, and when a big COUNTER hit happens, the image becomes sharper. That is to say that the entire state of the effect is backwards (goes from blurry to sharp,
  and effects foreground instead of background.) You can test this by picking Potemkin in the training mode, apply "Force Counter Hit" in the "Training Settings", and hit the opponent with a "Heavy Slash" move. This is also more noticeable when playing with lower effects quality.

============

Miscellaneous Observation:

• (Maybe Placebo) It seems like the Communicating with Server message is much faster on my Linux machine than it is on my Windows boot. In many ways a benefit, but is also kind of an interesting curiosity.

I did a little more digging on the save data.

According to SteamDB the game stores its save data in WinAppDataLocal GGST/Saved/SaveGames/{Steam3AccountID}.

I decided to do a find for the SaveGames directory in my wineprefix, but found there are actually two;

$ find . -name "SaveGames"
./drive_c/users/steamuser/Local Settings/Application Data/RED/Saved/SaveGames
./drive_c/users/steamuser/Local Settings/Application Data/GGST/Saved/SaveGames

Based on the file update times RED seems to be where the game is actually storing the data, but GGST also has save data in there; the dates are a bit abnormal but there is an autocloud.vdf file.

My initial hunch was that Proton is using this RED folder to store the save data for some reason and is only syncing the GGST folder (based on the autocloud.vdf)

I attempted to symlink from RED/.../{Steam3AccountID} to GGST/.../{Steam3AccountID} and seems that did the trick, save data is being uploaded after I close the game. I haven't rebooted into Windows to see if it downloads properly, but this RED folder seems to be the root cause.

tl;dr
There are two folders with valid Guilty Gear Strive save data, RED and GGST. The GGST folder has the cloud save data. For some reason Proton appears to be using the RED folder, which doesn't seem to be set up to cloud sync. Symlinking from RED to GGST appears to resolve the issue and allows the game to resume syncing save data to the cloud.

Yeah, I just checked on my Windows machine and I only have a GGST folder. It looks like something in Proton is using the RED folder instead? RED is the Unreal project name that the game seems to use based on files/paths in the game, so it might be falling back to that name somewhere.

@Pobega Thanks for the analysis. I'm working on the save location/sync issue and should have a fix for it soonish, although I can't give you specific timeframe.

I can confirm videos working in Proton 6.12 GE, but more pressingly, for some reason, it only exposes the first controller. With Proton Experimental (maybe 6.3-5 as well, haven't tried yet) all controllers are visible, as intended. It's a good thing the local I went to didn't need my setup before I found that out!

@HugLifeTiZ issues with Proton GE should be reported on the GE project instead of here.

It doesn't have an issue tracker. Should I just @ the maintainer here, instead?

The project page has a link to a Discord for reporting issues: https://github.com/GloriousEggroll/proton-ge-custom

Ah, that's new since the last time I saw the README. Thank you kindly.

I cannot seem to get it working as of today on Artix Linux (Arch derivative)

(vulkan-icd-loader and vulkan-headers were updated today on my system, to version 1.2.186-1)

Tried Proton 6.3-5 and the GloriousEggroll fork, too.

Logs attached

steam-1384160.log

Are you using a Valve-built Proton version? Your logs mention wine-staging 6.14 so I think you're using some other build, in which case you should first see if Proton 6.3 or 6.3 Experimental have the same issue.

Here is with Experimental

steam-1384160.log
I forgot to restore the version to Valve's Proton 6.3 sorry

I can confirm the 6.3-6 RC build fixes the cloud sync issues. I was able to play a match on Linux and sync and watch the replay on Windows.

I did not test the migration stuff though, since I just deleted the old prefix and remade a new one since I was using the symlink hack @Pobega mentioned above. Looking at the code it looks like it'll just migrate the old GGST folder and the RED one won't be moved, so I'm guessing migrations won't work.

@ToadKing Yes, unfortunately you are correct. You can rename RED to GGST manually to preserve the data, or just let it go and go forward with the new save data.

Hey all.

Just wanted to share that I've been frequently running into a seemingly random issue in Guilty Gear Strive that causes the game's performance to significantly degrade until I close and restart it. I'll play a couple of matches at a solid 60 fps, but then something happens that causes the game to run at <40 fps in both the online lobby and during matches--of course, since the game's logic is tied to the frame rate this makes it unplayable.

Here are my system specs:

AMD Ryzen 5 1600
NVidia Geforce GTX 1060 3GB (4.6.0 NVIDIA 470.63.01)
16GB RAM
Fedora 34 Linux 5.13.13-200.fc34.x86_64 x86_64 (x11 X.Org 1.20.11)
Gnome 40.4.0
wine-6.16 (Staging)
Proton Experimental

Here are 3 separate proton log files taken when this bug happened over the course of a few hours tonight:

steam-1384160-low-match-fps.log
steam-1384160-low-match-fps2.log
steam-1384160-low-match-fps3.log

@emmetoneillpdx I've noticed in your log you have some things like Mango HUD and libgamemode enabled. Can you try removing those and seeing if it helps? Also, are you able to see the problem if you disable Proton logging entirely? Logging can itself affect performance, so I suggest always disabling logging if you are concerned about performance.

If you are still able to reproduce the problem after removing those other projects and disabling logging, I'd be interested to have some more details. Do you notice any patterns that trigger the bad behavior? Does it consistently happen after some amount of time, or some in-game action?

@aeikum The game upon fresh launch is working good 60 fps. However I experience a 100% gpu (nvidia gtx 1050) load and fps drop to 7fps. This is how to reproduce it: go into training mode and chose character and dummy opponent - start the match. Hit enter to invoke menu and reselect a character - at this point the game is unplayable as I mentioned before. In order to fix it I have to relaunch it every time. PS Proton version 5.5 tkg hotfix which supports fsync + dxvk + manjaro xfce

@dagolinuxoid I've tried that just now and I can't reproduce. Selecting new characters in training mode is working fine for me with Proton 6.3-7.

I'm not sure what you mean with "Proton 5.5". Can you try with current Proton 6.3-7? If that doesn't fix it, you could try disabling fsync with PROTON_NO_FSYNC and see if something changes?

@dagolinuxoid A good thing to test first is to see if the issue still happens on an official Proton build (6.3-7) instead of a TKG/GE/etc. build. If it doesn't happen on an official build then you should try reporting the issue in the fork repo.

@ToadKing thx for the suggestion to use latest proton version. btw I've tried to use wined3d instead of dxvk and gpu hanging disappeared however my cpu not happy about wined3d since it raises temperature up to 95 deg. I've used custom 5.5 hotfix tkg version because it gave me the best experience with Nier Automata :) while latest version gave me sad crash on loading.

Today I tried GGST with Proton 6.3.7 - same problems: GPU hangover after quitting training mode.

I'm not usually much of a github poster, but Valve is putting this game in their Steam Deck marketing, so I'm guessing they care about compatibility with this game in particular. I just built a new PC, and the game runs great on Proton 6.3-7 on both the old and the new machine, with one caveat. Going into the online modes puts an additional UI panel on the screen (semi transparent, but partially obscuring the top part of the online modes' UI) that looks like it's supposed to only be visible in debug mode, where it displays hex strings in green text representing the online IDs for both me and my opponent; this happens on both of my PCs. Specs below.

Old machine:
Kubuntu 18.04
Intel i7 5820k
Nvidia GTX 1080 8 GB driver 460.91.03
16 GB RAM

New machine:
Kubuntu 21.10
AMD Ryzen 5 5600X
AMD 6800XT 16GB with latest mesa driver
32 GB RAM

That's a part of the Strive UI. It happens when you push the right stick down. I would check your controller or something.

That's a part of the Strive UI. It happens when you push the right stick down. I would check your controller or something.

No, that's not correct. Pressing R3 displays that same information in a different way (it replaces the user IDs while you're holding it down), but it doesn't display that entire black panel.

This is off topic but I made the following (aka desperate move): installed windows 11 alongside manjaro and Guilty Gear Strive gives me avg 60 fps and has no lags upon menu switching, temperature (gpu and cpu) is also lower.

@andrewdbanks Are you using a specific controller in the game? If so, what happens if you instead try to get into a game with the controller unplugged and just using the keyboard?

@andrewdbanks Are you using a specific controller in the game? If so, what happens if you instead try to get into a game with the controller unplugged and just using the keyboard?

You were right. It was the controller. It's not listed anywhere in the game, but sending some input on the right analog stick brings up that menu, and for some reason, my Brook Universal Fighting Board sends a right analog stick input for the Right Trigger and Left Trigger (in addition to their expected inputs), defaulting to the negative position. Pressing the Right Trigger zeroed it out and made the menu panel go away. For now, I've gotten around the problem by telling Steam to disable the right analog stick for Strive, but I should find a more permanent solution outside of the game.

Replying to https://github.com/ValveSoftware/Proton/issues/4894#issuecomment-949142395

Can you elaborate more on how you did this? I'm also playing on Linux from a Brooks UFB and have the same problem.

Replying to [#4894 (comment)](https://github.com/ValveSoftware/Proton/issues/4894#issuecomment-949142395)

Holding the right analog stick in some direction (not the R3 button) will pull up this menu. For some reason, the right analog stick axes are tied to the RT and LT buttons, and you'll notice that pressing one of them will make this menu panel go away, because it changes the input for that axis to be 0 when you push it. I don't know why this only happens in Linux and not Windows, but I still need to investigate more permanent solutions. My workaround is to use Steam Big Picture, go to the right stick, and select "None" for the type of input. This has the side effect of disabling the R3 button, which means you won't be able to use that button for recording or playback in training mode, but at least when I'm online, it gets rid of that panel. I don't have a better permanent solution for this controller yet, but we're now technically off-topic, as it's not really a bug with Strive so much as it is with the Brook UFB.

EDIT: I found out that you can navigate to the controller configuration in Big Picture; not the configuration for the game, but the master controller setup at the top menu of Steam Big Picture. From there, you can configure all buttons, and reset them to blank, then set each button that you do have on your Brook board, leaving your other axes blank. This was the workaround I found that worked. One other solution that I didn't pursue once this one worked was using jstest-gtk. You can reorder axes so that RT isn't tied to the right analog stick.

My system information is:

OS: Pop!_OS 21.04
KERNEL: 5.13.0-7620-generic
CPU: AMD Ryzen 5 1600 Six-Core
GPU: AMD Radeon RX 570 (POLARIS10, DRM 3.41.0, 5.13.0-7620-generic, LLVM 12.0.0)
GPU DRIVER: 4.6 Mesa 21.2.2
RAM: 16 GB

Before all this happened, I last played Guilty Gear -Strive- on Thursday November 11th, and it ran at near native performance, with zero frame drops.

On Monday November 15th I opened the Pop Shop (pop OS package manager) and selected the option to update the Operating System

Later that day I started -Strive-, and the game would function normally for a few minutes while rapidly alternating between keyboard and controller prompts, before lagging to a standstill, and then resuming
This alternation of lag and normal operation would continue indefinitely
The game would also not respond to any of my inputs, forcing me to externally close it, and would not properly boot upon re-selection

I eventually deduced that it was the game's response to my controller (Hori Fighting Stick Mini: Switch version), and booted it with controller functions disabled, and the controller unplugged.

I then attempted verifying the integrity of the game. No issues were present.

The game would then function normally. I proceeded through the menu to training mode, and selected Sol Badguy as Player 1 (self) and Ky Kiske as player 2 (CPU). The game played normally, and every special move functioned as intended.
Later I repeated the previous line, but selected Giovanna as player 1 (self) and Ky Kiske as player 2 (CPU).

I have since both updated the Operating System, through the Pop Shop, reinstalled the game, and the resulting performance has been consistently replicable in Proton Experimental, and 6.3-7

Giovanna (Self, Player 1) vs Ky Kiske (CPU, Player 2), training mode, Proton Experimental, and Proton 6.3-7

Attempting to restart the game after closing it once, through Steam, leaves it stuck on a black screen, but the game launches if I use Lutris to do so. I have left System Monitor open, and the excessive lag is not taxing my CPU.

Edit:
Upon feedback from the System76 Mattermost chatroom (issues channel), I tried rolling back my kernel to 5.13.0-7614-generic, from 5.13.0-7620-generic.

5.13.0-7614-generic:
(the following was all done with Proton Experimental as the version)

I started the game, controller unplugged. Proceeded to the same training room settings as before, It ran normally (60 fps) just like last week.
I closed the game.
Plugged in my controller.
Started the game with Qjoypad running (buttons mapped to corresponding default keyboard binds), and controller recognition forced off.
Strive proceeded to run normally.
Started the same training mode settings.
Strive ran at 30 fps.

Restarting the game, with the controller unplugged, yielded the same results.
I am currently returned to 5.13.0-7620-generic again, for any future tickets, unless otherwise specified.

Edit again:
so grep gave me

sketch@pop-os:~$ glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.2.2
OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.2.2
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.2.2

Checking AMD's own website, the drivers for Ubuntu are 21.40.1
I've bricked my PC before, futzing around with stuff, so if installing the 21.40.1's .deb wouldn't cause any issues updating witht he pop shop down the line, someone let me know and I'll do so.

I think I also might get some weird performance issues with this game + using a controller, but I can't quite pinpoint if that's the problem or not. If I play on keyboard, I get perfect game performance (from the little I've tested). For controller, I can't get any to work in game, but the game does register my brook UFB and can use it in training mode, but it can't be selected as a controller nor can the buttons remap (because it goes to the keyboard mapping). If using steam input or antimicrox for input, the game claims to be running 60fps (and for the opponent it is, good connections maintain 0 rollback frames), but visually looks like it's maybe displaying at 20fps at best, and generally gets worse the longer the game runs. Anyone have any ideas on how I might be able to get controllers to work without needing steam/keyboard input? Mangohud says the game is solid 60fps with GPU never really going over 50% and cpu usually around 15-20%

EDIT: not sure why xorg is still strange, but I found on wayland having vsync enabled mostly gets rid of the jankyness of the rendering

System:
Arch, both sway/i3/kde plasma tested
ryzen 5 2600
rx570 8gb
16gb ram

It looks like recent updates to Proton have affected aspects of the game. Before some of the videos in the command list were working and the character selection background was working previously. I believe Proton 7 and Experimental are when these issues start to occur.

System:
Fedora
Ryzen 3800XT
Nvidia 3080 10gb
32gb ram

Hi @kisak-valve. Apologies on taking a while. I'm not sure if these are the logs you are looking for as I could not find the location that you specified in your last comment. It did not seem to exist.
Additionally, if I recall the newest version where this was not an issue I believe version 6.3-8 but I tested it just now as it the character selection just had a black screen behind so I'm not sure what's going here. It must of been of this version however since this was the version where the cloud save issue was fixed and I do recall it working correctly previously at this point.

If you need any additional please let me know and I'll try to be as helpful as I can.

UPDATE: I just found the file and included it. Apologies for that.

GGST Logs.tar.gz
steam-1384160.log

Hello,

Sometimes I get performance regression in this game after a while playing it, seemingly at random, to the point fps drops even though it was fine right before GPU usage scales from 80% usage or even less, depending on the stage, to 99%, even on the same stage. Tried with stable proton, tried also with proton experimental, same issue. Tried using stable linux 6.6, and also from the branch linux-drm-tip. Same issue.

The issue is more prominent on the stage Original Times Square.

Computer Information:
Manufacturer: ASRock
Model: B550M-ITX/ac
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 5 5600 6-Core Processor
CPU Family: 0x19
CPU Model: 0x21
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 4502 MHz
12 logical processors
6 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.8.0-rc2-1-drm-tip-git-g935b84c7959e-dirty
X Server Vendor: The X.Org Foundation
X Server Release: 12302004
X Window Manager: wlroots wm
Steam Runtime Version: steam-runtime_0.20231127.68515
Video Card:
Driver: AMD AMD Radeon RX 6400 (radeonsi, navi24, LLVM 16.0.6, DRM 3.57, 6.8.0-rc2-1-drm-tip-git-g935b84c7959e-dirty)
Driver Version: 4.6 (Compatibility Profile) Mesa 23.3.5-arch1.1
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
VendorID: 0x1002
DeviceID: 0x743f
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 37.40" x 21.26" (42.99" diag), 95.0cm x 54.0cm (109.2cm diag)
Primary VRAM: 4096 MB
Sound card:
Audio device: ATI R6xx HDMI
Memory:
RAM: 15917 Mb
VR Hardware:
VR Headset: None detected
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 933778 MB
Largest Free Hard Disk Block: 87973 MB
Storage:
Number of SSDs: 2
SSD sizes: 240G,0B
Number of HDDs: 0
Number of removable drives: 0

When Dizzy hits an opponent with her ice spike, it's supposed to freeze the opponent.
Everytime, it insteads cause an instant crash. I've tried many of the lastest Proton options.
I can't seem to find what the problem is, as even all latest ProtonDB reports do not mention anything like it.

Maybe the log is easy to read but I really don't know jack about window$ stuff.
steam-1384160USER.log

I have a friend who has an Intel Core i5 with a UHD 630 running Linux Mint 21.3 and the game runs well for him except for in the character select screen where it runs in slow motion.

I'm not sure if it's a game bug or possibly a Proton bug, but could anyone else try to replicate this?

EDIT: NVM, I looked around and it seems to happen with other setups as well, so it's probably a game bug.

Thanks @kisak-valve and my apologies for doubling the efforts there!

I have been trying to resolve the issue and I run flatpak steam and proceeded to run a flatpak update and my updates included updated Nvidia drivers. The game is now launching without issue so far!