[JAVA] [Forge] How to register your own Entity and Entity Render in 1.13.2

Development environment

Introduction

I thought that there are few Japanese materials about Entity registration in 1.13.2, so I hope it will be helpful. The source code will be explained based on the TorchBowMod of my own mod.

• GitHub - TorchBowMod

Changes from 1.12 I noticed

-** Mod initialization process is now loaded in parallel ** --It has become easier to process clients and servers separately. -** It is now possible to initialize the client without using SidedProxy. ** ** ――For the time being, a processing method like Sided Proxy remains. -** The registration method for blocks, items, Entity, etc. has changed ** -** The method of adding Entity has changed. ** ** --It is necessary to create a mod information file "mods.toml" in the META-INF folder. --Recipe folder changed from assets to data --Language file changed from lang to json. --I need pack.mcmeta. --It seems to be for data pack

This time, I summarized the addition of Entity that I stumbled upon. The bold parts are the changes related to the addition of Entity.

Mod initialization process is now loaded in parallel

preInit

@Mod.EventHandler
public void preInit(FMLPreInitializationEvent event) {
}

In the past, processing such as preInit and postInit was annotated as described above, but with this change, the constructor of the class with @Mod annotation is changed to register the listener of initialization processing. it was done. For example, if the name of the class file with the @Mod annotation is TorchBowMod, the constructor will be as follows.

TorchBowMod.java

public class TorchBowMod {
    public TorchBowMod() {
        final IEventBus modEventBus = FMLJavaModLoadingContext.get().getModEventBus();
        modEventBus.addListener(this::preInit);//Register the listener that receives the initialization processing event here
        MinecraftForge.EVENT_BUS.register(this);
    }

    //Since the formal argument is FMLCommonSetupEvent, it corresponds to preInit.
    //FMLLoadCompleteEvent is equivalent to postInit
    //Various other events are prepared, but this time omitted
    private void preInit(final FMLCommonSetupEvent event) {
        //Processing performed by preInit ~~~
    }
}

I got an unfamiliar description of this :: preInit. Since lambda expressions are actively used in this update, the description of lambda expressions often appears. Please refer to other articles for lambda expressions.

Client initialization can now be done without using SidedProxy

In 1.12, I think that I created an interface or class called CommonProxy and branched the client / server processing between the inherited ClientProxy and ServerProxy. In addition to the above initialization processing event, 1.13.2 provides a client-side event FMLClientSetupEvent.

java:1.13.2

//Client-side event listener
private void initClient(final FMLClientSetupEvent event) {
    //Client-side processing
}

It looks like this. Events can be registered in the same way as initialization processing events. By the way, regarding the render of Entity, in 1.12 and 1.13.2, there is no change in the registration method, so I wrote it with ClientProxy.

ClientProxy

//In this case, the self-made Entity → EntityTorch and the RenderTorch that is the render of that Entity are registered.
enderingRegistry.registerEntityRenderingHandler(EntityTorch.class, RenderTorch::new);

Can be registered by writing in the event listener on the client side as it is.

The registration method for blocks, items, Entity, etc. has changed.

In 1.12, I think you used the @SubscribeEvent annotation to register items, blocks, models, etc. 1.13.2 uses the same annotation, but the method has changed a little. First, you need to create a static class with @ Mod.EventBusSubscriber (bus = Mod.EventBusSubscriber.Bus.MOD) annotation, and write a register method with @ SubscribeEvent annotation in that class. became.

RegistryEvents

@Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD)
public static class RegistryEvents {
    //Since the formal argument is the generics of Item, the item is registered, but if the generics of Block is used, the block registration process can be performed.
    @SubscribeEvent
    public static void onItemsRegistry(RegistryEvent.Register<Item> event) {
        //In this case item registration
    }
}

The method of adding Entity has changed

Well, finally the main subject. Until 1.12, ʻEntity Registrywas used to register Entity, but it seems that it was deleted in 1.13.2. Therefore, it is necessary to use the aboveRegistryEvent` to register Entity. However, if you look at the list of generics defined in Forge.

ForgeRegistries.class

public static final IForgeRegistry<Block> BLOCKS;
public static final IForgeRegistry<Item> ITEMS;
public static final IForgeRegistry<Potion> POTIONS;
public static final IForgeRegistry<Biome> BIOMES;
public static final IForgeRegistry<SoundEvent> SOUND_EVENTS;
public static final IForgeRegistry<PotionType> POTION_TYPES;
public static final IForgeRegistry<Enchantment> ENCHANTMENTS;
public static final IForgeRegistry<VillagerProfession> VILLAGER_PROFESSIONS;
public static final IForgeRegistry<EntityType<?>> ENTITIES;
public static final IForgeRegistry<TileEntityType<?>> TILE_ENTITIES;
public static final IForgeRegistry<ModDimension> MOD_DIMENSIONS;

It's simply <EntityType <? >> instead of <Entity>. So you can see that you need to specify <EntityType <? >> for the generics. And since the generics of ʻEntityType is ʻEntityType <T extends Entity>, you can see that the type specified for the generics of ʻEntityType` must be Entity type.

So I will try to make EntityType of Entity that I made by myself immediately. Suppose you want to register an Entity called "Entity Torch" that also appeared when you were a render.

public static EntityType<EntityTorch> TORCH;

First, define a global variable of EntityType type that is a generic version of your own Entity.

RegistryEvents

@SubscribeEvent
public static void registerEntityTypes(final RegistryEvent.Register<EntityType<?>> event) {
}

Then add the above method to the RegistryEvents class as described in "The registration method for blocks, items, Entity, etc. has changed". In this method, it is a process to write the property-like thing of Entity to TORCH which remains null and then register it.

In the registerEntityTypes method

TORCH= EntityType.Builder.create(EntityTorch.class, EntityTorch::new).tracker(60, 5, true).build(MODID + ":entitytorch");
TORCH.setRegistryName(new ResourceLocation(MODID, "entitytorch"));
event.getRegistry().register(TORCH);

EntityType is created by ʻEntityType.Builder, but at this time, it is necessary to rewrite the Entity side to the writing style of 1.13.2. I think that this can be done by referring to the existing Entity etc., so please check it. tracker () is specified in the order of range, updateFrequency, and sendVelocityUpdates, respectively. This is the same as the 6th, 7th, and 8th arguments of ʻEntityRegistry.registerModEntity () in 1.12, so you won't have any problems. The registry name etc. can be the same as the item etc.

Reference source

-Minecraft Forge 1.13.2 version Modding. Addition of items and entity renders

Serpentine

Since both Modding and Qiita have just started, I would appreciate it if you could point out any mistakes or points that you don't like. Q: Why did you write about 1.13.2 now? A: I recently registered with Qiita, so I posted an article I wrote on my blog about 3 months ago.