The issue
This is a design oversight that has many negative consequences.
Files in behavior and resource packs do not have any kind of consistent namespace support, or implementations. As a result, packs conflict with each other and vanilla, and are disorganized.
Here is a list of file types found in behavior/resource packs, and their level of namespace support:
Type | Supports namespaces? |
|---|---|
Entities | ✔ Yes, with |
Items | ✔ Yes, with |
Loot tables | ❌ No. Loot tables are referred to exclusively by their path, relative to the pack root, including the file extension. They don't even have to be placed in the |
Recipes | ✔ Yes, with |
Spawn rules | ✔ Yes, with |
Dialogues | ❌ No. These use plain strings called "tags" for some reason as identifiers. |
Trade tables | ❌ No. These behave identically to loot tables. |
Functions | ❌ No. Functions are referred to by their path. Unlike loot tables however, they are properly referenced relative to the |
Biomes | ❌ No. These use |
Blocks | ✔ Yes, with |
Features | ❌ No. These behave identically to biomes. |
Feature rules | ❌ No. These behave identically to biomes. |
Structures | ✔ Yes. The namespace is derived from the name of the folder inside of the |
Attachables | ✔ Yes, with |
Fogs | ✔ Yes, with |
Animation controllers | ❌ No. Instead, identifiers are of the form |
Animations | ❌ No. Instead, identifiers are of the form |
Models | ❌ No. Instead, identifiers are of the form |
Particles | ✔ Yes, with |
Render controllers | ❌ No. Instead, identifiers are of the form |
Sounds | ❌ No. Sounds are referred to by their path. Like loot tables, the path starts in the root folder instead of the proper folder. This means you can put sound files in whatever random folder you want, unlike every other resource. |
Sound events | ❌ No. The identifier is a string with no namespace. |
Translation keys | ⚠️ Inconsistent. It is intended for translation keys themselves to not be namespaced identifiers, but keys such as |
Textures | ❌ No. These behave identically to sounds. |
As you can see, bedrock's support of proper resource locations is a complete mess. Practically every type of file has its own completely random ad-hoc implementation for how it should be identified.
In Java Edition, every file is referenced using its namespaced "resource location," which is derived entirely and unambiguously from its path. So a function located in data/project/functions/attack.mcfunction has the resource location project:attack. It's that simple, and is the case for everything, from images and sounds to functions and loot tables. This greatly simplifies the organization of files, and the cognitive burden of figuring out how to reference them. You don't get to decide whether you want to use a namespace or not because all of your files must go in your namespace's folder! This is the case for vanilla as well as custom packs.
Vanilla bedrock itself ignoring namespaces on many of its assets is a major issue! Identifiers without namespaces in vanilla force packmakers to choose between either (A) following vanilla's example by excluding namespaces, causing conflicts with either vanilla itself in the future, or packs that make the same choice; or (B) adding hacky faux-namespaces to as many assets as possible, creating duplicate folders and disorganized projects.
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response.
Is this still an issue in the latest version? If yes, can you please add it to the affected versions (or mention it if you are not the reporter)?
This ticket will automatically reopen when you reply.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki