Suggestion: LUTRIS/Standlalone support

[outsidefactor]

I am looking to run multiple clients side-by-side: it's easy to do on Windows and was hoping to do the same now I run Linux. Steam pretty much rules this out, but stand-alone client installs on Lutris would work a treat (and I can cross-link the Products directory to save on space).

Is there any plan to extend the Mini Launcher to support stand alone installs?

[rfvgyhn]

When you say stand-alone client installs, are you referring to regular Frontier accounts (not Steam or Epic)? If so, I can attempt to implement it, but I'd need someone else to test/debug as I only have Steam and Epic accounts. It's also unlikely I'd go beyond implementing account auth (e.g. downloading game updates).

[outsidefactor]

Yes, I mean Frontier only accounts.

I would love to help. I have both Steam and non-steam accounts.

I already have a working Steam/Proton install. I have a full Lutris prefix ready to go. There is a problem with the current official Launcher and the Lutris runner, so this would be fantastic and solve my problem.

For my specific use I have no need to download game updates. I will use Steam to get the latest Products folder and then sym-link it into the Lutris wine prefix.

[rfvgyhn]

I haven't forgotten about this. I've just been distracted by the game Hades. :) I have a partial implementation but not enough to test yet.

[outsidefactor]

Hey, that's fine! I am thrilled that you've even made a start on this!

On Sun, 10 Jan 2021, 6:22 pm Chris, [email protected] wrote:

I haven't forgotten about this. I've just been distracted by the game Hades. :) I have a partial implementation but not enough to test yet.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Rfvgyhn/min-ed-launcher/issues/6#issuecomment-757430631, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7LC5PKF3UBWUV6IR5H33SZFIRPANCNFSM4VQQB4WQ .

[outsidefactor]

Hi!

Just letting you know I am still interested in helping test this :) I also have a pool of Elite players with stand-alone FDev Commanders who are interested in this, so you won't just have to rely on my feedback alone.

[rfvgyhn]

I just pushed my initial stab at it to the frontier-auth branch. You can try it by downloading the CI build.

You'll need to update your launch options to include /frontier some-profile-name. Just use letters and numbers for the profile name. If you have multiple frontier accounts, use a different profile name for each of them. After successfully logging in, there will be a .cred file created in either %LOCALAPPDATA%\min-ed-launcher\ or $XDG_CONFIG_DIR/min-ed-launcher/ (depending on OS). This file stores your username, password and machine token. On windows, the password and machine token are encrypted via DPAPI. On linux, no encryption happens but the file permissions are set to 600. If you login once and then decide you want to login again (refresh machine token), you can delete the appropriate .cred file.

I was only able to test the initial authentication which is username + pass and the auth code that FDev sends via email. When you encounter an error, please post the contents of logs/min-ed-launcher.log.

I have run into an issue when trying to paste my password when prompted after launching from steam. Auth just fails. I haven't looked into that yet. If pasting your password doesn't work, try manually typing it in.

A few things that can help me out:

• Paste your password when prompted to see if it works
• If you have a vanilla frontier installation, please try using that without launching via steam or any symlinks You can try this by running it from the command line. After placing MinEdLauncher.exe in the same folder that has EDLaunch.exe, open powershell and run .\MinEdLauncher.exe /frontier profile-name /autorun /edh. Ideally, it will automatically find the correct install location and proceed to the auth steps. If it can't find the install dir, specify it in your %LOCALAPPDATA%\min-ed-launcher\settings.json file (e.g. `"gameLocation": "C:\path\of\folder\that\contains-EDLaunch.exe".
• Launch from steam after updating launch options to include /frontier profile-name

[rfvgyhn]

For anyone that has tried this out, feedback on any issues would be great. I'd like to get this pushed to the main branch for a proper release.

[outsidefactor]

I am very sorry about my tardy response. Work has been insane and at the same time I've have a hell of a job getting Elite installed properly under Lutris after recent WINE changes.

Today I got a response from someone on the Lutris that gives me hope of a successful reinstall. I've force Lutris to use a different WINE version and the Install is running again. The Dot.NET 4.7.2 install is currently running, so I will let you know how I am go.

[rfvgyhn]

No worries and no rush. Just wanted to ask that if someone does try it out, they leave feedback on the issues they experienced.

Also, this app doesn't require .net to be installed so once this feature gets worked out, hopefully, the wine setup will become a bit simpler.

[outsidefactor]

I have solved the installation problem, so I have a WINE prefix ready to go with the ED Launcher installed in it, but I am now in a chicken-and-the-egg paradox: the ED Launcher starts cropped, and crashes when you click where the Install button should be. I suspect the issue is that it's trying and failing to launch a browser to authenticate for the first time, but I am no expert.

So I can't complete the install to test your launcher, which I want to use to replace the launcher that's crashing.

[rfvgyhn]

Are you able to try it with a Steam/Proton install?

Ideally, I'd have someone try to run it with and without Steam, but if it's too broken to get the game installed, we'll just have to do without. Perhaps someone with a non-Steam Windows install will be able to test it in the future.

[outsidefactor]

Are you able to try it with a Steam/Proton install?

Ideally, I'd have someone try to run it with and without Steam, but if it's too broken to get the game installed, we'll just have to do without. Perhaps someone with a non-Steam Windows install will be able to test it in the future.

I think I am close. I've managed to get the EDLauncher running with a hacked version of mono in place of Dot Net from https://github.com/redmcg/wine-mono/releases

At this stage I have the standalone launcher installed and started in a WINE prefix. It's currently downloading ED Horizons!

Here is the process I used to get it installed:

1. customise Lutris install script for standalone install of ED to remove Dot Net altogether from the install process
2. Run install script and install Launcher
3. Download https://github.com/redmcg/wine-mono/releases/download/wine-mono-5.1.1.2_ED/wine-mono-5.1.1.2_ED-x86.msi
4. Use winetricks to install wine-mono-5.1.1.2_ED-x86.msi into the created prefix
5. Start the launcher
6. Log In. Will lock up trying to create a hardware report
7. Kill the EDLaunch.exe and hardware reporting tool (you can use the Lutris "Kill all WINE processes" option
8. Start the Launcher again. Will lock up again
9. Kill the EDLaunch.exe instance
10. Start the Launcher again and complete the install of ED

OK, install is done!

About to try your launcher for the 1st time!

[outsidefactor]

OK, so I downloaded https://github.com/Rfvgyhn/min-ed-launcher/suites/2007344338/artifacts/40146420

And I extracted the two files inside to the EDLaunch folder in my working prefix for my alt account.

I edit the Lutris entry that was starting the prefix fine to use the MinEdLauncher executable

I add these arguments "/frontier cmdrname /autorun /edh"

and here's a trace from Lutris trying to start it: DEBUG 2021-03-18 16:19:18,886 [command.start:132]:/usr/share/lutris/bin/lutris-wrapper Elite - Dup1 0 0 /home/user/.local/share/lutris/runners/wine/lutris-5.7-11-x86_64/bin/wine /mnt/steam01/Lutris/Games/elite-dup1/drive_c/Program Files (x86)/Frontier/EDLaunch/MinEdLauncher /frontier cmdrname /autorun /edh lutris-wrapper: Elite - Dup1 Running /home/user/.local/share/lutris/runners/wine/lutris-5.7-11-x86_64/bin/wine /mnt/steam01/Lutris/Games/elite-dup1/drive_c/Program Files (x86)/Frontier/EDLaunch/MinEdLauncher /frontier strife /autorun /edh Initial process has started with pid 286149 Start monitoring process. fsync: up and running. Monitored process exited. Initial process has exited (return code: 12032) All monitored processes have exited. Exit with returncode 12032

OK, so that didn't work.

So I tried the Windows exe version and got: DEBUG 2021-03-18 16:21:53,981 [command.start:132]:/usr/share/lutris/bin/lutris-wrapper Elite - dup1 0 0 /home/user/.local/share/lutris/runners/wine/lutris-5.7-11-x86_64/bin/wine /mnt/steam01/Lutris/Games/elite-dup1/drive_c/Program Files (x86)/Frontier/EDLaunch/MinEdLauncher.exe /frontier dup1 /autorun /edh lutris-wrapper: Elite - dup1 Running /home/user/.local/share/lutris/runners/wine/lutris-5.7-11-x86_64/bin/wine /mnt/steam01/Lutris/Games/elite-dup1/drive_c/Program Files (x86)/Frontier/EDLaunch/MinEdLauncher.exe /frontier dup1 /autorun /edh Initial process has started with pid 286815 Start monitoring process. fsync: up and running.

(lutris:285865): Gtk-WARNING **: 16:21:54.471: Failed to fetch network locations: Timeout was reached [16:21:56 ERR] Failed to find Elite Dangerous install directory Monitored process exited. Initial process has exited (return code: 256) All monitored processes have exited. Exit with returncode 256

Please ignore the steam in the path: that's just the drive name. This is a freshly installed WINE prefix.

[rfvgyhn]

I'm not very familiar with lutris, but it looks like, in your first attempt, it is trying to launch MinEdLauncher via wine. This will fail since it's a linux binary. Are you able to launch it without running via wine but also have the WINEPREFIX env var set?

Second attempt is a bug from not being able to find the install dir. You can manually specify this by setting "gameLocation": "/mnt/steam01/Lutris/Games/elite-dup1/drive_c/Program Files (x86)/Frontier/EDLaunch/", in XDG_CONFIG_DIR/min-ed-launcher/settings.json until I fix it.

[rfvgyhn]

I've commited a fix for not being able to find the install dir, so download the latest build when you try to proceed.

I downloaded lutris and have attempted to run the min launcher with it. From what I gather, you won't be able to run the native launcher. You'll have to run the windows version via wine unless there's some sort of lutris mechanism to run the linux runner, have a wine prefix setup and then pass the WINE and WINEPREFIX env vars to the linux runner.

In order to use the launcher via lutris, you'll need to set the following game options:

• Executable = wineprefix/drive_c/windows/system32/start.exe
• Arguments = MinEdLauncher.exe /frontier cmdrName /autorun /edh
• Working directory = wineprefix/drive_c/Program Files (x86)/Frontier/EDLaunch

It looks like ANSI color codes in this particular environment don't work, so you'll see some garbage in the output. That can be ignored.

[kerberizer]

My use case is a bit different: I have both a Steam and a Frontier-bought (standalone) copy of the game, not just a standalone one. I hope my experience might still be helpful, as that was (and likely still is) the recommended and perhaps only possible way of getting a second commander (in my case, it was also a way to support ED's development, as I got my first copy at a hefty discount).

I used to run the standalone copy with Lutris, but 1) it was a waste of disk space in my case, and 2) it meant constantly fighting with the finicky ED launcher in not one, but two different environments (Steam's Proton & Lutris' own Wine). Trying to run the standalone copy with Proton, however, wasn't that much easier, though it might've been more my fault at the time.

TL;DR: With MinEdLauncher running both the Steam and the standalone copy from a single game installation is pure joy!

The Steam copy is run the way that the MinEdLauncher documentation prescribes it—nothing unusual here.

For the Frontier-bought (standalone) copy with another commander I use (naturally) a separate prefix:

env STEAM_COMPAT_DATA_PATH="${HOME}/my_super_cool_standalone_ED_prefix" \
"${HOME}/.local/share/Steam/steamapps/common/Elite Dangerous/MinEdLauncher" \
"${HOME}/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point" \
--verb=waitforexitandrun \
-- \
"${HOME}/.local/share/Steam/steamapps/common/Proton 5.13/proton" \
waitforexitandrun \
"${HOME}/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe" \
/Steam /novr /autoquit /frontier my_super_cool_profile_name /EDH

A few caveats:

• To create the new prefix, I just run any command, e.g. winecfg or wineboot, with Proton. Maybe there's a better way.
• In fact, I'm not yet entirely sure if it wouldn't be better to copy the existing prefix of the Steam copy and only delete the ED's commander-specific configuration files. While I'm using the exact same command that Steam is using to run ED (including the pressure-vessel container/soldier), I've still to determine if some of these notes are not relevant. However, they seem to refer to running the Proton's wine binary directly, and, more importantly, ED seems to run completely fine with the above command.

TL;DR2: At least in my use case, the frontier-auth CI build runs perfectly. Many thanks once again for the wonderful job!

[rfvgyhn]

Thanks for the feedback. I'm a little confused on why you are running a separate prefix for the secondary commander. Does using proton's prefix not work when trying to use both commanders? As far as I know, local config files are for non-commander specific things (i.e. graphics settings). Ideally, min-ed-launcher only needs a single install/prefix and should work with any number of commanders.

[kerberizer]

Thanks for the feedback. I'm a little confused on why you are running a separate prefix for the secondary commander. Does using proton's prefix not work when trying to use both commanders? As far as I know, local config files are for non-commander specific things (i.e. graphics settings). Ideally, min-ed-launcher only needs a single install/prefix and should work with any number of commanders.

Good question! I hadn't really thought it out that much, but probably two things pushed me in the direction of a separate prefix:

• the inertia from the time I was doing tests with Lutris;
• the journal files.

Obviously, the first one is irrelevant. As for the journal files, I remember how they got a bit messed up when I recreated my first commander. I haven't tested it, but I would expect that when ED is run with the second commander, it would simply add more journal files to the same directory. I think ED writes a separate file for each game session, so running two separate sessions with different commanders should result in separate journal files—not the single journal with two commanders when I recreated the first commander in the same session—and so this shouldn't be a problem on its own.

Now, I'm not sure if that wouldn't still confuse EDMarketConnector. Perhaps it does check the commander's name in the journal file, before syncing the info to INARA, etc., but I haven't looked at its code (and I haven't used it—nor played ED, for that matter—for quite many months, so I also don't have much recollection of how it worked, what were its options, etc.)

To sum it up, I think you're almost certainly correct that it should work with a single common prefix (what happens on Windows, anyway). I guess that to me remains mostly the question if the journal files would specifically need to be taken care of.

[rfvgyhn]

Both the frontier auth code and game updates code have been merged into master. I think all that remains for Lutris support is to check with the Lutris community to see if there's a runner that can create a wine prefix but launch a native binary with the proper env vars set. If there isn't, I'll just have to update the readme with the steps I outlined above.