-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Linux Setup Gotchas
There are a few caveats which bear mentioning when using mods on Borderlands 2/TPS under Linux.
- Game Patching
- Run Mods From The "Title" Screen!
- Case-Sensitivity Issues
- DLC Directory Ordering Issues
- Problems with connecting to SHIFT
In order to enable the console, which is required to run the mods, Windows users can use FilterTool to handle automatic patching of the main .EXE file. This isn't possible on Linux (or at least nobody's yet taken the time to figure out an equivalent), so Linux (and Mac) users must instead edit their engine.upk files manually.
FilterTool's successor, BLCMM, will support automatically patching engine.upk on both Mac and Linux, so I'm not including instructions here for doing so. Detailed instructions can be found here, though: http://apocalyptech.com/games/bl-modding/
Once BLCMM is released (which should be pretty soon, as of April, 2018), most of that URL will become pretty obsolete, since BLCMM will take care of it for you.
Windows users are able to run mods from the main menu, but the Linux (and Mac) ports work a little differently, and it won't actually work properly if you try from there. Instead, you need to do it from the "Press any key" screen, which just has the Borderlands logo and that phrase. Complicating matters slightly is that you do have to go into the main menu first, in order to have all the DLC content loaded and available for patching. So, in order to execute mods when first starting up, this is the procedure:
- When you get to the "Press any key" screen, hit a key to go to the main menu
- Once at the main menu, wait for a few seconds for the game to establish a connection to Gearbox. In BL2, you may see a very slight glitch in the character animation when that happens. In TPS, there's actually some text notifications letting you know that it's attempting the connection, and another message once it succeeds/fails.
- Hit
Escand then "Yes" to get back out to the Title screen. - From there, you can pull down the terminal and
exec patch.txtto load your patches.
If you need to re-execute any patches or anything later, be sure to go all the way back out to the title screen again.
When you type exec <filename> at the console to load up a patch file, on Linux the engine will automatically convert the filename to all-lowercase, so the patch you're trying to execute must have an all-lowercase filename to match. This can be somewhat confusing, since the error message you'll see at the console will retain the case as you typed it in, rather than the lowercase version.
Since FilterTool/BLCMM both expect the default filename to be Patch.txt (with a capital "P"), one way to make everything happy is just to create a symlink in your binaries dir, like so:
lrwxrwxrwx 1 pez pez 9 Feb 9 16:55 patch -> Patch.txt
-rw-r--r-- 1 pez pez 3520596 Feb 28 20:48 Patch.txt
That way, FT/BLCMM can continue to use Patch.txt for the filename, and you'll be able to just type exec patch from the console to load your patches.
This is a rather bizarre issue, due to some cross-platform differences between Windows and Linux, and because of some behaviors of the Borderlands engine. It's worth noting that this issue doesn't actually affect much - you'll miss out on some statements which modify gun parts, mostly - so don't sweat it if you don't want to deal with this.
Basically, when looking for DLC on your hard drive, Borderlands looks inside the steamassets/dlc directory and loads the mods in the order they're given by the kernel. On Windows, the filesystem driver will return the directories in alphabetical order by default. On Linux, the order of the directories is effectively random. (When looking at a directory listing via ls on Linux, the ls command does the sorting for you. If you want to see the "native" order in which the directory entries are given, you can run "ls -U" or "ls --sort=none".)
As the engine loads these DLC, some of the property names get dynamically-assigned number suffixes, and the numbers depend on what order the DLC is loaded. Mods which try to edit these values need to hardcode a number to use -- any mod written/tested on Windows is going to be using the numbers you get by sorting the directories alphabetically. For instance, the internal part list collection for one class mod from the Dragon Keep DLC has this property name:
GD_Aster_ItemGrades.ClassMods.BalDef_ClassMod_Aster_Assassin:ItemPartListCollectionDefinition_28
However, the last number could easily be something else, like:
GD_Aster_ItemGrades.ClassMods.BalDef_ClassMod_Aster_Assassin:ItemPartListCollectionDefinition_42
And on other Linux systems it could be something different. There's no way to actually predict what number it'll be. This doesn't have a super wide impact, since there aren't that many mods which actually touch these variables, but UCP does contain a few statements which do, and you'll risk not getting the full effect of some mods.
Unfortunately, the only real fix for this is to mount your Borderlands DLC directory under a separate filesystem which supports sorting directories alphabetically. No native Linux filesystem does this. It's possible to disable some features on an ext4 filesystem, so that directory entries will be given in the order in which they were created. So theoretically you could create an ext4 partition, use the following tune2fs command on it:
# tune2fs -O ^dir_index /dev/foo
... and then carefully copy the DLC directories into that filesystem, one at a time, in alphabetical order. That method seems quite fragile to me, though, and I wouldn't recommend that even though you'd still be using a native Linux FS.
What I've done on my own system is to just resign myself to using NTFS. The Borderlands 2 DLC dir contains a little over 6GB of data, so I created a new 10GB LVM LV, used "mkfs.ntfs /dev/vg/bl2dlc" (obviously substitute the proper device name there), copied over all the DLC data into that new filesystem, and then added the following to my /etc/fstab -
# Borderlands 2 DLC Modding Nonsense
/dev/mapper/vg-bl2dlc /usr/local/games/Steam/SteamApps/common/Borderlands\0402/steamassets/dlc ntfs uid=1000,gid=1000,umask=022 1 2
Note the special string "\040" in the pathname, required because there's a space in the directory name. Adjust the device name, path, UID/GID/umask, etc, to suit your circumstances. Make sure that the dir is mounted properly and that the DLC data is in there, and you should be good to go. You can use "ls -U" in the DLC directory to verify that they're showing up in alphabetical order now.
So... yeah. That is quite weird, and I suspect not a lot of folks are going to be willing to do something like that to their system, just to support some game mods. Still, if you're looking for 100% mod compatibility inside Linux, this is a step you'll have to deal with.
On some distros (Arch Linux for example), SSL sertificates is stored in /etc/ssl rather than /usr/lib/ssl. This will cause problems while connecting to SHIFT. Simple solution is to create a symlink:
ln -s /etc/ssl /usr/lib/ssl
But it can cause troubles, so the best way to handle this is to launch game with SSL_CERT_DIR=/etc/ssl/certs. Source: https://wiki.archlinux.org/index.php/Steam/Game-specific_troubleshooting#Logging_into_SHiFT