Jump to content

[1.12] Registering entities


Kokkie

Recommended Posts

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.

  • Like 1

Classes: 94

Lines of code: 12173

Other files: 206

Github repo: https://github.com/KokkieBeer/DeGeweldigeMod

Link to comment
Share on other sites

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

Classes: 94

Lines of code: 12173

Other files: 206

Github repo: https://github.com/KokkieBeer/DeGeweldigeMod

Link to comment
Share on other sites

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?

  • Like 2

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

  • Like 2

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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!

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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

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.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

This one is not deprecated:

not-deprecated.png

Edited by Draco18s

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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

  • 2 months later...

@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 by JoeStrout
(forgot "static" on my event handler again, dangit)
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.



×
×
  • Create New...

Important Information

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