BLCMods: a Borderlands mod collection where the governance is as important as the code

A collection of files, not a package, and a policy to match

BLCMods is a repository for community mods made for the Borderlands series, specifically Borderlands 2 and Borderlands: The Pre-Sequel, and the top level of the tree shows the shape of the thing. There are directories for Borderlands 2 mods, for Pre Sequel Mods, and a BLCMM Plugins directory, alongside docs/, wikiresources/ and a LICENSE.md.

What is not there is a build system, a package manifest or a test suite, and the primary language listed for the repository is Python, which points at the BLCMM plugin side rather than at the mod files themselves. The mods are assets, and the project is a distribution with rules about who may put what in it.

The technical conventions are stated in one line: the mods should use the `set` command in the Unreal console to change in-game variables, and if a mod has specific considerations the author should make it clear how to install it. That is a constraint on how the mod is written as well as a rule about documentation, and it is the reason a mod can be applied to a live game session rather than only to a saved file.

The supporting structure sits in the wiki. There is a main wiki for the project, a separate sorted repository in the ModCabinet organisation where mods are indexed by category, and dedicated FAQ pages for patching and for the super randomizer. The site for the project is at blcm.github.io/BLCMods/, and there is a support Discord.

The licence is a custom one in LICENSE.md, and the repository is classified with a category GitHub cannot name, so the file in the tree is the authoritative text.

Install through BLCMM, and treat master files as a warning

The installation section is short, and the guidance about master files is the part worth knowing before you download anything.

There are two download routes. To get a mirror of the whole repository at the current point in time, you use the green Clone or Download button at the top right. To get one individual file, you click the `raw` button at the top right of the bar that has `raw | blame | history`, and once the page loads you right click and save the page as. Installing the files themselves then follows the methods discussed in the wiki, under the tutorial on enabling the console.

The warning is the important part. The usage of master files has become strongly discouraged as Borderlands 2 and TPS modding has become more complex, and the reason given is practical: using master files will often end up breaking parts or all of the mods you are trying to use. The instruction is to always import mods into BLCMM, and then execute the single patch file that it saves.

That is a small sentence with a large consequence for how the repository is meant to be used. A master file is a patched copy of the original game data, so applying one replaces the game's own files with a modified version. Two master files applied one after the other fight each other, and a mod authored for one version of the data breaks when the other version is layered on top. BLCMM keeps the mods as separate patches and merges them into one file it produces, so the merging happens in one place, in the order the mod manager decides, and the original game data is left alone.

For a user this means the repository is not a folder of drop in files. It is a source of patches to be imported.

PC only, and the DLC requirement that decides your support

The requirements section states two constraints that settle most of the practical questions before you start.

The first is the platform. These mods can only be installed on PC and will never be ported to consoles due to technical and legal limitations. The legal half of that sentence is about the console platform's constraints rather than about the mods themselves, and the technical half is about how the modding tools work.

The second is content. All non-headhunter DLC is required for the patch and for most mods, which includes both the UVHM packs and Digistruct Peak. And then the support consequence follows directly: support will most likely not be given for errors that the UCP cause due to missing DLC. The rule essentially means that a broken install caused by missing required DLC, Digistruct Peak included, will not be triaged.

The README also sets expectations about individual support. Support for a specific mod is up to the author of that mod, and it is handled case by case. There is no central support desk for the collection, and the policy is stated bluntly: individual mod support for errors is up to the author of the mod and is a case by case basis.

One line is a direct warning to users rather than a policy about code. It says not to expect to be entitled to help, and gives the reason: each member of BLCM and the Discord is an individual first and a modder second, doing this for free, with potentially busy lives. The same passage then notes that most members are more than willing to help if you remember that.

The issues tab has been closed since August 2018

One line of the README explains a decision that shapes how this project is used. As of Aug 8, 2018, the issues tab has been disabled due to repetitive questions. If you have problems, the README points to the FAQ for patching and the FAQ for super randomizer, and to the community Discords if the answer is not in those articles.

That is a deliberate redirection of support load rather than an abandonment, and the reasoning is in the text: the questions that were arriving repeatedly had answers that already existed, in wiki pages. Keeping the issues tab open would have meant a permanent queue of answered questions above the ones that actually needed a maintainer.

For a user it means the support path is a wiki first, a Discord second, and no issue tracker at all. For a mod author it means the same, and it means a bug in your mod is handled through the community channels rather than through a public tracker.

The repository was last pushed to on 2026-10-17 and is not archived, and the project has no GitHub releases, which is consistent with how the mods are distributed: as files in a repository that people pull or download individually, not as versioned packages.

The wiki resources directory in the repository root, wikiresources/, sits in the repository root alongside the README, and the README points readers to the wiki for the documentation itself.

Modpack policy: written agreement from every author, or it is rejected

The modpack policy is the most unusual part of the repository, and it is worth reading as a governance document rather than as a rule set.

For a modpack, meaning a compilation of mods, it is highly recommended that you provide a screenshot or other proof of agreement from each mod author of a mod you include, regardless of whether you attained approval from them, or a screenshot of their policy showing that it complies. Preferably you use an image gallery of screenshots hosted wherever you like. The stated reason for the recommendation is that it helps the modpack become available as soon as possible.

Then comes the enforcement. If a modpack includes a mod from an author or collaborative group of authors who did not approve of it beforehand, or who are against its personal policy for distribution, modification, derivative use or inclusion in modpacks or groups, without contacting the author for permission, it will be rejected as a pull request. And if it was previously approved and this is found out later, it may be deleted with or without warning at the discretion of a BLCM admin or the author themselves, if they have read and write access to BLCM. UCP is named as an exception.

There is a companion passage for individual contributions, and it is more permissive in one specific case. If an author or user suspects that a contribution may be stolen, or uploaded without approval, or is against the author's personal policy for distribution, modification, derivative use or usage of their mod as a base, they are asked to contact an admin or the uploader to find a compromise. The README then concedes that there are situations where a mod is so simple that recreating it or its effect on gameplay is simply not possible without the equivalent of copy-pasting it, and that in such times it will be allowed.

So the policy is not a blanket prohibition on reuse. It is a rule about consent and credit, with a narrow exception for work so trivial that duplication is unavoidable. That is a coherent position, and it explains why the repository is administered by people rather than automated.

Where BLCMods is the wrong tool

The first wrong fit is a console player, and this one is not negotiable. The mods are PC only and will never be ported, so if you play on a console this repository is irrelevant to you and no amount of reading will change that.

The second is a mod author who wants an issue tracker. The issues tab has been disabled since 2018 and the modpack policy is enforced by admins reviewing pull requests rather than by automation. If your work needs a public bug list, a changelog per version and a release process, this is the wrong home for it, and the practical effect of contributing here is that your support burden is yours alone, which the README states as plainly as it can.

The third is a packager who cannot obtain written agreement from each mod author. The policy says such a pack is rejected, and possibly deleted later. That is a real constraint on distribution, and it means the directory of mods and the set of things you may legally repackage are not the same set.

The fourth is anyone without Digistruct Peak and the UVHM packs. The DLC requirement is not optional for most mods, and the support policy means the errors it causes will not be triaged. In practice that excludes a large number of players from most of the collection.

The fifth is a deployment model that expects versioned releases and reproducible installs. There are no GitHub releases, the distribution is a repository of files, and the README warns against the one workflow that would make an install reproducible, which is the master file. If your goal is to script and reproduce installs, BLCMM is the tool you are depending on, not the repository.

The honest summary is that BLCMods is a well-governed collection of community assets for one specific pair of games, run by volunteers on their own time, and the governance is the product as much as the mods are.

Editorial conclusion

BLCMods fits a Borderlands player on PC who wants community modifications and is willing to install Digistruct Peak and use the BLCMM mod manager rather than copying files into the game folder. It does not fit a console player, a modder who wants an issue tracker for their own work, or a packager who cannot obtain written agreement from each mod author. Before downloading anything, read the contribution and patching wiki pages, because the repository's rules are enforced by the admins rather than by a build system.

Frequently asked questions

Official sources

1. BLCM/BLCMods on GitHub
2. Issues
3. Project website
4. README