Q. Why can't lfs.dll be found when starting the script?
A. If the script errors loading lfs.dll, then you may need to install the
VC Redist package from Microsoft
Q. Why can lfs.dll still not be installed?
A. Make sure that your macroquest lua mq folder (usually release/lua/mq) contains the latest files available, specifically PackageMan.lua. A windows command prompt window appears when it attempts to install lfs.dll. This will likely show some output that looks like an error (Error: Unknown option '-e'). This error doesn't matter and can be ignored. After that, it will print the URL of what it is trying to install. This will look like
https://luarocks.macroquest.org/2.0.5/luafilesystem-1.8.0-1.win32-x86_64.rock. The important part in the URL is the "2.0.5". If you don't see that, you are probably on some old version of PackageMan.lua. (Note that the 2.0.5 may change, it may be any version number.
Q. Why can lfs.dll still not be installed after all that?
A. There may be binary compatibility issues between luajit updates within MQ. This means that if you have an incompatible lfs.dll in your lua folder somewhere it may be trying to load that one. Delete it so that MQ can automatically download a new one. This isn't supposed to be an issue anymore as the lua folder has been removed from the search paths for luarocks modules (dll files).
Q. What on earth is going on with lfs.dll?
A. If all else fails, search your entire mq folder for lfs.dll and delete anything you can find and try again? Best of luck!
Q. Yet another attempt to fix lfs.dll?!?!?!
A. Try deleting the content of C:\Users\<youruser>\AppData\Local\LuaRocks\Cache folder.
Q. Why can lfs.dll still not be installed after ensuring PackageMan.lua is up to date?
A. You may have some messed up permissions on a folder or something else somewhere in windows which is preventing the install from working properly. You can usually work around this by opening a windows command prompt and executing the command manually. This command will be something similar to: "C:\Users\xxxxxxxxxxx\AppData\Local\VeryVanilla\MacroQuest\Release\luarocks.exe" --lua-version 5.1 --only-server "https://luarocks.macroquest.org/2.0.5/" install --deps-mode none --tree "C:\Users\xxxxxxxxxxxxxxxx\AppData\Local\VeryVanilla\MacroQuest\Release\modules\2.0.5\luarocks" "luafilesystem".
Note: The "2.0.5" should be replaced with whatever version was printed in the URL when MAUI tries to install lfs.dll.
Don't run any manual luarocks commands or you will likely just remain broken the next time the lua version is updated.
Q. Does this run on live/test?
A. Currently this only works on MQ "next" with mq2lua, which is only available for live.
Q. Boxhud fails to start with error Could not find script at path C
A. Make sure you downloaded the resource and added the files to your lua folder
Q. Why are buttons not responding or the window can't be moved around?
A. Most likely a bug with ImGui and mouse inputs, and it thinks a mouse button is stuck pressed. Cycle through clicking all the buttons on your mouse.
Q. Why are values not updating properly for one or more characters?
A. Crashes, going LD, relogging, etc seem to screw up DanNet observers sometimes, and they don't appear to be removed properly or don't get added back properly when the character comes back online. Either go to the Admin tab on boxhud and reload the observers for the misbehaving character or reload the dannet plugin on the character running boxhud and it should hopefully fix the issue.
Q. Can boxhud be launched at startup?
A. To Run the script at login for a given character:
1. If you don't already have a character config file for the character which will run boxhud, create a file in your
next/config
folder like
servername_Charactername.cfg
, for example,
rizlona_Aquietone.cfg
2. Add the following line to the file:
/timed 100 /lua run boxhud
Q. Why does boxhud cause characters macros to throw errors about undefined variables?
A. By default, Boxhud will observe each configured property on all characters. Observing a property which doesn't exist on a character, for example, observing CWTN.Mode on a Bard, will cause undefined variable errors when trying to run a macro on the Bard. To avoid this, filters should be applied to the property to define which characters the property should be observed for.
For example, when adding the property CWTN.Mode, the DependsOnName and DependsOnValue fields can be set to restrict what classes CWTN.Mode will be observed for:
Property: CWTN.Mode
DependsOnName: Me.Class.ShortName
DependsOnValue: clr,shm,war,shd,mnk,rog,ber
Note that the observer is created from the character that is running boxhud, so if your driver toon is running boxhud and trying to observe CWTN.Mode on the bard, you would need to fix the property on boxhud on your driver toon to not observe the property for bards.
Q. Why does boxhud still cause characters macros to throw errors about undefined variables even after limiting what classes the property applies to?
A. If you swap toons, like going from an enchanter to a bard on the same account, DanNet still seems to think its trying to watch whatever properties it was watching before you swapped characters. Boxhud on your driver toon doesn't know you swapped toons on some other account to try and resolve it for you automatically. Try reloading the dannet plugin on the swapped character.
Q. Should anything and everything be added to boxhud?
A. Try to just add vital information that is frequently updated. No need to go adding a bunch of static info about characters that will rarely ever change. For ideas of what can be added, check out the MQ TLO documentation here:
MacroQuest Docs