Error in the API wiki
Da-Technomancer opened this issue ยท 6 comments
There's an inconsistency between the UniDictAPI wiki and the code, and I'm not sure which is meant to be correct.
The wiki (under Integrations) says that to create an integration, the class must extend wanion.unidict.integration.AbstractIntegrationThread. It also says that other mods may include integrations with UniDict using AbstractIntegrationThread. However, this is incorrect as the only constructor for AbstractIntegrationThread is package-private, meaning subclasses outside the package can't access it. If another mod wants to extend it, it can't because it can't access the only constructor.
Is this an error with the constructor or the documentation?
While I'm asking questions about Integrations, I have one other. If a mod has an item which, while oreDictionaried, has a functionality which means it should not be unified, how can that mod prevent UniDict from removing the item from recipes/jei through the UniDictAPI? addItemStackToBlackList(ItemStack) doesn't seem to have the required effect, and neither did adding the mod adding the item (small gears from Crossroads) to the ModID blacklist through addModIdToCraftingIntegrationBlackList(String modId) or the config seem to have any effect.
Ah, that makes sense now.
When there are multiple items from the same mod (or vanilla) that share the same oreDict, such as the saplings ("treeSapling", I just looked in JEI without Forestry installed), perhaps UniDict should automatically avoid unifying those (if it doesn't already).
I don't think vanilla or Forestry provide crafting or processing recipes that output saplings though - I'm fairly sure Gendustry does, and possibly Binnie's. There's also Mystical Agriculture, which adds "seedsTier1", "seedsTier2", up to "seedsTier5", and "essenceTier1" through "essenceTier5". I'm not sure why MystAg ore-dictionaries all its seeds and essences, though, since there don't seem to be any crafting or processing recipes that can use them interchangeably.
@Da-Technomancer the blacklisting occurs on the end of init, this is why it isn't working =P
wops, I forgot to make it public, and, honestly, I never though anyone would want to create an integration for UniDict, I guess I was wrong XD
about blacklisting specific items, the method UniDictAPI.addItemStackToBlackList(ItemStack)
was supposed to be able to do it, it isn't working?
ResourceHandler.java#L169
If a mod has an item which, while oreDictionaried, has a functionality which means it should not be unified
Perhaps I'm misunderstanding something here, but wouldn't such functionality make it inappropriate for the item to be oreDictionaried?
WanionCane:
During the PostInit loading stage I called UniDictAPI.addItemStackToBlackList(ItemStack)
with a size 1, metadata 0 stack of the item I don't want unified. It got unified anyway, and into another mod's version of the item. Adding the name into the config (with the "#0" at the end) also did nothing. The item is only ever used in the metadata 0 form.
MauveCloud:
The oreDictionary means two items are equivalent for recipe purposes, not necessarily for all purposes. It's just uncommon that this matters. For example (don't quote me on these), I think all forestry saplings (or even vanilla saplings) share an oreDict despite growing different trees.
Trying to blacklist at different loading stages still had no effect.
Using this code:
if(Loader.isModLoaded("unidict")){ UniDictIntegration.setup(); }
With UniDictIntegration being another class, where preInit calls UniDictAPI.addItemStackToBlackList
with the ItemStacks really seems to do nothing, no matter where in the loading cycle I put the call. I've tried postInit, preInit, and init. In all cases the logger shows that UniDictIntegration.setup
is indeed being called with the correct ItemStack, but when I actually view the item in JEI it's been overwritten by another mod's version.