Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

A while ago the Unity game engine sadly introduced a bug which has caused many games to either display a black screen or give no input, Slime Rancher [GOGSteam] is another I've discovered with it. Here's a temporary fix.

If you have issues, you can use this as a launch option on Steam. You need to right click the game, go to Properties at the bottom, then press the "Set Launch Options…" button and enter this:

-screen-fullscreen 0

If you have the game from GOG, you can use the same setting when launching it via terminal.

Alternatively, you can adjust the game settings file found in "/home/yourusername/.config/unity3d/Monomi Park/Slime Rancher/prefs" and set the fullscreen mode "Screenmanager Is Fullscreen mode" to zero.

The issue is supposed to be fixed in later versions of the Unity engine, hopefully the Slime Rancher developer will be able to upgrade sometime so Linux gamers don't have to resort to little fixes to get it running.

GOG links are affiliate links.

Article taken from GamingOnLinux.com.
4 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
29 comments
Page: «3/3
  Go to:

Cheeseness Mar 6, 2018
Quoting: Creak@Cheeseness: Maybe you could use the issue tracker? Once a bug is reported, it appears in our issue tracker.
Here is an example of a fixed issue in the issue tracker. If you see that it is missing some information, you can still ask the devs to fill out some information in the tracked issue.

The idea would be that thanks to the issue tracker, you would be able to give one single URL to the devs you're in contact with, and they would be able to follow this exact bug.
I understand the intention, and I often link developers to specific issues, but I think that that is nowhere near as effective as a maintained/generated Known Critical Issues list in each patch's release notes would be.

It's the cumulative impact of everything "wrong" with a particular release that's going to make developers go "Oh hey, actually, updating *is* a good idea," rather than the resolution to one problem alone that they have to take my word for being related. Linux is a small market, and upgrading is often seen as a big hassle. The effort vs reward proposition of updating just to resolve one Linux issue is, to a lot of developers I've interacted with, hard to justify.

The issue tracker isn't always so helpful. In this case if I remember right, it was 880426's fix that ended up resolving the issue that this thread is about, even though the issue itself focuses on mouse related issues. The issue tracker notes it resolved in 2017.1, and a comment says it was resolved in 5.6.1p2, but nowhere does it note that the initial fix didn't address the problem completely and 2017.1.0p5 and 5.6.2p3 are where the proper resolution for the issue can be found. I could go through and leave comments for everything I know about, but a) a developer in a hurry isn't going to read comments if they don't immediately recognise an issue as being relevant, and b) I'm not the authoritative source here - there's scads of stuff I don't know about (not to mention that that would mean less time helping other developers identify and work through their hurdles).

There are also plenty of things that aren't even on the issue tracker, such as 2017.1.0p5's fallbacks if xrandr calls fail. I can't even link developers to specific release notes to show them that.
Creak Mar 7, 2018
I completely understand your point, I'm just trying to find alternative solutions in the meantime. Because even if I also want everything you've explained, I don't think I would be able to change much at Unity since it's not exactly my area.

But on the other hand, you also need to understand that it's difficult to know what exactly is a critical issue. We have a system of "User Pain" rating on our issues, but it's based on an heuristic that, by definition, is not perfect. For instance, as we debug our systems, we can fix issues that hasn't been discovered yet, but if it was, it would have been a critical issue. And on another scenario, during our bug bash weeks, we can fix bugs that aren't critical yet, but that will become critical a few weeks later because users start to use the feature more intensely (maybe because a blog post has been published).

All that to say it is often more difficult than it seems to detect and communicate on these issues. But we are working on it and every day we improve our QA systems a bit more.

That being said, I do believe that even with the best QA system in the world, the developers would still not update the engine to a new release unless it becomes truly critical. And "critical" is a relative term here. What you would consider critical (like the fullscreen problem on Linux), could be considered as minor for another developer (if their main target is Windows for instance). Even with a 200% unit test coverage on Unity's side, there is still a risk on the developer's side. Simply because the way a bug is fixed, even if it is a better solution in the end, it could create a regression on the user code for multiple reasons: either they were using a feature to hack something, or they're using the feature in a way that is not tested by the unit test, since features are combinatorial, it is understandable.

Edit: In the end, I still think that the best solution for the Unity users is to frequently test your project with the next Unity release, using a temporarily duplicated version of your project. And if there are bugs, file them (which is still the best way to keep the devs informed) and if it is a regression, jackpot! the QA will be all over us to fix the bug ASAP :D


Last edited by Creak on 7 March 2018 at 4:05 am UTC
Cheeseness Mar 7, 2018
Quoting: CreakI completely understand your point, I'm just trying to find alternative solutions in the meantime.
It's all good - I feel like I'm getting by with things as they are, and there's nothing I can meaningfully do from where I'm at to address the broader culture of Unity-using developers being upgrade-averse. I was just highlighting an area for improvement at Unity's end that I think would make a big difference in response to Shmerl's earlier comments :)

Quoting: CreakEdit: In the end, I still think that the best solution for the Unity users is to frequently test your project with the next Unity release, using a temporarily duplicated version of your project. And if there are bugs, file them (which is still the best way to keep the devs informed) and if it is a regression, jackpot! the QA will be all over us to fix the bug ASAP :D
I wholly agree with this, but I can understand that it's an overhead that's difficult to justify for teams with limited resources (both QA for testing and HDD space/build server time for big projects).
Creak Mar 7, 2018
Quoting: CheesenessI wholly agree with this, but I can understand that it's an overhead that's difficult to justify for teams with limited resources (both QA for testing and HDD space/build server time for big projects).
True, and it's true as well, in that respect, that Unity should be doing as much of the QA work as possible
I also thought of something out of the control of Unity or the game devs: the asset store packages. Game devs uses a lot of packages in their games, which could be more or less stable with the latest release of Unity. It depends on the maintainer's QA. One more reason for the game devs to test their game on the latest releases. Even if it doesn't mean that the game will be updated to it, it gives a good overview of the potential problems.
Enverex Mar 9, 2018
Weird, this game used to work fine for me, but now I've got the black screen issue too. Arch, GTX 1060, 4.14 kernel, etc. I have however updated the game since it worked so I guess it was a Unity update itself that broke it.

Deleting the game's config folder (~/.config/unity3d/Monomi Park) got me to where the menu screen should be (I could see the logo and then the background) but the menu itself still doesn't appear so whilst it's an improvement, it's still not usable.


Last edited by Enverex on 9 March 2018 at 11:37 pm UTC
Cheeseness Mar 10, 2018
Quoting: EnverexWeird, this game used to work fine for me, but now I've got the black screen issue too. Arch, GTX 1060, 4.14 kernel, etc. I have however updated the game since it worked so I guess it was a Unity update itself that broke it.
My understanding of the Unity issue is that it doesn't happen under all window managers/environments. I wouldn't be surprised if system updates have played a role in this becoming more prevalent recently (given that the version of Unity being used is a 7 months old).

QuoteDeleting the game's config folder (~/.config/unity3d/Monomi Park) got me to where the menu screen should be (I could see the logo and then the background) but the menu itself still doesn't appear so whilst it's an improvement, it's still not usable.
If you edit the prefs file, as suggested in the article here and update the resolution width and height to something sensible, does that sort things out?
Cheeseness Mar 13, 2018
Today's Slime Rancher update resolves this issue.
Shmerl Mar 14, 2018
Quoting: CheesenessToday's Slime Rancher update resolves this issue.

Is it coming out on GOG too? The last update there was in 29th November 2017.
Cheeseness Mar 14, 2018
Quoting: Shmerl
Quoting: CheesenessToday's Slime Rancher update resolves this issue.

Is it coming out on GOG too? The last update there was in 29th November 2017.
Not 100% sure (I haven't heard back from them in a week or so), but I'd imagine so. The last big update that wasn't related to the holiday event thing was on the 29th of November.


Last edited by Cheeseness on 14 March 2018 at 3:11 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.