Adding new valid blocks to TileEntityType registry?

[InspectorCaracal]

I'm making my own beehives and I want to create them with the vanilla BeehiveBlock and BeehiveTileEntity classes. I've gotten it 99% working, except that when I place my custom hive, I get a warning and bees don't seem to recognize it (indicating there's no valid beehive te present).

[minecraft/TileEntity]: Block entity invalid: minecraft:beehive @ BlockPos{x=-232, y=65, z=60}

I'm not clear on why exactly this is happening, but my best guess is that it's due to the BeehiveTileEntity initially being registered with the bee nest and beehive blocks:

public static final TileEntityType<BeehiveTileEntity> BEEHIVE = register("beehive", TileEntityType.Builder.create(BeehiveTileEntity::new, Blocks.BEE_NEST, Blocks.BEEHIVE));

 

I've tried registering it with my own block in my registry class according to the TileEntityType registry docs and examples, but it didn't seem to affect anything. Is there a different syntax for adding new valid blocks to an already registered TileEntityType?

 

edit: I should specify, the BeehiveTileEntity class has TileEntityType.BEEHIVE hardcoded into the constructor, which is likely what's complicating things.

Edited July 2, 2021 by InspectorCaracal

[InspectorCaracal]

On 7/2/2021 at 12:52 AM, diesieben07 said:

You can make your own tile entity class that extends BeehiveTileEntity. Just override getType.

Ah, if only it were that easy.

[InspectorCaracal]

Well, that fix handles the specific problem I was having in regards to the constructor re: inheritance, but I'll be damned if I make another thread again at this point so my last remaining problem (optimistically) which I hunted down trying to figure it out is that the bees will only identify a hive as a valid potential target if they're BEEHIVE or BEE_NEST in the PointOfInterestType registry.

Is there something else I can overload somewhere to get my hives in there?

Edited July 4, 2021 by InspectorCaracal
thought something might work but it won't

[InspectorCaracal]

13 hours ago, diesieben07 said:

You can set PointOfInterestType#matchingStates using reflection. Do this in FMLCommonSetupEvent#enqueueWork.

By PointOfInterestType#matchingStates do you mean the variable holding the registered POI type?

Edited July 4, 2021 by InspectorCaracal
why did i think it was a method

[InspectorCaracal]

Tangentially, I just found this thread while researching to make sure I do the enqueueWork bit properly and I got to "Vanilla loves hardcoding things" and BOY is that the theme of my past week working on this lmfaooo

[InspectorCaracal]

11 hours ago, diesieben07 said:

It's a field. You have to set it using reflection because it is private.

Sorry, I'm not very good at keeping track of specific terminology and tend to just throw the closest word I can think of at it. Anyway, let me rephrase my question a little more clearly.

Is the thing I'm supposed to modify a field called "matchingStates", or is it the field called "BEEHIVE"? I assumed you meant matchingStates at first, but there's no field by that name or even a similar name in PointOfInterestType, or even in the entire code base.

I ran with it being the BEEHIVE field yesterday because I knew where that was, but it didn't work, and I want to find out if that's where you were pointing me before putting more work into figuring out what I might've done wrong.

edit: Oh, it just occurred to me while looking at the fields again that you might've meant `Set<BlockState> blockStates` so I'm going to give that one a shot

Edited July 5, 2021 by InspectorCaracal

[InspectorCaracal]

YES, IT WORKS!! Perfect! Thank you! Now I just need to dig into the obfuscation stuff to make sure this'll work outside of dev, but I can do all that on my own.

[InspectorCaracal]

Ah, never mind what I originally wrote here, there is a different thing going on.

Edited July 6, 2021 by InspectorCaracal

[InspectorCaracal]

10 hours ago, diesieben07 said:

You're still on MCP mappings then. Recent versions of Forge use official mappings.

Yep, already figured that out. I changed it over to official anyway because it was easier to look up the unmapped names in the official mappings file.