Quoting: tuubiIn any case, I don't see the harm in them requiring adherence to standard practices, like the XDG directory spec.

I fully agree here. I meant mostly that it shouldn't become a programmatic dependency, like games needing to use some Steam specific APIs and such.

View this comment - View article - View full comments

Quoting: buenaventuraPerformance for me in witcher 2 is just horrendous even on absolute bottom settings.

It's very good for me on max settings (RX 480 / Mesa 13.0.2). What hardware and Mesa version do you use? Also, remember to always keep ubersampling disabled.

View this comment - View article - View full comments

Valve have no control over how games store configuration. And games shouldn't rely on such control either. It will only complicate ability to release games without Steam.

View this comment - View article - View full comments

Quoting: M@yeulCEven Steam puts a .steam folder in my home folder...

I see. Then it's already a mess, and doing it for the client can help with moving client data to proper place, but it can also mess up games which check if $XDG_DATA_HOME isn't set, and use $HOME/.local/share when it's not. For those you'll get: $HOME/.local/share/.local/share in result.

Quoting: M@yeulCBut yeah, the ideal wold be for Valve to enforce this behaviour.

It's really up to individual games to follow the spec. Valve should fix their own client though.

View this comment - View article - View full comments

Quoting: M@yeulCOr in the steam launch options:

HOME=${HOME}/.local/share %command%

This is actually a pretty good idea, and I am considering changing this variable before launching Steam, considering the number of games that behave correctly.

In case of GOG release that would be start.sh, but I don't think it's a good idea to set it for every game, since some do follow XDG base directory spec correctly, and for those you don't want to do it. So setting it individually only for games which mess up $HOME directly is the best approach.

View this comment - View article - View full comments

Quoting: ShugyoushaThe patch only gets the game half-way there and I assume they will have to add another workaround before the game runs without issues.

They already stated, that it's a mistake in the game to read some hardcoded vendor string for AMD. Mesa isn't going to "fix" it for them. May be instead of making shims they'll provide some way to set that through environment variables. At least that won't require compilation.

View this comment - View article - View full comments

Quoting: Al3s

Quoting: ShmerlI also recommend setting this for the game, otherwise it will clutter your $HOME:

HOME=${HOME}/.local/share

Where should I set this?

In the same script that you set workaround hacks. I.e. in runner.sh that comes with the game.

View this comment - View article - View full comments

I've heard driconf is a dead project anyway.

View this comment - View article - View full comments

I also recommend setting this for the game, otherwise it will clutter your $HOME:

HOME=${HOME}/.local/share

View this comment - View article - View full comments

Quoting: Joeyboots80I look forward to playing this as I have had it for over a year but have nt tried it yet due to the fact that I use mesa. Thanks for this news Liam. ^_^

This won't solve the issue fully. The workaround for Mesa helps, so you can as well apply it today.

View this comment - View article - View full comments