Vanilla - Linux Success

[Ramius]

Hi everyone, first time poster here. I just wanted to report in success on Linux running EQ, MacroQuest, and EQBC under Wine. This post isn't really a step-by-step tutorial, but I did want to post a few of the things I ran into and how I fixed them.

I know my way around the Linux command line but I'm an amateur with MQ. So, if I've left out some details or overlooked something please feel free to comment.

I started by reading thedank's excellent tutorial, which provided some good ideas and a solid way to install things using PlayOnLinux. Ultimately, however I had a few different needs so I went my own way. Also, now that the EQ client and Macroquest are 64-bit, some of the steps have changed from the original tutorial.

I opted for a command-line solution. I prefer to script everything where possible, as my memory for these types of details doesn't seem to last a week. As such, this post is probably going to appeal to more seasoned Linux users.

To start with, I'm using Arch Linux on an AMD Ryzen 7 5800X with an Nvidia 3080. I will admit this hardware is pretty forgiving and is probably masking several performance issues that I would notice on older kit, so YMMV. Also, this is also not a completely new Arch install, so there may be packages contributing to success that I inadvertently neglect to mention.

I needed to download the Very Vanilla ZIP file as I did not use the RG installer.

For Wine dependencies, I have 'wine-staging' from the Arch repo, as well as the latest 'wine-mono' and 'winetricks' packages installed.

[CODE lang="bash" title="Shell"]
$ pacman -Qe | grep wine
wine-mono 7.1.1-1
wine-staging 7.5-1
winetricks 20220328-1
$
[/CODE]

Also, I use the following nvidia packages. I use the LTS Arch kernel package, so I have the 'nvidia-lts' driver package. If you are not using the LTS kernel, you should have the 'nvidia' package instead.

[CODE lang="bash" title="Shell"]
$ pacman -Qe | grep nvidia
lib32-nvidia-utils 510.54-1
nvidia-container-toolkit 1.9.0-1
nvidia-lts 1:510.54-12
nvidia-prime 1.0-4
nvidia-settings 510.54-2
$
[/CODE]

When setting up a Wine prefix, I only had to use three winetricks packages to make the game work: 'corefonts', 'd3dx9', and 'd3dcompiler_43'. Adding a fourth, 'dxvk', can improve performance with the right hardware. The following command will create a new Wine prefix, and install these packages into it:

[CODE lang="bash" title="Shell"]
$ env WINEPREFIX=/opt/wine/mqeq winetricks corefonts d3dx9 d3dcompiler_43 dxvk
[/CODE]

This command will set up /opt/wine/mqeq as the Wine prefix and do the installation.

Next, just copy in the EQ directory:

[CODE lang="bash" title="Shell"]
$ cp /opt/games/everquest /opt/wine/mqeq/drive_c/eq
[/CODE]

This will copy your everquest directory to C:\eq inside of the Wine prefix. You can also run the installer here instead, just make sure to cancel it once it starts to install DirectX. To run the installer use: env WINEPREFIX=/opt/wine/mqeq wine ~/Downloads/EQ_Setup.exe using the correct location and filename for the downloaded installer.

Now, unzip the download Very Vanilla Macroquest into C:\mq:

[CODE lang="bash" title="Shell"]
$ unzip ~/Downloads/RedGuides_VeryVanilla.zip -d /opt/wine/mqeq/drive_c/mq
[/CODE]

Viola, everything is in place to run EQ with MQ on Wine.

Run MQ with this command:

[CODE lang="bash" title="Shell"]
$ env WINEPREFIX=/opt/wine/mqeq wine /opt/wine/mqeq/drive_c/mq/MacroQuest.exe
[/CODE]

and then run the Everquest launcher with this command:

[CODE lang="bash" title="Shell"]
$ env WINEPREFIX=/opt/wine/mqeq wine /opt/wine/mqeq/drive_c/mq/LaunchPad.exe --disable-gpu
[/CODE]


I found that --disable-gpu was necessary to properly run the launcher. If you want to run eqgame.exe directly, do not use this flag.


NOTE: There are a couple of extra things that need to be done before this will run well:

1. If wine complains about esync, you may have to set the environment variable WINEESYNC=1. I do this in my .bashrc.

2. There are a couple of issues with the default MacroQuest.ini file that cause problems under Wine. I have a saved ini file that I copy into the mq/config directory after unzipping the VV files, but if you don't have one just run MQ then run EQ and let it crash.

• You may see some registry errors on launch. These can be resolved by putting the line DisableAppCompatCheck=true in the [MacroQuest] section of the MacroQuest.ini file.
• I also got immediate crashes when launching EQ under MQ2 the first time. Thanks to a post by njk70, I found out this was due to Dannet not running correctly under Wine. I had to make sure MQ2dannet=0 was set under the [Plugins] section of MacroQuest.ini. I don't have a solution for this yet, but EQBCS runs just fine under Wine. Launch it with: env WINEPREFIX=/opt/wine/mqeq wine EQBCS.exe from the mq directory in the Wine prefix.

I hope this helps. As I mentioned, this post is not intended to be a replacement for any existing guide, it is merely my field notes from getting things to work on my particular configuration. My configuration is actually much more complicated than what I've shown here (I am using the bspwm window manager and have scripts to manage window placement, launching teams, etc.), but this should help the curious user get started.

One final note: Wine can be a finicky beast. If you need to kill processes that may be left behind for some reason, don't kill the wineserver process. Instead, use env WINEPREFIX=/opt/wine/mqeq wineserver -k to clean up.

I find Linux fun for the same reason I find MQ fun: The amount of control I get with Linux over my equivalent Windows installation made all of this worth it for me. Much like with many other things in life, often the journey can be even more fun than the destination!

EDIT: Added dxvk for performance.

 

[Sic]

Nice!

 

[Ramius]

I forgot about the nav meshes!

[CODE lang="bash" title="Shell"]
curl -O --output-dir ~/Downloads https://mqmesh.com/resources/zips/MQ2Nav_meshes.zip
cd /opt/wine/mqeq/drive_c/mq/resources/MQ2Nav
unzip ~/Downloads/MQ2Nav_meshes.zip
[/CODE]

 

[craggyisland]

Followed your instructions just modified for Pop!_OS which is based on Ubuntu.

FIRST purged all wine installs. Followed https://www.addictivetips.com/ubuntu-linux-tips/how-to-purge-wine-from-linux/ . Then I also went into Synaptic Package Manager and searched wine made sure everything was gone.

Went to https://wiki.winehq.org/Ubuntu and followed the directions to install the "Staging branch".

Adding Nav Meshes I had to do the following as the default MQ installation does not have that directory to cd into

curl -O --output-dir ~/Downloads https://mqmesh.com/resources/zips/MQ2Nav_meshes.zip
mkdir /opt/wine/mqeq/drive_c/mq/resources/MQ2Nav
cd /opt/wine/mqeq/drive_c/mq/resources/MQ2Nav
unzip ~/Downloads/MQ2Nav_meshes.zip

Your post says to "run the Everquest launcher with this command:" This part you have a typo. Should be this instead.

env WINEPREFIX=/opt/wine/mqeq wine /opt/wine/mqeq/drive_c/eq/LaunchPad.exe --disable-gpu

Your post got me running EQ and MQ smoothly on PoP!_OS 21.10 which is based on Ubuntu 21.10. Also my video card is a Radeon RX-5700, and not sure what special drivers I have installed everything just worked. I tried to also setup the RedGuides Launcher and ran into some problems. It installed into the WINEPREFIX you had me setup and after setup even launched. Had problems with Login not working as it did not auto open the web page in a browser. I was able to copy the link from terminal and get Login box to go away. Then it froze and I quit out of it. Relaunching it did not work and trying to Repair the install did not work. Now I just cannot get it to install. If I figure this part out I will update this post.

 

[Sic]

nice craggy, keep posting! this is good info

 

[Ramius]

I fixed the typo, sorry about that! Thanks for pointing it out.

I haven't tried running the RedGuides launcher as I wanted to keep things as simple as possible when it comes to Wine. If you go through a reinstall, next time just copy/zip your wine prefix directory to make things easier in the future. I like to run a separate prefix for each instance I have running, so I have a set of scripts that I am working on to set up a new prefix, setting up MQ2AutoLogin, etc. I spend more time futzing with getting things set up on Linux than I do playing the game!

Speaking of keeping things simple, I don't really like running EQBCS in Wine, so I grabbed the EQBCS source and built it for Linux. It took a little work to get it working, and I may have gone overboard working on the source code cleaning things up. Let me know if you want to test it.

 

[njk70]

FYI if you set

export WINEDLLOVERRIDES=libglesv2=d

You can run launcher fine. I set that regardless of running launcher or eqgame.

 

[Sic]

FYI if you set

export WINEDLLOVERRIDES=libglesv2=d

You can run launcher fine. I set that regardless of running launcher or eqgame.

wine ed loves rides?! as a linux noob that took me a couple reads to figure that line out lol

 

[njk70]

I also run "winetricks dxvk" in my EQ wineprefix. This worked well for my lowish end Intel UHD integrated graphics but might vary depending on your GPU. I don't remember all the issues I had, but something didn't work right if I didn't use dxvk.

 

[Ramius]

FYI if you set

export WINEDLLOVERRIDES=libglesv2=d

You can run launcher fine. I set that regardless of running launcher or eqgame.

I was pretty excited to try this, but unfortunately I got a segfault when I did. I'll have to look into what this does and see if I can trace what is happening.

 

[njk70]

try the "winetricks dxvk" install. it might have been required to get the DLL overrides to also work, I don't recall. It could be video card/driver specific too. I iterated through a million things it seems to get things just right (for me anyway). Had to start over a lot too as installs would get funky with all the things I was trying. Biggest problem for me is lack of dannet (no mq2grind).

 

[Ramius]

Yeah, I run that on all my prefixes. I wish there was a native Dannet for Linux!

 

[njk70]

I have one idea for it to work but it would need a custom build of dannet and I don't have the time to setup a build environment for it. It probably would not work, but it had a chance. Hopefully a future version of wine will fix the issue.

 

[Knightly]

I grabbed the EQBCS source and built it for Linux. It took a little work to get it working, and I may have gone overboard working on the source code cleaning things up.

Submit an MR and we’ll incorporate those changes.

For dannet, it’s more about finding why it hangs under wine. I’m not sure explicitly how to do this in wine but outside of wine I’d attach a debugger and look at the call stack to see where it is hung. My guess is it’s in the way that wine handles windows sockets.

 

[njk70]

Submit an MR and we’ll incorporate those changes.

For dannet, it’s more about finding why it hangs under wine. I’m not sure explicitly how to do this in wine but outside of wine I’d attach a debugger and look at the call stack to see where it is hung. My guess is it’s in the way that wine handles windows sockets.

For dannet its something you probably wouldn't want to change for true windows. But there is a slim chance it would work for Wine. There is option -DPOLLER when building zeromq, setting that to select instead of epoll might work better under Wine. It also might completely not work at all. The failure under wine is in an epoll call in zeromq (and is socket related) which led me to this guess. And its just a wild guess as I know almost nothing about this in Windows (I'm mostly a linux dev, windows dev experience is like a decade+ old)

 

[Sum1]

@Knightly Would running this over Linux be a way to obfuscate some of what you all are guessing are detection mechanisms for the suspensions? Or is this just a fun project for super nerds?

 

[brainiac]

no

 

[njk70]

Honestly it has more down sides than positives, other than the fact the only computer I have available is Linux.

 

[Knightly]

For dannet its something you probably wouldn't want to change for true windows. But there is a slim chance it would work for Wine. There is option -DPOLLER when building zeromq, setting that to select instead of epoll might work better under Wine. It also might completely not work at all. The failure under wine is in an epoll call in zeromq (and is socket related) which led me to this guess. And its just a wild guess as I know almost nothing about this in Windows (I'm mostly a linux dev, windows dev experience is like a decade+ old)

Hey, that was pretty good on me for being a random guess and it actually being sockets. The epoll item is actually something we add, it would be fairly easy to test that by opening contrib/vcpkg/ports/zeromq/portfile.cmake and making the change in vcpkg_cmake_configure( if you wanted to test out some other options.

 

[njk70]

I would be thrilled to try anything if you can build it.

 

[Ramius]

For dannet its something you probably wouldn't want to change for true windows. But there is a slim chance it would work for Wine. There is option -DPOLLER when building zeromq, setting that to select instead of epoll might work better under Wine. It also might completely not work at all. The failure under wine is in an epoll call in zeromq (and is socket related) which led me to this guess. And its just a wild guess as I know almost nothing about this in Windows (I'm mostly a linux dev, windows dev experience is like a decade+ old)

I did try to get Dannet working under Wine a few weeks ago and actually did run it under a debugger and you are exactly right, it is failing on epoll. I did try rebuilding it with every other available polling option and was unsuccessful. I gave up because I didn't really need Dannet and EQBCS was working just fine. But I would be willing to help if there is some momentum to get this working. I'm not really much of a dev and don't know squat about zeromq but in my favor I am easily nerd-sniped by things like this which tends to make up for my shortcomings!

 

[Ramius]

Submit an MR and we’ll incorporate those changes.

For dannet, it’s more about finding why it hangs under wine. I’m not sure explicitly how to do this in wine but outside of wine I’d attach a debugger and look at the call stack to see where it is hung. My guess is it’s in the way that wine handles windows sockets.

I changed quite a bit... I split out the modules into separate files, converted to CMake, introduced C++20-isms, and started to remove raw buffer access when it wasn't really needed. So I am hesitant to drop that kind of a pull request since whomever is maintaining the code wouldn't recognize it (is that you?).

I guess it was more of a practice project for coming back up to speed on modern C++ once I fixed the few things keeping it from working on my machine.

I did confirm that it still builds on Windows under Visual Studio, though.

I think I did save a branch before I went ham on the file structure. So maybe I can pull that out and submit it as a pull request once I get some time.

 

[njk70]

I did try to get Dannet working under Wine a few weeks ago and actually did run it under a debugger and you are exactly right, it is failing on epoll. I did try rebuilding it with every other available polling option and was unsuccessful. I gave up because I didn't really need Dannet and EQBCS was working just fine. But I would be willing to help if there is some momentum to get this working. I'm not really much of a dev and don't know squat about zeromq but in my favor I am easily nerd-sniped by things like this which tends to make up for my shortcomings!

When you tried other pollers where did it fail then? The other clue I had was something about using undocumented winsock apis, but was my impression this was just for epoll. I think getting dannet to work under wine is pretty important, its being used more and more to coordinate actions between characters in ways eqbc can not do and I think its use will just be increasing over time. But I am shooting blind here. The best bet might be to create a simple standalone application using zeromq that can recreate the failure and submitting it to wine devs to see if they can fix wine.

 

[Knightly]

I changed quite a bit... I split out the modules into separate files, converted to CMake, introduced C++20-isms, and started to remove raw buffer access when it wasn't really needed. So I am hesitant to drop that kind of a pull request since whomever is maintaining the code wouldn't recognize it (is that you?).

CMake and C++ 20 would be deal breakers, not because I’m not familiar with them but because we want to keep things homogeneous.

CMake is all or nothing when it comes to msbuild so the vcxproj would be the preferred method so that the solution file can include all items in a single view. It’s fine to have both, though, as long as both are updated to match (but it is a pain maintaining both unless you’re just generating one from the other).

C++ 20 is less of an issue in that regard, because you can have projects on different versions within the same SLN, but the preference is to keep the same standard across the board to eliminate differences in behavior (especially while we’re using things that have been deprecated). Otherwise you run into situations where the same code doesn’t work in two places.

I touched it last, but I’m not the maintainer. Just interested in making sure that enhancements and updates make their way back into the core code.

 

[Ramius]

Interestingly, I just ran across a Go implementation of EQBCS on Github complete with a Dockerfile for easy building and running on Linux. I haven't checked it out yet, but it claims to remove the 55 connection limit and does the things that I added to my own C++ fork, including timestamped log entries and colorized logging.

I'm not sure if it is up-to-date with the current client that ships with Macroquest, but I'll play with it when I get some time and report back.

 

[Knightly]

The current source doesn’t have a 55 connection limit.