Draco18s

Your texture had some not-quite-fully-transparent pixels.

You don't have any code there. main/java is missing.

This is what I've had to do to insure that changes get sent. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L95-L98 This is also assuming your read/write NBT methods are overridden to include the data you want to send.

If it's in defaults and the variants don't change it, you don't need it in the variant block.

And likely, neither does anyone else. Personally I'd rather use Eclipse for C# instead of Visual Studio, but that's not going to happen any time soon.

$10 says that your texture isn't transparent. I don't see anything wrong with your JSON model.

You can also use ItemMeshDefinition and JSON models: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L80

JSON transformations are only X and Y, it assumes that Z rotation is just a combination of X and Y (because North is basically the same as East)

It's a registry name, name it whatever you want, just like you would a block or item.

Expected name at line 15 column 8 path The json is valid JSON but it's missing a required key entry

Also no. ModelLoader is correct.

Translate, rotate, translate back.

Loading a world happens waaaaaaaaay after item creation and registration. Your objection is wrong. Your renderer is broken because its happening BEFORE YOUR ITEMS EXIST.

There's already a recipe for combining two identical (and damaged) items. I'd use that class as a basis for creating your own recipe.

You should always register the items. ALWAYS. If you don't want them to be available, don't create recipes for them.

I actually utilized the class version structure to create my EasyRegistry implementation before we had the registry events. I'm not saying it was better, but the hierarchical nature of the common periodproxy being a class meant that item registration (GameRegist.register calls) were in a common location and client only aspects were in the client subclass. However, those methods were generic, they contained no references to outside objects (even the static methods only referenced the main mod class in order to get the proxy instance). All of my blocks and items were handled in the main mod class. Making that work with IStateMapper (and a few other things) was a hassle, but I managed it. Unlocalized name might change for subitems. Look at wool for example: each color had a different name, but the registration name is the same for all of them. Using getUnlocalizedName() for the regisrty name makes no sense. Mods should treat their items the same way.

Use two ItemHandlers. Wrap one in this: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java

Well....a Block will never equal an IBlockState... Also, you shouldn't use getStateFromMeta, use getDefaultState().withProperty(...)

Nope! The fake-items method sounds pretty reasonable. When it's equipped, shove anything in the other slots to the player's inventory and then fill them with the "fake" items. When any of them are removed (either the fake item gets an "I am in the inventory" update or an "I am an entity item" update) destroy the fake ones and put the chest piece back into the user's inventory.

Name it whatever you flipping want.

You also have a "HJarmor" that should be lower case: GameRegistry.register(HalJordanArmor = new HalJordan("HJArmor", HJArmor, "HJ", EntityEquipmentSlot.CHEST)); This is backwards: this.setUnlocalizedName(unlocalizedName); this.setRegistryName(Main.MODID + ":" + unlocalizedName); You should use the registry name to set the unlocalized name: this.setRegistryName(unlocalizedName); //of course 'unlocalizedName' is a bad name for this parameter now this.setUnlocalizedName(this.getRegistryName()); This appears to be unused: public String textureName;

He's referring to https://en.wikipedia.org/wiki/Generics_in_Java

Thanks. Last time I messed with it was 1.7 and I am not sure where that code is any more. And its been made entirely obsolete since (the purpose it served got written morebetter by someone else).

I poked around with this once a while back. There should be an NBTTools or NBTHelper (NBTCompressionTools?) class somewhere that deals with doing the actual File IO. You'd pretty much just need to invoke the methods in it and pass in the NBT and the file path.

Well, tecnically it did... The registry name is used as the file name... Changing one to match the other will fix it regardless of which one you changed.