Bleh… ran into the same problem. Rebuilt the wine prefix, fixed the new errors by installing mf and the 2019 VC libraries with winetricks, and… still stuck at “Checking GUI Version…”
I think I may have just won for real, because I didn’t log in often enough for me to go through the hassle of completely re-installing - which seems to be what fixed it for you.
I ran into the exact same problem this morning after the launcher update
with the exact same problems trying to do the override, it just stops at “Check GUI version”, I wiped the prefix and tried to reinstall with the current launcher version provided on the website, and ran into the exact same problem, the problem reappeared on a fresh prefix.
I’m on gentoo with wine-staging-6.1
Nothing else on my system changed except for this launcher update; the only way I was able to fix this problem is dig up an old link to an old launcher download on reddit, and reinstall using that.
“EveLauncher-1850297.exe” does not have this problem. If I hadn’t have found a link to the old launcher on reddit I guess I would have been out of luck? I don’t know what else to do at this point except for refuse any further launcher updates and hope they don’t force it. None of the games I’ve played around that DLL seems to work, the built-in version crashes and the native version installed from winetricks or anywhere else gets this “Checking GUI version” message you can’t bypass.
Hopefully we get some more reports of this for more info, if they pushed an update today that borked it, it probably affects proton too, if it knocked out both ubuntu and gentoo versions of wine; though I don’t have steam installed on my system to test it, i’m using regular wine-staging not proton.
After this I would suggest being far more careful for anyone reading this; you don’t have much of a choice for game updates, but if it asks you to update the launcher DON’T DO IT until you’ve backed everything up.
Probably you use beta version of launcher. Now it relased, so, confirmed
get in output: 0384:fixme:netprofm:connection_GetAdapterId ADDR1, ADDR2
and button Retry.
Reinstall eve using http://binaries.eveonline.com/EveLauncher-1850297.exe
and you should be good. You don’t have redownload everything, you can copy over the shared cache.
The first thing it’s going to do is try to update the launcher, but it’ll give you an option, refuse to take the update, and you can launch the game as normal.
Edit: Obviously a temporary solution, this leaves us all stuck on an old launcher version until it gets fixed.
Edit 2: I should also mention I’m not using any special winetricks overrides with this older launcher to get it to work, it works on a fresh wine prefix with no overrides. It also works with gallium-nine-standalone, however I don’t think gallium-nine/wined3d/dxvk overrides play a role with this issue.
Are you running with the current launcher (after todays update) or an older version of the launcher?
I’m trying to figure out if reverting the wine version fixes the issues with the new launcher, as unsavory as reverting the wine version is.
Same problem here running on Lutris. Stuck on checking GUI version… I only recently re-installed EVE so would rather not do that again for now, will try and tinker first!
Remember when your tinkering you can re-use that sharedcache folder, that’s where all the actual game data is, the big download. In the launcher settings you can see where that folder is; back it up, and when you install a new launcher you can go back into those settings and point the shared cache at the folder you just backed up; so you don’t have to re-download everything again.
Atleast for this problem it seems, it’s related to the launcher and not bad game files.
I just restored my wine prefix from a backup (last night’s backup) and launched it, rejecting the launcher update this time, things appear to be working now.
Anybody know an easy way to block launcher updates? Is there a specific domain I could block with /etc/hosts that wouldn’t affect other functionality? Don’t want to accidentally press OK and break everything again.
I’m not sure about blocking it in hosts, could probably run wireshark and figure out exactly where it’s pulling the launcher update from and block it.
I would make sure to separate the shared cache folder and folder the launcher is installed in. At least then if you accidentally hit update you don’t have to redownload everything again. If you keep the same prefix there’s also a lot of settings data stored in (wineprefix)/drive_c/users/(username)/Local Settings/Application Data/CCP/EVE/. If you reinstall the launcher, point it at your separated shared cache folder, and keep the same wineprefix, (or back up that app data folder too) you shouldn’t loose much.
The problem seems to persist for me. Can’t get it working with any tinkering of the options. I’m using the Lutris wine version, and setting it to system wine (6.0) fails due to lack of ESYNC support. Doesn’t launch at all without it. While I can install a new version and that works, as soon as the launcher update is applied the problem returns. Ignoring launcher updates is the only option unless there is some other adjustment that can be made. Looks like I’ll be spending some hours on this…
EDIT: Can confirm a successful launch using lutris wine version 5.7-11
