Dawn of War II has a minor patch to fix a few issues

I assume the launch issues were fixed by sym-linking (or renaming) the libraries to match the names the game binary was using to to look for them (or alternatively by updating the game binary to use the existing library name), as I pointed out in the Steam forum thread. Honestly, I don't know how that was missed by their QA people.

What I'm really interested in is seeing them finally get to the bottom of why the game wants to download an update every single time I launch Steam. It's really annoying!

Also, it seems one of my recent Mesa updates (which I compile myself) broke the game, so I'll need to look into that before I can play it again - and possibly do a regression test.

Give it to me straight, doc. What are the odds of Dawn of War I getting ported?

That's really nice of them fix those issues, that's what I like with these porting companies. So many games just go "port and forget". UT2004, for example.

The multiplayer problems where already present in the win2win match.

I'm playing this game from several years and there were a lot of trouble to play multi, you have to wait for a long time waiting for the matchmaking process to find partners and opposants, and when the party loads finally one or two people get kicked out and the game is screwed, every one quit and you have to start again ... very annoying for a game where i've bought all the extensions and DLC.

I assume the launch issues were fixed by sym-linking (or renaming) the libraries to match the names the game binary was using to to look for them (or alternatively by updating the game binary to use the existing library name), as I pointed out in the Steam forum thread. Honestly, I don't know how that was missed by their QA people.

These launch issues only existed on unsupported distros that have issues with the Steam runtime which then can impact games in different ways. We constantly tweak our scripts and options to make the game run more reliably and workaround these issues on unsupported systems to help users who don't use the officially supported distros however we can't reasonably test and fully support all distros especially rolling release distros (which are constantly changing).

What I'm really interested in is seeing them finally get to the bottom of why the game wants to download an update every single time I launch Steam. It's really annoying!

We've been looking into it and Valve are investigating the issue but we don't have a solution yet. It seems related to ownership of multiple DoW2 games but we haven't pinpointed the exact cause yet.

Also, it seems one of my recent Mesa updates (which I compile myself) broke the game, so I'll need to look into that before I can play it again - and possibly do a regression test.

If you play on the bleeding edge of git you have to expect to get cut every once in a while. :) I'm sure it will get fixed quickly many of the most active Mesa developers have DoW2 keys so they should be able to easily repro issues :)

These launch issues only existed on unsupported distros that have issues with the Steam runtime which then can impact games in different ways. We constantly tweak our scripts and options to make the game run more reliably and workaround these issues on unsupported systems to help users who don't use the officially supported distros however we can't reasonably test and fully support all distros especially rolling release distros (which are constantly changing).

That's fair. However checking the libraries would seem to be something fairly easy to automate for a bunch of different distributions, via chroots/schroot/pbuilder or some such.

What I'm really interested in is seeing them finally get to the bottom of why the game wants to download an update every single time I launch Steam. It's really annoying!

We've been looking into it and Valve are investigating the issue but we don't have a solution yet. It seems related to ownership of multiple DoW2 games but we haven't pinpointed the exact cause yet.

Ah. That could well be the case. I purchased the Australian retail box of DoW 2 waaaay back when it had Games for Windows Live. The Retribution add-on was purchased much later as a digital purchase.

Oddly, the GNU/Linux version didn't appear for Retribution immediately, but the ancient GFW base game showed the GNU/Linux version immediately.

Also, it seems one of my recent Mesa updates (which I compile myself) broke the game, so I'll need to look into that before I can play it again - and possibly do a regression test.

If you play on the bleeding edge of git you have to expect to get cut every once in a while. :) I'm sure it will get fixed quickly many of the most active Mesa developers have DoW2 keys so they should be able to easily repro issues :)

It's a weird one, and I'm surprised nobody else has seen it since I've been experiencing it for a few weeks now. In fact, just last night I checked out the 13.0.2 git tag, and I still experienced corrupted graphics - built using llvm 3.9, with amdgpu as included in a clean Linux 4.9-rc7 build. This is on a Fury X (Fiji) card. Every time I click past the Feral launcher, all the graphics become garbled - something I don't think I've seen on any of my other games to date. It doesn't seem to be an issue when running the game under Wine, so I'm going to see if I can find time to do a regression test this weekend.

That's fair. However checking the libraries would seem to be something fairly easy to automate for a bunch of different distributions, via chroots/schroot/pbuilder or some such.

There is a difference between assumption and reality on this problem, sadly it's not as simple as an automated script. :) The constant flux of a rolling distro combined with the steam runtime compatibility issues usually means a more manual approach is best/quicker, although we do have some automation present.

As we've mentioned our scripts are constantly evolving to work around issues with distros, certain libraries and hardware however when we make a change in the script we need to make sure it works well for all users with those effected by the issue and those that aren't.

Many workarounds posted are very specific to certain setups which means further analysis and tests need to be done you can't just paste them in, this is why you might get a delay between someones workaround for an unsupported distro on reddit and a similar solution built into the game launcher.

It's a weird one, and I'm surprised nobody else has seen it since I've been experiencing it for a few weeks now. In fact, just last night I checked out the 13.0.2 git tag, and I still experienced corrupted graphics - built using llvm 3.9, with amdgpu as included in a clean Linux 4.9-rc7 build. This is on a Fury X (Fiji) card. Every time I click past the Feral launcher, all the graphics become garbled - something I don't think I've seen on any of my other games to date. It doesn't seem to be an issue when running the game under Wine, so I'm going to see if I can find time to do a regression test this weekend.

We haven't seen any major reports of issues from AMD GPU users which we would have expected if this was repeatable on multiple machines so I suspect it's related to a library you compiled or linked against. Every game will use OpenGL and other libraries in unique ways so you'll often see issues only on certain software and hardware combinations. If you do track something down that appears to be repeatable then do let our support know and/or log a bug with the Mesa devs so they can revert the change if needed or we can look at making a change in a patch as needed.

Edwin

[If you do track something down that appears to be repeatable then do let our support know and/or log a bug with the Mesa devs so they can revert the change if needed or we can look at making a change in a patch as needed.

Thanks Edwin, will do.

An update:

It's a weird one, and I'm surprised nobody else has seen it since I've been experiencing it for a few weeks now. In fact, just last night I checked out the 13.0.2 git tag, and I still experienced corrupted graphics - built using llvm 3.9, with amdgpu as included in a clean Linux 4.9-rc7 build. This is on a Fury X (Fiji) card. Every time I click past the Feral launcher, all the graphics become garbled - something I don't think I've seen on any of my other games to date. It doesn't seem to be an issue when running the game under Wine, so I'm going to see if I can find time to do a regression test this weekend.

We haven't seen any major reports of issues from AMD GPU users which we would have expected if this was repeatable on multiple machines so I suspect it's related to a library you compiled or linked against.

I'm running an up to date Debian stretch on amd64. I also tested Mesa 13.0.2 that's provided by the distribution, and that has the same problem as the builds I compile myself.

Every game will use OpenGL and other libraries in unique ways so you'll often see issues only on certain software and hardware combinations. If you do track something down that appears to be repeatable then do let our support know and/or log a bug with the Mesa devs so they can revert the change if needed or we can look at making a change in a patch as needed.

I had a little bit of time to look into this tonight. I didn't get too far since Mesa takes a long time to build (and then launching Steam and launching the game also adds time to each test). However I have identified the last good build was 12.0.5 stable. The next stable release is 13.0.0 which fails in the same way 13.0.2 does on my Fiji-based card. The timing sounds about right - it's probably been 1 to 2 months since the game has worked. Again, the game continues to work perfectly under Wine with 13.0.2 and the Gallium on Nine patches so it's not a big deal, just a bit annoying.

An update:
I'm running an up to date Debian stretch on amd64. I also tested Mesa 13.0.2 that's provided by the distribution, and that has the same problem as the builds I compile myself.

I had a little bit of time to look into this tonight. I didn't get too far since Mesa takes a long time to build (and then launching Steam and launching the game also adds time to each test). However I have identified the last good build was 12.0.5 stable. The next stable release is 13.0.0 which fails in the same way 13.0.2 does on my Fiji-based card. The timing sounds about right - it's probably been 1 to 2 months since the game has worked. Again, the game continues to work perfectly under Wine with 13.0.2 and the Gallium on Nine patches so it's not a big deal, just a bit annoying.

We have a Fiji card here (R9 Nano) it's pretty much the same hardware as the Fury X. We retested just now using running Mesa 13.0.2 (using the Padoka stable PPA Paulo Dias created for us the other day) our distro used is Ubuntu 16.10.

Everything runs perfectly with no issues on the latest release, we've also not had other reports. I suspect this might be related to something else linked to your system given stretch is the testing distribution it's completely possible some other related library in your distro is causing side effects. It's one of the reasons why we can't support rolling releases / testing distributions as things are in a state of constant flux.

Hope this helps you debug your issues further. Do let us know if you find anything we should know about.

We have a Fiji card here (R9 Nano) it's pretty much the same hardware as the Fury X. We retested just now using running Mesa 13.0.2 (using the Padoka stable PPA Paulo Dias created for us the other day) our distro used is Ubuntu 16.10.

Everything runs perfectly with no issues on the latest release, we've also not had other reports. I suspect this might be related to something else linked to your system given stretch is the testing distribution it's completely possible some other related library in your distro is causing side effects. It's one of the reasons why we can't support rolling releases / testing distributions as things are in a state of constant flux.

Hope this helps you debug your issues further. Do let us know if you find anything we should know about.

Thanks! That's really helpful to know, as it could also be different Mesa compilation options which I can now look at. This makes me more interested to know what the problem is with my setup, so I'll be sure to let you know what I discover.

We have a Fiji card here (R9 Nano) it's pretty much the same hardware as the Fury X. We retested just now using running Mesa 13.0.2 (using the Padoka stable PPA Paulo Dias created for us the other day) our distro used is Ubuntu 16.10.

Everything runs perfectly with no issues on the latest release, we've also not had other reports. I suspect this might be related to something else linked to your system given stretch is the testing distribution it's completely possible some other related library in your distro is causing side effects. It's one of the reasons why we can't support rolling releases / testing distributions as things are in a state of constant flux.

Hope this helps you debug your issues further. Do let us know if you find anything we should know about.

Okay... by now I've spent way more hours trying to get to the bottom of this than I care to admit.

I started by ruling hardware issues out of the picture. I have a second PC running an AMD R9 285 TONGA. Still GCN hardware supported by AMDGPU, so the software stack can stay the same. Then I installed Ubuntu 16.10, and the game ran fine. Next I compiled the latest Mesa 13.0.2, and the game failed. Okay, must be one of my build options then! But I think they are reasonable, and they used to work (and indeed do still seem to work with all my other games - I tested Dirt Showdown, glxgears, looked carefully at the glxinfo output of both the x86 and amd64 builds, etc. - everything seemed great), so I wondered if tracking down the commit that introduced the regression could help explain the issue. So started my way down that path.

After 12 or so rebuilds of Mesa (running tests on each build), git bisect eventually narrowed down the problem to... [d9546b0c5d1a5136a92276cdd7c14883f0c62737] i965: Integrate precise trig into configuration infrastructure. WTF?! That didn't look right. Just to be sure, I reverted that commit on top of 13.0.2, and the issue remained. Darn it!

So then I got thinking, the issue might be intermittent? So I re-built and re-tested some of the builds that I had previously marked off as bad, and to my surprise they now appeared to be working. I tested some more builds from around that commit, but with the randomness it was hard to come to any conclusions. It seemed once it stopped working, the game wouldn't start working easily again for the next few minutes. So strange!

Then I figured I'd tackle the problem by comparing my compile flags to the ones used in the Padoka repo. I set up a pdebuild environment, but it seems the builds are not produced in a perfectly clean environment since that always produced a linking error... (I later noticed it would only seem to build with dpkg-buildpackage) however, at least I was able to get the configure flags from the build log file, and I updated my build scripts to match - adjusting the paths to /opt/xorg which I also reference via my /etc/ld.so.conf.d/custom-mesa.conf and /etc/profile.d/custom_xorg.sh configs to enable a clean uninstall (well, I do have dpkg-diverts for /usr/lib/x86_64-linux-gnu/dri and /usr/lib/i386-linux-gnu/dri references too).

So built that, ran the game and... fail! Gah! It's supposed to be the same software! Sure the Padoka has four extra patches (in the source debian/patches/ directory), but those don't look related to radeonsi on x86/amd64 at all.

After some more messing around, eventually it worked - and I was at a loss to explain why. Eventually I stumbled upon the suspicion that it was the way I launched Steam. Sometimes I would just type the "steam' command into the terminal, and sometimes I would just click the Steam icon in my Xfce panel. Maybe Steam was inheriting different environment variables based on where it was launched, which impacted the ability to run? It seemed unlikely, but at this point I was running short on ideas.

So I added "env > ~/ENV ; %command%" to the game launch options, launched Steam from the Xfce panel, launched the game to the menu, quit the game and Steam, moved ~/ENV out of the way and repeated by launching Steam from the command line. Then I looked at the two ENV files I had via the Meld tool, and noticed four obvious additions to the command line run which I added to the launcher options.

ORBIT_SOCKETDIR=/tmp/orbit-abolte COLORTERM=gnome-terminal TERM=xterm IBUS_DISABLE_SNOOPER=1 %command%

I then launched Steam from the Xfce panel, and bam.. the game ran fine! Next I just needed to narrow down which of the environment variables caused the problem.

I tried "ORBIT_SOCKETDIR=/tmp/orbit-abolte IBUS_DISABLE_SNOOPER=1 %command%", and that failed. Then I tried "COLORTERM=gnome-terminal TERM=xterm %command%", and that worked! Then I tried "TERM=xterm %command%" and that worked too! Really?

Just to put to rest any doubts, I used "%command%". That worked too. Uhh...

Next, I left the launch options entirely empty, and the game continued to launch fine.

I also messed with enabling and disabling the Xfce compositor and relaunching Steam from the Xfce panel, but the results there also seemed random.

Now that I've spent my entire weekend on this and not gotten anywhere, I think I'm going to go have a cry in the corner. I'm not even convinced the issue is Mesa-related anymore. There's a ton of ALSA warnings, so maybe it's something related to that. At least I now know that if it doesn't work, it'll probably work if I quit Steam and try again (and *may* be more likely to work if I log out and in again, or reboot). Or I might just stick to Wine which works 100% all the time. Haven't decided.

Since you haven't seen the problem yet, perhaps there is something about my computers that make the issue more likely to show. Here are the specs, in case it helps:

Machine 1:
Intel i7-6700K (overclocked to 4.6GHz, many hours of prime95 Small FFTs torture testing to prove stability)
G.Skill Trident Z F4-3200C15D-32GTZ 32GB (2x16GB) 3200MHz DDR4
Samsung 950Pro M.2 512Gb (for OS, x2 plus other SSDs unused here)
Western Digital 6Tb HDD (for games, although typically cached in RAM after first execution anyway)
AMD Radeon R9 Fury X (Fiji) (x2 actually, although only one used here)
MSI Z170A Gaming M7
Antec HCP-1300W PSU

Machine 2:
Intel i7-5820K 3.3GHz (no OC)
Corsair CMK8GX4M2B3000C15 8GB (2x4GB) 3000MHz DDR4 running at SPD 2133MHz during testing
Corsair CMFSSD-128GBG2D SSD
AMD Radeon R9 285 (Tonga PRO)
ASRock X99E-ITX/ac
Corsair AX860i PSU

Aside from both being Intel and relatively modern, they aren't really that similar. Machine 1 runs Debian Stretch, and Machine 2 runs Ubuntu 16.10. Both show exactly the same issue. Both also run Xfce.

It's way harder to get the game working at all on Machine 1. Could the issue be related to clock speed? I don't really want to undo my overclock, since it took many hours to perfect...

It's way harder to get the game working at all on Machine 1. Could the issue be related to clock speed? I don't really want to undo my overclock, since it took many hours to perfect...

No, unless your CPU is failing in some way I doubt the overclock is a factor in your issue, I don't think you should need to undo any overclocking if everything else works perfectly.

Sounds more likely something in a subsystem what that could be is a mystery but I've logged your (super detailed) reports internally. If anything crops up that we think could be the cause of your problem we'll let you know but I would say the odds are fairly low due to the extremely low reproduction levels.

It's way harder to get the game working at all on Machine 1. Could the issue be related to clock speed? I don't really want to undo my overclock, since it took many hours to perfect...

No, unless your CPU is failing in some way I doubt the overclock is a factor in your issue, I don't think you should need to undo any overclocking if everything else works perfectly.

I was thinking along the lines of there being a race condition or some such. But like everything I've considered, it seems a long shot.

Sounds more likely something in a subsystem what that could be is a mystery but I've logged your (super detailed) reports internally. If anything crops up that we think could be the cause of your problem we'll let you know but I would say the odds are fairly low due to the extremely low reproduction levels.

No worries. If anyone at Feral comes up with something specific you would like me to test or would like more information on anything, feel free to contact me by e-mail at any point via abolte at systemsaviour.com.


Last edited by boltronics on 12 December 2016 at 11:06 am UTC