Leaderboard

This is typical software engineering jargon for "I wouldn't do it that way." In this case, if the code works, it works. If you're going into professional programming, then maybe you should take the time to learn how to efficiently write code, but for someone who's learning how to mod Minecraft, it really doesn't matter. As time goes on, you'll eventually learn what practices to use over others. The important thing is that most of this forum will not help you out well unless you come already with code. The people here, and in many other places, do not like to just "hand out code" and will be more likely to help. So start out by working with what you know. You're not expected to have perfect code when you first start. And trust me, if you come here with one error, they're going to point out all of the other ones, too. That's my advice. Chances are one of the "higher ups" here will trump me, because that's what they do. Welcome to Forge.

Coding style, 1 and 3.

Yes they do matter. They break your own mod and other peoples mods. Usually text based tutorials have something at the beginning saying “learn java”. This is important. Most video tutorials say “I’m just starting, this is what worked for me. Do this, this, this and this. Why? Because.”

I've literally never heard a reason to not uses IHasModel beyond "it's a terrible idea, use this far more complicated method instead". As for common proxy, I don't think any of the 3 "big" modding tutorial channels even use it for registry. I literally only use it for networking, and have never had a problem with it.

To add my 2 cents on the issue: IHasModel makes you write redundant code. It's not bad in a sense that it will break compatibility or something, it's bad because you literally write way too much code. For an interface that's suposed to simplify the code it's doing the exact opposite. Consider the following: A typical IHasModel usage: class ItemX extends Item implements IHasModel { ... @Override void registerModels() { Mod.proxy.registerModel(this, 0, "inventory"); } } class ClientProxy implements IProxy { ... @Override void registerModel(Item i, int meta, string variant) { ModelLoader.setCustomModelResourceLocation(i, new ModelResourceLocation(i.getRegistryName(), variant)); } @Override void registerModel(Block b, int meta, string variant) { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(b), new ModelResourceLocation(b.getRegistryName(), variant)); } } @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { for (Item i : ModItems.ITEMS) { if (i instanceof IHasModel) { ((IHasModel)i).registerModel(); } } for (Block i : ModBlocks.BLOCKS) { if (i instanceof IHasModel) { ((IHasModel)i).registerModel(); } } } } And then you have to duplicate the code in ItemX for every item class you have. While you can have something like ItemBase do that for you you will STILL have to replicate this code for every item that doesn't extend ItemBase, like custom tools or armor or god knows what. Now compare this to the "correct" approach to the situation: @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { StreamSupport.stream(Item.REGISTRY.spliterator(), false).filter(i -> i.getRegistryName().getResourceDomain().equalsIgnoreCase("modid")).forEach(i -> ModelLoader.setCustomModelResourceLocation(i, 0, new ModelResourceLocation(i.getRegistryName(), "inventory"))); } } ..and you are done. No, really, that's it. How about items that have damage? @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { StreamSupport.stream(Item.REGISTRY.spliterator(), false).filter(i -> i.getRegistryName().getResourceDomain().equalsIgnoreCase("modid")).forEach(i -> { ModelResourceLocation staticLocation = new ModelResourceLocation(i.getRegistryName(), "inventory"); if (i.getMaxDamage() == 0) { ModelLoader.setCustomModelResourceLocation(i, 0, staticLocation); } else { ModelLoader.setCustomMeshDefinition(i, it -> staticLocation); ModelBakery.registerItemVariants(i, staticLocation); } }); } } What about special cases? This is where an interface is acceptable. There, that's all the code you need and even this can be simplified further using streams better than I did. No need to repeat your code for each new item. CommonProxy: Of course a common proxy isn't going to cause incompatibilities. There are 2 issues with this concept - the first one is the name, the second one - the whole concept. The tutorials on the internet don't explain you what a proxy is or why it is needed, they just blindly tell you - create these classes, do that and this and it will work. The thing is though - a common proxy makes no sense at all if you think about it. Proxies existed to separate sided only code. If your code is common it goes anywhere else but the proxy. Think about it. A network handler wouldn't have a "Common" side - it has a client and a server. Why would a proxy have it? As for the "clutter" argument - please provide me an example of things you put in your common proxy that would otherwise clutter your mod class. What code do you even have there? 95% of all things were done with event handlers anyway, you rarely needed to do something in your FML lifecycle events. Additionally I just want to point out that I indeed had helped people on this very forum that had an issue with their code where the whole case of the issue was indeed the CommonProxy. So it's not even harmless. Also we are talking about 1.13.2. Proxies are gone anyway. As for the whole "it's fine for a beginner, they will learn to do stuff properly later" argument - no, they won't. Look at the most popular mods out there. They still use IHasModel and CommonProxy. And many other things. Clearly those people haven't learned.

SpecialTileEntityRenders. Clutters the main file. Some people like to keep their nice and neat main file clear of clutter, like myself. While I don't use my proxies for that (though I should definitely use my client proxy for client-side stuff), it has the same effect. It's not really as bad as you want to think it is, since most of the time, mods don't register stuff solely on the server-side. A common proxy setup really just saves space in your main file, for most people. And by the time an aspiring mod dev is making server only mods, they probably have a good idea of how to register it so it's not needed on the client.

https://gist.github.com/Cadiboo/fbea89dc95ebbdc58d118f5350b7ba93 Short version: "Every item/block has a model, therefore every single item/block should implements IHasModel". Well, in that case, since every item/block has a model, then why bother to create another interface for it? Why not just register every item/block's model? Theoretically, IHasModel would not break anything. However, the concept itself is totally pointless, and causes people to write extra useless code. The point of IHasModel is to distinguish those with a model from those without a model; however, everything has a mode. The whole point of having proxies is that they run code based on the sides, which is the exact opposite of what a CommonProxy does. Proxies should not have common code. All common code goes in the main mod file.

I mean, I respect you, Cadiboo, but I've not had a situation where it was the things I've used that many would've considered bad practice breaking other mods, or my own. The most incompatible mod I've made would be Resizing Potion/ArtemisLib, and its issues are with mods that mess with hitboxes or eye height, just like those do. That's less bad practices, and more lack of easy compatibility (which is the whole reason ArtemisLib was made in the first place). As I stated, I've yet to be given an actual reason to not use IHasModel when registering item renders, despite how many people have said they don't recommend using it to others. There's blind acceptance on all sides.

Depends. Starting with bad practices might cause people going back and rewriting everything (which normally isn't the desired case). I personally had the painful experience of going "wtf why" as videos promote (terrible) practices like CommonProxy and IHasModel when I first learned to make mods. AFAIK it is the other way around. McJty's tutorials are indeed good, but the rest of the tutorials on youtube only covers the basics, as well as suggesting "just copy the code and paste them in your code because it worked for me" (i.e. loremaster and harrytalks). Text-based tutorials often go in more depth about concepts like packets, complex item/block behaviors, rendering, and networking. To sum it up, I would recommend to start with video tutorials like McJty's, and move on to text-based ones. It is easy to get lost if you start with text-based ones at first, so you might want to get the feel of modding by watching videos first. It's up to you, really.

As Mod stated above, these "bad practices" don't matter too much for someone just starting out, as they'll learn how to improve it themselves as time goes on. Most of the text based tutorials rarely actually explain anything, or are outdated, or don't get into the complexities of some of the good YouTube tutorials, like those by McJty. Not for everyone. Some, like myself, learn better by example, and fixing one issue at a time, not having every single mistake pointed out all at once, in one massive dump. It's why I only use this forum as a last resort. Depending on OP's learning style, your advice could steer them away from making mods. My suggestion, OP, is to look around in general, to figure out what method of learning helps you the most. I learn best from looking at YouTube tutorials by McJty, and looking through other mods' code, as well as Vanilla's. From there, I gather what I need to do to accomplish the task that I set out to do. You may learn in the way David supplied, or you may learn in a way unmentioned in this thread so far. But if you want my personal suggestion: don't mess with 1.13.2 yet. It's buggy, it's broken, and it's a pain to set up. If you want video tutorials, go to YouTube and search up "McJty modding tutorials". He's pretty good at what he does, and generally has good practices. Maybe not perfect, and maybe not universally considered as good, as it's a fairly subjective term, but at least in my experience, many people think his videos are good. I also recommend looking at other mods, and how they do things. Just looking at 1.13.2 mods on GitHub won't give you everything, though, as you do have to do some things that weren't necessary in 1.12.2.

1. Do not watch tutorials on youtube, as most of them do have bad practices. Most good tutorials are text-based, here is one for example: https://github.com/TheGreyGhost/MinecraftByExample/ 2. Be prepared to make mistakes and get criticized. The best part (and perhaps the worst part) of the Forge Forum is that people are blunt in pointing out all the mistakes in your code. This is a great way to learn coding practices, as well as how to use the Forge API properly. 3. 1.13.2 is indeed quite new, and there are not enough tutorials out there. I would suggest you to search up 1.13.2 mods on GitHub and learn from their source code.

It should be a quick and easy project for someone who already has a mod environment set up. I'll start work on it today. Edit: Scratch that, someone already made it: https://minecraft.curseforge.com/projects/scavenge?gameCategorySlug=mc-mods&projectID=282988 It looks like that mod should be able to do what you want. It has a bunch of addon mods too, though I didn't look through them.

Please don't follow Neale Gaming's tutorials. Their quality is sub-par, the content is often erroneous, and the code doesn't follow well-established conventions. Furthermore, the speaker's explanation of how things work are often misunderstood.