CCP_Bartender

I actually don’t know the answer to either of these questions. As far as I know the black cubes show up on both the 32 and 64 bit clients in dx11 mode (I might check when I get home), so I think it’s just a DX11 thing.

I’m not suuuper-concerned about the CPU usage as long as it’s still functional. I have to pick my battles on linux patches since it’s not officially supported so I work on it in my spare time. I’ll keep an eye on the situation but I won’t be putting any time into investigations unless CPU usage makes it impossible to play. I am however always open to people who know what’s up telling me what’s wrong and giving me clear info on how to fix it, so if you know why it’s happening please clue me in

Hey all, I’ve just dropped wine 4.13 into the development wine list, it’s build 227.

This build includes some new graphics card profile that we’ve been working with codeweavers to upstream into wine proper. This is unlikely to affect anyone on linux since they’re all obscure macbook cards, but never the less it’s likely that we’ll be making the jump to wine 4.13 (or even 4.14, there’s a few more cards coming in the next patch I hope) fairly soon.

If you’d like to hop on the train early and let me know what you think of 227/4.13, feel free to do so

It’s in the settings window of the launcher if you’re on mac

Hey all,

I’ve just released a new version of wine into the dev versions branch, it’ll be listed as “winehq-binary-226”.

Under the hood it’s wine 4.11, specifically this one: https://sourceforge.net/projects/wine/files/Slackware%20Packages/4.11/x86_64/

I don’t have any plans to push this to release wine any time soon, it’s well upstream of where the mac wine version is at. I’ve put it in dev because I want to play around with it and see if it’s got any fixes for the black gas cloud cubes etc.

Give it a spin if you want and let me know what your experience is. Don’t forget to include your distro and bitness!

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

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

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!