Linux Issues on Steam

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.

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.

@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.

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.

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

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

6 Likes

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?

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?

Does anyone else in this thread reproduce this issue?

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

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.

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?

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.

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.

I just tried pushing a new build of Night Road that might help.

The app is designed to start up and query to see what you’ve purchased, but if it can’t connect to Steam, then it’ll falsely think you’ve purchased nothing (which means you’re in the demo). Steam recommends calling SteamAPI_RestartAppIfNecessary to restart the app if it can’t connect to Steam, but in the Electron update I posted about upthread a couple weeks ago, I didn’t call it. Now, Night Road does call SteamAPI_RestartAppIfNecessary, so I’m hoping that fixes your problem.

Hi,
After the update every game runs smoothly natively and the issue seemed fixed. However, yesterday I was not able to launch the latest hosted game, “The Passenger”.
I’ve tried the usual stuff (uninstall, reinstall, check files integrity etc) and I even tried running it with Proton (newever and older versions alike), but I was not able to launch it.

To be more precise, if I try to launch it natively nothing happens, while if I try with Proton a blank screen appears with an error message (it mentions error code 77779).
I’m using Ubuntu 20.04, if that can help.

Am I the only one experiencing this? Was someone else able to run it on Linux?

I have the same error as you. Have you managed to fix the problem since your message?

Hi,
I contacted the support team and they told me the problem was on their end. I can confirm you they fixed that issue and now every game that had problems runs smoothly (just checked on The Fernweh saga, The Passeger and Fallen Hero 2 - those were the games I own that didn’t work).

Be sure you’re not forcing the compability with Proton, because now the games run natively on Linux and with Proton they don’t launch.
A month ago I also had to reinstall Steam (through Flatpak), so I don’t know if that helped someway with their update. If someone also can confirm everything is working I’d be grateful.

Anyway, if you’re still having this issue you can try to play the games on a web browser. Just be sure to let CoG website store cookies and to not play on anonymous window.
Games’ progess is stored locally, so if you wipe out the cookies/don’t allow their storage every time you play you start from the beginning and can’t save your progress in-game.

Hope that will help improve your experience!

1 Like

Thank you so much for all this informations! ^^

1 Like

Part of the mass update of Linux builds I just did was an attempt to improve compatibility with Steam Deck.

Valve has a Steam Deck Compatibility testing team. From time to time, they test out our games on Steam Deck, check for compatibility, and post results. Prior to the most recent round of updates, they would normally say that our games are “Unsupported :no_entry_sign:” on Steam Deck, but, on the current version, they typically claim that our games are “Verified :white_check_mark:

But, to my surprise, they claim that the native Linux version didn’t work on Steam Deck, so instead, they were testing our Windows build via Proton. That does work if you use the latest version of Proton, but it just doesn’t work as well IMO as the native Linux version.

The reason they were using our Windows build on Proton instead of the native build is that they only want to test the native build in the Steam Linux Runtime. (You can test the Steam Linux Runtime yourself by using the “force compatibility tool” feature in your Steam Library and selecting “Steam Linux Runtime” off the list. It’s wayyyy at the bottom, under all those Proton versions.)

Last week, I discovered that all of our apps (all apps built on Electron) don’t work in the Steam Linux Runtime. I filed a bug about this here:

I was pleasantly surprised at how helpful the Valve team was at helping me diagnose and fix this issue! They have a fix forthcoming in a beta version of the Steam Linux Runtime. I just tested it myself with Steam Linux Runtime on my Steam Deck, and it works great, better than Proton.

… but the Valve developer “smcv” who has been working with me on this issue said something a bit ominous as well.

While testing this more thoroughly in preparation for a new beta, I found that on a Debian 11 host system with AMD GPU and Mesa, the Slammed and Heart of the House demos running under SLR both crash shortly after startup (I get a white window for a moment, but no text is drawn) with a segfault in the Chrome_InProcGp thread. The sniper runtime behaves similarly, and so does the non-container scout runtime.

Debian 10 and 12 on the same hardware are OK, and so are Arch Linux, Steam Deck, and Ubuntu 22.04 on different hardware. (It could be a graphics driver bug specific to the version of Mesa in Debian 11, I can’t tell.)

This isn’t a regression, and your games don’t run under SLR by default on anything except Steam Deck, so I’m treating this as non-critical and will proceed anyway; but I thought you should be aware that adding these few libraries is not a 100% solution to running Electron/NW.js games in a cross-platform way.

I verified that our games work great in the Steam Linux Runtime on my Steam Deck, but I don’t have a wide variety of Linux versions to test. (I’ve lent my Intel machine to a friend, so currently my only Intel Linux box is a Steam Deck.)

Therefore! I’d appreciate it if y’all would try out our games in Steam Linux Runtime on whatever version of Linux you happen to run, and let me know how it goes.

Here’s how!

Please test our games in the beta version of the Steam Linux Runtime

  1. Go to your Steam Library. (If you’re testing on Steam Deck, you’ll need to switch into Desktop Mode to do this testing.)

  2. In the upper left corner, there’s a dropdown, “Games.” If you click it, you’ll see that, by default, Steam Library shows Games and not Tools. Check the box for “Tools”.

    image

  3. Once you’ve enabled “Tools,” you’ll see “Steam Linux Runtime” and “Steam Linux Runtime - Soldier” in your Library. Click on the “Soldier” version.

  4. In “Steam Linux Runtime - Soldier,” click on the gear icon to “Manage” and then click on “Properties…”

  5. Click on “Betas” and select “client_beta”. Close the Properties window. (It may take a minute to download the beta.)

  6. Download one of our games (or a demo, if you prefer), select it in Steam Library, and view its Properties, like you did for Soldier. I’ve mostly been testing with Slammed, but I believe any game will work.

  7. Click on “Compatibility”, check “Force the use of a specific Steam Play compatibility tool”, and select “Steam Linux Runtime” from the list of tools. (It’s wayyyy at the bottom, under all those Proton versions.) Close the Properties window.

  8. Try playing the game. If you can launch the game and click around for a few screens, that’s all I need.

  9. When you’re done, you probably want to opt-out of the Soldier beta. Go back to the “Betas” page for Soldier and select “None.” (Slammed does crash on startup when opting into the non-beta Soldier SLR; that’s expected.)

I’ve been testing on Steam Deck, and it’s working great on the Soldier beta, but it might not work on your machine, and, if not, I wanna know.

In particular, the Valve developer “smcv” reported that Slammed just crashed outright on Debian 11 (but worked fine on Debian 10 and Debian 12). Does it crash for you on the Soldier beta?