Draco18s

Well there's your problem.

Yes, because the power is coming from nowhere. As soon as you change the blockstate the game makes all the adjacent blocks check whether they should still be powered (etc) and find that no, they shouldn't be, and then the block you fiddled with sees that one of the other blocks updated its state to not be powered and turns off again. Realistically you'll never get this to work the way you want it to.

NBT is for serialization. Capabilities are runtime. Don't serialize to JSON then store the result in NBT, just serialize to NBT.

That's a generic. Here's how its implemented (note: I don't think much has changed since 1.14, but that's what I've got handy) https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/network/PacketHandler.java#L28

Right, because hasEffect() is an Item method, not a ItemGroup method. @Override is not valid here. Remove the method, it is doing nothing. How about enchanting the itemstack stored in the Supplier, rather than getting it out of the supplier and enchanting the result, and dropping it on the floor?

You didn't put @Override on this method, and I suspect the reason you did, is because it doesn't override a method in the super class. Which means that this method is not being called, and you are expecting that it does, for Magic Reasons. You need the displayStack to be enchanted.

https://mcforge.readthedocs.io/en/1.15.x/items/globallootmodifiers/

If you use @Object holder, the field needs to be final and null, so you can't assign a value to it like you are.

All of these methods are pointless, just call setRegistryName instead of calling a wrapper function that calls one line of code. https://github.com/eddie1101/PortalTest/blob/c26623c062770115212536c540219f7abda1091f/src/main/java/erg/voidcraft/common/util/Util.java#L12 All of the declared types of these can just be Block https://github.com/eddie1101/PortalTest/blob/c26623c062770115212536c540219f7abda1091f/src/main/java/erg/voidcraft/common/block/VoidcraftBlocks.java#L10-L14 Also, you haven't @ObjectHolder'd them, so you're not even using the thing you said you are in your thread title. You aren't registering any blocks or items, because you haven't registered your classes with the event bus: https://github.com/eddie1101/PortalTest/blob/c26623c062770115212536c540219f7abda1091f/src/main/java/erg/voidcraft/common/Voidcraft.java#L40 (You also aren't using the @EventBusSubscriber annotation) Or the @SubscribeEvent annotation: https://github.com/eddie1101/PortalTest/blob/master/src/main/java/erg/voidcraft/common/block/VoidcraftBlocks.java#L16

GUIs haven't changed much in quite some time. The only major differences you probably need to be aware of (aside from methods and classes getting new names, eg. GuiScreen -> Screen) is that Slots to handle items still point at vanilla style IInventory rather than Forge's ItemStackHandler capability. But Forge has also supplied a SlotItemHandler (ItemHandlerSlot? I'm looking at my older 1.14 code and that name might've changed too) which accepts an ItemStackHandler and does all the things it needs to to give the proper behavior.

someTE.getPos()

Example: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/item/ModItemTier.java

I'd say "look at the available methods, one probably makes sense."

I used Curves to show the pixels with boosted values. Here's the histogram, you can see some tiny bars in the lower left. In pulling the anchor on the curves panel over I can make those values more apparent.

canContinueUsing is the wrong method. The first, the very first, thing you need to do is create your own Item subclass.

Because some of the pixels are transparent, but not completely transparent. So the game thinks you should be able to see through the item.

There's also the various block tags. There should be one for logs and another for planks.

DeferredRegister is the other way.

Cool. Then yeah, the above looks like the right thing. I haven't done a lot of entity based loot stuff, just piped the funcs around to call the GLM system.

This would work if the entity being passed is the bobber. If its the player, then it won't.

I'd have to dig into this myself, but I'd start with finding the logic that gets the fishing loot table (probably in the fishing rod, but not sure) and check what parameters it passes in to the LootParameters object and how it calls the LootTable functions. Basically check the logic and see what you can find and what sorts of discriminators you can extract from that info.

That said I'm 99% sure that the player is passed as a loot parameter and you could query their main hand and its item inside doApply. (For that matter you might even be able to write a custom ILootCondition). D7 is right about doing what you want to do, but it occurred to me that someone might not want to change the harvest level (i.e. can still harvest) but instead discriminate results based on the harvest level (e.g. dropping cobblestone unless you're using a diamond pick, then drop smoothstone).

https://www.geeksforgeeks.org/overriding-in-java/

...8?

THERE ARE MORE VALUES THAN 0 AND 1. I even told you, twice, what to look at. Here's a big blindingly stupid hint: The value returned from getOpacity is subtracted off the current light value in order to determine how bright the next space is.