Quoting: Shmerl

Quoting: Cheesenessbut everything generated and you can't move backwards, so while the game always has new things for you to find (whether that's ancient alien structures, outlaw bases, solar storms, a node that's too close to a star, etc.), you're not exploring a universe the way you might in say, Pulsar, nor are you learning to navigate environments the way you might in Sublevel Zero.

Ah, I see. I thought it's something similar to Freelancer where you can travel anywhere in the sector back and forth. Still sounds interesting, though I'd prefer a fully "sandbox" type of experience.

It's probably more analogous to FTL's sector map, except that you can't jump backwards. It also has overpowering enemy forces that spawn into a node if you linger too long to make sure that you keep moving (which I think is balanced pretty well and helps keep the game's pacing nice and solid).

If it's helpful, the stream archive from yesterday of me doing a "no-violence" run is still up https://www.twitch.tv/videos/245683121 [External Link]

View this comment - View article - View full comments

Quoting: Feist

Quoting: ShmerlHopefully we'll see GOG release once it's out. Does it offer some exploration missions too, or it's about combat only?

Sort of, there are missions where you are supposed to search for and scan various life-forms. There's also a fair bit of exploration involved in gathering resources for manufacturing weapons/shields/devices as well as searching through ship wrecks for stashes that contain valuable loot.

However, combat is very much the main focus of the game.

Chiming in with my experiences here too. There's definitely an element of exploration in that a sector is made up of nodes that you don't know the contents of (unlockable perks let you see a danger rating, whether the node contains a shop, etc., but beyond that, it's up to you to explore), but everything generated and you can't move backwards, so while the game always has new things for you to find (whether that's ancient alien structures, outlaw bases, solar storms, a node that's too close to a star, etc.), you're not exploring a universe the way you might in say, Pulsar, nor are you learning to navigate environments the way you might in Sublevel Zero.

I'm about 73 hours deep in the game now, and it's still showing me new things. I've recently started doing "no violence runs" as an extra challenge and made it to sector 6 last night. Not having access to resources from enemies you kill is definitely a handicap, and I don't think the finale can be completed without killing everybody, but generally speaking the game can definitely be played without combat being a primary focus.

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

Today's Slime Rancher update resolves this issue.

View this comment - View article - View full comments

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

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.

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?

View this comment - View article - View full comments

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

View this comment - View article - View full comments

Quoting: Creak@Cheeseness: Maybe you could use the issue tracker [External Link]? Once a bug is reported, it appears in our issue tracker.
Here is an example of a fixed issue [External Link] 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.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: CreakWell put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.

Simplest, but not available if developers don't have time or will to do it. So giving users that unsupported option is not a bad thing in such case. Most will never use it, and those who would, know it's not a guaranteed method. If Unity would have been properly FOSS, it would have been doable anyway, just by the nature of the openness :)

I've been helping/working with Levi (one of Unity's primary Linux developers) to identify and resolve issues with Unity's Linux player for years [External Link] and have had the opportunity to witness this first hand. For a variety of reasons (some more valid than others), many developers are unwilling to upgrade.

As a proponent of Free Software and a Free Software developer, I love the idea of getting rid of the distinction between users and developers. As someone who also exists within the proprietary world, I can see that if we end up in a situation where proprietary developers can be sell a Linux game and then leave it up to Linux users to solve their own problems, the long term impact of that would be that we wouldn't get any actual support :(

It's not a nice situation either way, but I think this is just the nature of the proprietary world. The best thing we can do is focus on rewarding/supporting developers who support us properly and report bugs/work with/make note of those that don't (FWIW, I've shot information through to the developers of Slime Rancher with details on the issue and its resolution).

Quoting: Creak

Quoting: CheesenessIMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.

You're right, we do have detailed release notes [External Link] for each versions, but it's very difficult to bring interest to them.

It's bigger than this though. That focuses on what's fixed in each patch release, and doesn't make note known critical issues that have/have not been resolved in future patch releases. If I could point a developer to a list like that, I think I'd have an easier time convincing them of the value of upgrading.

View this comment - View article - View full comments

Quoting: ShmerlI think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that arne't updated by developers anymore.

As I understand it, the engine specifically looks for data files made by the corresponding editor version so that it's not possible to mismatch engine/data versions. Given how much stuff can change between releases and how much work upgrading can be, that's pretty sensible.

Allowing users to swap in/out whatever engine version they please sounds nice, but it would also create more opportunities for QA oversights (not to mention increased support overheads for developers who couldn't be certain of what versions their users are running). A cool thought, but definitely a double edged sword.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: CheesenessI don't think this is a regression.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

It's definitely a bug, and everybody felt very embarrassed when it was discovered that that bug made it into release builds. The problem was resolved pretty quickly and, in my opinion, it was handled as well as it could have been. So far as I'm aware, it also resulted in improved testing practices, which is really all we can expect/ask for.

View this comment - View article - View full comments