Thanks for the report, this has been fixed for 2.0.56.

We have been using an OpenGL extension called NVX_gpu_memory_info to query the amount of VRAM on Linux, but this function does not work correctly on the Steam Deck, erroneously reporting 1 GB instead of 6 GB. This was causing the game to ...

Glad to hear that you figured it out!

Please upload your save file so I can take a look.

My money is still on a driver issue because you are the only one on Earth who is experiencing this problem. If there was a bug in the game logic then more people would be experiencing this.

Thanks for the report, this has been fixed for 2.0.53.

Yeah, the bug has something to do with the removal of the internal valve entities - whether that be by migration from valves 1.2 -> 2.0, or removing the mod entirely.

It's not the mod's fault, it is simply triggered by the mod's behavior.

This appears to be related to the Valves 2.0 mod - if I keep valves on 1.2.1 then the issue does not occur.

Thanks for the report, this has been fixed for 2.0.52. Sorry for the wait!

Thanks for the report. Unfortunately, I haven't the foggiest clue as to what could be causing this. I am tempted to blame GPU drivers.

Do you have the capability to test on a more bleeding-edge distro such as Fedora or Arch?

Thanks for the report. This is actually a bug in SDL. I have opened an upstream bug report.

Boskid is correct - this is not a bug. These pipes are fast-replaceable with one another. To get the behavior you want, the pipes need to not be fast-replaceable.

Thanks for the report, this has been fixed for 2.0.48.

Was this problem actually reproduced?


Yes, I reproduced it on my machine (Fedora Linux, i9-10900k), but I had to up the number of mods to around 650. LAN games would not show up whatsoever and connecting to public games would fail (even though I could see them). Changing all usages of select ...

Yeah, this is because of the double-buffering as you mentioned. I plan to improve this situation for 2.1.

Thanks for the report, this has been fixed for 2.0.45.

Ref 116654

Unfortunately, there is never going to be a 100% foolproof solution to this. The new system is a lot more resilient to update-order-dependence than the old system was, but it still isn't perfect because it remains as a one-pass system.

In this case, you can fix the issue by temporarily removing the ...

Forgive my confusing statements, I was wrong. Here is what happened:

In 1.1.0, the default lamp color was changed to {1, 1, 0.75}. However, this wasn't actually being applied to lamps due to an engine bug that went unnoticed for years. A modder finally noticed this bug in 2.0, and it was fixed by ...