Draco18s

I know Forge does some of this stuff to make Capabilities work on vanilla inventories, but I can only find such for the Hopper right now. https://github.com/MinecraftForge/MinecraftForge/blob/1.16.x/src/main/java/net/minecraftforge/items/VanillaInventoryCodeHooks.java But basically you have to wrap the IInventory in an ItemStackHandler instance that acts as an intermediary.

Local play has both a ClientWorld and a ServerWorld via the IntegratedServer.

You need this. Not sure what the Mojang mapped name for the method is. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/block/AxelBlock.java#L61

ItemStack#getCapability

NBT is for saving data to disk, not for runtime storage.

Capabilities

Also why are you building a new loot table every time? Either: a) build the loot table once and store it in a field b) don't use a loot table at all and just go "derp, I can ask for a random integer from 0 to 1 and if 1 add a new item stack to the generated loot list." Because the loot table you're building is overkill for what you need. c) put that loot table stuff in the loot table json file and deserialize the details so datapacks can override it

Wow, so you grabbed the broken code from the older thread and didn't read the solution!?

If you want to change a block at a location to be something, you need the BlockState representation of what you want that block to be. You haven't said what you want to happen, just that you want to change the blockstate, so "where you get that blockstate" can't be answered because I could say "Use Blocks.STONE.getDefaultState()" but if you didn't want to change the block at the targetted location to stone, that wouldn't be useful, now would it?

Ah yes. I wondered if this was the case. You're trying to change the weather using a GUI screen. https://github.com/NoEffort/NuggetMod/blob/main/src/main/java/me/noeffort/nuggetmod/client/screen/WeatherPedestalScreen.java#L82 That code cannot and will not ever work because only the client knows about it.

Seeing as that logging isn't coming from the block, I can't say. You only shared your block code and the problem isn't in your block code.

There's nothing wrong with your block class. The reason you're seeing the difference is because there's two threads: the server thread and the client thread. Notice at the left how it says "Server thread" and the next line "Render thread"? You have a synchronization problem.

Making bedrock breakable with the right tool: There are events for this, iirc. I forget exactly, but BreakSpeedEvent is one.

Post the log file?

Note that enchanted books call a different method. You'll want to prevent that as well.

Global Loot Modifiers

Ah, there it is. I was having trouble tracing my way through your code to the right class. This may be your problem: https://github.com/skiprocks999/ElectrodynamcisExperimental/blob/3170c78e673ea81faf0e83d0d8d5b56862607965/src/main/java/electrodynamics/common/recipe/categories/o2o/O2ORecipe.java#L42-L45

As far as I can tell, your recipe serializer class isn't. That is, it's called a "recipe serializer", but it doesn't actually perform the required functions. Namely having the Read and Write methods defined by IRecipeSerializer to actually serialize and deserialize to/from json.

You mean this part? Then why did you annotate the class for automatic registration if you were just going to fuckoff and register its only method manually?

Your event handler method will not be called because it is not annotated with @SubscribeEvent

Ah yes, it is a newly spawned thread. I just saw the Thread.sleep part of things, because that's so commonly suggested and/or tried and "didn't work."

Your mod is a data pack. Your data files go in src/main/resources/data/<modID> https://github.com/Draco18s/ReasonableRealism/tree/1.14.4/src/main/resources/data Any datapack can place overrides in the same modID directory and Forge will override as expected.

event.getEntity()? maybe event.getLiving() Might have a different name, but as it is a subclass of EntityEvent (or LivingEntityEvent) it will have a reference to the relevant entity or entities. Take a look at the class and see what fields it, and its various parent classes, are available and what getter methods expose them.