[1.8] [Solved]Crash on planting custom crop

[Cleverpanda]

When I try to plant my seed item, the game crashes due to a null pointer exception.

My blocks are registered before my items, So I'm pretty sure that's not it.

 

Error log: http://pastebin.com/5CMq5U6V

 

Seed Item:

public class ItemKernels extends ItemSeeds{

    public ItemKernels() {
    	super(GameRegistry.findBlock(Corn.MODID, "corn"), Blocks.farmland);
    }
}

 

Registration:

@EventHandler
    public void preInit(FMLPreInitializationEvent event)
    {
    	Block corn = new BlockCorn().setUnlocalizedName("corn");
        GameRegistry.registerBlock(corn, "corn");
        
        Item itemkernels = (Item)(new ItemKernels().setUnlocalizedName("kernels"));
        GameRegistry.registerItem(itemkernels, "kernels");
        
    }
    
    @EventHandler
    public void Init(FMLInitializationEvent event)
    {
    	if(event.getSide() == Side.CLIENT)
    	{
    		Item corn = GameRegistry.findItem(MODID, "corn");
    		ModelResourceLocation itemModelResourceLocation = new ModelResourceLocation("corn:corn", "inventory");
    		Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(corn, 0, itemModelResourceLocation);
    		
    		Item ItemKernels = GameRegistry.findItem(MODID, "kernels");
    		itemModelResourceLocation = new ModelResourceLocation("corn:kernels", "inventory");
    		Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(ItemKernels,0,
		itemModelResourceLocation);
    	}
    }

 

Crop Block: ( yes, I know its messy right now) http://pastebin.com/RNSb5yPH

[Jedispencer21]

Why don't you extend BlockCrops?

[Cleverpanda]

I started off basing corn on the way reeds worked, and reeds didn't use it.

[jabelar]

Well, the crash specifically says that it is a null pointer exception in line 61 of the ItemSeeds class. That line of code is:

 

        return this.crops.getDefaultState();

 

For that to return a null pointer exception, it would mean that the crops field is null.

 

The crops field is assigned in the constructor, as the first parameter passed in. The constructor is:

 

    public ItemSeeds(Block crops, Block soil)

    {

        this.crops = crops;

        this.soilBlockID = soil;

        this.setCreativeTab(CreativeTabs.tabMaterials);

    }

 

Your ItemKernels constructor is:

 

    public ItemKernels() {

    super(GameRegistry.findBlock(Corn.MODID, "corn"), Blocks.farmland);

    }

 

So that means you're passing GameRegistry.findBlock(Corn.MODID, "corn"). For some reason that is failing and returning null. It does seem that you're registering it in the right order, but there must be something wrong with that. To confirm, can you add a console statement like this after the super call?

 

    System.out.println("The corn block is "+GameRegistry.findBlock(Corn.MODID, "corn").toString);

 

I think that should print out what the findBlock is finding (or not finding). If it prints out null, or crashes, at that console print statement then it confirms that it is a problem with looking it up from the registry.

[Draco18s]

As an aside, any reason you aren't storing references to your blocks and items where they can be easily accessed? That would eliminate the need to so FindBlock.

[jeffryfisher]

I started off basing corn on the way reeds worked, and reeds didn't use it.

IIRC, Like flowers, reeds are planted as themselves, not as seeds. Since your corn is a seeded plant, then crop might be a better parent (do more for you).

 

While a print statement may be informative, I'd recommend setting a breakpoint and stepping through the constructor using the debugger. The reason to use the debugger is to get over any aversion / sense of mystery you might feel toward using that tool. Once you've added the "debugger" arrow to your quiver, you'll become a much more powerful code warrior.

 

Problems like this can be solved in a handful of minutes when you can respond to a crash by launching the debugger, running up to the edge of the crash, and examining every variable within reach before stepping into the call that failed. Therefore, force yourself to climb its learning curve, become familiar with it, and then it will become easy-peasy (and powerful).

[Cleverpanda]

Thanks guys, I managed to figure it out though. I changed the way I registered my block by initializing corn in a public variable o I could access it in another class and referenced that in the seeds class.

public static final Block  corn = new BlockCorn();
corn.setUnlocalizedName("corn") 
GameRegistry.registerBlock(corn, "corn");

And I did use the debugger, It just told me my block was null where you said. I did not understand why.

 

I started off using reeds because the corn was a multiblock plant, so I specifically wanted to see how it handled updating itself for block breaks and growing. I did clean up my code and ended up extending BlockBush and implementing IGrowable instead though. I chose this because my crop is so different from the way the other crops work, that If I had extended BlockCrops, I would've overridden almost all of the methods, So I just started from higher up.

[jabelar]

While a print statement may be informative, I'd recommend setting a breakpoint and stepping through the constructor using the debugger. The reason to use the debugger is to get over any aversion / sense of mystery you might feel toward using that tool. Once you've added the "debugger" arrow to your quiver, you'll become a much more powerful code warrior.

 

I think it depends on what you're debugging. If you've already narrowed down an error to very specific part of the code, the debugger can certainly be best way to get full view of what is going on. However in modding I find a lot of things I'm debugging are more general logic related to actual gameplay and it isn't easy to debug if it takes repeated user interaction or it takes multiple ticks for the problem to manifest itself.

 

I find it is really good practice (at least for my own coding purposes) to put logger statements liberally through my code, basically indicating the entry to every key method and at every major decision point. I don't just do it after I notice a problem, rather I use the flow of logs to help confirm "healthy" operation of the code -- i.e. that everything happens in the order I expect. I think this especially important in modding because you often don't control when your methods are called, so you actually learn about the Minecraft functionality (like does a method only get called on one side, does a join event happen before or after a login even, etc.).

 

Anyway, I personally find having real-time feedback to user interaction is key to validating and debugging a lot of problems.

 

But yes, you should also be comfortable with a debugger and know when it is the sharper tool for quickly peeking into specific code areas.