Would like to add that it works on normal WINE Steam install.
Hello @dRaiser, this unimplemented function is already being tracked at #18. Closing as a duplicate.
Reopening this for the XNA category...
Thanks @flibitijibibo, it should be noted I closed this issue report fairly early on, before a general policy had been established for unofficially supported games.
I just tried this with Proton 4.2-3, but didn't have any luck. I've attached the proton log. I hope this is helpful.
steam-250520.log
The game launches and runs fine, but is unable to save:
328674.358:0027:0028:warn:debugstr:OutputDebugStringA "Underrail (Ouroboros) - Error - 40000 : [Timelapse Vertigo] - Failed to save game 'savegame'. Exception: System.Runtime.Serialization.SerializationException: Type 'System.Random' in Assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.\r"
Attached is the relevant log.
steam-250520.log
Sounds like a possible Mono corlib incompatibility, Random is supposed to be Serializable:
https://docs.microsoft.com/en-us/dotnet/api/system.random
Though why Random is serializable, I don't know... usually devs set that as ignored via XmlIgnore or something along those lines.
Mono uses System.Random from corefx.
Even if we marked it as serializable, I don't think it'd be compatible with .NET, though the version from referencesource might be.
Swapping in System.Random from referencesource gets it past that exception.
Besides code formatting, attributes, and variable names, it the only difference I'm noticing between referencesource and corefx is that corefx's default constructor doesn't seed based on timer. I haven't worked with .NET serialization, but I imagine the corefx version could easily be made compatible.
Corefx has a bug for it here: https://github.com/dotnet/corefx/issues/32354
For some reason the bug discussion got caught up on the potential for serializing derived types, when the test case just uses System.Random.
Corefx isn't interested in a fix, so I changed wine-mono to use the referencesource class. It should be possible to save now (Proton 4.11-8).
Game launches, but when hovering your cursor over objects in game, FPS drops drastically. Massive stuttering.
Heres a log using Proton 4.11-11 and NVIDIA 440.44, which still has the big FPS drop when your cursor mouses over objects in the game.
This still happens even under current experimental.
i've also been experiencing the nasty performance issue. comments on protondb suggest that this can be addressed by installing dotnet452 and xna40, but it is somewhat difficult to install those on proton versions newer than 5.0.
i ended up updating winetricks to something newer than focal fossa ships using the self-update, and that ended up helpfully informing me that installing those packages on most modern wine versions simply can't work, which seems strange to me, but not my wheelhouse.
ultimately, proton 5.0-10 had the final junction of: a) loading the game without graphics device complaint (see anecdotal aside below), b) able to successfully perform the installs of dotnet452 and xna40 (via protontricks 250520 <verb> as usual) , c) appearing not to suffer from the stuttering issues once those were installed. however running on 5.0-10 presented a new problem: save data made with 6.3-7 (and without dotnet452 and xna40, obviously) would not load in it. so i have the unfortunate need to decide if fixing the performance problem is worth starting over. i find the fact the on-disk format for data apparently changes based on environmental conditions (primarily experienced with changing wine versions) rather alarming.
further: there is also a persistent issue across all tested versions of proton (from 4.11 up to 6.3 and even several distinct glorious eggroll versions along the 6.x range) with underrail not properly exiting when you quit the game, requiring you to forcibly kill the process (via steam UI, task manager, or cli). it's especially obnoxious since underrail tends to try to emit broken sound while failing to quit.
also: at least in proton 6.3, right clicking the mouse to pan the camera didn't work correctly (it always just panned straight up regardless of actual mouse motion), so i just turned it off and lived without while also enduring the stuttering. 5.0 doesn't have that problem, i don't know if other versions exhibit it since i just didn't try it again until after i got an install that has the performance corrected.
finally: in proton 6.x, underrail seems to have the wrong icon at least as far as xfce is concerned; i get some strange two square thing rather than underrail's icon (which does show up correctly for 4.x and 5.0, i don't remember if it did for 5.13-6 and i am not super excited about tinkering with this prefix more)
anecdotal aside: while trying to find the bounds of 'what might work', i tried falling all the way back to proton 4.11-13, but that resulted in complaints about not having a valid graphics device (i'm assuming due to subsequent changes on the mesa side, and older wine stuff not being able to deal with that). unfortunate that we seem to have passed a threshold where certain things are unavailable for testing regressions.
Seems that save games made on proton won't load on a windows computer anymore, not sure if it's fixable on proton's end since there's deck specific customizations for the game but it's very annoying.
With Proton 8.0-4, the Steam overlay shows up for me as plain squares.
System info
Runtime info
steam-250520.log
2025 edit: Overlay started working normally at some point since I last tried running without gamescope.
It's blocks again after making a new prefix...
Hello @DonKatsu, the overlay issue you're seeing is most likely the same as https://github.com/ValveSoftware/steam-for-linux/issues/7889.
Underrail (250520)
Issue transferred from https://github.com/ValveSoftware/Proton/issues/7821.
@Raikiri posted on 2024-06-07T12:05:44:
In fullscreen mode when the game resolution does not match the resolution of the desktop, right mouse button teleports the cursor, effectively preventing interaction with items and dragging the view or the map.
Note: the problem happens because the game is trying to hold the cursor at the position where RMB was clicked (to allow indefinite scrolling of the view or the minimap), presumably using something akin to GetCursorPos()+SetCursorPos(). However, something goes wrong in the fullscreen mouse position transformation code and the mouse cursor is set to a different position as to where it was clicked.
I assume it's related to the fact that proton does not change the actual desktop resolution in fullscreen mode and instead rescales the game's rendertarget to whatever the desktop resolution is.
This breaks dragging the in-game view, dragging the map (opened with M) and RMB interaction with certain in-game items (jets, ventilation shafts and a bunch of other things you interact with using RMB).
Forgot to mention that as a temporary workaround I set my desktop resolution to be the same as the game's fullscreen resolution before launching it. That does fix the mouse cursor issue, but is obviously sub-optimal.
proton 8.0-4x1 2023-11proton 4.11-13x1 2021-10proton 5.0-10x1 2021-10proton 6.3x1 2021-10proton 4.11-11x1 2019-12proton 4.11-8x1 2019-11proton 4.2-3x1 2019-04mscoree.dllx1 2018-08
Error: