Sieve Registry with NBT Data Tags / Forestry Integration
Opened this issue · 12 comments
The current SieveRegistry.json does not appear (I found no documentation of this) to support custom items with NBT tags. If this is possible to implement, that would be great, particularly because of the lack of Forestry bee support. The idea for this came about while I was playing a modpack with Forestry, which needs bees for most things in the mod. Normally beehives spawn in the overworld but since skyblock is what it is there is no access to bees at all. I attempted to add bees to the sieve registry so that if you sift leaves you have a really small chance of getting a princess/drone (and gravel for rocky princesses/drones), but since bees need proper NBT data in order to work, I can't do that. But, if datatags are added to the JSON sieveregistry then we can do this. A feature like this would be greatly appreciated. Thank you!
Currently this is what the registry looks like:
"ore:cobblestone": [
{
"drop": {
"name": "minecraft:diamond_sword",
"meta": -1,
"nbt": {
"ench":[{"lvl":5,"id":21}],
"display":{"Name":"Excalibur"}
}
},
"chance": 1.0,
"meshLevel": 1
}
]
Is this what you had in mind?
Just to point it out, forestry addons like More Bees may also need to initialize first for the same reason
Figured that one out myself :P.
Got a working branch with forestry+addons integration that doesn't break Ex Compressum.
This issue is addressed in PR #113.
When adding default forestry recipes I found that forestry doesn't load genetic templates until after our registry changes. Moving our recipes to post-init seems to break Ex Compressum compat.
This will be a mess to sort.
@blay09 does ex compressum have a method for us to prompt it to reload its recipes?
Any kind of reloading would result in the JEI recipes to no longer be accurate, and workarounds to fix that by forcing to load before JEI is going to result in circular dependency errors: Jozufozu/ExNihiloOmnia#102.
I don't know if I fully understand the issue but it looks like Forestry is registering its genetics stuff in init, so moving the default registries to init and specifying dependencies = "after:forestry;" in your @Mod annotation should solve the problem.
