@liamdawe I'm wondering, what's the hardware configuration of your server? what is your provider? do you use AWS at all? and how much does everything costs?

I know it's a lot of questions, sorry O:-D

View this comment - View article - View full comments

Quoting: DisharmonicPpl still take youtubers seriously?

Not all the youtubers are bad, I'm following a couple of dozens of them.

View this comment - View article - View full comments

Quoting: muellThere is no radv OpenGL driver and apparently you're blindly copying release announcements.

Gosh! people can be so disrespectful on Internet...

View this comment - View article - View full comments

Quoting: TheRiddickYeah screendoor is a issue. In all honestly I would probably wait for the 4k helmets anyway, one coming out later this year already (they advertise it as 8k but yeah, that's marketing BS). PIMAX is the brand. I'll wait for reviews. Not sure if a 1080ti is enough for it however...

Linus Tech Tips made a video about the PIMAX VR headset:
View video on youtube.com

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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

View this comment - View article - View full comments

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

View this comment - View article - View full comments

One thing that I just thought of that would be very interesting is your machine, the SmachZ, and the Steam Cloud!
So you can play a game on your PC, quit it, take your SmachZ and continue playing with the same saved state.

Must admit that it's pretty cool! ;)

View this comment - View article - View full comments

Whether it runs on Linux or not, who wants to play LoL on a handheld device?
Even Dota 2 that runs very well on Linux, I'll still play it on my main desktop.

As for GTA 5, well if most of the games you want to play are AAA games, then maybe it would be better to install Windows on this device, don't you think?

I guess you'll choose your OS depending on your profile. If you don't know Linux and/or want mainly to play AAA games, then it is probably better to go with Windows. On the other hand, if you like indie, "AA" games and are not afraid to tinker a little with your device, then Linux is probably the right choice for you.

View this comment - View article - View full comments

Quoting: CheesenessSlime Rancher is on 2017.1.0p4, which was released in August last year. The fix for the issue highlighted here didn't land in the 2017.1.x branch until 2017.1.0p5, which AFIK coincides with it being fixed in the 5.6.x branch.

Yep, we've improved our testing and QA workflow for about a year now. When we detect a regression, we backport it to the earliest supported branch. The idea is that we don't backport a fix to a previous version until the next version is fixed. This is done in order to prevent from having a bug fixed in 2017.1 and 2017.3, but not 2017.2, which would be considered as a regression.

The "p*" releases are patched versions that contains the most recent fixes. At some point, we pack together all the patches and re-delploy a new release.

That is why a fix can be in both 5.6 and 2017.1, but the game devs still need to use the latest version of their release in order to have the latest fixes.

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 for each versions, but it's very difficult to bring interest to them.

Quoting: ShmerlIt 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 not because a bug is easy to reproduce that it means it is easy to discover. We have tens of thousands of tests that runs non-stop on our build machines. When we create a feature, we also create tests for it, and each time we detect a regression, we create a test to prevent it from reappearing. But despite all that, it happens that we don't detect some bugs in time for the next release.

But as you can see from Cheeseness comment, we fixed the linux-fullscreen bug and backported it on all the supported releases. Now it is up to the game devs to make the update. If they're using 2017.1.0p4 and the fix is indeed in 2017.1.0p5, it should not be too much of a risk to upgrade their game to this release. But upgrading the engine is not an easy job as a game dev, you still need to verify that it doesn't add more regressions in your game. If they don't have QA resources (which must be the case for 99% of the indie devs), or unit tests of their own (which would not surprise me if it was also another huge majority), upgrading the engine is definitely a riskier move to make.

Quoting: Cheeseness

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.

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

View this comment - View article - View full comments