Jump to content

[1.12] NullPointerException populating the SearchTree


TheA13X

Recommended Posts

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'

 

Sincerely,

A13XIS

Link to comment
Share on other sites

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 by XFactHD
Link to comment
Share on other sites

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 by TheA13X

Sincerely,

A13XIS

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.