Draco18s

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.

#1: You're wrong, it's 3 values, not four. #2: No integers are present, see #1: you're wrong, its 3 values not 4. #3: 1, 1, 0 is not invisible, it is yellow: Ergo yes, you're an idiot. The reason it isn't showing up has nothing to do with the color values, but the fact that you're moving them around by manipulating the Z position.

http://minecraft.gamepedia.com/Sapling#Block_state The 4th bit of the metadata component number is the "stage." Saplings need to receive two block updates in order to turn into trees, rather than 1. That bit stores whether or not its already "grown" once (it's similar to crop's AGE state value). The bitwise operators are just a fast way of composing and decomposing the state into/outof metadata integers.

Oh jesus christ. First, the color arguments are only 3 values, not 4. The -2 there is not part of your color values. It's part of your "position Z" argument. Second, -1 and 0 are functionally identical. Color values range from 0 to 1 as a floating point number and are clamped to this range. Third, you didn't "find" green. You threw random numbers at it until green occurred which everyone else here could have told you (and did, actually) that green is 0, 1, 0.

Yellow is yellow that's why they call it that goofball Your computer screen does not contain yellow pixels. It contains RED pixels, GREEN pixels, and BLUE pixels. In order to display yellow it turns on both the RED and the GREEN pixels. Hence: I am now muting all of your posts because you're a bloody idiot.

You want what to do the thing you said? You want an item that activates your 9th hotbar slot? A block? An event?