There is actually a partial fix in 1532453 but when you run the update, the broken version you just upgraded from leaves running threads in the background, so even though it may be fixed for you it doesn’t seem that way until you reboot or run a killall.

There’s a second step to this fix which I hope to release this evening, and the same potential caveat applies.

It wouldn’t have been fixed in that version but it should be fixed now.

No release date yet, it’s being actively worked on.

I believe the current plan is to run the old and new side-by-side for at least a while after release so we will wave the flags about it some more once it’s up and running to give people time to play around and migrate.

Could I get details on the X crash please?

At the moment there’s no difference between beta and release in either the launcher or wine, so it’s very odd that it would crash with one but not the other.

Currently the launcher is pulling down wine-staging-4.4 by default.

Re the DXVK stuff, the best way to speed that along would be to give me very specific instructions that I can follow to the letter and then immediately test.

I suggest the following:

1. Allow the launcher to download the default wine
2. Go to the wine folder in the shared cache (often something like ~/.eve/wine) and do a git init there, then add and commit everything to create a baseline
3. modify the contents of the wine folder in place to have the patches you’d like me to implement
4. Launch the client to ensure your modifications work
5. Send me the git diff of what you’ve changed
6. Tell me where to get the files that are shown as added or modified on the diff

Armed with that information, it should be fairly simple for me to make a DXVK testing branch and implement your patches, and we’ll see how it goes

CCP does not support linux, and I’m not interested in attempting to partner with valve as an individual

A quick note on the performance, it does look like there is increased CPU usage with this version of wine under linux. I hope to be able to find ways to improve that although I remind people that this is a spare time project for me so I’ll do what I can but I can’t promise anything.

Despite that, it looks like this build is very stable across a wide range of distros and so I’ve elected to push it to release (happened yesterday) and make it the default wine because the old wines will certainly break once we push a 64bit client.

I’m choosing a performance hit over a crash for people who just want a plug and play experience. Anyone who needs high performance may need to look into a custom tuned wine, at least in the short term.

Launcher version: 1501045
Launcher download link: https://binaries.eveonline.com/evelauncher-1501045.tar.gz
Shipped wine version: Wine-4.4-Staging

Changelog:

14/05/2019 - Bumped release wine to wine staging 4.4 32/64bit, paving the way for a 64 bit client build

If this is the black cubes in space, it’s a shader problem with gas clouds rather than a texture problem I think. I might try pushing the linux dev build even further upstream and see what happens to this. Science!

The wine environment bitness and the client environment bitness are related, but orthogonal.

This wine can support both 32 and 64 bit windows applications inside it. The previous wine could only support 32 bit.

If you’re using this wine on TQ, you are running a 32 bit client inside a 32+64bit wine.

Later today there will be a 64bit mass test on sisi. If you join in, you will be running a 64 bit client inside a 32+64 bit wine.

Yep, I can repro it here too. I’m not gonna look at it today, for the moment I recommend fixed window mode if you want to keep playing with the new build

There were several new ones after the one you tested on slack to solve the libwine issue, but not since last night.

It’s possible that the way I added the new build to the launcher is not good and thus it isn’t correctly persisting your wine choice between restarts.

It’s not different. That’s the biggest change to the wine delivery pipeline. The last major revision of CCP wine, which is at this point very old, had a lot of custom patches in it. Some graphics card ID’s that weren’t in upstream wine at the time, a few custom patches to solve eve-specific graphics bugs, stuff like that.

At this point a lot of those custom changes have been solved in upstream wine independently, and we’re working at upstreaming some of the stuff which hasn’t made it. There’s very little left in our custom fork that we can’t upstream and that isn’t already fixed in newer versions of wine, so we’re jettisoning our custom fork.

Instead, we’re taking binaries from the winehq website, fiddling with their shipped libraries a little to make sure they work on the systems we target and then repackaging them so they can be installed by the eve launcher.

The alpha build this thread is referring to is really just this: https://sourceforge.net/projects/wine/files/Slackware%20Packa...

Hey all,

We’re overhauling our wine delivery pipeline as part of the work for the 64bit client. The mac environment needs a combined 32/64 bit wine and I have side-ported that work to linux too.

If you’d like to give it a spin:

1. Set your launcher to beta mode
2. Wait for it to patch to at least version 1500694 and restart it
3. check settings->wine options->Use dev versions
4. Set Dev branch to winehq-linux-binary (this is only available if you have the latest beta)
5. Wait for wine to install and launch

Be aware that if you’ve done custom things in the CCP wine folder, this will replace them, and the replacement may not work. Only give this a try if you’re willing to re-create your old wine setup from scratch if it doesn’t work. This is alpha, and you’re the first testers.

Please check in with what distro you’re on, whether you’re using dx9 or dx11 and how it went!