Mods & dependencies

Installing mods, dependency conflicts, and what deleting or disabling a mod does to the mods that depend on it.

Installing mods

Browse mods from inside a module's editor and install directly into the layer you currently have open. If a mod has dependencies, those are pulled in automatically as part of the same install.

Deleting or disabling a mod

If other installed mods depend on the one you're deleting or disabling, Bricky checks for that first and asks what to do:

• Remove it anyway, leaving its dependents installed (they may not work correctly without it — that's on you at that point).
• Remove it and its dependents, cascading the removal to everything that needed it.

This check runs against the actual current dependency graph, not a cached one, so it reflects whatever's really installed at the moment you act.

Ownership vs. files on disk

Internally, Bricky tracks which mods "belong" to which layer (ownership) separately from the actual jar files sitting in that layer's folder on disk. These are supposed to always match. If you ever see a mod listed as installed that doesn't seem to actually be there (or vice versa), that's exactly the class of bug worth reporting — it's a real, non-hypothetical failure mode we've chased down more than once.

Unavailable mods during cross-version cloning

When cloning a module into a different Minecraft version, a mod might simply not have a build for the target version. See Cloning modules for what happens in that case.