[1.10.2] Alter beacon behavior when base is certain material

[IceMetalPunk]

I have a custom block (BlockAmethyst) which is a beacon base material. I would like the UI of the beacon to change if its entire base is made of BlockAmethyst, to allow different effects to be chosen.

 

Changing the UI is a simple container replacement in the GuiOpen event. Detecting the material of the beacon base would be easy as well. The hard part is that there's a HashSet of valid beacon effects in TileEntityBeacon, and without reflection, it's private. The primary and secondary effects are also private members with no setters. In fact, it seems the only way to change the beacon effects is to use readFromNBT, but that inherently verifies the beacon effects against that HashSet.

 

So I'm thinking the best approach would be to replace the default Minecraft TileEntityBeacon with a custom one...but I have no idea how to do that. Is there even a way to replace a vanilla tile entity with my own? Or should I just be hooking into the beacon block placement, removing the instance of the tile entity naturally created, and then creating an instance of my own that extends it?

[IceMetalPunk]

Perhaps I'm mistaken, but isn't reflection generally frowned upon? As in, a last-ditch effort if nothing else works?

[Draco18s]

Perhaps I'm mistaken, but isn't reflection generally frowned upon? As in, a last-ditch effort if nothing else works?

 

No that's--

 

 

User was banned for coremodding

[IceMetalPunk]

Sure, but it is a valid use-case here.

 

Fair enough; I'll go that route and see what I can manage. Thanks.

[jeffryfisher]

Perhaps I'm mistaken, but isn't reflection generally frowned upon? As in, a last-ditch effort if nothing else works?

That's correct for developers on the inside (if we were Mojang employees), but we're not. Being on the outside looking in, our mods are stuck using reflection rather more often than nicely integrated projects would.

 

If used only to init data rather than in tight loops running many times per second, we don't care about the performance hit. Even if some reflected element needs to be used frequently, you can usually arrange to pay the cost during initialization so your data access is reasonably fast.

 

However, reflection can defeat some of our IDE tools (because classes and fields become text strings that the IDE doesn't trace -- never assume that "unused" elements are really unused). Therefore, you're right that we're better off using reflection only when  needed.