Draco18s

Don't modify a collection that you are itterating over. Also. Post your code.

Blocks have states. Those states contain extra information. Like what kind of stone the stone is. Polished diorite is a variant of minecraft:stone. Also, stop using getFromName and just use the constants in the Blocks class.

Blocks use loot tables now.

That looks like JSON, so I would probably put it in one of the two JSON files. This is Java and would go in the block class. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/block/BlockSifter.java#L40-L54 Things have changed a bit in 1.14 (one of those methods is gone)

Ok, now I see what you mean. The "picture that's worth 1000 words" only works if there's an obvious problem or a freehand red circle around it. Personally, I'd say screw it and not worry about it. Its minecraft, it has a blocky aesthetic. I'm not sure how to go about handling this.

Yes

Show your code. Preferably as a working github repo

Because Enchantments are registry objects you should be always registering all of them all the time. You will need to find a different way of preventing them from being used.

You don't. It's generated internally based on the texture.

Ok, what do you mean by "smooth"?

Remember: The Client is a lying, cheating bastard. Never trust the client for anything. There is no way to insure the integrity of the client, for any message the client sends can be faked.

1) The energy stuff is only calculated on the server, so you need to either send the information or the calculation to the client 2) Use packates 3) To display the information you need a GUI

The @Mod annotation in the mod's source code. If you are not a mod-maker you are in the wrong section of the forum.

And probably more. Remember, both are written in Java and the only limitations are those where there aren't API hooks. Forge has different hooks than Bukkit, but the overlap is pretty close to Forge having everything Bukkit does, and probably some extras. Because Forge is open source developed, anyone who needs a new hook can write a pull request to get that hook added to Forge. Doesn't necessarily mean it will be approved, but in my experience Bukkit is rather static with the opinion of if Bukkit can't already do it, then it isn't needed.

And what if they have a mod installed that falsely reports what mods are installed?

No. Use the debugger.

You're running in a dev environment, which is not using a valid Minecraft account, on a modded game, and therefor is not allowed to connect to official Realms servers. So stop caring about it because you're not going to be joining Realms anyway.

ManaStoneContainer, ManaStoneTile, and ManaStoneScreen are not blocks and should not be in your blocks package. They should be in inventory, tileentities, and client.gui respectively. https://github.com/Cleardragonf/AsuraMagica/blob/master/src/main/java/me/asuramagica/blocks/Mana_StoneTile.java#L101-L103 BlockPos.getInBox(...) https://github.com/Cleardragonf/AsuraMagica/blob/master/src/main/java/me/asuramagica/blocks/Mana_StoneTile.java#L150 1) you can just make the field a CustomEnergyStorage in the first place so you don't need to cast 2) you shouldn't have "add fire energy" as a separate method from "add water energy" on your custom energy storage as you already separate them by using different instances 3) What, if you're "adding fire energy" as your singular method name, its named wrong. And now on to your requested problem https://github.com/Cleardragonf/AsuraMagica/blob/master/src/main/java/me/asuramagica/blocks/Mana_StoneTile.java#L249 Because all of your energies are all the same ENERGY capability you can't distinguish which energy you return from GetCapability. Either: 1) make a new capability 2) use a custom energy storage that stores all four as independent variables I recommend #1, as #2 will require an assumption when dealing with energy systems from other mods (which one is the right type to send over?)

You have to go to the places those interfaces or classes are USED by a class you do know exists. You can't just blindly try and import them, because if their package changed or their name changed, it will fail. But if you go to where that code is USED you can find the new name and package.

Note that you can't modify vanilla code. You can look, but not touch.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#cross-referencing-a-quick-how-to

And that's what causes the behavior. The event--not firing on the client--isn't canceled on the client, so the default (block is placed) behavior takes over and places the block. Then the packet data comes back from the server and says "that space is air" and the block vanishes again.

Inner variants don't exist.

Then you have to have them in your blockstate file alphabetically. variant=east,activated=true does not equal activated=true,variant=east

Gradle > Existing Project