It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Urnoev: Sure, I can do that, theoretically. I always test both Wine-Staging (which is what I usually use) and vanilla Wine.
It's perfectly fine how you have done it in your last report for Limbo (when I consider that rc version as stable as it's very unlikely that the final release will suffer from regressions compared to it). I'm happy with that. Thanks!

avatar
Gydion: There is little value in doing this here. Particularly as you are on the development branch of Wine. Additionally the version that you have used the most is the one that should be reported (unless they have seen nearly equal time). Now it can be useful to mention that e.g. it appears to work on non-staging versions. One can assume it would be the same version unless you specify differently.
The stable version of Wine has a much longer life span than any development or otherwise patched Wine version and is less prone to regressions, so test results for the stable version are much more valuable. Only when a game does not run with the stable version test results for development or patched Wine versions are more interesting, at least for me.

avatar
Gydion: No need for repeating redundant information that negatively impacts readability.
I don't think adding another version number in that line impacts readability. And how's that information redundant? A test result for the development version of Wine already can be invalid a few weeks later while the test result for the stable version usually is valid for a much longer time.

avatar
Gydion: Let's not forget there is an entire website specifically designed for submitting tests on various versions of Wine. I encourage any who is interested to also use it: AppDB.
Reports on WineHQ are mostly not for the GOG version of a game and the GOG version often differs in behavior from other versions. So for GOG games this thread is much more helpful than WineHQ.
avatar
rampancy: On a tangentially related topic: What's the status of CSMT in WINE 2.0? Is it going to be enabled/included in the final versions, or is it still confined to wine-staging?
CSMT is still quite experimental and involves huge changes. It's still only in wine-staging, I don't think it will be included in regular wine in the near future, or maybe ever. It actually was dropped from wine-staging 1.9.6 and reintroduced in 1.9.10, because of some incompatibility issues, or something. So, not stable vanilla Wine material.
Post edited January 04, 2017 by Urnoev
avatar
eiii: Reports on WineHQ are mostly not for the GOG version of a game and the GOG version often differs in behavior from other versions. So for GOG games this thread is much more helpful than WineHQ.
I'll also add that a lot of them are very poorly written, with almost no useful information as to how a game fails on a given WINE version. Many of them also were written for 1.1.x-1.3.x builds or earlier, at least for classic games.
avatar
Urnoev: It's just one line, how can those few characters significantly impact readability? But you're right, in general there is no point in mentioning the normal Wine version. It takes me about three minutes to test it, so I usually do it anyway, since Staging still isn't an option/necessary for everyone.
Personally, I think that line in your LIMBO entry looks dumb. I'm halfway tempted to have it a requirement to have only one for the version field (that being whichever had primary testing done with it). I have no issues with it being mentioned down in the install section/notes. In fact that usually useful as I already mentioned.
As far as readability, just expect to hear some whining if a report has 4 different Wine versions in it. Depending on how it's presented.

You are wrong about Wine Staging by the way. It has been an official part of the Wine project for some time now. The Staging folks are actually the ones who build the official WineHQ packages (both vanilla & staging versions).


avatar
Urnoev: I could omit that information if that isn't the case of course...
That's part of what I was trying to say.

avatar
immi101: can you add the version of your installed mesa package as well? xf86-video-ati just contains the 2d x11 driver which is mostly irrelevant for gaming. The 3d driver is is included in the mesa package.
avatar
Urnoev: Sure, I didn't think about that. :)
Thanks. I would have mentioned this had I noticed it. That's included in inxi -SG output, but I realize you may not have that installed.
avatar
eiii: The stable version of Wine has a much longer life span than any development or otherwise patched Wine version and is less prone to regressions, so test results for the stable version are much more valuable.
I'm not interested in the branch of Wine. The specific version used is the requirement. That suffers from no regressions. I have no problem for anyone who tests with 1.8.x, but they would need to be exact.

avatar
eiii: I don't think adding another version number in that line impacts readability. And how's that information redundant?
It looks dumb there. It's redundant because it can assumed to be the same. If it's different than it would be required to specify which version.

avatar
eiii: Reports on WineHQ are mostly not for the GOG version of a game and the GOG version often differs in behavior from other versions. So for GOG games this thread is much more helpful than WineHQ.
You do realize I created the thread, yes? Not to mention the "ratings" I assign to the AppDB reports. This thread however is not going to attempt to track all tests for all versions of Wine for a given game. The forum software is completely unsuited to it, and the AppDB site is specifically designed with that in mind.

Oh, there is nothing stopping anyone from submitting a test on AppDB with all useful information included. Again for anyone who might be interested in doing so.
avatar
rampancy: On a tangentially related topic: What's the status of CSMT in WINE 2.0? Is it going to be enabled/included in the final versions, or is it still confined to wine-staging?
It did not make it in before the code freeze. Whatever is left, which is not insignificant, would be considered new features. No, in other words.
Post edited January 05, 2017 by Gydion
avatar
Gydion: Personally, I think that line in your LIMBO entry looks dumb. I'm halfway tempted to have it a requirement to have only one for the version field (that being whichever had primary testing done with it). I have no issues with it being mentioned down in the install section/notes. In fact that usually useful as I already mentioned.
As far as readability, just expect to hear some whining if a report has 4 different Wine versions in it. Depending on how it's presented.

You are wrong about Wine Staging by the way. It has been an official part of the Wine project for some time now. The Staging folks are actually the ones who build the official WineHQ packages (both vanilla & staging versions).
I think you're maybe overreacting a bit. :D
What's the difference between mentioning it in the info list and in the details? I can't see anyone interested and capable enough to try to install the Windows version of a GOG game on Linux whining about the confusing versions...

As far as CSMT is concerned, I was talking about the wine and wine-staging packages, not the project, which was the question, if I'm not mistaken. :)
avatar
Urnoev: What's the difference between mentioning it in the info list and in the details? I can't see anyone interested and capable enough to try to install the Windows version of a GOG game on Linux whining about the confusing versions...
I want the version it was tested with. Not the one you tested for half a minute and the game happened to successfully load. Now for some that may be the same if you didn't do more than install it and run around for a second. Otherwise the version with the most playtime is more valuable. Mentioning the e.g. vanilla 1.9.27 is likely useful. It does not have the same prominence however.

avatar
Urnoev: As far as CSMT is concerned, I was talking about the wine and wine-staging packages, not the project, which was the question, if I'm not mistaken. :)
I was actually speaking of both the project & packages. If you have access to Wine HQ packages you have access to wine-staging packages. Also, while CSMT is a significant patch, staging has many other fixes in it. Not all of which are complete.

Edit: In case I haven't been expressing myself clearly I'm not telling people to go over to the AppDB instead of posting in here. This thread however is not trying to replicate the AppDB's multi-Wine, multi-testing abilities. The format does not support that in any elegant fashion vs the site which does. I'm also not all that spun up about it all.
Post edited January 05, 2017 by Gydion
avatar
Gydion: I'm not interested in the branch of Wine. The specific version used is the requirement. That suffers from no regressions. I have no problem for anyone who tests with 1.8.x, but they would need to be exact.
Sorry, I haven't been clear enough. I also would like to have test results for exact versions. That's why I wasn't very happy with the "older and non-staging versions work fine as well". But when a game works with one of the stable releases of Wine it is very likely that it also works with any subsequent release from the stable branch while that may not be true for releases from a development branch. That's why I prefer test results for stable releases.

avatar
Gydion: It's redundant because it can assumed to be the same. If it's different than it would be required to specify which version.
When a game runs with a staging or CSMT version of Wine I wouldn't expect that it also always runs with the same vanilla version of Wine. At least that's my experience.

avatar
Gydion: You do realize I created the thread, yes?
I do. Your thread, your rules. :) This wasn't meant as an argument, just my opinion. I'm very happy that this thread exists at all, and would like to thank everyone who's contributing to it, especially you!

avatar
Gydion: Oh, there is nothing stopping anyone from submitting a test on AppDB with all useful information included. Again for anyone who might be interested in doing so.
It's not that there are no good reports on WineHQ. But the average quality level of the reports is much lower than it's here, thanks to the good testers and the refining of the reports due to the interaction between testers and you.
How about a specific section about the Wine versions tested?

For example:

Wine version(s) tested:
wine-staging (with CSMT) 2.0rc3-1: Played for about 20 hours, works perfect.
wine 2.0rc3-1: Starts fine, walked around a bit, no further testing beyond that.

It's not optimal of course, but clearly states what was mainly tested and in which way.
avatar
Urnoev: Wine version(s) tested:
wine-staging (with CSMT) 2.0rc3-1: Played for about 20 hours, works perfect.
wine 2.0rc3-1: Starts fine, walked around a bit, no further testing beyond that.
Obviously it's fine to only have staging 2.0-rc3 for the version and mention in the notes that wine 2.0-rc3 appears to work. If you want to go to that level of detail though I think that does work well. Thanks.
Post edited January 06, 2017 by Gydion
Hmm, I noticed that The Witcher 2 isn't mentioned. I'm sure that I've played it from start to finish on wine, but have no idea what version of wine or what overrides I might have used, or if there were any issues involved.
Well, GOG offers a Linux version of The Witcher 2... which is just using a Wine wrapper, if I'm not mistaken.
avatar
Urnoev: Well, GOG offers a Linux version of The Witcher 2... which is just using a Wine wrapper, if I'm not mistaken.
That came later, I'm sure I played it on wine. But maybe it's not that interesting given the port.
avatar
Urnoev: Well, GOG offers a Linux version of The Witcher 2... which is just using a Wine wrapper, if I'm not mistaken.
Witcher 2's Linux version is not Wine-Wrapped, it's using Virtual Programming's 'eON' translation layer. While some may argue whether it's a wrapper or not, the end result is that it's better than Wine and it can run DX11 games (BioShock Infinite is a good example of this).
avatar
Ganni1987: Witcher 2's Linux version is not Wine-Wrapped, it's using Virtual Programming's 'eON' translation layer. While some may argue whether it's a wrapper or not, the end result is that it's better than Wine and it can run DX11 games (BioShock Infinite is a good example of this).
Really?! I didn't know that, very interesting. I think I'll give it a try then.