[1.13.2] How to learn?

[SizzleBae]

Hi!

I have been wanting to get into Minecraft modding, but it seems that I might have chosen a bad time to start. From what I can tell, [1.13] brought a lot of structural changes to Minecraft, and forge is doing the same to keep up. At first, I thought I should start with [1.12]. But I really do not want to, as I will be learning outdated workflow and structuring. So I decided to stick with [1.13]...

 

The official Forge documentation looked promising, but it seems to be outdated, which is understandable considering that [1.13] Forge is still in beta. I have tried to find good resources on how to learn [1.13] forge, besides this forum, I have had little success... The forum has at least saved me from using bad learning resources since there appear to be many pitfalls in Minecraft modding... Every time I find a learning resource, I always see the comments saying "this is bad practice", stuff like that. I have found some learning resources for people transitioning to [1.13]. But I have yet to find resources designed for new modders...

 

I think I have programming experience sufficient for getting into this. So in the end, my question is, does anyone have any pointers to some good resources or tips? All help is very much-appreciated! :)

[ModMCdl]

  On 3/12/2019 at 5:50 PM, SizzleBae said:

Every time I find a learning resource, I always see the comments saying "this is bad practice", stuff like that. 

Expand  

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.

[DavidM]

  On 3/12/2019 at 5:50 PM, SizzleBae said:

Every time I find a learning resource, I always see the comments saying "this is bad practice", stuff like that.

Expand  

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.

[Daring Do]

  On 3/13/2019 at 1:47 AM, DavidM said:

1. Do not watch tutorials on youtube, as most of them do have bad practices.

Expand  

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.

 

  On 3/13/2019 at 1:47 AM, DavidM said:

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.

Expand  

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.

[DavidM]

  On 3/13/2019 at 1:59 AM, Daring Do said:

these "bad practices" don't matter too much for someone just starting out

Expand  

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.

 

  On 3/13/2019 at 1:59 AM, Daring Do said:

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.

Expand  

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.

Edited March 13, 2019 by DavidM

[Daring Do]

  On 3/13/2019 at 2:17 AM, DavidM said:

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.

Expand  

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.

[Cadiboo]

  On 3/13/2019 at 1:59 AM, Daring Do said:

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.

Expand  

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.”

[Daring Do]

  On 3/13/2019 at 2:22 AM, Cadiboo said:

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.”

Expand  

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.

[DavidM]

  On 3/13/2019 at 2:27 AM, Daring Do said:

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.

Expand  

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.

 

  On 3/13/2019 at 2:22 AM, Daring Do said:

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.

Expand  

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.

Edited March 13, 2019 by DavidM

[Daring Do]

  On 3/13/2019 at 2:34 AM, DavidM said:

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?

Expand  

SpecialTileEntityRenders.

 

  On 3/13/2019 at 2:34 AM, DavidM said:

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 mood file.

Expand  

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.

[DavidM]

  On 3/13/2019 at 2:39 AM, Daring Do said:

SpecialTileEntityRenders

Expand  

I suppose you meant TileEntitySpecialRenderer. How is that related to IHasModel?

 

  On 3/13/2019 at 2:39 AM, Daring Do said:

Clutters the main file. Some people like to keep their nice and neat main file clear of clutter

Expand  

Do not abuse inheritance to "just keep my code cleaner". Composition over inheritance.

Edited March 13, 2019 by DavidM

[Daring Do]

  On 3/13/2019 at 2:42 AM, DavidM said:

I suppose you meant TileEntitySpecialRenderer. How is that related to IHasModel?

Expand  

You don't need IHasModel for it. Registering a model for it would just take up time, and is completely unnecessary.

 

  On 3/13/2019 at 2:42 AM, DavidM said:

Do not abuse inheritance to "just keep my code cleaner". Composition over inheritance.

Expand  

I'm not. I just like to keep my code clean. Messy code is hard for me to read, and it takes me longer to find an issue in it that code I've kept nice and tidy. It's not just for cleanliness's sake, it's for identifying potential problems easier.

[devguydan]

  On 3/13/2019 at 2:17 AM, DavidM said:

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 (i.e. loremaster and harrytalks)

Expand  

Ok great so literally the two guys I started watching are the wrong ones. of course. Also, very curious why CommonProxy and IHasModel are bad practice (other than the Hungarian notation there). That is straight from loremaster, and wondering why this is bad practice.  Nevermind, I kept reading. Although from a design patterns perspective I very much agree with a HasModel Interface. And very much disagree with using a CommonProxy lol. You can separate and declutter your main file in much better ways that breaking the purpose of a structure.

 

I am new to mc modding as well. (as of today) I am a professional developer, and want to get my younger brother into coding as well, and I thought a good way to do that would be to teach him how to write his own mc mods. So I need to learn this quickly. I am only focussing on 1.12, not 1.13. Any good text tutorials would be great, as well as any 1.12 mods (github links) with good practices so I can review them. 

Edited March 13, 2019 by devguydan
I kept reading and found the answer to stuff:)

[DavidM]

  On 3/13/2019 at 3:08 AM, devguydan said:

why CommonProxy and IHasModel are bad practice

Expand  

Coding style, 1 and 3.

[devguydan]

Oh that is a very good resource, and yeah I updated my question after reading your last post.

[SizzleBae]

Thank you so much for your tips, everyone! I am happy to see such an active forum :) I will take you up on the tips concerning looking at other [1.13.2] mod sources and vanilla source. Also, McJty's wiki and youtube tutorial look promising. I will try some different learning methods, and if I absolutely have to, I'll post threads concerning specific problems in the future! Again, thanks a lot for your responses! :)

[desht]

  On 3/13/2019 at 2:39 AM, Daring Do said:

SpecialTileEntityRenders.

Expand  

1. I'm going to assume you're referring to TileEntityItemStackRenderer, since TileEntitySpecialRenderer has nothing to do with items (it's purely for tile entities).
2. Assuming you're using a TileEntityItemStackRenderer, it's because your item has some special animation requirements, and you're not using the Forge animation system. Even in that case, your item will need a static model for rendering in a GUI, on the ground, in an item frame, etc.

So no - there is no case for IHasModel, under any circumstances. It does not make your code simpler, it just adds unnecessary cruft. Please don't use it, and please, please, don't suggest that its use is in any way OK.

 

As for your assertion that using a "CommonProxy" avoids cluttering the main file - seriously?  If you're that concerned about clutter, put those "common" methods in their own class.  But not in a proxy class whose sole point is to separate the implementation of client-only and server-only code.

[V0idWa1k3r]

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.

[DavidM]

1. The IHasModel interface can actually be harmful in that it confuses beginners how the model registry actually works.

Examples of which being:

http://www.minecraftforge.net/forum/topic/69344-solved-1122-block-item-texture-missing/

http://www.minecraftforge.net/forum/topic/69142-texture-not-showing/

Both Modder are confused on how the model registry works, and led to double registering/didn't register some model due to the inconsistence usage of IHasModel.

 

2.

  On 3/13/2019 at 2:45 AM, Daring Do said:

I'm not. I just like to keep my code clean.

Expand  

 

  On 3/13/2019 at 2:42 AM, DavidM said:

Do not abuse inheritance to "just keep my code cleaner".

Expand  

Again, the point of OOP is not "make my code look nice".

 

3. Never judge a code in the sense "it works so it is fine". Optimizations, readability and conventions matters.

[Cadiboo]

IHasModel is fine if it’s used for what it’s meant for, a high level of control over individual item models. For example if your mod has lots of items with many variants and complicated models. It is not fine for beginners as it complicates their code, they don’t need it and they probably don’t understand how it works,  why it’s used or what it does. Therefore it shouldn’t be in tutorials.

@devguydan Some good tutorials include MinecraftByExample, ShadowFacts tutorials, Jabelar’s tutorials and Cubicoder’s tutorials. I’ve also heard that McJty’s tutorials are good, but IIRC they use IHasModel and CommonProxy. I’ve got a list of tutorials and resources at https://github.com/Cadiboo/Example-Mod and I’m also doing my own 1.13.2 tutorials. 

[Draco18s]

  On 3/13/2019 at 9:11 PM, Cadiboo said:

IHasModel is fine if it’s used for what it’s meant for, a high level of control over individual item models.

Expand  

In which case, it should be something like IComplicatedModel or something.

 

Like this:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/interfaces/IItemWithMeshDefinition.java

 

That lets me go "oh, this is special and needs special treatment" and register its model appropriately.