Looks for me like a missing driver for your graphics card or missing support libraries (opengl and vulkan support). For AMD hardware you need mesa installed for opengl afaik. Furthermore try to launch your Desktop Environment in Xorg Mode don’t use Wayland if possible.
P.S. For installation and configuring your graphics card have a look at AMDGPU - ArchWiki can be used for Manjaro too.
After the update i have setup a new installation of the beta 1734683 and cleaned up the cache directories from QtWebEngineProcess in my $HOME as before. The crashes are still there but after a refresh it works as intended. The launcher made a clean exit now, no more zombies and i read nothing about elg on console or in the log. 
In the ps tree are exefile.exe a child process from the evelauncher process so nothing unusual here i think. If you kill or end the parent process then should the child processes be terminated too, so all works so far as expected.
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.
Thanks!
I did some random install of stuff and managed to get it working. There were other issues stopping me downloading the client again, but apparently fixed and running on my nice, shiny amd!!
That’s behavour should not be “init” related. I run OpenRC instead of SystemD and seam to have the same behavour.
I always run EVE from the terminal. I did notice that the last version of the launcher, when I close it while EVE is running, it “quit” but I don’t get the terminal back until I close the EVE.
But I know some bases console stuff, for example, if you add a & after a command, it go kind of in the background and free the console. While using a & on a graphic application will run the application normally but leave the console usable instead of locking it.
So I think that for your solution you simply have to add “&” to the end of commands.
WINEPREFIX="blabla" wine C:\tq\bin64\exefile.exe /noconsole /server:tranquility /ssoToken=00000000000000000000 /settingsprofile=Default /language=en /remotefilecachefolder=Z:/home/yournotgoingtohavethatone/SharedCache//ResFiles &
Maybe someone else have a better solution for that.
I did test and it work, adding the & orphan the process and it become child of init.
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?
my “custom wine” is a sh script that run wine and add everything your launcher add as parameters…
It allow me to change environment variables. Use to be useful to debug.
I just added the & at the end of the wine line in my script.
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 ?
No, it did not prevent the launcher process to end as I remember, I take a look tonight.
In the meantime, did you ran your test in debug mode from your IDE or something or you ran it without debug (like compile release and execute it)? I did lookup about qprocess::startDetatched and some peoples have the same exact complain and it seam that “running with debug” do that (preventing the main process to close until all process started with qprocess::startDetatched are also closed).
Nah, standard release builds. Very weird problem.
I do get that error : kde-open5: /home/xxxxxxxx/evelauncher/./libQt5Core.so.5: version `Qt_5.14’ not found (required by /usr/lib64/libKF5GuiAddons.so.5) whenn trying “account management” or “create account” (Need to create extra “steam” enabled account and i’m supposed to do that from the launcher, I think)
Small problem in evelauncher.sh:
joe@joe:/media/joe/EvE Online/evelauncher$ ./evelauncher.sh
./evelauncher.sh: 12: export: Online/evelauncher/.: bad variable name
It doesn’t like path with spaces.
Some variables have to be quoted.
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?
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.
Thanks for the update. Had to delete libxcd*.* to make it work (again).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.