Linux Issues on Steam

General
6

I just tested what Graviton said… and he is correct.

The extra line I added is not required for version 4.11-13 of Proton, and is the simpler solution.

Valve’s Proton 4.11-8 Begins Bundling VKD3D

I am just going to assume it is related to that then, since around that time period is when Proton versions break, and it is specifically Vulkan settings I am disabling with the line I added, to make it work for new versions of Proton.

Edit:
just for clarification, the two lines before did the following…
PROTON_USE_WINED3D=1
(Forces Proton to use OpenGL/WINED3D instead of Vulkan/DXVK)
PROTON_NO_D3D11=1
(Disable Direct3D 11)

2 Likes
7

I got the Linux version of the games working!
(on all three devices/OSs, including the Steam Deck)

Preliminary conclusion below:

Alright… this was bugging me. A lot.
Even though Proton let the Windows game be run in Linux, it was very non-ideal. It was fixing the Windows version, and not the Linux one.

I had to dig around in the processes running around in the background with the game, but I found roughly what it was doing, and a command to fix it.

–disable-seccomp-filter-sandbox

Note what is being disabled:
Seccomp (Wikipedia)

I will look into this slightly further later… but the Linux version can now be run with a launch command.

Also, a request: can any Linux users verify the above launch command works for them?

1 Like
8

I’m happy it worked!

Probably you’re right about the article, I reckon you had modified exactly the settings that made the newer Proton versions break when you launch the game.

About seccomp, since the game is sandboxed probably the sandbox’s restrictions and the newer versions of Proton conflict with each other and you can’t launch the game. However, to be honest I wouldn’t modify seccomp’s default settings and I’d go with your other way if I had to choose (better to keep programs sandboxed).

Luckily Proton’s older versions work so we got a quick and safe way around the problem!

9

I agree that people are generally better off without disabling seccomp, and using proton instead, unless they cannot use Proton (for example, Chromebooks have very limited space, and Proton takes up a great deal of space).

but the default option that you see on Linux does not appear to be using Proton, so I do not see how they could be conflicting. If you look at the game’s folder (at least the one I looked at), it has an “.exe” file when Proton is enabled, and it does not when the Linux runtime is enabled.

I mainly note seccomp because it gives strong suggestions on where to look for the issue to the game developers, and unlike the average Linux user, I do not expect the average person from the new batch of Steam Deck users to find a workaround (especially if it becomes more mainline/popular). I could be wrong, but it seems to be attracting a fair number of people who are not accustomed to tinkering with their games to get them to work. So better for it to be working by default, because otherwise people purchase games they cannot play.

1 Like
10

You made valid points, I agree with them.

You’re right, sorry, I didn’t think about that.
Probably seccomp is indeed partly responsible for that misbehaviour.

Yeah, some games sometimes require a bit of tinkering and tipically average Linux users are the ones used to that sort of things.
Unfortunately, on protondb there is little about this type of games and essentially the only way out is the one you pointed out, that is, using OpenGL and disabling DirectX11 on Proton. That way everything works fine.

Hopefully this post will help out those who had this problem in finding an easy solution!

11

I think I’ve addressed the Steam Linux issue, but, for now, I’m only rolling the fix out to one game, “Jolly Good: Cakes and Ale.” Please give it a try (you can test the demo, if you don’t own the full game) and report back.

(Before you test, you might want to right-click on the game, and go to Properties → Local Files → Verify Integrity. That will ensure that you’re running the current latest version of the game.)

For the record, here’s my understanding of the problem.

Background Terminology: Electron, Chromium, CEF

ChoiceScript games are all just web pages. On desktop, to distribute a web-page game as a native app, we distribute a private copy of Google Chrome, and configure it to only be able to open our single web page.

We use an open-source framework called “Electron” to embed Google Chrome. https://www.electronjs.org/ “Build cross-platform desktop apps with JavaScript, HTML, and CSS.”

Technically, Electron doesn’t use Google Chrome, but just the open-source parts of Google Chrome, which is called “Chromium.”

In 2014, prior to using Electron, I used another framework called the “Chromium Embedded Framework” (CEF). CEF forces me to write a bunch of code that Electron handles automatically, so Electron is better and far more popular than CEF.

Upgrading Chromium is manual effort: Whether I’m using CEF or Electron, upgrading to the latest Chromium requires manual effort, and it often breaks when I do it. As a result, I never upgrade Chromium (CEF or Electron) unless I need to, to fix a bug.

In 2017, I moved the Windows build from CEF to Electron, but I’d never switched the Linux build from CEF to Electron (because it worked fine, and upgrading would be actual work). Thus, most of our apps are currently running a Windows build with a 2017 version of Chromium, and the Linux build is running a 2014 version of Chromium.

(On macOS, we embed Safari instead of Chrome, and it’s super super easy to do by hand, so we’ve never really run into trouble with it. No special upgrades are required AFAIK.)

The Blank Screen Problem Is New

On my Ubuntu 22 Jammy Jellyfish machine, I repro the bug with a blank screen. The issue doesn’t occur on Ubuntu 20 Focal Fossa.

I’ve also reproduced the blank screen issue on Manjaro Linux, (based on Arch Linux) which is the distro that Steam recommends for testing Steam Deck compatibility. Developing for Steam Deck without a Dev-Kit (Steamworks Documentation)

We Can’t Use Proton to Fix This (But You Can)

Steam Proton is a compatibility tool to allow Linux machines to run Windows apps without recompiling them for Linux. (“Proton” and “Electron” have nothing to do with each other; it’s a total coincidence that both pieces of software are named after subatomic particles.)

As an end user, you can right-click on a game, go to the Compatibility section, and turn on Proton. There are a bunch of options to fiddle with there, and, here in this thread, @NoiramSang has explained how to turn on Proton, set those settings, and get the game to work.

Unfortunately, as a Steam app developer, I’m not allowed to automatically enable Proton or set its settings. Specifically, when I use the Steam developer console (“Steamworks”), there are a bunch of configuration options I’m allowed to set and use, but there’s no “Compatibility” section; no way to enable Proton. Individual end users like you can turn on Proton, but Steam doesn’t provide a way for us to say “Just turn on Proton for all Linux users, and use the following settings: _____.”

If we’re gonna fix this, we’re going to have to fix our Linux app “the right way,” by making an app that works fresh out of the box on Ubuntu and Manjaro.

Fixing It the “Right Way” Meant Upgrading Electron and Turning Off Sandboxing

As @NoiramSang discovered, there is an another way not to use Proton, which is to pass the --disable-disable-seccomp-filter-sandbox parameter to the Linux executable as it launches. Unlike Proton, I am able to instruct Steam to pass specific command-line arguments to my launcher; when I use it, the blank-screen issue goes away.

But even though the issue went away, I still had issues running that ancient 2014 version of Chromium on modern versions of Linux. For example, I was testing on a VM on a high-resolution “retina display” MacBook Pro, and I’d configured Ubuntu/Manjaro to increase the UI font size to match, but our Linux app wasn’t honoring those settings, so the font was teeeny tiny.

Upgrading CEF would require a ton of work on my part, and I’d hate to continue running Linux on CEF and Windows on Electron, so I decided to switch the Linux build from CEF to Electron. I’d hoped that just that would fix the blank-screen bug, but it didn’t; I still had to pass --disable-seccomp-filter-sandbox to get it to work.

While I was at it, I upgraded to the latest version of Electron on Windows and Linux. On paper, there’s no pressing need to upgrade Electron for Windows. Our Windows Steam app works fine. But it seems wise to get on the latest version of things (to delay the point at which things will randomly start breaking later on).

Initially, the new app with --disable-seccomp-filter-sandbox seemed to work fine on Ubuntu 22 and Manjaro, by which I mean: I copied a zip file containing an example ChoiceScript game to those machines, extracted the zip, and double-clicked the app, and it worked great.

But I found that there was another problem that only occured when launching the game via Steam. I submitted the app to Steam as a “beta” app, and tried launching it on Ubuntu 22. I clicked Play, and Steam just sat there, doing nothing, for almost exactly 90 seconds. (The green “Play” button changed to a blue button that said “X Stop,” but no game window opened; I couldn’t even see a blank screen.) Then, 90 seconds later, the window appeared, and the game ran.

On Manjaro, it was even worse… I think the game instantly crashed on startup. I clicked the Play button, it flashed to a blue “X Stop” button, and then instantly flashed back to a Play button, again, with no window popping up.

I had no clear idea why this was happening, but, while investigating --disable-seccomp-filter-sandbox, I found this page documenting Chromium sandboxing options. It mentioned that instead of --disable-seccomp-filter-sandbox, I could use --no-sandbox, which completely turns off sandboxing. When I used that, the app launched quickly and cleanly, scaled to the correct size, on both Ubuntu and Manjaro.

It Is Safe to Disable Sandboxing, I Think

The premise of Chromium sandboxing is that Chromium may be used to access untrusted third-party code. That code could do anything. It could try to exploit a bug in the browser, and from there, they might be able to gain access to the user’s home directory. If they’re very clever, they might even be able to exploit the kernel itself by exploiting bugs in Chromium.

But, from my perspective, we’re not running untrusted third-party code. All of the code in our game process is code that I’ve written or code that I’ve tested and vetted. We never use our Chromium browser to navigate to arbitrary web sites, so the sandbox doesn’t have much/any benefit for us.

Now, from your perspective, as a player, you might not fully trust me, and you might prefer that I leave sandboxing enabled, or at least disable it as little as possible, i.e. to prefer --disable-seccomp-filter-sandbox instead of --no-sandbox.

If the sandbox were working, if it were allowing my code to run but blocking dangerous exploits, I’d be happy to leave it on. But the sad fact is that Electron isn’t very well tested on various Linux distros. As far as I can tell, I do have to completely disable the sandbox to ensure a good experience for users, and so, that’s what I’ve done here.

6 Likes
12

I greatly appreciate the response and the (incoming) fix, as well as the amount of detail provided.

I only ran the demo for a few minutes, but it initially seems to work better than the two Proton options with the other games I tried. There were no apparent issues.

  1. I did not receive a blank screen, when starting or running the game.

Clarification: with Proton ~4, I did get a blank screen a couple of times while playing a different Choice game, not while starting it; closing+starting the game fixed it.

  1. It started more quickly than using Proton 7+ with the other games (which is more noticeable on older hardware than newer)

I checked it, as before, with 3 pieces of hardware (including a Steam Deck), and three distros of Linux. For the sake of avoiding cluttering up this thread, I will put my minor notes related to the Steam Deck and the game(s) in a different thread.

13

Thank you for the exhaustive response, it really helped understanding how your apps work!

As @NoiramSang did, I tried running Jolly Good too and it had no problems. Now it works out of the box.
However, it crashes if I use Proton. I don’t know if it can help with this discussion, but in that case a window pops out and tell me that it could not connect to steam and gives me error code 77779.
Since we no longer need to find a workaround I guess that’s not a problem though.

If someone is concerned about this and doesn’t trust the game’s code, downloading the flatpak Steam app and running it through flatpack (you can use this command to run apps directly from flatpak, flatpak run application_ID) should do the trick. As far as I know flatpak applications are sandboxed by default so the games opened through it should be too.
I tried it on Ubuntu 20.04 and the games worked flawlessly.

Kindly note that I’m not an expert on the topic, so if someone has more input about this or wants to correct something, please do.

14

@Graviton That bit about Proton is interesting, because when I checked the game last night, it also did not work when I Forced the Linux Runtime in the Compatibility settings, even when I launched it with the line disabling sandboxing (either of them). So it seems to be when forcing anything but the default… it is not just Proton.

Having said that, I do not consider it to be an issue, so long as the default continues working. It mostly means if something were to break in the future, there either is not a workaround anymore, or it is a slightly different one now. I assume it is due to the game now, as I understand it, passing a command-line argument that the compatibility options do not like.

Oh, and just to note, I am running Steam on some devices/OSs installed directly/normally, and some via flatpak. There is no observable difference in between them when playing the game that I am aware of, except what would affect all other Steam games. The sandboxing just results in minor oddities/annoyances, such as, the button to view the local game files does not work by default. All related to the sandboxing, as far as I know.

So, yes, although I am also not an expert on flatpak, it is sandboxing, and does offer more security than installing Steam directly… and, in my experience, also makes doing non-basic/non-standard things with it slightly more annoying. Which is to be expected.

15

At least at first glance, Parliament of Knives and Night Road appear to have been patched on Steam, and be working now, on both Linux and the Steam Deck (no modification required).

Edit:
No, it seems like it is all four VtM games working.

Greatly appreciated.

16

Is this why every choice game on steam needs to be updated?

17

Yes, earlier today I pushed updates for every Steam game to fix Linux support.

6 Likes
18

Everything now works out of the box on Linux too, thank you!

As I already wrote on the new topic that they opened, kindly note that you should turn off the compatibility tool option now or the game won’t start and you have to update it again.

Edit: just out of curiosity, is it just an impression of mine or did the character font of the games on Steam change? If that’s the case, is it possible to change it/revert it back manually?

19

My CoG games had been working out of the box, but since this last update went out all of them are bugged and no longer think I own them, only offering demo access. This is on Steam, running Linux Mint 19.3, by the way.

The in-game ‘restore purchases’ button did not help, verifying the files did not help, and reinstalling the game did not help. Then I tried running Night Road in Proton Experimental and that actually did fix it. Or at least it goes right to the game instead of the demo versions advertisement/overview page, though I haven’t played through the first four chapters to confirm that I’m playing the full game yet.

Also, it does feel a bit laggy and the window doesn’t size itself properly, cutting off the ‘next’ button on longer pages under my scrollbar. I never had to use Proton on a CoG product before, so maybe that’s not new. Anyone know how to fix this or do I need to email support?

20

Does anyone else in this thread reproduce this issue?

21

I decided to quickly mess around with Night Road to see if I could replicate the issue, but I cannot, and given I would not know what the thing is checking for (to see if it is purchased), I would not know what to look for.

I can only make three suggestions at this time.

  1. I think the lag is normal when using Proton Experimental. I just tested it, and I have the same issue, but it corrects itself if using Proton 4.11-13 (when not using any Launch Options; using any might break it). If you must use Proton, I would see if that works better for you.

  2. Were you originally running the games through default (non-forced), or forcing the Linux Runtime? The latter does not seem to work correctly, so try the other if that is the case.

  3. Try disabling Steam Cloud Saves if they are enabled (so it does not undo the next step), delete the local saves (back them up first), and see if it is in some way related to the save files. Since it seems all of your saves would have needed to be affected… and I think they are shared with the Windows version, I doubt the issue is related to the saves/configuration folder. But, well, process of elimination.

The folder should be located in Steam/userdata (then your Steam number), in the folder 1290270 .

Edit:
Alright… I tried 4.11-13 again and it says it cannot connect to Steam, and tried Experimental again and it played the game smoothly. So 50/50 on it working better than Experimental. I have no idea what changed between tests. Also, Experimental looks like it may have been updated to not require the old launcher settings I had to use before, so if you are using them, removing them might help. shrugs

22

Previously to all of this I had simply been running my games with the default settings, using no compatibility tools and no command line/launch options.

Since you made me think of it though, I just gave the Linux Runtime a try and it resulted in the game just failing to start. No window pop up or anything. It was just ‘Running’ according to my steam library for a moment and then it stopped.

Proton 4.11-13 just gave me the ‘There was an error connecting to Steam’ message.

Steam cloud saves were already disabled for all of my CoG games, but I deleted my saves and tried that with no change in the result.

Thanks for the ideas to try out.

23

Hmm… alright.

My only other idea, at this time, is I was able to get the forcing Linux Runtime option working by using a workaround, which is the only other thing I can think of to change.

For reasons I do not understand, the Linux Runtime running by default and forcing Linux Runtime appear to work very differently (I have never heard of a game differing between the two before the Choice games).

Forcing the Linux Runtime under Compatibility works for me under one condition: rather than clicking Play, instead go to Local Files and run the executable directly (while Steam is still running, otherwise it will error out).

Does that result in the same Demo-only problem, or does it behave differently?

24

I don’t think I completely follow the workaround you’re suggesting. I’m fairly new to Linux and unsure of how I run an executable directly, or even 100% sure which file it is. In each of my CoG game folders there’s a file with the name of the game and no extension which I guess is the .exe file, but my system doesn’t recognize it/know what to do with it (and neither do I).

If this involves Wine, I haven’t actually used it yet. Most of the games I play work fine on Linux natively and the handful that don’t I have on Steam, where I just find a the right version of Proton and/or launch option for them. So I don’t actually have a general Wine program installed. If that’s what I need to do next to try this workaround, I’m just going add it to a to-do list for now as I’m just low on mental energy at the moment.

To step back, I’m not really anticipating or even needing to find a solution here. As I can still play my games via Proton (even if it’s laggy) and haven’t been in the mood to play any of them at the moment anyway, I really just wanted to make sure this new bug with the last round of Linux updates was reported somewhere CoG devs would see it.

And if it’s really just me experiencing this, I wonder if it’s something specific about Mint 19.3 that doesn’t play well with the change to the CoG engine. If it is, the problem might effectively solve itself by around April of next year, which is when Mint 19.3 reaches the end of it’s life and those still using it will (presumably) upgrade. I’ll have to do that myself at some point soon and, if nothing else has by then, I’ll find out if that fixes it. Thanks for your help, Noiram.

25

Ah, okay then.

Also, just for future reference, the below is what I was suggesting. No need to read it if you have no use for it, it is just there if you (or anyone else) has a use for it. It does not involve WINE, and should not require installing anything but the game itself.

Note: the below should work, but may not if Steam was installed as a flatpak (which restricts access to the system).

  1. Enter Night Road’s Properties.
  2. Force Compatibility to Steam Linux Runtime

At this point, clicking Play seems to not work, so…

  1. Go to the game’s Properties, then Local Files, then Browse.
  2. Execute the file NightRoad.

You can do this with the visual interface, but as that can differ depending on your desktop environment, I will simply state how to run it using the terminal.

In the terminal, typing “./NightRoad” (without quotes) will launch it.