Leaderboard

No. No capes. Mojang explicitly stated that modders should not mess with capes. Adding backdoors to your mod is also a bad idea. In addition, putting the cape code in post init makes no sense. Post init occurs when the game launches; it doesn't do anything about how a player is rendered.

I highly doubt that, considering the 1.13 tutorials that people are making now still continue with those outdated practices like static initializers that should've been gone by now and with the new loading system are causing a ton of issue. So yeah, the issues I saw: https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/BlockBase.java Block/Item/WhateverBase is an antipattern that abuses inheritance. Don't use it, you don't need it. There is already a BlockBase, it's called Block. If you want to set common data of your block don't abuse inheritance, use a helper method. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/util/interfaces/IHasModel.java IHasModel is a bad practice, drop it. Not only do you not need it at all, you actually end up writing almost 3 times as much code using it compared to the amount of code you would write without it. I have no idea why everybody got so attached to this stupid thing. Oh well, at least 1.13 practically killed it with automatic item model registration. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/CommonProxy.java A common proxy makes no sense. Proxies exist to separate sided-only operations, if your code is common it goes anywhere else but your proxy. Even besides that I would say that if you need to use a proxy for an operation common executing code is not possible at all. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/CommonProxy.java#L18 This makes no sense. On a server that would just return you the english translation. On the client you can use I18n directly. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/proxy/ClientProxy.java#L23 Don't make your proxies into event handlers, that invalidates the whole purpose of a proxy - a class that would only be loaded on the respecive physical side. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/Duelcraft.java#L76 A CommonProxy is bad enough, but having it as your ServerProxy makes even less sense. Server proxy executes the code that would crash on the client with ClassNotFoundException. This is the opposite of common code. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/init/ModBlocks.java Don't use static initializers for your Registry entries ever since you can't control the loading order of those classes. It WILL mess everything up at some point. Registry entries must be instantinated in the appropriate registry event. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/tileentities/BlockTileEntity.java#L14 I don't understand the point of this class at all. Just override Block#hasTileEntity and Block#createTileEntity in your block classes. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/blocks/tileentities/TileEntityPillar.java#L58 Don't "request a sync" from the client ever. The server knows perfectly well when to sync and what to sync, the client shouldn't have a say in this at all ever or it will be abused by malicious clients. Override TileEntity#getUpdatePacket, TileEntity#getUpdateTag, TileEntity#onDataPacket and TileEntity#handleUpdateTag instead. https://github.com/Mekelaina/Duelcraft/blob/master/src/main/java/com/mekelaina/duelcraft/util/handlers/RegistryHandler.java#L37 This is too early to add new entries to the ore dictionary, and if you would look at the output log of your game as it starts up forge tells you that with a bunch of errors already.

*Referenced @SideOnly literally deletes the code on the other side. If you have a reference to it that isn't also covered by @SideOnly (even if its never called!) the JVM will say, "Whoah boy! You've got a method call in this class that isn't valid!" and terminate.

Oh, and for reference, Forge doesn't even have to instantiate the class in order to get a ClassNotFoundException the way you have. Simply by telling the JVM that your client sided packet handler exists is sufficient. Because the JVM goes "I have to load this class, I don't know when--or indeed if at all--any given part of it will be executed, so I'm going to check that all of it is valid. To do that I need to make sure any additional classes it references are ones I can find, just in case I need to load them in the future. Oh what's this? I see a reference to EntityPlayerSP, I don't know what that is or where it find it. Crap."

What you are asking to do is very specific, thus I doubt there will be any tutorials out there. However, mods like MeeCreep do have entities that chop trees; I would suggest checking out its source: https://github.com/McJtyMods/MeeCreeps.