[1.12] Registering entities

[Kokkie 55]

Hello,

I was just wondering what the best way to register an entity would be.

Thanks.

[aw_wolfe 14]

directly with.

ForgeRegistries.ENTITIES.register([EntityEntry]);

 

or better, trap the event (per docs)

@SubscribeEvent
public void registerBlocks(RegistryEvent.Register<EntityEntry> event) {
    event.getRegistry().register([EntityEntry]);
}

 

[Kokkie 55]

Ah, it was EntityEntry instead of raw Entity, thanks!

[Kokkie 55]

Just tried it, it crashes.

The log:

[14:33:39] [main/WARN] [FML/]: Registry EntityEntry: Override did not have an associated owner object. Name: dgm:cheese_boss Value: net.minecraftforge.fml.common.registry.EntityEntry@79ed43f8

My code:

public class Entities {
	public static final EntityEntry CHEESE_BOSS = new EntityEntry(CheeseBossEntity.class, Reference.MOD_ID + ":cheese_boss");
	public static final EntityEntry[] ENTITIES = new EntityEntry[] { CHEESE_BOSS };
	static {
		CHEESE_BOSS.setRegistryName(Reference.MOD_ID, "cheese_boss");
		CHEESE_BOSS.setEgg(new EntityEggInfo(new ResourceLocation(Reference.MOD_ID, "cheese_boss"), 0xFFFFFF, 0xAAAAAA));
	}
}

@Mod.EventBusSubscriber
public class CommonHandler {
	@SubscribeEvent
	public static void registerBlocks(RegistryEvent.Register<Block> e) {
		DeGeweldigeMod.LOGGER.info("Registering Blocks.");
		e.getRegistry().registerAll(Blocks.BLOCKS);
	}

	@SubscribeEvent
	public static void registerItems(RegistryEvent.Register<Item> e) {
		DeGeweldigeMod.LOGGER.info("Registering Items.");
		e.getRegistry().registerAll(Items.ITEMS);
		for (Block block : Blocks.BLOCKS) {
			e.getRegistry().register(new ItemBlock(block).setRegistryName(block.getRegistryName()).setUnlocalizedName(block.getUnlocalizedName()));
		}
	}

	@SubscribeEvent
	public static void registerEntities(RegistryEvent.Register<EntityEntry> e) {
		DeGeweldigeMod.LOGGER.info("Registering Entities.");
		e.getRegistry().registerAll(Entities.ENTITIES);
	}
}

Tell me if you need more code/stuff.

[diesieben07 6303]

Use this: https://github.com/MinecraftForge/MinecraftForge/commit/f2b07e8db1e2a6cf3a5b47393783bb367f2afdb2

Don't create EntityEntry instances in a static initializer.

[Kokkie 55]

How can I get the ModContainer?

[diesieben07 6303]

What?

[Kokkie 55]

Correct me if I'm wrong but I'm creating an EntityRegistration and it takes a ModContainer as parameter, I need to know how I can get the ModContainer of my mod...

[diesieben07 6303]

No, you use the builder.

[Kokkie 55]

But I couldn't find that class.. Let me try updating...

[Kokkie 55]

All is fine now, only the methods return a EntityEntryBuilder<Entity> instead of one using my Entity, how can I fix this?

Code so far:

public static final EntityEntryBuilder<CheeseBossEntity> CHEESE_BOSS = EntityEntryBuilder.create().entity(CheeseBossEntity.class).id(new ResourceLocation(Reference.MOD_ID), ID++).name("cheese_boss").egg(0xFFFFFF, 0xAAAAAA).tracker(64, 20, false);

Tell me if something is wrong in this as well.

Forgot to add tracker, fixed now

Edited October 7, 2017 by Kokkie

[Kokkie 55]

Okay turns out it didn't matter, what is the correct way to register the renderers?

[diesieben07 6303]

51 minutes ago, Kokkie said:

Okay turns out it didn't matter, what is the correct way to register the renderers?

RenderingRegistry.registerEntityRenderingHandler

 

1 hour ago, Kokkie said:

Tell me if something is wrong in this as well.

You need to call build and register the resulting entry.

[jabelar 590]

This is exactly the type of thread I envisioned when I was complaining on the pull request about the complexity of the new registration system... we went from needing a single, easy-to-understand line of code to register an entity to complex set of entries, builders and such. I'm still at a bit of a loss to understand the advantage of the new system. diesieben07 do you understand the advantage / reason that this sort of complexity is needed? I suppose it has something to do with the fact that entities need to be instantiated where other things that are registered (items, blocks, recipes) are singletons?

[diesieben07 6303]

2 minutes ago, jabelar said:

diesieben07 do you understand the advantage / reason that this sort of complexity is needed? I suppose it has something to do with the fact that entities need to be instantiated where other things that are registered (items, blocks, recipes) are singletons?

I don't think

EntityEntry entry = EntityEntryBuilder.create()
    .entity(MyEntity.class)
    .id(new ResourceLocation(...), ID++)
    .name("my_entity")
    .egg(0xFFFFFF, 0xAAAAAA)
    .tracker(64, 20, false)
    .build();
event.getRegistry().register(entry);

is any more complex than

EntityRegistry.registerModEntity(new ResourceLocation(...), MyEntity.class, "my_entity", ID, MyMod.INSTANCE, 64, 20, false, 0xFFFFFF, 0xAAAAAA);

 

In fact I would argue that the first one is

• much easier to understand: you clearly see what each argument does, one of the advantages of a builder over a huge one-method factory with 20 parameters.
• more consistent: you only register things to event.getRegistry inside RegistryEvent.Register, you don't call random other methods.
• more future proof: If we need new parameters entity registration they can be added to the builder without breaking old mods.

[jabelar 590]

1 hour ago, diesieben07 said:

I don't think

EntityEntry entry = EntityEntryBuilder.create()
    .entity(MyEntity.class)
    .id(new ResourceLocation(...), ID++)
    .name("my_entity")
    .egg(0xFFFFFF, 0xAAAAAA)
    .tracker(64, 20, false)
    .build();
event.getRegistry().register(entry);

is any more complex than

EntityRegistry.registerModEntity(new ResourceLocation(...), MyEntity.class, "my_entity", ID, MyMod.INSTANCE, 64, 20, false, 0xFFFFFF, 0xAAAAAA);

 

In fact I would argue that the first one is

• much easier to understand: you clearly see what each argument does, one of the advantages of a builder over a huge one-method factory with 20 parameters.
• more consistent: you only register things to event.getRegistry inside RegistryEvent.Register, you don't call random other methods.
• more future proof: If we need new parameters entity registration they can be added to the builder without breaking old mods.

Well, I meant it is conceptually more difficult as well as inconsistent with the other registries. You want to register an entity, but you need to wrap that in an entity entry. That would be okay except you can't simply construct that but rather you need to build it through a builder class then chain the methods -- and don't forget to actually call the build() method which is different than create()!

 

Basically, you can see the OP in this thread ran into all the problems conceptually -- initially thought they could register entities directly, finally figured out that they needed a builder for entries but then forgot to do the build().

 

I guess I'd like it better if it was consistent across all the registries.

 

I think the problem is that Forge is moving to more high-end programmer style -- lots of factories, functional interfaces, builders, and such. These are all really good programming style things and of course the "proper" way to do things. However, I believe it greatly reduces the accessibility to the general modder who is just dabbling.

 

Also, the point with an API is that it is supposed to be a "contract" that is only modified under extreme situations. The amount of work it takes now to port a mod is literally weeks per mod. Forge ideally would be an API that stands the test of time (with all the changes happening invisibly under the hood). This is why there are so many people stuck modding back on 1.7.10 -- they simply can't keep up either conceptually or effort-wise.

 

Basically, I think Forge is doing great stuff but is getting way ahead of the actual modding community both in terms of skill level required as well as simply keeping up porting mods. Heck this morning I upgraded my 1.12.1 mod to 1.12.2 and had to spend some serious time to clear out the errors. That is a problem when a modder like me who tries to keep up and has intermediate Java level has to scratch their head just to keep their previously working mod working.  It is really fracturing the modding community -- if you don't believe me go to Minecraft Forums modification development forum and you'll see that only about 1 in 10 questions is about anything after 1.8!

 

I guess I'm hoping that all these big changes get solid soon and then stay stable for a few years. Otherwise it is really disheartening to see all your learning and work get obsolete so quickly.

[Kokkie 55]

1 hour ago, jabelar said:

and don't forget to actually call the build() method which is different than create()!

I didn't forget this, I only called this when registering instead of at creation, should've said that though.

[Kokkie 55]

3 hours ago, diesieben07 said:

RenderingRegistry.registerEntityRenderingHandler

In what event do you suggest doing this?

[diesieben07 6303]

1 hour ago, jabelar said:

Well, I meant it is conceptually more difficult as well as inconsistent with the other registries. You want to register an entity, but you need to wrap that in an entity entry. That would be okay except you can't simply construct that but rather you need to build it through a builder class then chain the methods -- and don't forget to actually call the build() method which is different than create()!

No, you are not registering an Entity, you are registering an EntityEntry. This is unavoidable, since entities are not singletons, unlike the other registry types. Yes, an EntityEntry requires a builder, but that is just because registering an entity requires so many damn  parameters (which is also unavoidable). A giant constructor on EntityEntry would not help here at all. 

 

1 hour ago, jabelar said:

I guess I'd like it better if it was consistent across all the registries.

It can't be. Entities are fundamentally different from Blocks, Items, Biomes, etc.

 

1 hour ago, jabelar said:

Also, the point with an API is that it is supposed to be a "contract" that is only modified under extreme situations. The amount of work it takes now to port a mod is literally weeks per mod. Forge ideally would be an API that stands the test of time (with all the changes happening invisibly under the hood). This is why there are so many people stuck modding back on 1.7.10 -- they simply can't keep up either conceptually or effort-wise.

Which is exactly my point. A constructor with a parameter added is no longer backwards compatible (unless you keep both constructors, which is a hassle). A builder continues to work even if you add more parameters.

[Kokkie 55]

15 minutes ago, Kokkie said:

In what event do you suggest doing this?

 

[diesieben07 6303]

28 minutes ago, Kokkie said:

In what event do you suggest doing this?

preInit of your client proxy.

[jabelar 590]

29 minutes ago, diesieben07 said:

Which is exactly my point. A constructor with a parameter added is no longer backwards compatible (unless you keep both constructors, which is a hassle). A builder continues to work even if you add more parameters.

 

I agree it is good f we're moving towards something we can keep stable for the long term. Up until now there has been a major overhaul of some aspect of Forge literally every couple months which is well-intentioned but has fractured the modding code base and left a lot of people and mods behind. Hopefully we'll be finished upgrading everything soon and we let the modding community catch up!

[DragonFerocity 0]

On 10/7/2017 at 11:04 AM, diesieben07 said:

RenderingRegistry.registerEntityRenderingHandler

 

Is there another way to register entities now? Whenever I type in this function, Eclipse says "Deprecated. use the factory version during Preinitialization. TODO Will be removed in 1.11."

 

What should I do instead?

 

EDIT: I already have 

EntityEntry entry = EntityEntryBuilder.create()
    .entity(MyEntity.class)
    .id(new ResourceLocation(...), ID++)
    .name("my_entity")
    .egg(0xFFFFFF, 0xAAAAAA)
    .tracker(64, 20, false)
    .build();
event.getRegistry().register(entry);

implemented. I'm assuming I still need to register the render though?

Edited October 9, 2017 by DragonFerocity

[Draco18s 1978]

4 minutes ago, DragonFerocity said:

 

Is there another way to register entities now? Whenever I type in this function, Eclipse says "Deprecated. use the factory version during Preinitialization. TODO Will be removed in 1.11."

There are two methods with the same name, use the not-deprecated one.

[DragonFerocity 0]

1 minute ago, Draco18s said:

There are two methods with the same name, use the not-deprecated one.

On my end, they both show as deprecated.

 

These are the two different ones that I see:

RenderingRegistry.registerEntityRenderingHandler(entityClass, renderFactory);
RenderingRegistry.registerEntityRenderingHandler(entityClass, renderer);

And both show

Deprecated.  use the factory version during Preinitialization. TODO Will be removed in 1.11.