Biome.SpawnListEntry.newInstance doesn't use entity factories

[bs2609]

Currently this just looks for a constructor with a single World parameter and uses that to construct the entity.
It'd be nice if this deferred to EntityEntry.newInstance similarly to EntityList.newEntity, but I don't know if the TODO here would need to be addressed first for this to not be a performance hit:

MinecraftForge/src/main/java/net/minecraftforge/fml/common/registry/EntityRegistry.java

Lines 376 to 386 in ab22883

	@Nullable
	public static EntityEntry getEntry(Class<? extends Entity> entry)
	{
	//TODO: Slave map for faster lookup?
	for (EntityEntry e : ForgeRegistries.ENTITIES)
	{
	if (e.getEntityClass() == entry)
	return e;
	}
	return null;
	}

[liach]

you can just patch spawnlistentry class.

not necessary to adress that. if you go on and add a fast class to entry map, it would be an internal impl detail than a public api. btw vanilla also iterates over all furnace recipes every time to find a match, too. it won't hurt that bad.

[mezz]

I wouldn't want to iterate over the whole registry each time something is spawned, but this is only called on each new SpawnListEntry which is only done a few times at startup so it should be fine.

[bs2609]

That wouldn't be strictly correct however, as it wouldn't take any subsequent registry changes into account.

[liach]

anyways the lookup efficiency is not related to the issue itself. We can easily address the lookup in another pull request

[mezz]

Hmm ok. If you are making it so that SpawnListEntry handles registry changes, then I see what you're saying.
If you are going to be calling getEntry for each spawned entity, I think we definitely need to maintain a lookup map that gets updated along with the registry.

[bs2609]

As another point, even discounting later registry changes, an eager lookup will cause problems with SpawnListEntry instances created from new Biome(...) calls, as biome registration occurs before entity registration at present.