V0idWa1k3r

onBlockHarvested is called when the block is harvested by the player. The default implementation invokes getDrops. getDrops populates a list with drops from the block. The default implementation invokes getItemDropped. getItemDropped simply returns the Item to drop. It may or may not be called in a custom implementation of getDrops.

The problem with villager trades is that they are not fixed, see EntityVillager.ListEnchantedBookForEmeralds for example - it just gets a random enchantment from the registry, and you can't control it in any way. You could iterate the profession registry, then iterate the careers, iterate the list-in-a-list in each career and remove those kind of recipes but it won't include custom modded trades and you will be deleting all trades like that, not just your specific enchantment. You could make a system that checks whether the enchantment is applicable for the trade, say add Enchantment#canAppearInTrade or something and submit a PR to forge.

You could use reflection. The problem with that is that you can't call super in your constructor since the constructor of the original class is private. And you must call it because MapColor doesn't provide a parameterless constructor. Alternatively I suppose you could use access transformers, but that is not an ideal solution. Or you could submit a PR to forge.

https://gist.github.com/OtisGoodman/96da24295c450bc02f4d58890ef60faf#file-shoutbook-L59 https://gist.github.com/OtisGoodman/96da24295c450bc02f4d58890ef60faf#file-shoutbook-L124 So if the stack has no NBTTag you create a new one and then do nothing with it. You need to assign it to the stack with ItemStack#setTagCompound https://gist.github.com/OtisGoodman/487e771261a107a451c20d97f7712504#file-cmdshout-L45 Any particular reason you are implementing ICommand directly instead of using CommandBase?

Utilize your renderer class. In the render method check the distance to the client's player, if it is less than the distance you want then change the RenderLivingBase.mainModel field's value to your other model. Or override RenderLivingBase#renderModel and render a different model there.

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L100 This happens because minecraft's code is obfuscated, meaning that the names of the fields in the deobfuscated(dev) version don't match the names in the build version. Use ReflectionHelper/ObfuscationReflectionHelper's methods. You must provide an SRG name of the field/method to those methods(if you are using ReflectionHelper then you must also provide the dev name). You can get the SRG name using mcpbot or you can find it on your pc in your gradle caches. Unrelated to the issue but still issues with your code: https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L28 Don't ever use static initializers they can and will cause numerous issues. Instantinate your stuff directly in the appropriate registry event. ItemBase is an antipattern, there is already an ItemBase, it's called Item. https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L60 https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L146 You can't do this, since the method will be stripped away on the physical server. You might crash with a JVM error as a result because the method referenced in the code is no longer there. If you need to perform a side-specific operation use a proxy. https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L103 Don't just catch exceptions, scream that they are there and continue as if nothing happened. If an exception like this occured you should crash the game. https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/proxy/CommonProxy.java A CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. This makes even less sense. Your common proxy can't be your server proxy. A server proxy either provides NOOP implementations for client-only methods or utilizes code that would crash the physical client. Common code is neither. https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/util/IHasModel.java IHasModel is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected data. Register your models directly in the ModelRegistryEvent.

It might be, but it isn't easy. The fact that it's item textures complicates things a lot. First you would need to work with a BufferedImage to have the image that is later converted into a sprite. Presumably you would serialize them into a folder of sorts on the user's hard drive. The problem here is that you also need them to exist on the server if you want other players to see the texture. Once the user has done the image in-game you would send it to the server, and the server would then send it to all other players. The image recieved would be stored on the user's hard drive. Then you trigger a resources reload. You would need to store a TextureAtlasSprite per image somewhere. You can create TextureAtlasSprite objects using TextureMap#registerSprite. Alternatively you might just instantinate one and use TextureMap#setTextureEntry to add it to the map. You need to do this in the TextureStitchEvent.Pre. Then you would either need a custom IResourcePack associated with your mod to load the images from the folder or you can use custom TextureAtlasSprite implementations that override TextureAtlasSprite#hasCustomLoader and TextureAtlasSprite#load. Finally you would need a custom IBakedModel for your item that returns a custom list of quads with your custom texture - you can use BakedQuadRetextured to easily change the textures on existing BakedQuads. The hard part here is making sure all clients are aware of the new textures. Also the fact that the resources need to be reloaded every time the user joins a server or every time a new texture is generated will upset people since reloading resources takes a while, especially on big modpacks.

Yes, using the blockstate file as item model is a forge feature. If you want to use the vanilla format then you have to have a separate model file. Which in your case may or may not be a copy-paste.

don't add "blockstates" to the path. Just leave it as modid:registry_name. It doesn't. It just sets the ModelResourceLocation association with the item and the meta passed. Determining where to look for the model file is up to the model loader. Vanilla's looks in models/items. Forge's looks for the blockstates file. Yes.

Forge blockstates is, well, a blockstate file. It goes into your blockstates directlory, not the model one. Forge will automatically use the blockstate as both the block and the item model. While I do agree with you somewhat the docs outline the structure of the format and it's usage. They don't outline it fully but they do a descent job. Just put that variant as the variant parameter in ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation. These are not the correct parameters passed to that method, it expects a ModelResourceLocation as the last parameter, not a string.

https://mcforge.readthedocs.io/en/latest/models/blockstates/forgeBlockstates/ Well, you can have the variant name be both of your properties, like in vanilla blockstates, just be sure to put them alphabetically. However this may(and likely will) override other variants. You could define every possible variant but that's a lot of work. I would rather stick to vanilla in this case.

TickEvent.[X]Tick Define "Instrumentation".

Well first and foremost a CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere but your proxy. Your issue might be caused by the fact that you have a Common Proxy but since you didn't provide any more code I can't tell for sure.

entity renderers are fine to register in preinit(on the client only, obviously). There is no dedicated registry event for renderers.

Try using ConfigManager.sync

IModel is just a collection of data that is needed to construct an IBakedModel. The easiest way is just to hve some block/item have the model you need and grab their IBakedModel. However if you absolutely must you can load a IBakedModel yourself through the usage of ModelBakeEvent. You can get your IModel by using ModelLoaderRegistry.getModel and you can get the IBakedModel from it by using IModel#bake. It does require a IModelState which is basically a collection of transformations. You can do something similar to what forge does at ForgeBlockStateV1.Variant.Deserializer.<clinit>(the static { } block). As for actually rendering it you can look at an example here.

The code you've provided looks mostly fine apart from the switch statement but that's my preference. Could you please provide more of your code, preferrably as a git repository?

That's not the reason old versions are not supported. There have been too many changes, we simply can't provide support when most of the things were changed - like the registry events, or the annotation config system which is the issue you ran into.

Anything below 1.9 is no longer supported on this forum and you've just discovered yet another reason why. Update to a modern version of minecraft to receive support.

As far as I can tell you never actually register your . You do register it's ItemBlock though.

Use the overload of that method that takes in an ItemStack as one of it's parameters.

You can't store ItemStack sensitive data in Item since items are singletons. Either use capabilities or NBT.

This happens because you are extending ItemSword and instantinating the base MultiMap through a super invocation. That returns you a multimap with the sword's base values already in place set by ItemSword. Your additions are not taken by the game since they are already applied by ItemSword, and they don't override the old ones because it's a MultiMap. Basically create a new empty multimap instead of grabbing the one from ItemSword.

No, but you have the metadata which you can use as variants. But it's best to have one item per variant anyway. You can still reuse the enum just fine, just make the item's metadata the ordinal or something.

This doesn't work because the default implementation of BiomeDecorator resets these to default values every time it decorates a chunk, so you need a custom BiomeDecorator. Use Biome#createBiomeDecorator to have a custom one for your biome. Are you sure about that? Setting them both to 0 should completely prevent trees from spawning. In your code you don't have them both set to zero. In any case you can simply return a NOOP implementation of WorldGenAbstractTree in Biome#getRandomTreeFeature. This is not how Random#nextInt works. It returns a number in range of [0 - (max-1)], meaning that in this case it will return [0 - 2] and will never return 3. Or you could simply write a hex number through a 0x literal, like 0xffffff for example.