[1.12] NullPointerException populating the SearchTree

[TheA13X 0]

Hi there!

 

I'm currently updating one of my mods to 1.12 (and 1.12.2). While doing that I ran into this exception:

Quote

---- Minecraft Crash Report ----
// But it works on my machine. Oh wait, no it doesn't

Time: 11/29/17 1:30 PM
Description: Initializing game

java.lang.NullPointerException: Initializing game
    at net.minecraft.client.util.SearchTree.lambda$index$0(SearchTree.java:91)
    at java.util.Collections$SingletonSet.forEach(Collections.java:4767)
    at net.minecraft.client.util.SearchTree.index(SearchTree.java:89)
    at net.minecraft.client.util.SearchTree.add(SearchTree.java:78)
    at java.lang.Iterable.forEach(Iterable.java:75)
    at net.minecraft.client.Minecraft.populateSearchTreeManager(Minecraft.java:634)
    at net.minecraft.client.Minecraft.init(Minecraft.java:570)
    at net.minecraft.client.Minecraft.run(Minecraft.java:416)
    at net.minecraft.client.main.Main.main(Main.java:118)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
    at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97)
    at GradleStart.main(GradleStart.java:26)

 

Here's what I found out so far:

 

The exception is caused, because the Lambda Functions, given to the Search Tree as an argument, returned null:

//Citing Minecraft.java
/*618*/SearchTree<ItemStack> searchtree = new SearchTree<ItemStack>(
/*   */(p_193988_0_) ->
/*619*/{
/*620*/  return (List)p_193988_0_.getTooltip((EntityPlayer)null, ITooltipFlag.TooltipFlags.NORMAL).stream().map(TextFormatting::getTextWithoutFormattingCodes).map(String::trim).filter((p_193984_0_) -> {
/*621*/    return !p_193984_0_.isEmpty();
/*622*/  }).collect(Collectors.toList());
/*623*/}, 
/*    */(p_193985_0_) ->
/*624*/{
/*625*/  return Collections.singleton(Item.REGISTRY.getNameForObject(p_193985_0_.getItem()));
/*626*/});

-> Item.REGISTRY.getNameForObject(ItemStack.getItem) returned null.

The question that remains is, why?

It must have something to do with the registration process. Therefore I have to tell you

How the Registration works:

1.Loading

When the FMLPreInitializationEvent is fired, all blocks/"pure" Items get constructed and loaded into static lists located in my ModBlocks/ModItems class

 

2. Registering

On the Register<Item>-Event the following code is executed:

//Citing Registrator.java
/*17*/@SubscribeEvent
/*18*/public static void registerItems(RegistryEvent.Register<Item> event){
/*19*/  event.getRegistry().register(ModItems.parcelInstance()); //Register the only "pure" Item in this Mod. Does not throw the NullPointerException in the Search Tree
/*20*/  ModBlocks.registerAllItems(event.getRegistry());//Register all the Block Items in this Mod
}

RegisterAllItems:

public static void registerAllItems(IForgeRegistry<Item> reg)
{
  	registerAllLogItems(reg);
  	registerAllLeavesItems(reg);
  	registerAllSaplingItems(reg);
  	registerAllWoodItems(reg);
  	registerAllStairsItems(reg);
  	registerAllDoorItems(reg);
  	registerAllSingleSlabItems(reg);
}

Example for a Registering function:

//Citing ModBlocks.java
/*208*/private static void registerAllLogItems(IForgeRegistry<Item> reg) //It crashed on the Log Block Item btw.
/*209*/{
/*210*/  int logCount = 0;
/*211*/  for (final LogBlock block : logBlocks)//for every Log Block...
/*212*/  {
/*213*/    String name = String.format("log%d", logCount);//...define registry name...
/*214*/    ImmutableList<String> subblockNames = block.getSubBlockNames();//...get all the Subblock names... 
/*215*/    if(block instanceof  ModLogBlock){//... if type 1...
/*216*/      reg.register(new ModLogItem(block,(ModLogBlock)block,subblockNames.toArray(new String[subblockNames.size()])).setRegistryName(name));//...register Item using the Type 1 item constructor after setting the registry name  
/*217*/    }
/*218*/    else if(block instanceof  ModLog2Block){//... if type 2...
/*219*/      reg.register(new ModLogItem(block,(ModLog2Block)block,subblockNames.toArray(new String[subblockNames.size()])).setRegistryName(name));//...register Item using the Type 2 item constructor after setting the registry name  
/*220*/    }
/*221*/    else if(block instanceof  ModLog3Block){//... if type 3...
/*222*/      reg.register(new ModLogItem(block,(ModLog3Block)block,subblockNames.toArray(new String[subblockNames.size()])).setRegistryName(name));//...register Item using the Type 3 item constructor after setting the registry name  
/*223*/    }
/*224*/    else{//... if type 4...
/*225*/      reg.register(new ModLogItem(block,(ModLog4Block)block,subblockNames.toArray(new String[subblockNames.size()])).setRegistryName(name));//...register Item using the Type 4 item constructor after setting the registry name  
/*226*/    }
/*227*/    logCount++;
/*228*/  }
/*229*/}

The Block registration works in the same way, only with on the Register<Block>-Event, instead of the item one.

I guess it's also important

How the Block Classes look like

Essentially I have a mod (Koresample) containing all the "basic" block/item classes and my specialized Mod (Dendrology) containing Classes with logic for the specific tree types.

Pasting all of them would be way to much so I'll just link my GitHub.

Koresample

Dendrology:

 

I know it's a bit much, but this problem seems quite unusual...

Thanks for trying and help me out. I got nothin'

 

[XFactHD 16]

You can't populate those static list's of Blocks and Items in FMLPreInitializationEvent and then expect them to be populated in the RegistryEvent as the registry events are fired before the FMLPreInitializationEvent.

Edited December 1, 2017 by XFactHD

[TheA13X 0]

12 hours ago, XFactHD said:

[...] registry events are fired before the FMLPreInitializationEvent.

No. No they are not.

 

I Debugged Forge's building process line by line, so I know that the all registry events are fired after the FMLPreInitializationEvent.

Also if the Registry Events were fired before the lists are populated, there would be no exception in the first place.

Edited December 1, 2017 by TheA13X

[ScottKillen 17]

I had to change my ways for 1.12. This works:

 

Blocks

Items

 

I hope that helps.

 

I'm glad to see you updating this!