Draco18s

You have done something horrifyingly wrong if your server proxy is directly calling your client proxy!

This is because your model file: Does not have a definition for the #all texture reference. eg: "textures": { "all": "[some texture png]" }, Nor is this specified in your blockstate file. Also, these: "textures":{ "visible=true": "cruelars_triforcemod:blocks/air", "visible=false": "cruelars_triforcemod:blocks/dungeonbrick" } Are creating texture references, #visible=true and #visible=false. They are NOT variants! You could then reassign these textures in your blockstate file: "variants": { "visible=true": { "textures": { "#visible=false": "[some new texture png]" } }, ... }

Metadata is limited to 16. Also metadata is an implementation detail. Use IBlockState properties.

Well if you want a damaged anvil to look like an undamaged anvil (but is still damaged) I would not like that as a player: I would never know when my anvil might just poof out of existence. If you want to change the anvil back to a less-damaged state, just change its state. (Other properties: sure, these exist, but none of them are "different" for the different stages of anvils, this is why I asked).

What do you mean, "change its properties"?

oh, absolutely you can do this. But the block needs to exist in the world. It can't be phantom.

Still troublesome, but possible. I know I've seen people do similar things before. Trying to think of how to search for it... Try these:

Oh god, you're in for a world of trouble. Getting the visuals is one thing, allowing to climb it is another. Ladders (and vines) are climbable due to the collision box and other properties that the block has. If the block isn't real, you can't mimic that behavior.

The second block parameter goes into a field named unused. It is unused. The array of strings are a parameter called namesByMeta. Which would be the block's name by meta (e.g. "yellow glass" or "white glass") handled like this: public String getUnlocalizedName(ItemStack stack) { return super.getUnlocalizedName() + "." + this.nameFunction.apply(stack); } Where the nameFunction determines which string in the array to use (handled for you). All that said, there's nothing stopping you from creating your own ItemBlock subclass or using a different one (ItemColored?). Block metadata isn't used any more, except as a means of serialization. It's an implementation detail. And even that is going away in 1.13.

No, its not. Minecraft has metadata blocks too (wool, planks, logs). Here's the list of vanilla ItemBlock subclasses: ItemBanner ItemCloth ItemColored ItemLeaves ItemMultiTexture (This is the one I couldn't remember the name for that you want) ItemPiston ItemShulkerBox ItemSlab ItemSnow

Again, its handled by the ItemBlock.

That's where the custom ItemBlock class comes in. Right now you're using ItemBlock, which by default, places the default state of the block, ignoring any item metadata. Look at the type hierarchy for ItemBlock, I know vanilla has a meta-specific version.

I'm still seeing a File Not Found error: Caused by: java.io.FileNotFoundException: blockstatetraining:blockstates/blockstatetraining.json

Here's an example of an ItemStackHandler in use: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java the outputslotwrapper is used for the GUI so that the player can't insert items into the output slot (but the machine can still do so when it generates its output). Predominantly you will want to look at getCapability.

Ah, sorry, for blocks that have variant items you need registerBlockWithCustomItem, so you can pass in a non-default ItemBlock instance (vanilla has one, I think its ItemBlockColored for colored blocks). There's a lot of register variants and I can't always remember the right one without looking (they are, however, intelligently named). Mind posting the whole log on Pastebin? The error isn't pointing to anything specific still.

You will need to show the whole error. I need the "Caused By" line that comes later. Odds are, something is wrong with your blockstate or model file.

Problem #4: ITileEntityProvider is outdated, still using numeric metadata as a paramter, rather than a fully defined IBlockState For BlockContainer, it will cause issues, as BlockContainer overrides several methods of the block class that it is very unlikely that you actually want to override, such as what model type your block uses. 90% of TileEntity blocks do not need a TESR, but BlockContainer sets the default model type to INVISIBLE in preparation for a TESR. Problem #5: IInventory is deprecated in favor of more flexible and inter-mod compatible Capabilities. Problem #10: Problem #14: You cannot control the order of execution when dealing with static initializers. As a result you can have objects created before the other objects they depend on (e.g. a CreativeTab that gets created with a null item icon, or an item that gets a null creative tab).

You don't need to test any of the fixes from problems 10 and 14. 4 takes literally 30 seconds to fix and test: all you're doing is overriding a different method and removing the implements/extends. Fix 5 is the only one that takes more than token effort. You can do 4, 10, and 14 pretty much all in one go.

Just make this a subclass of the existing ItemStackHandler class that overrides the extraction and insertion code to do that synchronization. When an item is inserted, convert it to a stack of cobble, and insert that into the super implementation. When non-cobble is extracted, give the player the stack without reducing how many of that stack is available for extraction (unless their EMC falls too low) and modify the EMC available based on its cost.

Its a block, use the RegisterBlockWithItem method, it will automatically create and register the item form.

Diesieben07 here is a forum moderator. It doesn't help you to talk down to him.

Yes, you would need those too. You can put them anywhere convenient, just update the package names and import reference. I forgot about those two. IMetaLookup is how I handle enum variants for items, e.g. this enum and this item. IItemWithMeshDefinition is used for custom mesh definitions (you can omit this one and any code that uses it, if you don't need NBT-driven models, e.g. this item). They just let me specify strict types for the generic methods and know that I'm getting everything needed in order to register things completely. Its not perfect, but once set up it works amazingly.

All you should have to do is: Copy-paste the raw text into a class file somewhere in your project. Let Eclipse rename and fix package declarations as needed. Replace all references to Hardlib with a reference to your own mod. Be aware that these classes were proxy-based. If you copy the code into your common proxy and your client proxy, you will just need to replace HardLib with your own main class name.

Honestly? Grab these two classes. They're set up as Common/Client proxy, just wire them up to use your own mod class rather than HardLib and change the package name (or if you want, declare a dependency on HardLib, I wouldn't mind the extra downloads). Then use EasyRegistry.registerItem(...) and EasyRegistry.registerBlock(...) (or the -WithVariants version). I've done a lot of work to make the system easy to use and still conform to proper registration methods.

I've never looked at the system before, so all I can really say is... Good job, you've got something functional. Probably. (I still can't make sense of the system)