Draco18s

You don't need all of these: https://github.com/dustpuppy/wizardmod/blob/master/src/main/resources/assets/thewizardmod/models/item/magic_extractor.json#L4 For any model unless you want the model to be different than the default values present in item/generated. Similarly... https://github.com/dustpuppy/wizardmod/blob/master/src/main/resources/assets/thewizardmod/models/item/iron_wand_0.json#L2 Use item/generated not builtin/generated. Third: Post your log. If models don't load, there's always an error.

Sure. Which is why I recommended it.

No one said "every time" Lex:

The "click and reset growth" is usually done via right click not left. As for how to handle that, there's a player interaction method in the block class for the block being right clicked. Check for pickaxe, set the growth age back to 0 (or 1 or whatever), drop a shard, and damage the pick (if you want).

Lookup performance wise, ObjectHolder is probably faster. After that, it's going to be the same. Personally I'd recommend ObjectHolder.

Just returning super means you did dick with the function and shouldn't bother with the override at all. So yes, return true and the itemstack you want to stay in the crafting grid. (With d7 ninjaing me by a few seconds)

Either put this in Support & Bug Reports, open an issue on Github, or create a pull request on Github.

Override hasContainerItem() and getContainerItem().

You need to copy the AI behavior resposible, modify it, and use it instead of the original.

Uh... Use the metadata value that that state encodes to in your getMetaFromState?

Neither of those are going to do what he wants. The former will still generate, only now its his ore that generates (and in a location he doesn't want it to). The latter is only useful if he replaces the ore block with stone or we end up in the same situation again: only now its his ore that generates (and in a location he doesn't want it to).

This line does jack and all. Get rid of it. ModelLoader is SideOnly(CLIENT), you can't have it in common code. You are not using ObjectHolder correctly. If you are assigning the value yourself, you don't need the annotation. You're doing nothing with this hashset except adding things to it. You don't need it. You're registering two different model variants for the same item-metadata combination.

This would be covered by IBlockStates pretty well. All you have to do is properly define your blockstate json.

FFS. They are two different ways of doing the same thing. You either make a common proxy (which is used server side) and extend it for the client proxy, or you make the common proxy an interface which the server and client proxy implement. I never said "I believe ClientProxy should extend" I said I still do it this way, even though it is bad.

Yes.

Ok, so 1: ModelLoader.setCustomModelResourceLocation( item, meta, new ModelResourceLocation(Reference.PREFIX + id, "inventory") ); item.getRegistryName(), magic. 2: You're registering your item models at the wrong time. You must use the ModelRegistryEvent. 3: you didn't post the log, so there's still the possibility of several problems: The possibility that the file is in the wrong place / misnamed (despite what you've said) The possibility that the file isn't a valid json file (even though it looks like it) The possibility that the texture is in the wrong place / misnamed

I still go by the ClientProxy extends CommonProxy setup myself. <_< Mind, that came in handy when I built my EasyRegistry (they act as a common and client proxy, with the common actually containing a large portion of code, but code that makes no sense to be anywhere else).

Move everything in CommonProxy.class to your main mod class. Then retype the CommonProxy to an interface.

It's called twice. All you have to do is check "is hand == mainhand" in that last if-block. That prevents an empty off-hand from making the "dog" sit.

I don't know, but you can easily fix this by making it do nothing if the hand is the off-hand.

Ok, good, you didn't fuck up the usual suspects. Unfortunately I can't identify the problem. :\

The function is called twice: once for each hand. If both hands are empty, the "dog" will get toggled twice in a row. You make no discrimination about which hand is being used (you do identify if the hand is holding food/dye/etc items, but the "dog" only sits when the hand is empty, and if both are empty, you process that interaction twice: sit, then unsit).

Show me. Like this:

You might actually want the function getMouseOver() in EntityRenderer, it's pretty much what you're looking for (note: this existing method is client-side only and if you need to run the code on the server, you will have to duplicate it).

The bit diesieben07 forgot to say ways, "Use UUIDs"