[1.12] Registering Blocks and ItemBlocks the new way?

[desht]

I'm converting my mod to use a fully registry-based block and item (and sound etc.) registration system, but I'm a bit uncertain about how ItemBlock registration (and associated model registration) should be handled.

 

Would the following be the right way to go about it?

@GameRegistry.ObjectHolder("my_mod_id")
public static class Registrar {
  @GameRegistry.ObjectHolder("myblock")
  public static MyBlock MY_BLOCK = null;
  // is this correct..?
  @GameRegistry.ObjectHolder("myblock")
  public static ItemBlock MY_BLOCK_ITEM = null;
  
  @SubscribeEvent
  public static void registerBlocks(RegistryEvent.Register<Block> event) {
    event.getRegistry().register(new MyBlock().setRegistryName("myblock"));
  }
  
  @SubscribeEvent
  public static void registerBlocks(RegistryEvent.Register<Item> event) {
    // will MY_BLOCK have been injected at this point?
    event.getRegistry().register(new ItemBlock(MY_BLOCK).setRegistryName("myblock"));
  }
  
  @SideOnly(Side.CLIENT)
  @SubscribeEvent
  public static void registerModels(ModelRegistryEvent event) {
    ModelLoader.setCustomModelResourceLocation(MY_BLOCK_ITEM, 0, new ModelResourceLocation("my_mod_id:myblock", "inventory"));
  }
}

 

Update: I've tried this and it does appear to work as expected.  But the question stands: is this the right way to do it now?  In particular, using @ObjectHolder annotations for the ItemBlock registration.

Edited June 29, 2017 by desht

[V0idWa1k3r]

1 hour ago, desht said:

// is this correct..? @GameRegistry.ObjectHolder("myblock") public static ItemBlock MY_BLOCK_ITEM = null;

You could use this if you need an instance of ItemBlock, sure. Or you could completely dismiss this line and just use Item::getItemFromBlock whenever you need an instance of ItemBlock.

 

1 hour ago, desht said:

registerModels(ModelRegistryEvent event)

This should be in a client-only side class. In your client proxy or some place else.

 

1 hour ago, desht said:

// will MY_BLOCK have been injected at this point?

Yes, it will. First the registry event is fired for blocks, then all ObjectHolders for blocks get populated, then the registry event is fired for Items, then all ObjectHolders for items get populated, then all other registry events get fired in alphabetical order and all other ObjectHolders are populated last.

 

Apart from all that - yes, looks like you are using the new registry system correctly.

[Alpvax]

4 hours ago, V0idWa1k3r said:

This should be in a client-only side class. In your client proxy or some place else.

Actually it is fine to have it where it is, as the @SideOnly annotation will cause it to be stripped on the server side, so it won't exist to be called.

[desht]

4 hours ago, V0idWa1k3r said:

You could use this if you need an instance of ItemBlock, sure. Or you could completely dismiss this line and just use Item::getItemFromBlock whenever you need an instance of ItemBlock.

Right, that makes sense now that I think about it.  OK, makes life even easier!  I'm liking the new system, it turned out to be a lot easier to move things over than I initially feared.

[The_Wabbit]

On 6/29/2017 at 7:45 AM, V0idWa1k3r said:

You could use this if you need an instance of ItemBlock, sure. Or you could completely dismiss this line and just use Item::getItemFromBlock whenever you need an instance of ItemBlock.

 

This should be in a client-only side class. In your client proxy or some place else.

 

Yes, it will. First the registry event is fired for blocks, then all ObjectHolders for blocks get populated, then the registry event is fired for Items, then all ObjectHolders for items get populated, then all other registry events get fired in alphabetical order and all other ObjectHolders are populated last.

 

Apart from all that - yes, looks like you are using the new registry system correctly.

Out of curiousity...what if you have a block that requires an ItemStack of one of your items in its construction? As item registration seems to always come after blocks if using events, is such a thing no longer possible? Background: ItemStacks[1.8.9] used to barf if the underlying item was not registered in some cases...have not checked recently in 1.11+. So I was always careful to ensure an item was not just created but also registered before creating an ItemStack of it...for use by block initialization.

[V0idWa1k3r]

There is nothing stopping you from separating that ItemStack/whatever requirement from a constructor argument into a setter method and invoking it some time later in your code at init for example.