Teardown (1167630) #4332

JonathanBrouwer · 2020-10-30T17:59:59Z

Compatibility Report

Name of the game with compatibility issues: Teardown
Steam AppID of the game: 1167630

System Information

GPU: GTX 970
Driver/LLVM version: nvidia 455.28
Kernel version: 5.8.16-2-MANJARO
Link to full system information report as Gist:
Proton version: 5.13-1

I confirm:

that I haven't found an existing compatibility report for this game.
that I have checked whether there are updates for my system available.

Proton log:
steam-1167630.log
Std error:
Std error

Symptoms

The game works perfectly (better performance than on windows btw), except when I load a level there is about a 10% chance the game will crash. The log file above contains the crash report.
Reproduces on proton 5.13-1 and proton 5.0-9. Does not reproduce on Windows 10.

Reproduction

Start the game, and load into a mission (was not able to reproduce it when quickloading in the lobby world)
Make a quicksave
Repeatedly quickload, the crash usually happens within 10-20 quickloads.

Moire9 · 2020-10-30T18:16:17Z

This happens to me as well, except it's not on loading a level. It seems to be either random, or happening within a time frame. I spent a lot of time checking out the Löckelle compound, and crashed before I was even able to get to the first level. The second time I went as fast as I could, and was able to play the first level for about 30 seconds before crashing.

JonathanBrouwer · 2020-10-30T20:28:16Z

I played for about an hour, and crashes definitely only happened during loading for me. Could you create a proton log so we can compare and see if the Backtraces are similar? @SirNapkin1334

domve · 2020-10-31T12:23:07Z

i've only had one crash so far, but sometimes the audio completely stops working until i restart the game. anyone else experience this?

ashirviskas · 2020-10-31T13:13:20Z

@JonathanBrouwer Same crashing on level loading happens on my laptop, which has RTX 2070, but it doesn't happen on my desktop with a GTX 1060.

Both are running Arch.

Solitary · 2020-11-01T17:26:28Z

@ashirviskas Crashing is probably not related to GPUs. What is the rest of the specs? CPU, RAM? I also have desktop with GTX 1060, 28GB RAM and slightly overclocked i5 2500K. Running Fedora 32.

So far from what I can gather, it is sorta coin flip on whether the loading screen crashes or not. Because I don't think the crashing gets worse the longer you play (like a leak), but it is just game of chance that you eventually lose and your "winning" (not crashing) streak is over. From what I have seen it is just as likely to crash on 1st one as is on 10th loading screen. Obviously, the chance you get to see 10 loading screens in a row is quite low.

But given your success with the desktop, maybe it is possible to get better chances with specific setup?

ashirviskas · 2020-11-01T21:40:40Z

@Solitary I've played like 5+ hours on my desktop with 0 crashes.

My specs on non-crashing machine are:

CPU: 3900X
GPU: GTX 1060 6GB
RAM: 32GB
Kernel: 5.8.12-arch1-1
Nvidia: 455.23.04-3

Crashing laptop:

CPU: 9750h
GPU: RTX 2700
RAM: 16GB
Kernel: 5.8.14-arch1-1
Nvidia: 455.28-4

Any idea what could it be?

Solitary · 2020-11-01T22:02:46Z

@ashirviskas I can point out similarities, CPU vendor and gfx driver version. Also possibly kernel, mine and your laptop are both newer than your desktop. My game is running from SSD.

My specs are:

CPU: i5 2500K
GPU: GTX 1060 6GB
RAM: 28GB
Kernel: 5.8.15-201.fc32.x86_64
Nvidia: 455.28

ashirviskas · 2020-11-02T01:05:41Z

@Solitary
Huh, that's interesting. It could also be the nvidia driver. Could you try downgrading that? (I can't test it on my laptop rn)

Solitary · 2020-11-02T01:10:09Z

@ashirviskas
No, I can't. Not without having to do extra work and installing it from different source. Probably not worth the effort. Repo I use only has the current version.

JonathanBrouwer · 2020-11-02T12:31:49Z

On protondb, someone suggested to add this launch command:
WINEDLLOVERRIDES=winedbg.exe=d %command%
I couldn't reproduce the crash with this enabled, can other people confirm?

Brainzman · 2020-11-02T21:03:21Z

I personally have played ~2 hours, with no crash either.
I would like to point out that the main problem, for me at least, is the complete absence of particles effects. The game thus lacks fire particles, which are really hard to play without since you need to guess where the fire is, and other particles like extinguisher gas.

Anyways here are my specs so you guys can compare:

RAM:16 GB
GPU Driver:4.6 Mesa 20.1.9
GPU:Radeon RX Vega
CPU:Intel Core i5-7600K @ 3.80GHz

0x4C4A · 2020-11-03T16:53:55Z

I encounter crashes on level loads and sometimes in levels, when playing.

Adding the WINEDLLOVERRIDES=winedbg.exe=d %command% string made it not crash that much, but resulted in a loss of sound (presumably when the game would have normally crashed) - nothing would get the sound back on that session. It still did crash on a load later though.

Distro: Linux Mint 20
Kernel: 5.4.0-51-generic
RAM: 16 GB
GPU Driver: NVIDIA 450.80.02
GPU: NVIDIA GeForce GTX 1070
CPU: Intel Core i5-6500 @ 3.20GHz```

ruabmbua · 2020-11-03T19:46:24Z

For me it crashes the entire system in the third level (Marina) after a while.

I am running 20.2.1-1 on kernel 5.9.3-arch1-1 using a radeon rx5700xt.

I already reported kernel crashes on mesa and amdgpu bugtrackers. Looks lile the radeonsi opengl driver is messing something up.

Tried a couple of different kernels 4.19, 5.4, 5.8 all crash with similar issues.

ruabmbua · 2020-11-03T19:46:57Z

Is anyone aware, how I can capture e.g. an apitrace, to help the radeonsi developers reproduce the issue?

Solitary · 2020-11-03T22:00:05Z

I encounter crashes on level loads and sometimes in levels, when playing.

Adding the WINEDLLOVERRIDES=winedbg.exe=d %command% string made it not crash that much, but resulted in a loss of sound (presumably when the game would have normally crashed) - nothing would get the sound back on that session. It still did crash on a load later though.

I can confirm that it does help with constant crashing. Did multiple reloads during a long mission without crashing, but I also did end up losing sound on the last reload (luckily it was actually the last one before I finished a long level), but I can't confirm whether the loss of sound would otherwise result in a crash. I did successfully reload more times than ever before, which maybe means it is different issue? Hard to tell, needs more testing.

Adding log from the play session, I exited the game cleanly through main menu.
steam-1167630.log

JonathanBrouwer · 2020-11-04T19:08:36Z

Yep, can confirm the loss of sound with WINEDLLOVERRIDES=winedbg.exe=d %command%

ruabmbua · 2020-11-05T17:49:46Z

To make particle effects like fire work on amd GPU driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3714#note_682885

Brainzman · 2020-11-06T17:35:10Z

To make particle effects like fire work on amd GPU driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3714#note_682885

Thanks, works great !

Zed-GH · 2020-11-07T07:50:50Z

I've also been game crashes, but much more catastrophic. Instead of just the game crashing, it seems to crash the X server as well. This crash mainly happens during general gameplay. I haven't experienced any of these crashes that happen during loadfing that others are reporting. I'm no Linux wizard, and am certainly not a troubleshooting genius, but figured I should say that its an issue I'm having.
Specs:
Ubuntu 20.04.1 LTS
Kernel: 5.4.0-52-generic
Ram: 8 GB, 3000MHZ
Cpu: Ryzen 3 2300X, not overclocked
Gpu: RX 570 4GB, Driver: 4.6 Mesa 20.0.8

ruabmbua · 2020-11-07T18:31:25Z

I've also been game crashes, but much more catastrophic. Instead of just the game crashing, it seems to crash the X server as well. This crash mainly happens during general gameplay. I haven't experienced any of these crashes that happen during loadfing that others are reporting. I'm no Linux wizard, and am certainly not a troubleshooting genius, but figured I should say that its an issue I'm having.
Specs:
Ubuntu 20.04.1 LTS
Kernel: 5.4.0-52-generic
Ram: 8 GB, 3000MHZ
Cpu: Ryzen 3 2300X, not overclocked
Gpu: RX 570 4GB, Driver: 4.6 Mesa 20.0.8

This is probably a bug in the radeonsi driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3714

As a workaround, launch the game with AMD_DEBUG=zerovram,nodcc radeonsi_clamp_div_by_zero=true radeonsi_no_infinite_interp=true.

Additionally set allow_glsl_extension_directive_midshader=true force_glsl_version=420 to fix missing particle affects on radeonsi driver.

Zed-GH · 2020-11-08T03:01:09Z

I've also been game crashes, but much more catastrophic. Instead of just the game crashing, it seems to crash the X server as well. This crash mainly happens during general gameplay. I haven't experienced any of these crashes that happen during loadfing that others are reporting. I'm no Linux wizard, and am certainly not a troubleshooting genius, but figured I should say that its an issue I'm having.
Specs:
Ubuntu 20.04.1 LTS
Kernel: 5.4.0-52-generic
Ram: 8 GB, 3000MHZ
Cpu: Ryzen 3 2300X, not overclocked
Gpu: RX 570 4GB, Driver: 4.6 Mesa 20.0.8

This is probably a bug in the radeonsi driver: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3714

As a workaround, launch the game with AMD_DEBUG=zerovram,nodcc radeonsi_clamp_div_by_zero=true radeonsi_no_infinite_interp=true.

Additionally set allow_glsl_extension_directive_midshader=true force_glsl_version=420 to fix missing particle affects on radeonsi driver.

Regarding the fix for missing particles, that has worked, thanks.
However, the workaround for the crashing X server has been unsuccessful for me, Teardown still takes down my GPU with it in the event of a crash.
It also seems other people haven't gotten the workaround to work( https://steamcommunity.com/app/1167630/discussions/0/3001047413717024275/ )

EDIT: I have found a workaround that works for me:
Setting these launch options seems to have fixed the game crashing my RX 570:
allow_glsl_extension_directive_midshader=true force_glsl_version=420 force_integer_tex_nearest=true MESA_NO_ERROR=1 %command%
With these launch options, the game does still sometimes decide to crash the GPU, however its so infrequent that I was able to spend a good 2 hours in a single session before the GPU crashed on me.

Hype02 · 2021-02-13T17:58:52Z

Morning/evening. The issue aswell affects computers with AMD graphics card and a processor. We both have SSD so that may be the issue somehow.

Proton latest experience version,
Steam Beta,
Pop-OS, Ryzen 5 2600,
16GB RAM DDR5
and RX 590 8GB

Friz64 · 2021-03-06T15:50:13Z

The game is crashing after the "Warning / Press any key to continue" splash screen since version 0.6 (Steam Workshop Update).

proton-5.13-6
steam-1167630.log
Used launch options: PROTON_LOG=1 allow_glsl_extension_directive_midshader=true force_glsl_version=420 AMD_DEBUG=zerovram,nodcc radeonsi_clamp_div_by_zero=true radeonsi_no_infinite_interp=true %command%
Arch Linux 5.10.20-1-lts; RX 580 8 GB; Mesa 20.3.4

I also found this Steam Community discussion of a Nvidia GTX 1650 SUPER user having the same issue.

I tried other Proton versions and Launch options to no success.

kisak-valve · 2021-03-06T16:00:01Z

Hello @Friz64, these look like lines of interest from the log:

err:steamclient:create_win_interface Don't recognize interface name: SteamController008
err:steamclient:create_win_interface Don't recognize interface name: SteamInput002
err:steamclient:create_win_interface Don't recognize interface name: STEAMUGC_INTERFACE_VERSION015

Looks like 302e5d9 2f63954 in Proton experimental-5.13-20210302 can help with that. Please test the game with the current Proton Experimental build.

Friz64 · 2021-03-06T16:04:20Z

That fixed it, thank you so much!

zaggynl · 2021-07-05T19:10:52Z

Game works well up until it crashes, which can take 30m or pretty short after loading a level.
Steam System Information:
http://paste.debian.net/plainh/a1e4e6d8
dmesg output: http://paste.debian.net/plainh/01654921
proton log: http://paste.debian.net/plain/1203498

Edit:
Launch option: radeonsi_no_infinite_interp=true allow_glsl_extension_directive_midshader=true %command%
seems to not cause any crashes anymore, via: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3714#note_691556

mathew2214 · 2021-08-05T18:22:21Z

Replying to #4332 (comment)

even with those arguments, i still get frequent crashes. it make s significant improvement though.

ruabmbua · 2021-12-20T20:05:06Z

Had the game running successfully for a long time with all the environment variables from here. Unfortunately it stopped working, now it crashes every time, when something in the game should explode (gas tanks etc...). This started with a game update.

Here is a log of the crash: https://gist.github.com/ruabmbua/bc988e72310aa922e95bc72fb2f7e87b

Nothing suspicious in dmesg, seems like a straightforward segmentation fault from the game binary itself.

Liamolucko · 2022-01-18T00:58:31Z

I think I've figured out the source of this issue, but I'm not quite sure how to fix it.

The crash is happening on a thread which seems to be handling Teardown's audio, and is happening when the callback passed to winmm.waveOutOpen gets called reentrantly. (The callback calls winmm.waveOutWrite, which then calls the callback again.) I think the crash is caused by then attempting to acquire a lock which is still locked from the outer invocation; it doesn't actually make the syscall to acquire it, but presumably it's finding out through some other avenue that it's already locked.

The part I'm not sure about is whether or not it's valid for that callback to be called reentrantly; evidently, Teardown assumes it isn't, but it might just be a coincidence that it never does on Windows. I don't really know anything about winmm.

(Also, this explains the report of audio cutting out, if this is the thread which crashes.)

Here's the relay trace of the end of the run (with added indentation and comments):

// This is what a normal invocation of the callback looks like; acquires some locks, does some stuff, and releases them.
    0128:trace:driver:DriverCallback (40256DA0, 32bit function 0003, 000000000000FF00, 03BD, 00000000, 005E0148, 00000000)
    0128:Call ntdll.RtlAcquireSRWLockExclusive(005e0068) ret=140270d41
    0128:Ret  ntdll.RtlAcquireSRWLockExclusive() retval=00000001 ret=140270d41
    0128:Call ntdll.RtlAcquireSRWLockExclusive(003b03d0) ret=140270d41
    0128:Ret  ntdll.RtlAcquireSRWLockExclusive() retval=00000001 ret=140270d41
    0128:Call ntdll.RtlReleaseSRWLockExclusive(003b03d0) ret=1402710a0
    0128:Ret  ntdll.RtlReleaseSRWLockExclusive() retval=ffffffff ret=1402710a0
    0128:Call winmm.waveOutWrite(0000ff00,005e0148,00000030) ret=140256d79
        0128:trace:winmm:waveOutWrite (000000000000FF00, 00000000005E0148, 48)
        0128:trace:winmm:waveOutWrite dwBufferLength: 4096
        0128:trace:winmm:WINMM_BeginPlaying (000000000000FF00)
        0128:trace:winmm:WOD_PushData (000000000000FF00)
        0128:Call ucrtbase.memcpy(02c829f0,005e3178,00001000) ret=3b8f16e5d
        0128:Ret  ucrtbase.memcpy() retval=02c829f0 ret=3b8f16e5d
    0128:Ret  winmm.waveOutWrite() retval=00000000 ret=140256d79
    0128:Call ntdll.RtlReleaseSRWLockExclusive(005e0068) ret=1402710a0
    0128:Ret  ntdll.RtlReleaseSRWLockExclusive() retval=ffffffff ret=1402710a0
// End of normal invocation.
    0128:trace:driver:DriverCallback Done
    0128:Call user32.MsgWaitForMultipleObjects(00000001,02b70690,00000000,ffffffff,3000004ff) ret=3b8f172f3
        0128:Call ntdll.NtWaitForMultipleObjects(00000002,02b2f480,00000001,00000000,00000000) ret=7b06de8a
        0128:Ret  ntdll.NtWaitForMultipleObjects() retval=00000000 ret=7b06de8a
    0128:Ret  user32.MsgWaitForMultipleObjects() retval=00000000 ret=3b8f172f3
    0128:trace:winmm:WOD_PushData (000000000000FF00)
    0128:Call user32.MsgWaitForMultipleObjects(00000001,02b70690,00000000,ffffffff,3000004ff) ret=3b8f172f3
        0128:Call ntdll.NtWaitForMultipleObjects(00000002,02b2f480,00000001,00000000,00000000) ret=7b06de8a
        0128:Ret  ntdll.NtWaitForMultipleObjects() retval=00000000 ret=7b06de8a
    0128:Ret  user32.MsgWaitForMultipleObjects() retval=00000000 ret=3b8f172f3
    0128:trace:winmm:WOD_PushData (000000000000FF00)
// Start of invocation which causes crash.
    0128:trace:driver:DriverCallback (40256DA0, 32bit function 0003, 000000000000FF00, 03BD, 00000000, 005E00B8, 00000000)
    0128:Call ntdll.RtlAcquireSRWLockExclusive(005e0068) ret=140270d41
    0128:Ret  ntdll.RtlAcquireSRWLockExclusive() retval=00000001 ret=140270d41
    0128:Call ntdll.RtlAcquireSRWLockExclusive(003b03d0) ret=140270d41
    0128:Ret  ntdll.RtlAcquireSRWLockExclusive() retval=00000001 ret=140270d41
    0128:Call ntdll.RtlReleaseSRWLockExclusive(003b03d0) ret=1402710a0
    0128:Ret  ntdll.RtlReleaseSRWLockExclusive() retval=ffffffff ret=1402710a0
    0128:Call winmm.waveOutWrite(0000ff00,005e00b8,00000030) ret=140256d79
        0128:trace:winmm:waveOutWrite (000000000000FF00, 00000000005E00B8, 48)
        0128:trace:winmm:waveOutWrite dwBufferLength: 4096
        0128:trace:winmm:WINMM_BeginPlaying (000000000000FF00)
        0128:trace:winmm:WOD_PushData (000000000000FF00)
        0128:Call ucrtbase.memcpy(02c839f0,005e0178,00001000) ret=3b8f16e5d
        0128:Ret  ucrtbase.memcpy() retval=02c839f0 ret=3b8f16e5d
// Start of reentrant callback.
        0128:trace:driver:DriverCallback (40256DA0, 32bit function 0003, 000000000000FF00, 03BD, 00000000, 005E00E8, 00000000)
// This is immediately different; literally every other invocation of the callback starts by calling ntdll.RtlAcquireSRWLockExclusive.
        0128:Call ntdll.RtlAllocateHeap(00140000,00000000,00000020) ret=1402cceb4
        0128:Ret  ntdll.RtlAllocateHeap() retval=02b70710 ret=1402cceb4
        0128:Call ntdll.RtlAllocateHeap(00140000,00000000,00000020) ret=1402cceb4
        0128:Ret  ntdll.RtlAllocateHeap() retval=02b70750 ret=1402cceb4
        0128:Call ntdll.RtlAllocateHeap(00140000,00000000,00000020) ret=1402cceb4
        0128:Ret  ntdll.RtlAllocateHeap() retval=02b70790 ret=1402cceb4
        0128:Call ntdll.RtlAllocateHeap(00140000,00000000,00000040) ret=1402cceb4
        0128:Ret  ntdll.RtlAllocateHeap() retval=02bd07d0 ret=1402cceb4
        0128:Call KERNEL32.HeapFree(00140000,00000000,02b70750) ret=1402cc7a8
        0128:Ret  KERNEL32.HeapFree() retval=00000001 ret=1402cc7a8
        0128:Call KERNEL32.HeapFree(00140000,00000000,02b70790) ret=1402cc7a8
        0128:Ret  KERNEL32.HeapFree() retval=00000001 ret=1402cc7a8
        0128:Call ntdll.RtlAllocateHeap(00140000,00000000,00000031) ret=1402cceb4
        0128:Ret  ntdll.RtlAllocateHeap() retval=02bd0830 ret=1402cceb4
        0128:Call KERNEL32.HeapFree(00140000,00000000,02bd07d0) ret=1402cc7a8
        0128:Ret  KERNEL32.HeapFree() retval=00000001 ret=1402cc7a8
        0128:Call KERNEL32.HeapFree(00140000,00000000,02b70710) ret=1402cc7a8
        0128:Ret  KERNEL32.HeapFree() retval=00000001 ret=1402cc7a8
        0128:Call ntdll.RtlPcToFileHeader(140428b30,02b2f790) ret=1402776bb
        0128:Ret  ntdll.RtlPcToFileHeader() retval=140000000 ret=1402776bb
// And then it throws an exception, causing the crash.
        0128:Call KERNEL32.RaiseException(e06d7363,00000001,00000004,02b2f750) ret=1402776fa

I captured the log with PROTON_LOG=1 WINEDEBUG=+relay,+seh,+tid,+winmm,+driver %command%

Liamolucko · 2022-01-18T01:00:10Z

I don't know whether this applies to @ruabmbua's issue, I haven't been experiencing it.

Liamolucko · 2022-01-19T08:19:46Z

I think I've managed to solve this on https://github.com/Liamolucko/wine/tree/winmm-no-reentrancy.

kisak-valve · 2022-01-19T13:31:08Z

Hello @Liamolucko, when you're happy with your patches, please send them to wine's mailing list for review and integration into upstream wine, then make a merge request for them to be cherry picked into Proton's variant of wine.

…without getting called reentrantly. This behaviour is relied upon by Teardown, see ValveSoftware/Proton#4332. Signed-off-by: Liam Murphy <liampm32@gmail.com>

…Write` without getting called reentrantly. This behaviour is relied upon by Teardown, see ValveSoftware/Proton#4332. Signed-off-by: Liam Murphy <liampm32@gmail.com>

…Write` without getting called reentrantly. This behaviour is relied upon by Teardown, see ValveSoftware/Proton#4332. Signed-off-by: Liam Murphy <liampm32@gmail.com> --- v2: Add `todo_wine` to avoid test failure --- v3: Use block comments instead of line comments

…Write` without getting called reentrantly. This behaviour is relied upon by Teardown, see ValveSoftware/Proton#4332. Signed-off-by: Liam Murphy <liampm32@gmail.com> --- v2: Add `todo_wine` to avoid test failure --- v3: Use block comments instead of line comments --- v4: Simplify test

Liamolucko · 2022-01-30T09:18:52Z

The fix is included in Wine 7.1, so this should be fixed once Proton updates to it.

In the meantime, Proton-GE has already updated, so it's fixed there.

ruabmbua · 2022-01-30T18:56:52Z

Still crashing for me with Proton-GE updated. Probably a different issue then? I have to get into proton debugging, I have no experience with it.

ruabmbua · 2022-01-30T19:06:34Z

When looking at my logs, its rather weird, that the crashing instruction is at 0x00007fa510fc9878, which is apparently not even inside the memory map, according to the crash dump. The closest module is winepulse, but at a slightly higher address...

kisak-valve added the Game compatibility - Unofficial Games not expected to work without issues label Oct 30, 2020

kisak-valve added the Mesa drivers Possibly involves an issue with a Mesa video driver label Nov 8, 2020

Teardown (1167630) #4332

Teardown (1167630) #4332

Comments

JonathanBrouwer commented Oct 30, 2020

Compatibility Report

System Information

I confirm:

Symptoms

Reproduction

Moire9 commented Oct 30, 2020

JonathanBrouwer commented Oct 30, 2020

domve commented Oct 31, 2020

ashirviskas commented Oct 31, 2020

Solitary commented Nov 1, 2020

ashirviskas commented Nov 1, 2020

Solitary commented Nov 1, 2020

ashirviskas commented Nov 2, 2020

Solitary commented Nov 2, 2020

JonathanBrouwer commented Nov 2, 2020

Brainzman commented Nov 2, 2020 • edited

0x4C4A commented Nov 3, 2020

ruabmbua commented Nov 3, 2020

ruabmbua commented Nov 3, 2020

Solitary commented Nov 3, 2020

JonathanBrouwer commented Nov 4, 2020

ruabmbua commented Nov 5, 2020

Brainzman commented Nov 6, 2020

Zed-GH commented Nov 7, 2020 • edited

ruabmbua commented Nov 7, 2020

Zed-GH commented Nov 8, 2020 • edited

Hype02 commented Feb 13, 2021

Friz64 commented Mar 6, 2021 • edited

kisak-valve commented Mar 6, 2021

Friz64 commented Mar 6, 2021

zaggynl commented Jul 5, 2021 • edited

mathew2214 commented Aug 5, 2021 • edited by kisak-valve

ruabmbua commented Dec 20, 2021

Liamolucko commented Jan 18, 2022

Liamolucko commented Jan 18, 2022

Liamolucko commented Jan 19, 2022

kisak-valve commented Jan 19, 2022

Liamolucko commented Jan 30, 2022

ruabmbua commented Jan 30, 2022 • edited

ruabmbua commented Jan 30, 2022 • edited

Brainzman commented Nov 2, 2020 •

edited

Zed-GH commented Nov 7, 2020 •

edited

Zed-GH commented Nov 8, 2020 •

edited

Friz64 commented Mar 6, 2021 •

edited

zaggynl commented Jul 5, 2021 •

edited

mathew2214 commented Aug 5, 2021 •

edited by kisak-valve

ruabmbua commented Jan 30, 2022 •

edited

ruabmbua commented Jan 30, 2022 •

edited