ninety

Nice, the ConditionalRecipe looks like it might be just the thing I'd need. Thanks! On second thought, I still don't exactly like the "dummy item" approach in general here. At my own risk, I've gone for the "all of nothing" approach in the end of conditionally registering the extra items from somewhat more generic Item-like definitions.

Returning briefly back to this topic, would it be possible at least to do things like disabling crafting recipes outright for an item if some condition (in this case, the other mod being present) isn't met? While I'm content with the dummy item approach for now, I'd rather they remained as far away from view as possible if there's otherwise no reason for them to be used.

Was worth a try. I'll just have them be dummy items otherwise.

I'm currently writing an add-on for another mod, but also wish to add integration with yet another add-on within mine — more specifically, an AE2 add-on for larger tiers of storage cells with Applied Mekanistics integration to also offer higher-capacity chemical cells for use with Mekanism. As part of that integration, I am trying to create and register some new items only if the other add-on is also installed and attempting to make use of Object holders in order to retrieve registered instances of those items. So far, I've been successful in adding these items and making them work when the other add-on is installed. However, attempting to run a game with my add-on installed but not the other optional one results in an IllegalStateException crash because of the Item holders not having a registry entry to inject from. I am not sure how to handle this case, so I would like to know how to go about only having these items in the presence of another mod. Huge disclaimer: I am very new to a lot of the mod-making process in Forge and this is also my first time using some of the features in it, so my code will most definitely look like shit in a few places. I have a GitHub repo for my add-on here with the beginning of this integration attempt committed to it just now. Full crash report:

Apologies in advance if I'm going to be missing anything fairly obvious, but I'm not quite sure what approach to take here. I am attempting to implement an automated version of the vanilla Smithing Table such that it has its own tile entity and item handler, and allows items to be piped into the input slots and extracted from the output slot. Hence, I figured making the container for this table extend SmithingTableContainer would be enough to start with, though now I'm not sure how I would go about tacking the desired tile entity behaviour onto it and I'm very likely cutting a few corners trying to go about it this way. Is this approach feasible in the first place or would I be better off extending the pure Container class and re-implementing most aspects of SmithingTableContainer in this new class? Should go without saying that I am very much a novice with Forge still; the last I used it (circa MC 1.8) I had next to no idea what I was doing from a programming standpoint either.