Combine Bedrock Add-ons and Find the First Conflict

Quick answer: Two Bedrock add-ons can work alone and still fail together. Start from a restorable world copy, prove add-on A alone, prove add-on B alone, record each release and its Behavior Pack and Resource Pack layers, then test A+B. Add only one new layer between tests.

Pack stack order can decide which overlapping definition wins. It cannot merge incompatible logic, install a missing dependency, make two scripts compatible, or prove that the losing feature still works.

What the official guidance establishes

Microsoft’s cooperative add-on and manifest documentation was rechecked on August 24, 2026. It documents conflicts when add-ons define the same identifier or modify the same vanilla system, recommends unique namespaces and additive design, and defines exact UUID/version or Script API dependencies.

MineBrush did not test a selected add-on pair for this article. The exact Bedrock build, UI precedence direction, creators, licenses, files, dependencies, experiments, saved-state behavior, Realms support, and performance are unknown until a specific stack is sourced and tested. This workflow isolates a conflict; it does not certify compatibility.

1. Build a stack record before troubleshooting

Create one row for every add-on:

Keep matched layers from one creator release together. Do not combine a Behavior Pack from one version with a Resource Pack from another. Not every add-on needs both layers, but an exact declared dependency is a requirement, not a suggestion.

Do not rehost, repackage, or edit third-party files unless the license clearly permits it and you understand the consequences. This guide provides no add-on download.

2. Establish a clean world baseline

Use a restorable copy, never the only valuable save. Disable optional test packs in that copy and confirm the base world loads normally. Record one short route: the same location, inventory, ordinary interaction, and save/reopen cycle.

If the clean copy already fails, repair or replace the baseline before diagnosing add-on compatibility. A broken starting world can make every later result look like a pack conflict.

3. Prove each add-on alone

Activate only add-on A’s creator-matched layers. Run one feature the creator documents, save, close Minecraft fully, reopen, and repeat the feature.

Return to a fresh copy of the clean baseline and repeat the same process for add-on B. If either add-on fails alone, you have a single-add-on problem, not an A+B conflict. Use the Bedrock add-on troubleshooting guide before building a larger stack.

An import notification, a readable manifest, or a name in the active-pack list is not a runtime pass. A pass requires the creator-documented feature to work and survive a save/reopen cycle in the recorded setup.

4. Build A+B one change at a time

1. Return to a known-good clean copy.
2. Activate A and repeat A’s short feature check.
3. Add B without changing anything else.
4. Repeat both A’s and B’s checks.
5. Save, close Minecraft, reopen, and repeat both checks.
6. Do not add C until A+B has a recorded result.

If the interface allows deliberate order changes, record the exact visible order and test each order from the same known-good starting copy. Do not assume “top” or “bottom” has one universal precedence direction across every current build and device.

If one order makes a feature visible, you have learned which definition won in that tuple. You have not proven that the packs merged or that the losing system remains functional.

5. Classify the first repeatable failure

Missing or mismatched dependency

Microsoft’s manifest reference says dependencies can name an exact pack UUID/version or a native Script API module. A declared dependency does not prove the required file is installed, licensed, or compatible. Restore the creator-matched release instead of mixing files or editing a manifest to silence the warning.

Identifier or definition collision

Microsoft documents that when two add-ons define the same entity identifier, one can win according to the per-world pack stack. The cooperative guidance also identifies collision risks in textures, functions, tags, scoreboard objectives, loot tables, animations, sounds, and other named content.

Order may select a winner; it does not repair the losing add-on. Prefer creator-documented compatibility or an updated release over random reordering.

Saved-world effect

If A+B works in a new copy but not in the older test copy, record the difference. Do not guess which saved data is responsible. Disabling a pack is not a proven rollback for custom blocks, items, entities, scripts, or other stored state.

Script or experiment mismatch

Treat Script API modules, API versions, and experiments as release- and build-specific. Do not enable every experiment or edit a manifest to force a pass. Return to the creator’s exact requirements.

Capacity or performance symptom

The number of pack names is not a useful performance limit by itself. Microsoft’s guidance notes that content size and device capability matter: a few enormous content packs can cost more than a longer list of small ones. Repeat the same route on the weakest device you intend to support and record load time, responsiveness, and the first visible failure. MineBrush has no measured safe pack count.

6. Use a compatibility matrix

“Partial” is not compatible. If one creator-documented core feature disappears, the stack has not passed even if the world still opens.

7. Stop with a result another player can reproduce

If both add-ons work alone but not together, preserve the single-pack baselines and record the failing tuple: creator names, releases, Bedrock build, device, experiments, active layers, visible order, and the smallest repeatable action.

Keep private details out of public reports. Do not post account names, Realm codes, private chat, coordinates of private builds, device identifiers, or full logs. Do not describe the stack as compatible on Realms, servers, consoles, or joining clients unless those exact environments were separately tested.

Choose the next MineBrush guide

• Use the Bedrock file-format guide when the imported file type is unclear.
• Use the Behavior Pack versus Resource Pack guide when layer roles are unclear.
• Use the backup-first activation guide before enabling the first add-on on a valuable world.
• Use the safe update workflow when replacing one stack member.

Official references

• Guidelines for Building Cooperative Add-Ons
• Bedrock pack manifest reference
• Pack dependency reference

Evidence limit: Official documentation was rechecked on August 24, 2026. MineBrush acquired no creator files, original screenshots, world copies, device captures, or runtime results for a selected A+B stack.