Draco18s

Probably make it extend the class that already controls the trident.

Don't use the Crafting manager. Wait for the Register<IRecipe> event and access the registry then. I built an entire helper class to handle this sort of thing. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/RecipesUtils.java#L105

Yes.

BlockPos p = e.getPos()?

1) You need to implement the ItemMeshDefinition interface. Here's an example: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L89-L118 2) You need to register it, here's an example: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L185-L195

Have you tried looking at the net.minecraftforge.eventbus package? Also, christ that video is a terrible demonstration. The only time you could see the keyboard light up is when the room lights were off. The only time the keyboard did fuckall is when the room lights came on...

Such a guide does not exist. This is all I know: https://gist.github.com/Barteks2x/41122efc766afdd47aeb457a3c19b275#gistcomment-2989342

Crash Course in block states: You know how torches sit on different sides of a block? You know how dispensers can face in different directions? You know how there's grass and snowy grass? You know how there's both sand and red sand? You know how fences connect to each other in different directions? All of those things are block states. States of the block that define some behavior, be it a different texture, model, or behavior. Metadata is the underlying implementation of how blockstate information (which is complex) is saved to disk. Some states (like fence connectivity) is not saved as it is a property that can be determined by looking at the world. 1.13 The Flattening removed all "its actually a different block" states, so Red Sand is now its own block, rather than a "variant state" of Sand. Same goes for the 16 wool colors (and their associated dyes and the fact the dye and the wool metadatas were mirrors of each other for no god damn reason).

Huh, I wonder what these numbers do.

You also need to invalidate them when your TE is removed: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L174-L179

1.7.10 is so fucking old no one knows or cares any more. It was released June 26, 2014, over five years ago.

Don't run the forge-server.jar and run server.jar instead? Download a replacement server jar?

Don't do this. Flatten your items.

Yes, I understand. Look at what that method does. I didn't say "invoke the method" I said "look at what it does."

Also look at the Block#getPlayerRelativeBlockHardness method (and the ForgeHooks.canHarvestBlock method it calls). You'll probably want to perform similar checks to see if the break speed you got from the event is greater than what you'd expect from an empty hand, and allow that, otherwise cancel it. There's probably a better way than comparing the speeds, but this is where I'd start.

As an example: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java#L115-L136 Do note two things: 1) the block will disappear and pop back into place on the client because the client assumes that all blocks when broken stay broken (and the chunk update packet arrives a fraction of a second latter correcting that notion). 2) if your block generates any drops you'll want to spawn them in an adjacent block or weird stuff will happen (if there are blocks above yours, those drops will vibrate their way upwards to the "surface" even if its 30 or 40 blocks). You can see how I did that here. There's no attempt to make sure that the space is as close to the player as possible, just looks for a non-solid spot to put them (and there is guaranteed to be one because the block was harvested somehow).

Yeah, that was the thing I definitely did *not* want to do. I was afraid that that was the alternative. I don't particularly like that much either, but it would work and be more flexible.

Your error is caused by a File Not Found Exception, meaning it is either in the wrong place, has the wrong name, or your resources haven't been refreshed/cleaned and your IDE doesn't know it is there.

ForgeRegistries.THING_TYPE.getValue(new ResourceLocation(domain, name));

This is literally the best I have right now and its disgusting. AbstractFurnaceTileEntity furn = (AbstractFurnaceTileEntity)te; furn.setInventorySlotContents(0, stack.copy()); IRecipe<?> recipeIn = null; if(furn instanceof BlastFurnaceTileEntity) { recipeIn = this.world.getRecipeManager().getRecipe(IRecipeType.BLASTING, furn, this.world).orElse(null); } else if(furn instanceof FurnaceTileEntity) { recipeIn = this.world.getRecipeManager().getRecipe(IRecipeType.SMELTING, furn, this.world).orElse(null); } else if(furn instanceof SmokerTileEntity) { recipeIn = this.world.getRecipeManager().getRecipe(IRecipeType.SMOKING, furn, this.world).orElse(null); } else return false; return (recipeIn != null && !recipeIn.getRecipeOutput().isEmpty()); Any suggestions?

Create your own and muck about replacing the ore generators IMO.

We're not java school. If you want to learn java, that's fine, just don't do it here.

Minigames in the context you are referring to are managed server side. Bukkit does this with plugins (serverside only mods). You can also do it with command blocks. But regardless, they're managed from the server side, like all non-input systems (the client is a lying cheating bastard). Forge mods can be for one side only, but are typically used on both sides (as without the client's involvement, you can do new items, blocks, and such).

I don't know what, precisely, you need to do as it entirely depends on what effect you are trying to achieve: are you trying to do this client side only? I only posted because I knew what hadn't been done. Please do not PM me, if I had any further insight I would have posted.