• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver
MultiBoxing EverQuest on Linux with MQ2

Guide - MultiBoxing EverQuest on Linux with MQ2 (1 Viewer)

Overview Discussion
thedank

thedank

Creator
Joined
Dec 22, 2019
RedCents
1,263¢
thedank submitted a new resource:

MultiBoxing EverQuest on Linux with MQ2 - A in depth guide on how to multibox on Linux using MQ2

Resurecting this old thread at the request of @Redbot

I have been running EverQuest under wine on Gentoo Linux for close to 20 years now, I don't do Windows! Here is the method I have used that works pretty well for the most part.

1. Install PlayOnLinux from your distro's repository. This is a very handy tool for managing wine versions on your system, as well as easily installing software in separate bottles.

2. Make sure your system supports 32 bit software, ie. its...
Click to expand...

Read more about this resource...
 
I am excited about this and will try it out. This game with MQ2 and upcoming CyberPunk are the only two games that I am interested in playing for quite a while. I used to daily drive a linux desktop but gaming was difficult on it.

Thanks for the write up.
 
I am glad a few of you found this helpful!

Also if you haven't tried running Steam on Linux lately you should! They have a modified version of wine built into the beta client which they call Proton that practically makes it so ANY game in your steam library will run on Linux easily!
 
Nice... do you run in wine desktops to avoid the problem of mouse capture? When I was doing this, I just ran MQ2 through wine with the same prefix and didn't need a wine desktop setup, but it had issues with mouse capture (I find using wine desktops to be kind of annoying that way, too).

I also had an issue where it would crash pretty consistently after about 2-3 hours, is that gone now as well?
 
@Wink- No I have not tried to run EQ on a Pi. I don't think the graphics would support it well.

@dannuic- I run each instance in its own bottle and emulated desktop to avoid mouse issues and to be able to semlessly move between the game instances without dealing with window focus issues. EQ just runs best in wine with an emulated desktop. Also MQ2 tray icon works better as well this way. I have no issues with crashes and leave some toons running 24/7. I usually leave all 6 instances at character select or playing/trader mode up all the time. The only time they get restarted is typically patch days or if MQ2 happens to crash the instance for some odd reason. Also I run 6 instances of MQ2, one within each wine desktop. I messed around with using one bottle for all 6 instances and one MQ2 instance, but things did not play well with my scripts using that method in terms of how I wanted things to be automatically laid out on the screen. It was much more buggy that way. So 6 instances of game (each with its own desktop in full screen mode) and each with its own MQ2 session running inside the bottle.
 
Last edited:
Also the PC I run all of this on was built in 2010. It can easily run 6 more EQ instances if I wanted too! I typically have the 6 instances runing between two workspaces then also have 2 more workspaces filled with terminals, browsers, discord, evolution, and virtualbox running dev VMs, all while I am running 6 toons!

CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (two CPUs with 8 cores each)
Memory: 48Gb (ECC Server Memory)
GPU: Nvidia Quadro K4000 (Current Driver Version: 440.64)
HDDs: 1 Samsung 850 EVO 500G SSD for Gentoo, 1 Samsung 860 EVO 1T SSD for games, 1 Samsung 860 EVO 1T SSD For virtual machines

SSD drives breath new life into old systems!
 
Last edited:
I guess I was just annoyed by the wine desktop "containerization" interface, so I decided I wanted it to work without. It might also be a problem that doesn't exist anymore, but I don't have a computer to try it on (my only computer is a surface). When I was running this though, I definitely had no problems with MQ2 running outside of a desktop, and could have multiple EQ clients getting hooked by one MQ2 instance (all that mattered was the wine prefix).
 
Yeah if they are all in the same wineprefix then you can use one MQ2 instance, but this did not work well for me and caused many issues with focus since I could not use the emulated desktop to separate each game window. If you run in full screen mode all of the wine desktop stuff is hidden sice there is no window. Once you put the game in "windowed" mode you see the desktop. You just have to mess around and see what works best for your setup.
 
So why Gentoo? Is it a personal preference or is there something special about that distro that makes this all click?
 
@Redbot it can run on a pi, laggy, crappy controls, and you need at least 2 to 3 pi's clustered (guessing) to run it. it requires wine and an x86 emulator and a lot of frustration but it can be done (you may not have hair before you are thru). I have not tried it on a cluster, that may work better. I also only have 2 b versions, the 4 may work better
 
Many_Whelps said:
So why Gentoo? Is it a personal preference or is there something special about that distro that makes this all click?
Click to expand...

I just have been using Gentoo since it became a thing and never looked back. I like the source based distro that can be highly customized and tuned for performance. Other than that I have made this work on debian as well rather easily.
 
The patch today (8/19/2020) bugged the LaunchPad.exe process on wine and you may get a bunch of crash popups when you try to patch the game. If this happens to you here is the fix:

1. Open a terminal

2. cd to the wineprefix location
Code: 
 cd ~/.PlayOnLinux/wineprefix/EverQuest

3. export the prefix
Code: 
export WINEPREFIX=`pwd`

note: those are backticks `

4. Run winetricks to re-install corefonts to the prefix
Code: 
winetricks corefonts

That should get you rollin' again!
 
Updated the main script in guide, added the following OPTIONAL lines to fix issues that occur when starting up things after a Game Client/MQ2 crash/improper shutdown where certian .ini files need to be "refreshed" from the template stored in ~/Downloads/MacroQuest2:

Code: 
# (OPTIONAL) refresh MacroQuest.ini (fixes issue when game client crashes and ini file is borked)
cp /home/thedank/Downloads/MacroQuest2/MacroQuest.ini $EQHOME/MacroQuest2/

# (OPTIONAL) refresh KissAssist_*.ini files (fixes no camphere command bug if toons logged out before /endmac)
sed -i 's/11.005/0/g' $EQHOME/MacroQuest2/Macros/KissAssist_*.ini
 
I updated the guide with more details on how to get the emulator version of MQ2 working under wine.

Notes on EQEmu version:

You can follow this guide to also run EQ on any EQEmu server including P99. You will just need to use the 2.22-staging version of wine for both the Titanium and RoF clients, anything newer will cause issues.

WMI needs to be installed in the wine prefix in order to get the MQ2 tray icon to work correctly and not error out the program. However, if you follow the instructions above using winetricks at the terminal it will not work since it will use the system version of wine which is 64 bit, not the 2.22-staging 32-bit version which the prefix should have been built under. Here is how to install WMI in the 2.22-staging prefix.

1. Export the WINEPREFIX variable setting it to the directory for the RoF2 client


export WINEPREFIX=/home/thedank/.PlayOnLinux/wineprefix/EverQuest_RoF2


2. Temporarily change your PATH in the local terminal so that the 2.22-staging wine binary is found first over the system one


PATH=/home/thedank/.PlayOnLinux/wine/linux-x86/2.22-staging/bin:$PATH


3. Run winetricks and install wmi


winetricks wmi corefonts


4. Go through the wizard and it should be installed. Now you can proceed back to installing MQ2 in the prefix since the supporting wmi api should be there to allow the tray icon to run.
 
A few other things to note:

If your going to manually run MQ2 from the command line then you will need to always export the prefix and set the PATH up so the 2.22-staging binary is at the start in order to launch MQ2 correctly in the prefix. Alternatively you can copy the MQ2 directory into your 'Program Files' directory within the RoF2 prefix and then create a 'Shortcut' for the MacroQuest2.exe binary in the PlayOnLinux launcher. Now when you lauch MQ2 from the PlayOnLinux menu it will launch it in the proper prefix for you.
 
Just a little update. I tried tinkering with updating to the latest version of wine-staging available on my distro (gentoo, wine-staging-5.20.0) and it was not pretty. Stay at 4.21-staging for Live and 2.22-staging for Titanium/RoF2 clients. May as well keep these versions of wine around for the long haul, since it does not look like EQ is able to keep up with the new changes unless someone wants to start filing a ton of bug reports to the wine devs to get these performance issues resolved. I even did the installs in clean wine bottles so that they would not be affected by any crap left over by previous wine upgrades.

Currently wine 5.20 makes things look like a slide show. It is unbearable to even log into the game.

Just giving you guys info from the trenches so you don't have to go through the experiment if you already have a working 4.21 or 2.22 install running.
 
Last edited:
I just got the following older clients working on wine-staging-4.21

Titanium - Tested on Private EQEmu dev/testing server
RoF2 - Tested on Private EQEmu dev/testing server
P99 (v53 latest) - Logged into P99 Blue

All three worked on 4.21 with the following command added before launching with wine:

INI: 
taskset -c 0 wine eqgame.exe patchme

The lag issue that has held us back to 2.21 on the older clients and prevented from moving to 4.21 to roll with live is because the older clients do not support the following eqclient.ini parameter, which is a must to reduce lag on EQ under WINE:

INI: 
CPUAffinity0=-1
CPUAffinity1=-1
CPUAffinity2=-1
CPUAffinity3=-1
CPUAffinity4=-1
CPUAffinity5=-1
CPUAffinity6=-1
CPUAffinity7=-1

You always had to force it with taskset -c <CPUID> prior to the addition of the INI CPUAffinity entry. So it looks like the older clients still need the ol' nudge.

Now this makes the older clients playable with wine-staging-4.21, however there is still a bit of graphics lag from my initial testing compared to when running under 2.21. More tweaking and testing is needed. If you want a 100% seamless experience stick with wine-staging-2.21. If you can deal with a bit of lag, or want to mess with settings a bit more and have one wine version that works with both EQEmu, P99, and Live then use taskset and stick with 4.21. I will also say that MQ2 is much more stable under wine 4.21 than 2.21. So that may be another game changer for you when choosing versions for the older clients.
 
Building wine from source with wine-staging patches applied:

Make sure you have all dependencies installed as per the instructions here: https://wiki.winehq.org/Wine_User's_Guide#Getting_Wine

Applying the staging patch set and compiling wine is generic to any version. We will use 4.21 as our example here since most linux distros do not have it in their package manager any longer so you will either need to use a utility like PlayOnLinux (which is becoming deprecated) as I outlined above in my original guide, or build from source yourself.

1. Download wine and wine-staging sources for the version you want to build:

Source code link for wine-4.21 (EQ Live): https://dl.winehq.org/wine/source/4.x/wine-4.21.tar.xz
Source code link for wine-staging-4.21 patches (EQ Live): https://github.com/wine-staging/wine-staging/archive/v4.21.tar.gz

Source code link for wine-2.21 (EQEmu): https://dl.winehq.org/wine/source/2.x/wine-2.21.tar.xz
Source code link for wine-staging-2.21 patches (EQEmu): https://github.com/wine-staging/wine-staging/archive/v2.21.tar.gz

2. Lets work from /usr/local/src for standards sake:

INI: 
cd /usr/local/src
mkdir wine-versions
mkdir wine-versions/4.21
cd wine-versions/4.21
cp ~/Downloads wine-4.21.tar.xz .
cp ~/Downloads wine-staging-4.21.tar.gz .

3. Extract sources:

INI: 
tar xaf wine-4.21.tar.xz
tar xaf wine-starging-4.21.tar.gz

4. Apply staging patches to vanilla directory:

INI: 
cd wine-staging-4.21
patches/patchinstall.sh DESTDIR="/usr/src/wine-versions/4.21/wine-4.21" --all

You will see a bunch of spam go by indicating the patches being applied

5. Build wine

INI: 
mkdir /opt/wine-versions/wine-staging-4.21
cd ../wine-4.21
./configure --prefix=/opt/wine-versions/wine-staging-4.21
make
make install

6. Run eqgame.exe from the new wine installation

INI: 
export WINEBIN=/opt/wine-versions/wine-staging-4.21/bin/wine
${WINEBIN} eqgame.exe patchme


Notes: To use for wine-2.21 just 's/4.21/2.21/gc'
 
Last edited:
wine-staging-2.21 would not build for me until I added the --without-pcap flag to configure. Without the flag the compile would error out during the build process on winsock.h.

So for wine-staging-2.21 use the following configure command for step 3 to get around build errors:

INI: 
./configure --prefix=/opt/wine-versions/wine-staging-2.21/ --without-pcap
 
An update on EQEmu RoF2 client with MQ2 after some new testing this morning. It seems the newest version of VV (RoF2) is working well again with wine-staging-2.21. Here is the process I performed and tested running a new warrior on my EQEmu dev server for a few hours with the latest version of VV for RoF2 and a simple KA ini file.

1. I compiled a fresh version of wine-staging-2.21 on my system using my directions above

2. Setup a new RoF2 client wine bottle

INI: 
# export prefix
export WINEPREFIX="/home/thedank/Games/RoF2"
cd $WINEPREFIX

# build 32bit bottle
WINEARCH=win32 /opt/wine-versions/wine-staging-2.21/bin/winecfg

# install necessary winetricks goodies using the right version of wine for the bottle
env WINE=/opt/wine-versions/wine-staging-2.21/bin/wine sh winetricks corefonts wmi d3dx9_43

# copy RoF2 client backup into the new bottle
cp ~/RoF2_Backup/Sony $WINEPREFIX/drive_c/Program\ Files/

3. Download and setup RedGuides VV RoF2 version and extract

INI: 
mkdir ~/Games/MacroQuest2_RoF2/
cd ~/Games/MacroQuest2_RoF2/
cp ~/Downloads/RedGuides_VeryVanilla_ROF2EMU.zip .
unzip RedGuides_VeryVanilla_ROF2EMU.zip

4. Launch Game

INI: 
export WINEPREFIX=/home/thedank/Games/RoF2
cd $WINEPREFIX/drive_c/Program\ Files/Sony/EverQuest\ F2P
/opt/wine-versions/wine-staging-2.21/bin/wine eqgame.exe patchme &

5. Launch MQ2 RoF2 version (same shell)

INI: 
cd ~/Games/MacroQuest2_RoF2/
/opt/wine-versions/wine-staging-2.21/bin/wine MacroQuest2.exe &
 
Last edited:
thedank said:
Currently wine 5.20 makes things look like a slide show. It is unbearable to even log into the game.
Click to expand...
It's an issue with wine and nvidia(saw you use an nvidia card,) use this patch when building:
Code: 
diff --git a/dlls/winex11.drv/xrandr.c b/dlls/winex11.drv/xrandr.c
index 78ad98ac..951c1ec5 100644
--- a/dlls/winex11.drv/xrandr.c
+++ b/dlls/winex11.drv/xrandr.c
@@ -403,13 +403,13 @@ static BOOL is_broken_driver(void)
             continue;
 
         /* Check if it is NVIDIA proprietary driver */
-        if (XQueryExtension( gdi_display, "NV-CONTROL", &major, &event, &error ))
-        {
-            ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. "
-                           "Please consider using the Nouveau driver instead.\n");
-            pXRRFreeScreenResources( screen_resources );
-            return TRUE;
-        }
+        /* if (XQueryExtension( gdi_display, "NV-CONTROL", &major, &event, &error )) */
+        /* { */
+        /*     ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " */
+        /*                    "Please consider using the Nouveau driver instead.\n"); */
+        /*     pXRRFreeScreenResources( screen_resources ); */
+        /*     return TRUE; */
+        /* } */
     }
     pXRRFreeScreenResources( screen_resources );
     return FALSE;

Or just enable virtual desktop in winecfg.
 
Interesting, I do use the virtual desktop and still have issues with 5.20. I'll try the patch when I have a chance. Thanks!
 
Hi, I am trying to get this working using Crossover on MacOS and I am wondering if some of the expertise in this thread might apply. If you could, please check out my summary here with posts above it documenting my mixed journey. I believe I have to use Crossover (which is wine) because they have a layer in there that works with the latest MacOS Sierra and M1 chip. I am at a point where my initial instance is working really well but I can't seem to add the second. I am not sure how to translate the setup in the Linux guide in to the Crossover setup to try that though (where you have 1 install and multiple bottles using it). I might try messing with the shell setup using the clues in the Crossover shell init (posted in the other thread), but I don't know wine or bottles all that well.

Making this work for MacOS in the latest chip and OS would be a gamechanger for a lot of us I am sure! Hopefully someone has some ideas I can try next.

 
PSA: If your getting serious video lag after the last patch or within the last week of this post on your live install you may need to go dig into your eqclilent.ini file and check your CPUAffinity settings. After reloading a few of my toons today I noticed that my framerates had gone to unplayable. After some debugging I found that my CPUAffinity settings were reset to default in my eqclient.ini file. Not sure when this occurred, but I was playing fine up until this morning, and have not edited my eqclient.ini file since my original installation. Resetting the CPUAffinity to the settings I indicate in a previous post instantly fixed my video lag issues.

Edit: Upon further inspection, more than just my CPUAffinity was changed. The entire file was reset to default! AutoAFK was on again and all of my video settings were reset to the defaults. CHECK YOUR INI's if you customize!
 
Last edited:
da Man said:
@Redbot it can run on a pi, laggy, crappy controls, and you need at least 2 to 3 pi's clustered (guessing) to run it. it requires wine and an x86 emulator and a lot of frustration but it can be done (you may not have hair before you are thru). I have not tried it on a cluster, that may work better. I also only have 2 b versions, the 4 may work better
Click to expand...
ive been digging into this lately, will share any successes (but i'm also always working on too many projects , and i haveto get the parts etc too)

there are several different ways to run x86 on ARM nowadays, some better than others. the emulators are the slowest, so i plan to avoid that. idk if box86 would or wouldnt work, but Hangover is an on-demand recompiler of x86 to ARM, only what needs converting as it needs it, and appears to run better. this is all from research in the last week, and i personally havent messed with linux in a decade so id haveto relearn that before i even tried. i know there used to be a paid program, i forget, that disappeared but it wouldtn have played eq either. what im seeing with hangover are people successfully playing games newer than eq, so though it may not work in the end for a live server, im sure with the right experimentation EQ can be played on the new pi 4's np. usb 3.0 instead of 2.0, unless you go bottom of the barrel youstart off with double to 8x the ram of a 3 or before, and iirc, better wifi.

if you/whoever is jsut looking to run EQ on an SBC, that is perfectly doable as there are x86 SBCs out now for not too much. and you can also get the mini computer sticks for about 100 and up, with atoms, celerons, and more, 4 and 8gb ram, and emmc already installed. the non-stick micropcs (little more but starting about 150) can even install m.2 drives. with that kinda equipment, running eq in linux or even windows should be plenty doable at a much smaller footprint and a tiny electric bill lol

power consumption is why i started even looking into any of these devices, but i'll be building a piZero wordprocessor and refamiliarizing myself with linux soon before i delve into trying to game. i KNOW older than eq games like AoE and diablo 1 and 2 can be played on pi's np at all, it's the dx9 stuff you have to go with latest and greatest for ARM it seems.,...oh and theres tunnel OS9sic) too that is similar to box86 but is built for the pi 4's instead. that one is also promising with some time. bonus: as usual, the pi 4 starts at same price as the pi 3 did: $35 just dont go looking on amazon or newegg etc, theyre always marked up. have my Zero coming at the msrp of $5 as we speak. peripherals i did find better deals on some parts on amazon though
 
PSA: this last patch on 5/20 reverted my eqclient.ini file back to the default again. I had to go back in and setup the cpuaffinity variables to fix the lag issue. BE WARNED! This occurred after I ran the game once after patching then logged out completely to desktop and loaded up again. So it was not reset on the first run but on a complete cycle of the games state after patching. The order of variables in the eqclient.ini file is now generated differently with the general stuff we normally see on top now being at the bottom of the file and your chat variables being at the top. The CPUAffinity=0 default value is now on the last line of the file. So for my 12 core system I modified the file to include the following at the end:

INI: 
CPUAffinity0=-1
CPUAffinity1=-1
CPUAffinity2=-1
CPUAffinity3=-1
CPUAffinity4=-1
CPUAffinity5=-1
CPUAffinity6=-1
CPUAffinity7=-1
CPUAffinity8=-1
CPUAffinity9=-1
CPUAffinity10=-1
CPUAffinity11=-1

Also after logging in make sure to check your options on each character. Everything is reset to default! Video settings, Auto-AFK, sound settings, etc.
 
Last edited:
Hi! Have any of you seen the 2 issues I am hitting? described below:
- EQ works well without MQ2,
- MQ2 starts up well (can see icon in taskbar),
- Select server and go to character screen in EQ, see character rotate,
- First issue: MQ2 is not automatically injected. Have you seen that? Any known fix?
- Right click "Reload MQ2" in MQ2 taskbar icon. This seems to inject the DLL properly (can see the new release notes window in character selection screen, also title changes to name of toon and level), but when I Enter game then:
- Second issue: MQ2 window is not visible in-game and I don't get the new UI elements (although the game still runs fine). It seems like MQ2 maybe crashed, but I see no log in the terminal (I launch MQ2 and EQ from that terminal) and the MQ2 icon in the taskbar seems to work properly still. Have you seen that? Any known fix?

I'm on a debian based distro, all up to date. I have tried wine version 5.6-2 and wine version lutris-hack-6.14-3, both through Lutris. I suspect the first thing you're going to ask is have you tried wine 4.21 :-) but the fact is that Everquest runs perfectly well for me in those newer versions of wine that come with Lutris. I would have thought that staying at wine 4.21 would be for EQ to work. Is the reason you recommend 4.21 also for MQ2 to work properly?

Any experience running MQ2 in-game on wine 6+?

Any help appreciated!
 
I have been testing under wine 6.11 development on ubuntu 20.04 and have everything working, however there are some tradeoffs to what I had setup under wine 4.21.

A. You no longer can use the virtual desktops, they lag out bad on startup. Need to run in windowed mode (however this comes with a few new advantages)
B. Since you no longer need to run virtual desktops you can just run all windows from a single wine bottle/instance.
C. MQNext (macroquest) works perfectly on 6.11 devel with MQ2Nav (finally! due to directx 11 support under dxvk)

The quick and dirty

1. Install wine winehq-devel to get latest wine on ubuntu:
INI: 
dpkg --add-architecture i386
wget -nc https://dl.winehq.org/wine-builds/winehq.key
apt-key add winehq.key
add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main'
apt update
apt install --install-recommends winehq-devel

2. Install dxvk
INI: 
apt install -y dxvk

3. Install corefonts
INI: 
apt-get install ttf-mscorefonts-installer

4. setup default wine bottle with dxvk
INI: 
winetricks dxvk

5. Launch EQ from installed location (I use ~/Games/EverQuest) with DXVK framerate hud for testing
INI: 
DXVK_HUD=1 wine eqgame.exe patchme &

(Do this for each instance you want to run up, make sure WindowedMode=TRUE in your eqclient.ini!)

You should see a little HUD in the upper left corner of the screen that gives FPS stats. If so then you have DXVK (Vulkan DX11) support setup correctly! Congratz! You can remove the DXVK_HUD=1 from future startups.

6. Launch MacroQuest (MQNEXT) from installed directory (mine is in ~/Games/MacroQuest)
INI: 
wine MacroQuest.exe &

Notes:

A. I still cannot get the launcher/patcher to run under wine 6.11 devel. It just hangs in a black screen. I need to revert to my old wine 4.21 install to get the patcher to update
Update: use the following to get launchpad to load properly for patching
Code: 
export WINEDLLOVERRIDES=libglesv2=d
wine Launchpad.exe &

B. Running in windowed mode has the nice side effect of producing Gnome Alert Popups if a toon on a different "Workspace" gets a tell in a new tell popup window. For some reason the OS sees the update and lets you know that you have something happening over there. Pretty nice!

C. Initial game startup through the menus is a lot slower than under 4.21. But game play under DXVK is much faster! MacroQuest (ie. MQNext) is so much smoother!

I can provide more detailed updates and findings down the road. Been very swamped with work and have not had the time to produce a new official linux guide yet. This should get you guys going though!

Update: this is still working on the latest wine-development v7.7 as of 4/20/2022
 
Last edited:
Also make sure you have a default MacroQuest.ini file that is setup the way you like for plugins. And then cp that over to MacroQuest.ini before you run each time. This will probably solve your 2 issues with no injection and no UI elements.

What I have noticed even under 4.21 and I have it in the original guide is that when you run up MQ2 it basically rewrites your MacroQuest.ini file. When you go to close everything out, or have a crash it leaves the ini file in this changed state, with no plugins listed. So when you go to start up again it uses this cleared out ini file that loads nothing for you. Check it out, do a 'cat MacroQuest.ini' before starting up and then after everything is running and see the difference.

I basically keep a MacroQuest_Backup.ini in my ~/Games/MacroQuest/config directory alongside MacroQuest.ini. My launch script takes care of making the copy on each new startup.
INI: 
cp ~/Games/MacroQuest/config/MacroQuest_Backup.ini ~/Games/MacroQuest/config/MacroQuest.ini

I figured this out long ago when I restarted and my MQ2 window was always missing. Turned out the plugin was not getting loaded, along with all the other goodies that were there before!
 
That was exactly it! MacroQuest.ini was getting reset/corrupted. Restoring it from a backup before each launch fixes all my problems. Thank you!
 
You must log in or register to reply here.
Guide - MultiBoxing EverQuest on Linux with MQ2
Next unread thread 🦁

Users who are viewing this thread

Total: 2 (members: 0, guests: 2)
Back
Top
Cart

Cart

Total -