Environment:
Mod version: AbsoluteOrder-2.0.0-forge-mc1.20.1.jar
Minecraft version: 1.20.1, Forge
Conflicting mod: The Aether (registers a creative tab with path building_blocks, colliding with vanilla's own tab of the same path but different namespace)
Root cause (found via decompilation):
In ChestSeparatorsEditor, creative tabs are assigned to fixed UI slots by comparing only the tab's ResourceLocation path, ignoring the namespace:
java
BuiltInRegistries.CREATIVE_MODE_TAB.forEach(group -> {
ResourceLocation id = BuiltInRegistries.CREATIVE_MODE_TAB.getKey(group);
String path = id.getPath();
...
if (path.equals("building_blocks")) {
this.session.availableTabs.set(0, tab);
} else if (path.equals("colored_blocks")) {
this.session.availableTabs.set(1, tab);
}
// ...and so on for other fixed slots
});
Since this iterates every registered tab from every mod and matches purely by path string, any mod that registers its own tab under the same path as a vanilla one (e.g. The Aether registers aether:building_blocks) will overwrite the vanilla minecraft:building_blocks entry in availableTabs, because registry iteration order isn't guaranteed to put vanilla first, and there's no guard against the collision.
Observed symptom:
Slot 0 (intended for vanilla "Building Blocks") instead shows "Aether Building Blocks".
Vanilla items that live in the real Building Blocks tab (e.g. Oak Log) never appear in the Search tab's results or via manual tab browsing, since the mod is scanning Aether's tab contents instead of vanilla's for that slot.
Vanilla items in tabs without a naming collision (e.g. Wool, in the colored_blocks tab) work correctly, confirming the issue is isolated to specific tabs with colliding paths.
Suggested fix:
Compare the full ResourceLocation (including namespace, e.g. minecraft:building_blocks) instead of just getPath(), or explicitly prioritize minecraft:-namespaced tabs when a path collision is detected.
Additional testing done:
Confirmed reproducible in a brand-new world.
Importing items directly from chest/inventory contents works fine (bypasses this tab-based lookup entirely).
Searching for wool (tab: colored_blocks, no collision) works correctly; searching for log (tab: building_blocks, collision with Aether) fails.
Visually confirmed via the tab bar that slot 0 displays "Aether Building Blocks" instead of vanilla "Building Blocks".
Environment:
Mod version: AbsoluteOrder-2.0.0-forge-mc1.20.1.jar
Minecraft version: 1.20.1, Forge
Conflicting mod: The Aether (registers a creative tab with path building_blocks, colliding with vanilla's own tab of the same path but different namespace)
Root cause (found via decompilation):
In ChestSeparatorsEditor, creative tabs are assigned to fixed UI slots by comparing only the tab's ResourceLocation path, ignoring the namespace:
java
BuiltInRegistries.CREATIVE_MODE_TAB.forEach(group -> {
ResourceLocation id = BuiltInRegistries.CREATIVE_MODE_TAB.getKey(group);
String path = id.getPath();
...
if (path.equals("building_blocks")) {
this.session.availableTabs.set(0, tab);
} else if (path.equals("colored_blocks")) {
this.session.availableTabs.set(1, tab);
}
// ...and so on for other fixed slots
});
Since this iterates every registered tab from every mod and matches purely by path string, any mod that registers its own tab under the same path as a vanilla one (e.g. The Aether registers aether:building_blocks) will overwrite the vanilla minecraft:building_blocks entry in availableTabs, because registry iteration order isn't guaranteed to put vanilla first, and there's no guard against the collision.
Observed symptom:
Slot 0 (intended for vanilla "Building Blocks") instead shows "Aether Building Blocks".
Vanilla items that live in the real Building Blocks tab (e.g. Oak Log) never appear in the Search tab's results or via manual tab browsing, since the mod is scanning Aether's tab contents instead of vanilla's for that slot.
Vanilla items in tabs without a naming collision (e.g. Wool, in the colored_blocks tab) work correctly, confirming the issue is isolated to specific tabs with colliding paths.
Suggested fix:
Compare the full ResourceLocation (including namespace, e.g. minecraft:building_blocks) instead of just getPath(), or explicitly prioritize minecraft:-namespaced tabs when a path collision is detected.
Additional testing done:
Confirmed reproducible in a brand-new world.
Importing items directly from chest/inventory contents works fine (bypasses this tab-based lookup entirely).
Searching for wool (tab: colored_blocks, no collision) works correctly; searching for log (tab: building_blocks, collision with Aether) fails.
Visually confirmed via the tab bar that slot 0 displays "Aether Building Blocks" instead of vanilla "Building Blocks".