Creating a crop (1.12.2) and gives wierd errors!

[UM3 F0R TH3 W1N]

Hey fellow minecraft developers, I am working on a crop (Lemon Crop. P.S. I know it sounds wierd). I have the Lemon Seed in-game and the Lemon but, when i place the seed it crashes the game. This is extremely strange because it is giving a NullPointerExeption. I believe that it is because the Items might be registered into the game before the crops. If this is the case how can i change it. Heres is the crash log: https://pastebin.com/eZLpWgGP

 

[jabelar]

Not strange. Almost everyone who creates a custom crop runs into this. It is because the block instance is null when you construct the seed item to your seed item tries to plan a null. Just control the order. In 1.12.2 you should be using the registry event and @ObjectHolder system for registering and instantiating. In that case, the item registration should happen after the blocks get their object holder injection.

 

Anyway, yes your suspicious is correct. It has to do with the order of registration and construction of the related classes. Just think through it and it should become obvious.

[UM3 F0R TH3 W1N]

errm

Edited February 17, 2018 by UM3 F0R TH3 W1N
cuz

[UM3 F0R TH3 W1N]

6 minutes ago, jabelar said:

Not strange. Almost everyone who creates a custom crop runs into this. It is because the block instance is null when you construct the seed item to your seed item tries to plan a null. Just control the order. In 1.12.2 you should be using the registry event and @ObjectHolder system for registering and instantiating. In that case, the item registration should happen after the blocks get their object holder injection.

 

Anyway, yes your suspicious is correct. It has to do with the order of registration and construction of the related classes. Just think through it and it should become obvious.

so how do i do this??

[jabelar]

Well first of all make sure you're using latest techniques for registering blocks and items. Then if that doesn't fix it by itself, post your registration and class code here so that people can help.

[UM3 F0R TH3 W1N]

there:

Edited February 17, 2018 by UM3 F0R TH3 W1N

[UM3 F0R TH3 W1N]

1 hour ago, jabelar said:

Well first of all make sure you're using latest techniques for registering blocks and items. Then if that doesn't fix it by itself, post your registration and class code here so that people can help.

https://pastebin.com/9Vi5kqfb

[UM3 F0R TH3 W1N]

helloo?

[jabelar]

Sorry I know it can be frustrating to not get quick answers but remember we have lives. Today I had to get my daughter to the airport, have lunch with friends and now have to put in a couple hours at work. I can't look at it on my work break because my work blocks paste bin site. Ill probably be able to look at it this evening. Otherwise hopefully someone else can respond. But generally it is considered rude to bump your topic unless a full day has passed.

Edited February 18, 2018 by jabelar

[jabelar]

Okay, I was able to find way to look at paste bin. You are not using the recommended way of using the registry events and @ObjectHolder annotation. The way you are doing it will not work as you cannot control their order of the static initialization between the two classes.

 

Please look how too use the new system and implement that. 

[jabelar]

Okay, now I'm home and I have some time to give more specific advice. It took me a while to get into the @ObjectHolder annotation but the way you should do it is as follows:

 

In your InitBlocks and InitItems classes you should actually initialize them to null. Then you should give each class the @ObjectHolder annotation. What this does is during mod loading there are several passes after each registry event to "inject" the actual instance into the fields. The fields are matched up by the field name matching the registry name (or you can add additional annotation if you want a different field name).

 

Next you need methods that handle the registry events. I personally put those in an inner class of the class that has the @ObjectHolder instances. Those require methods regular event handling meaning the class needs the @EventBusSubscriber annotation and the methods need to be static and have the @SubscribeEvent annotation.

 

The registry events are generic so you have to handle each valid type. Such as RegistryEvent.Register<Block> and RegistryEvent.Register<Item>.  (Note you should also be using this for entities, biomes and some other things.)

 

Lastly you do the actual constructing of your singleton instances in the registry handling event.

 

You can see my example mod classes for ideas on how to put it all together: 

• https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModBlocks.java
• https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModItems.java

Now the cool thing is that if you do all this, you'll also solve your original problem because the Item registry event will happen after the Block is registered and injected into the object holder. So then when you instantiate your seed it will get the plantable block rather than null.

 

Hope that helps.

 

[UM3 F0R TH3 W1N]

9 hours ago, jabelar said:

Okay, now I'm home and I have some time to give more specific advice. It took me a while to get into the @ObjectHolder annotation but the way you should do it is as follows:

 

In your InitBlocks and InitItems classes you should actually initialize them to null. Then you should give each class the @ObjectHolder annotation. What this does is during mod loading there are several passes after each registry event to "inject" the actual instance into the fields. The fields are matched up by the field name matching the registry name (or you can add additional annotation if you want a different field name).

 

Next you need methods that handle the registry events. I personally put those in an inner class of the class that has the @ObjectHolder instances. Those require methods regular event handling meaning the class needs the @EventBusSubscriber annotation and the methods need to be static and have the @SubscribeEvent annotation.

 

The registry events are generic so you have to handle each valid type. Such as RegistryEvent.Register<Block> and RegistryEvent.Register<Item>.  (Note you should also be using this for entities, biomes and some other things.)

 

Lastly you do the actual constructing of your singleton instances in the registry handling event.

 

You can see my example mod classes for ideas on how to put it all together: 

• https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModBlocks.java
• https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModItems.java

Now the cool thing is that if you do all this, you'll also solve your original problem because the Item registry event will happen after the Block is registered and injected into the object holder. So then when you instantiate your seed it will get the plantable block rather than null.

 

Hope that helps.

 

this would take forever tho is there not a quicker way?

 

[UM3 F0R TH3 W1N]

oh rip lol

 

[jabelar]

I do admit that keeping up with latest version can be a bit of work, but it is worth doing and while a number of big things have been overhauled in recent versions I think it will settle down and everything is getting more modern/professional in their implementation.

Edited February 18, 2018 by jabelar