Also, I have just released beta 1747682, which contains a fix for some problems unpacking bulk downloads. These were resulting on clients relying on download-on-demand in some cases where they should have been able to use pre-downloaded assets.

That’s interesting, I wonder if something like that is causing @Ravow’s qt problem as well. The QTDir directive is also unquoted.

@Ravow is there a space in the path to your evelauncher.sh file?

Nah, standard release builds. Very weird problem.

I did some testing last night, simply adding the ampersand doesn’t work. I presume because QT isn’t really using a shell to do the launching.

Using qprocess::startDetatched kinda works, however the exefile (game client) blocks shutdown of the launcher. Similar symptoms to the thread problem, when the launcher is closed the window disappears, but the actual process remains open until the exefile process also quits. This seems to mean that qprocess::startDetatched doesn’t actually start the process fully…detatched.

Do you see the same thing with the ampersand trick on your system ?

This thread is an experience.

The official CCP position on linux: We don’t support linux.

What does that mean: It means that officially, zero thought goes into how things support linux. Hypothetically speaking, if an anti-cheat system started being triggered by linux, that anticheat system would not be adjusted on company time.

Unofficially: I also stripped windows out of my personal life about 5 years ago, and I want to continue playing eve. So under this hypothetical situation I would probably spend some personal time attempting to fix such an issue, but any fix would have to work without undermining robust anti-cheat on our supported platforms, which are mac and windows. So you’ve got an insider, but I have to respect that linux is not supported and be careful not to cause issues on the supported platforms.

Silver lining: linux maintenance has required probably less than 20 hours of my time over the last two or so years, because we use wine on mac as well, so the official time spent...

Oh yeah, the & thing is dead obvious in retrospect, should be easy to add.

How did you do the testing though? I thought the launch commands were executed from within the c++ qt code?

If you kill or end the parent process then should the child processes be terminated too, so all works so far as expected.

I’m not sure about that actually. I did some investigation, windows picks up the orphaned processes and lets them keep running. The mac tests weren’t super clear because the mac environment wasn’t totally clean, but it looks like mac also rescues the orphans.

Some research suggests that linux also should adopt the processes, by reparenting them directly under the init process. Maybe this is another systemd thing that I don’t know about?

In any case, could be tricky to solve, given that we’re in OS-dependent behavior here. If anyone knows stuff about how processes are supposed to be adopted or killed based on what happens to the parent process, I’d appreciate any extra info.

There are many potential causes, in your case you’ll probably have to wait for the underlying issue to get fixed.

Hrm, intriguing behavior.

I do get them placed under the same process tree as you. When I close the launcher, the existance of the eve processes seems to block the launcher process from going away.

However, in my case, it seems that closing the launcher causes the eve clients to lock up a few seconds later. I guess your distro is more aggressive in murdering processes that don’t respond to a kill. It definitely didn’t do this before, but rolling back to current release causes the same behavior. Any idea when it started?

I’ve just pushed beta 1734683, containing a partial fix for the zombie process issue.

The underlying issue is that there is a background thread that can fail to initialize properly, and if it does fail to initialize it blocks termination of the entire process. That will need to be fixed by the launcher team, and affects all platforms.

However, the elg warning people were seeing was a symptom of a problem which was causing that thread to fail to initialize 100% of the time, and I have fixed that issue. You’ll get one last zombie process when the update to 1734683 happens, as the version it’s upgrading from fails to close properly. After that, for most people the zombie process issue should go away.

I also am seeing the zombie process on close issue. I’ll poke people about it.

I can’t get a repro on the “closing the launcher kills the clients” issue. Any chance Gentoo is doing something super-weird involving placing the eve instances under the process tree of the launcher, instead of launching them as independent processes?

I’ve just pushed beta 1732478, containing a fix for the minimise-on-close-issue

Hrm, further investigation suggests this is in some fashion a known problem with flicking between QT versions:

https://bugreports.qt.io/browse/QTBUG-82105

I haven’t looked any further into it, but my guess is that this might just be happening because in this update you moved from qt 5.11 to 5.12. Given that the launcher isn’t exiting properly, the two running versions may have been fighting with each other.

Based on what I’m reading in that bug report, I would guess that provided you stay on the current beta and do not downgrade, you should not see the issue again. Let me know if it does keep showing up

The E0523 I’m not particularly worried about. It puts a lot of noise on the console, but I’m not sure it has any ill effects. I’m not sure what that server is, but I’ll check in with the launcher team about it. It’s probably a content server for some part of the UI.

I’m more worried about the crash. Does that happen under any specific circumstances?

Looks like the reason mine forgot my accounts might be because the launcher isn’t actually closing properly, so after the patch I had multiple launchers open. Carefully killing all launchers after patch and then relaunching a single instance may restore the account list. Seen on Xubuntu 18.04.

If other people see this issue, please let me know.

Hey all, the linux launcher release is now quite far behind current windows release, so I’m embarking on a little project to bring it forwards in time somewhat.

The first step of this is to update the linux beta to bleeding edge, so I have released beta 1732117. I’d like to ask people to give this a try and let me know if they encounter issues. Don’t forget to include your distro and version!

Notable changes in 1732117:

• QT version updated to 5.12.0
• Login flow now contained entirely within main window
• fancy splash screen
• Like 9 months of other patches or something IDK there’s a lot of stuff in there

Known issues:

• Steam and facebook login buttons do not work

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!