Draco18s

So make a custom damage source.

While true, it completely misses the point. A static reference can only be used with non-instances. An instance reference cannot use static references. You can pass instances to a static method, but a static method does not magically contain the information from an instance just because they're the same class.

You're creating your items before creating your blocks, which causes your BlockCrop reference to be passed as null. This is an ungodly common problem that gets posted about very super frequently (like, twice a month).

Not null? Of course those are easy to find. Derp. Distracted and such. I probably retyped half the post twice.

Debug your code. You have an object that is not null. These are very easy to find.

Look at any vanilla block you can walk through. Look for any method that returns AxisAlignedBB.

What the..?

Well...."pmcheese" isn't equal to cheese.getRegistryName()

I've never had anyone complain, but I recognize your point as valid.

Exactly what I (tried) to do. Ended up realizing I'd done it in a way that didn't do what I'd been trying to accomplish. Ended up with a scenario where I had to increment the number that was the "Library" version number despite the library not having actually changed. The 1.10 version numbers will fix that. The major-est number will be explicit the Library version, rather than just a major revision. Except that the reason I'm doing it is because my users explicitly requested it. They wanted a single feature I had in a mod as its own mod, without all the other things the main mod did. I did split it off as a standalone feature, but the two mods were effective "mutually exclusive" with each other (although checks were made to insure that singleton static references behaved nicely). So in the 1.10 rebuild, they're properly separate, and the main mod instead depends on the single-feature mod.

What I did was just have separate packages in my workspace (mod.draco18s.library, mod.draco18s.mod1, mod.draco18s.mod2...) and use the build.gradle file to set up separate build tasks that would put the compiled code into separate jar files. A few other folks will have other suggestions, but this is the one that worked for me.

Looks good, but for one thing that I made a comment about.

That's actually an O(n) operation, not an O(2n). You're still doing one loop, you're just comparing "old vs. new" and then either Doing Stuff or not, then saving new to old. You don't need to loop twice. But yes, not the most efficient way to do things.

The problem is, you've overlapped two different ways of handling containers (the old way and the new way) and the two don't talk to each other. At all. You just kind of float along hoping Magic will solve it, but it won't.

Also, if you do any tooltip stuff, or other text-on-screen that you translate, good practice to put your modID in those too. e.g. from one of my items: @Override @SideOnly(Side.CLIENT) public void addInformation(ItemStack stack, EntityPlayer playerIn, List<String> tooltip, boolean advanced) { tooltip.add("+10 "+I18n.format("description.harderfarming:damagebonus")); }

This: Item myItem = new Item(); myItem.setRegistryName("my_cool_item"); System.out.println(myItem.getRegistryName()); Will print: mymodid:my_cool_item Basically, it takes whatever string you input and prepends your mod ID so that Minecraft can locate all assets related to your item: blockstate files, model files, etc. It's also good practice to set your items' unlocalized name to the registry name: myItem.setUnlocalizedName(myItem.getRegistryName()); So that the unlocalized name contains your mod ID and prevents language translation collisions between mods (e.g. two mods using the same unlocalized name for unrelated items).

Sooo...first off...neither CROP_ROCKCRESS nor FERTILESOIL appear to have a registry name set (it is definitely missing for FERTILESOIL, as it is in neither the constructor nor the register function). This is bad. VERY VERY BAD. Until you fix that, I cannot help you with models.

Don't check against BlockCrop or of BlockBush. Check against IGrowable. Its the interface that all bonemeal-able blocks implement somewhere in their higherarchy.

While the advice trollworkout is mostly correct, I would make one small change: Rather than item.setUnlocalizedName("ingot_copper").setRegistryName("ingot_copper") I would do: item.setRegistryName("ingot_copper"); item.setUnlocalizedName(getRegistryName(); This puts your modID in your unlocalized name string, which avoids conflicts, should another mod use the same unlocalized name (which for an item like "ingot_copper" is non-zero).

Well, bonemeal outright increases the plant's AGE state. If you want to force-tick it, you'll want world.scheduleBlockUpdateTick() But that'll only make it tick once, which may not make it grow at all.

It should throw a logging error. Also, use ROCKCRESS.getRegistryName() instead of "PMReference.MODID + ":" + "pmrockcress"

ModelLoader.setCustomModelResourceLocation

Well. ItemSeedFood (if vanilla*) doesn't implement ItemModelProvider, your class. So of course your register(...) method isn't going to register an item model for it. *The vanilla class is ItemSeeds. Oh derp, carrots/etc.

The problem is not that the method he wants to override is private, but that that method invokes other methods which are private. So to duplicate the base (public) function he needs to duplicate several private methods as well. I'd suggest a forge PR that makes those methods and fields protected.

Following that, what do you mean by "activate"? Do you mean "left click action" or "right click action"? Also, take a look at how Minecraft handles input for the [9] key and the mouse buttons.