[1.12] Registering entities

[Kokkie]

Hello,

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

Thanks.

[aw_wolfe]

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]

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

[Kokkie]

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.

[Kokkie]

How can I get the ModContainer?

[Kokkie]

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...

[Kokkie]

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

[Kokkie]

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]

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

[jabelar]

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?

[jabelar]

  On 10/7/2017 at 4:28 PM, 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.

Expand  

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]

  On 10/7/2017 at 6:14 PM, jabelar said:

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

Expand  

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

[Kokkie]

  On 10/7/2017 at 4:04 PM, diesieben07 said:

RenderingRegistry.registerEntityRenderingHandler

Expand  

In what event do you suggest doing this?

[Kokkie]

  On 10/7/2017 at 7:30 PM, Kokkie said:

In what event do you suggest doing this?

Expand  

 

[jabelar]

  On 10/7/2017 at 7:33 PM, 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.

Expand  

 

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]

  On 10/7/2017 at 4:04 PM, diesieben07 said:

RenderingRegistry.registerEntityRenderingHandler

Expand  

 

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]

  On 10/9/2017 at 12:00 AM, 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."

Expand  

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

[DragonFerocity]

  On 10/9/2017 at 12:05 AM, Draco18s said:

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

Expand  

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.

 

[Draco18s]

If your variables are untyped, it's going to assume you're passing a Render<? extends Entity>

This one is not deprecated:

Edited October 9, 2017 by Draco18s

[DragonFerocity]

Okay, am I getting the second parameter (the IRenderFactory) correctly?

 

I found this thread which said to use 

RenderingRegistry.registerEntityRenderingHandler(EntityNewEntity.class, RenderNewEntity::new);

 

Now that I have that implemented, my entity has the same texture as the player for some reason

Edited October 9, 2017 by DragonFerocity

[JoeStrout]

@DragonFerocity, did you ever get this figured out (including the correct texture)?

 

And @jabelar, any chance you're working on an up-to-date projectile tutorial?  I find your tutorials in general to be exceptionally clear, well-written, and helpful.  But I am more or less completely befuddled at the moment when it comes to projectiles — all the examples and tutorials I'm able to find are for the older system, and don't match the advice I'm finding here at all.

 

So a tutorial that actually shows how to put all this together into a working 1.12 projectile would be really, really helpful.

Edited December 29, 2017 by JoeStrout
(forgot "static" on my event handler again, dangit)