Draco18s

Do you know how tags differ from items? You have specified the former and your mod contains the latter.

Yes, because: And you've got ten more like it. When data pack loading fails, it often causes all data packs to not be loaded (I had a bad advancement once that made vanilla recipes not work).

The thing to search for is any lines containing "Exception" or "Caused By" (note that there will always be one about failing to verify the account, as the dev environment has to be configured to use a real account).

Nothing. Literally nothing. Remove the =, I underlined and bolded it too. That's a separate issue for which you have no provided any log files.

You see this bolded underlined part? Remove it. Use annotations. As for the null, you need a block there. That block would be your crop block that the seed plants.

All of this, use @ObjectHolder. This should be BlockNamedItem or BlockItem as you want the item to place a block, which a regular Item can't do. In either case, it is not pointing to the class you originally said was your seed's class (MSeed), nor is that class referenced at all.

See this thread:

Refer to the documentation, but as an example: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L174 More information is required. It would be best if you posted your project as a working git repository.

Don't use static initializers. If this isn't static, then don't assign the field yourself, use an @ObjectHolder annotation. Your seed class does not have any references to IBlockAccess, it does however have to references to IBlockReader, is that what you meant? Either way, you haven't said what "the problem" is with those lines, only that you suspect that something's wrong. Other than having wrapped it in <>... Your "seed" is a CropsBlock, so its not even an item. You have also implemented IPlantable, which is completely unnecessary. Here's an example seed: public class WinterSeedsItem extends BlockNamedItem { public WinterSeedsItem(Block cropBlockIn) { super(cropBlockIn, new Properties().group(ItemGroup.MATERIALS)); } @Override @OnlyIn(Dist.CLIENT) public void addInformation(ItemStack stack, @Nullable World worldIn, List<ITextComponent> tooltip, ITooltipFlag flagIn) { super.addInformation(stack, worldIn, tooltip, flagIn); tooltip.add(new TranslationTextComponent("tooltip.harderfarming:growsColdWeather")); } } And the only reason I need an entire class for it is because I wanted to add information to the item's tooltip. If you're not doing that, then new BlockNamedItem(...) is sufficient. And example crop: public class CropWinterWheatBlock extends CropsBlock { public CropWinterWheatBlock() { super(Properties.create(Material.PLANTS).tickRandomly().hardnessAndResistance(0.0F).doesNotBlockMovement().sound(SoundType.CROP)); } protected IItemProvider getSeedsItem() { return HarderFarming.ModItems.winter_wheat_seeds; } }

Step 1: create a new loot table json for the block you want to modify (and named with the name of the block). Step 2: if you want to override completely, place this file in data/minecraft/loot_tables/blocks. If you want to add to, place it in data/<modid>/loot_tables/blocks Step 3: if you want to override completely, you're done. Otherwise, subscribe to the LootTableLoadEvent: @SubscribeEvent public static void onLootLoad(LootTableLoadEvent event) { if (event.getName().equals(new ResourceLocation("minecraft",the_block_to_modify))) { event.getTable().addPool(LootPool.builder().addEntry(TableLootEntry.builder(new ResourceLocation(modid,filename))).build()); } }

Show your updated code.

Wait, what? Why are you using vi? Get a real IDE and not a text editor.

That's not how that works. https://github.com/Draco18s/ReasonableRealism/tree/1.14.4/src/main/resources/data/minecraft/tags/blocks

F5 is a shortcut hotkey for it, too.

Ok. Then you did a bad job of explaining what you CAN do as you just stated over and over what you CAN'T do. In trying to tease out what it is you CAN do from your posts.... You know you don't have to extend item and implement an interface on the same class, right? Put the interface stuff off in a soft-dependency area and when the interface methods get called, it can have a reference to your item and pass over (or get) the necessary details to do its thing.

You still have not

Then why are you converting it to a string? boolean isPowered = state.get(SWITCH_POSITION) == Corners.TURN And I don't think that this is what you want to check anyway.

Uh. That's a stack, not an item.

You haven't explained why you can't pass an ItemStack but can pass an Item. Is it because this other mod requires an item be passed because that's the method signature? Already you're in dependency territory, that stuff lives inside the `doStuff` implementation D7 talked about. Everything outside of `doStuff` doesn't know about the method that only accepts an Item.

Interfaces are code-objects that describe what an object has or can do. Consider this example: Knobs expose a method called "twist": interacting with a knob involves twisting. - Dimmer switches are Knobs Toggles expose a method called "change state": interacting with a toggle involves changing its state from ON to OFF or vice versa. - Light switches are Toggles Buttons expose a method called "engage": interacting with a button involves changing its state from OFF to ON, and it automatically changes back when you stop. - Keyboard keys are Buttons A bathroom fan timer implements both Knob and Button in the sense that you interact to twist it, but it automatically turns back OFF after a duration because you've stopped interacting with it. Abstract classes are a code-object that exists halfway between a typical class and a typical interface, providing some default functionality, but leaving some up to its implementors. None of that is relevant to events, however. What D7 is referring to is that the PlayerInteractEvent is that it has subclasses that are more specific. Always use the most specific event for what you are doing.

That's in the entity itself, and the check is thus: if (entity.getPushReaction() != PushReaction.IGNORE) If isn't ignore, they're going to get thrown.

I misread your post originally. The same method is used for both effects, there's no way around this.

The first three are empty methods, so they currently do nothing. "setup" is just a generic point in time to do "setup" style tasks. It's called setup because the event that fires it is the FMLCommonSetupEvent. The Two IMC methods are for handling IMC things: Inter Mod Communication. In this case the mod only receives messages and simply logs them to the log file. Some older info can be found here. The events have changed, but the usage is the same.

Other vanilla blocks? No.

Start with an issue, so that folks can figure out what makes the most sense. The grow-into-large-mushrooms thing is typically only when bonemealing (or on mycellium? or mushroom island biome??) so it doesn't really count there either for what I'd call "growing."